Identity as an Attribute

A while back I posted a couple of entries on the concept of an identity token. The idea being that a client/requester/relying party could request an identity token from the Identity Provider (IdP) when authenticating the user and then use it when accessing protected resources to represent who is making the request. This becomes very important in person-to-person sharing use cases.

One such use case that recently appeared on the OpenID specs listserv is the need to access protected <Link> elements in a user's XRD/JRD. For example, I want to allow family members to be able to discover my family photo albums but keep those links restricted from public access. The basic need is that the requesting client/service needs to "prove" to my XRD provider that they are a "family member". A very easy way to do this is for the requesting client/service to obtain an "identity claim" from the family member's identity provider and pass that along to the XRD provider. This of course would most like be in the form of some structured OAuth token.

Thinking about it this way, the user's identity is really just a 3rd party asserted attribute. 3rd party because the client is the 1st party in this scenario and will be the entity presenting the attribute to other services.

This concept of 3rd party asserted attributes is not new. There have been many discussions and posts about how to obtain an "over 18" attribute from the DMV and store it in the IdP. What makes representing the user's identity different in this case is that often, the user's identity is the key that gets them access to their resources. Thus, this identity attribute has to be recognized as just a verified identifier (i.e. like relying parties want a verified email address) and not some sort of authorization token.

My one concern has to do with whether 3rd party asserted attributes should just be bearer tokens? or whether they need some holder-of-key mechanism to ensure that only the client that is issued the 3rd party asserted attribute can present it in future requests.

Previous posts:

Protecting "discovery" information?
Open Identity Token
Open Identity Token and Personal Discovery Service (Praveen Alavilli)
Continuing the discussion...

Identity, Token, Sharing, Attribute, OAuth, XRD

Protected Sharing on the Open Web

One feature I have wished for on the web for quite some time is the ability to securely share family photos with my extended family and close friends. Currently, all photo sharing sites (that I’ve been able to find) require all parties to have an account at that photo sharing site in order to securely share the photos. Note that I don’t want the current solution of “security-by-obsecurity” where a big random URL is created and emailed to the group.

I think we can build a much better sharing environment using existing and emerging specifications like OpenID, OAuth, Portable Contacts and XRDS-Simple. Here is a use case and one way it could work.

I have an account at flickr and I create an album (flickr set) that I want to share with my extended family. Previously, I’ve associated my flickr account with my plaxo account (using OAuth) to enable flickr to access my contacts (via “Portable Contacts”). Flickr needs to use XRDS-Simple to find my “portable contacts” service and OAuth discovery to set up the connection between the two services.

1. I tell flickr I want the new album (“Family photos”) protected and shared only with those people in my contacts lists that are labeled as “Family”.
2. Flickr marks the album as “protected” and remembers that those allowed to view the album are anyone who is a member of my “Family” tag at my “Portable Contacts” service.
3. I send out an email to my family members sending them the direct URL to the protected resource (note that flickr could also do this for me since it has a connection to my portable contacts service).
4. A family member receives the email and clicks the URL to the protected album at flickr
5. Flickr recognizes this is a protected resource and returns both the OAuth information for how to access the protected resource as well as HTML telling the user that the resource is protected and the user needs to authenticate
6. The family member logs into flickr using their OpenID (not currently supported)
7. Flickr takes the OpenID and asks my “Portable Contacts” service whether this OpenID has a tag of “Family” (basically a membership query; see previous post)
8. If the user's OpenID is a contact with a tag of “Family” then they get access to the album, otherwise they are denied

What’s currently missing to make this a reality are...

• Relying parties accepting OpenIDs
• Users knowing they have an OpenID and using them
• Portable Contacts adding “membership” type APIs
• Portable Contacts supporting an explicit 'urls' type of 'openid'
  

In finalizing this blog post, I read David Recordon's summary of the Portable Contacts hackathon held last night. The following quote shows this is very near reality, Yeah!

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth. Finishing the flow, his demo site uses the Portable Contacts API to access information about his contacts directly from Plaxo. End to end, login with an OpenID and finish by giving the site access to your address book without having to fork over your password.

Tags: OpenID, OAuth, XRDS-Simple, Portable Contacts, Sharing, Access Control

Tagging for contacts

Has any one else had this problem? You need to IM someone and you can't remember which group you filed their name under. I realize that if I just kept an alphabetized list, and I remembered their name this wouldn't be a problem. However, sometimes it not that I’m looking for a particular person, but someone on a particular team.

Basically, what I’ve found is that I want to attach “tags” to my contacts that describe attributes about that person. Then I can find people by my own “folksonomy” whenever I need to. This would allow me to “query” my contacts (or IM client) by a “tag”. So I could say, “Show me all the architects at AOL that are currently online?”. It also allows me to do queries like “Does Bob have an ‘Extended Family’ tag?”. This is really a membership query and can be thought of as “Is Bob a member of the group ‘Extended Family’?”

Combining tags with contact data allows for all sorts of interesting capabilities. For instance, my Adium IM client could query my Portable Contacts service for all contacts with at least one IM identifier present and return all IM identifiers and tags. With this information Adium could auto-create groups, show me a “tag-cloud” of who’s online, etc. Another use would be true access-controlled sharing of protected resources. I’ll have another post on that soon.

With the emerging Portable Contacts specification, I think there is a great opportunity to enable this kind of capability in an open standard. The portable contacts spec already supports both tagging and filtering. What is a little unclear from a quick read of the specification is whether filters can be combined. However it should be easy with this specification to support the queries listed above. For a membership style query, the following should suffice...

/@me/@all?filterBy=urls&filterOp=equals&filterValue=http://bob.example.com&filterBy=tags&filterOp=equals&filterValue=ExtendedFamily

Tags: Portable Contacts, Tagging, Access Control, Instant Message

Protecting "discovery" information?

I’ve been thinking a lot lately about discovery of personal services (e.g. endpoint and metadata of my “portable contacts” service, endpoint and metadata of my preferred “email service”, etc). One problem with enabling discovery of this kind of information is that it leaks information about me. For example, I might not want the world to know where I keep my personal photos?

So the question is... How, in the world of open identity protocols, do I restrict access to a subset of my “discovery” information? The obvious answer is for the discovery service (or service provider in general) to restrict access based on the identity of the invoking party. However, how is that invoking identity presented? At first thought is seems like OpenID and OAuth should suffice, but it turns out this doesn’t work to well in practice.

Let’s take the following example and walk it through.

“Alice logs into her hiking site, uploads a GPS track and photos, and notifies her friends of the new information.”

1. Alice logs into one of her favorite web sites (hikingtrails.example.com).
2. Alice uploads a GPS track and some photos of a new trail she hiked over the Labor Day weekend.
3. At the conclusion of her upload, hikingtrails.example.com asks Alice if it should notify her friends about her activity.
4. Alice thinks that’s a great idea and agrees.
5. So hikingtrails.example.com queries portablecontacts.example.com, using pre-established OAuth credentials, and retrieves Alice’s list of contacts with a tag of “hiking buddy”.
6. Now for each of these friends, hikingtrails.example.com has to discover the “notification” service and send it the new activity message.
7. One of Alice’s friends, Bob, only exposes the endpoint and metadata of his “notification” service to a restricted list of people.

It’s at this point that things begin to break down. How does hikingtrails.example.com identify Alice to Bob’s discovery service so that hikingtrails.example.com can attempt to discover Bob’s “notification” service? There currently isn’t a binding for OAuth to be used with XRDS discovery, and even if there were, it would mean that Alice would have to have an “account” at Bob’s discovery service in order for the discovery service to be able to authenticate Alice and establish OAuth credentials. While this would only have to be done once with Bob’s discovery service, the user experience would have to be repeated with each of Alice’s friend’s discovery service. That seems like over kill for the simple purpose of identifying Alice to Bob's discovery service.

A possible solution would be an “open identity token” that could be created by an identity provider and passed to any service provider. I have some thoughts on this that I hope to expound on in another post.

Tags: Discovery, Portable Contacts, OpenID, OAuth, Access Control