Discovery, wherefore art thou Discovery?

The web seems "a buzz" these days with different flavors of "discovery". I've recently been hearing more and more need for Personal Service Discovery. This is coming from both internal and external customers. Two key questions are asked. (1) What is the user's preferred service? (e.g. picture service) and (2) Where is this user's specific service located. The two questions are not mutually exclusive. What I find quite humorous is that the Liberty Alliance has had a "Discovery Service" for quite some time that is capable of answering both those questions (and others). I wish I had Paul's witty way of poking fun... but alas I'm not that talented.

Here are a few recent proposals for "Discovery" services. I'm sure there are many I'm missing...

• XRI Resolution -- a mechanism for describing and querying personal service endpoints (among other things)
• XRD Provisioning Protocol (XPP) -- an XRI based mechanism for Service Providers to attach their service to a user's individual XRDS file hosted by the user's IdP
• "DHCP for Identity" -- "As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen tools or vendors."
• Dynamic Federation -- service provider metadata is discovered via transformation of a user identifier
• OAuth Discovery 1.0 Draft 1 -- This is really "service provider metadata" that is "discoverable".

Interesting to me is the leveraging of XRDS as a containing structure for describing service metadata amongst a number of these proposals. Anyway my hope is that as an industry we leverage all the work that has already been done while looking for ways to make things easier for users and developers.

"Standing on the shoulders of giants" comes to mind.

Tags: Discovery, Liberty Alliance, XRI, XRDS, OAuth

"Schooled" again...

I'm here in Tokyo for a Liberty Alliance meeting of the Technical Expert Group. This noon we had a "pick-up" soccer (football to the rest of the world) game. Not being in the best shape our TEG co-chair made quick work of our challenges on the field:)



Here are some less incriminating pictures from the event.



Many thanks to Mikko Laukkanen for taking the pictures.

More pictures by Phil Hunt found here. I'm sure more will be appearing shortly.

Tags: Liberty Alliance, TEG, Soccer

AOL releases OpenAuth

As has been blogged by Praveen Alavilli and John Panzer, today AOL released a set of http-rpc based API's for authenticating AOL identities and leveraging that authentication to access AOL services. These API's fill a niche in the existing http based web protocols by supporting the concept of authenticated service access and user consent. As many web based applications move to an AJAX model, being able to expose identity based services in a user-centric way becomes very important. Hence the importance on user consent for access to a user's data by a 3rd party application.

There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).

The basics for web developers are...

• Provisioning

1. Get a provider id (called a developer key)


• At runtime

2. Request an authentication token

• requires both authentication and consent from the user before returning the authentication token

3. Invoke AOL identity based service

• requires user consent (can be remembered) before returning requested data

Much more detailed documentation is available at http://dev.aol.com/openauth.

Full disclosure: I work for AOL but not directly as part of the Authentication team.

Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF

Provisioning identity to mobile applications

Not to long ago I decided to try and set up the instant messaging client on my cell phone. I dutifully went through the painful process of entering my authentication credentials (loginid and password). However, when I got to my password, I couldn't find one of the characters in my password using the phone character entry system. This was rather frustrating and I gave up using the instant messaging client for a while. Later I tried a different account where I knew I could find the characters for the password and the mobile application worked.

This got me thinking that there has to be a better way to provision the identity to the phone for use with mobile applications. One possible process flow would be...

1. User authenticates to web site of mobile application provider
2. User enters their phone #, and carrier to the web site
3. The web site sends a code to the phone
4. User receives the code and enters it into the web site
5. The web site generates a unique set of authentication credentials for the phone
6. The web site sends a binary SMS message to the phone with the mobile application identity configuration
7. User starts up mobile application and is automatically authenticated

This should all be doable with today's technology. Of course, the next step would be secure provisioning of multiple identities for the device, where the identities are consumable by multiple applications. For this, the Advanced Client work underway in the Liberty Alliance should help.

Tags: Identity, Mobile, Instant Message, Liberty Alliance

Users want convergence, not interoperability

Paul Madsen has a great post today regarding the permutations that must be supported to allow for interoperability between the different identity systems. A meta-system framework is great, but implementing it can be a big problem. Interoperability is a great first step but it can not be the end goal.

Stopping at interoperability has some unfortunate consequences for each of the parties in the identity transactions.

Identity Provider: Must implement multiple protocols. This isn't so bad for IdP's because there are relatively few of them and they can get a fair amount of value for their effort because it means more people will want to use their IdP (why Paul selected ProtectNetwork over AOL).

Relying Party: Must implement multiple protocols based on the services they provide. This is much more invasive because there are a lot more RPs than IdPs. Getting lots of RPs to support multiple protocols will be difficult unless it is made extremely easy through available toolkits. Developers (people?) are inherently lazy and spending time writing the equivalent of a TCP/IP stack by hand is not something they want to do. You can also apply these same consequences to web service providers.

Users: Must have multiple identities from different IdPs and know when to use them. This is the one that will kill the internet identity layer if we don't figure out a way toward better convergence. Here is my reasoning (corrections greatly appreciated)...

• Web site will need to implement multiple identity systems in order to take advantage of services available on the web
• Supporting multiple identity systems means that the bootstrap problem must be solved (how to exchange my OpenID authentication for a WS-Trust binary security token)
• Solving the bootstrapping problem is most easily done at the IdPs
• Not all IdPs will support all the necessary bootstrapping mechanisms
• Therefore, users will need to have identities at the "right" IdPs in order to use certain web sites
• Those web sites will have to figure out how to inform the user that their single-sign-on identifier doesn't work at their site.

As we work toward convergence, we need to be mindful of the impacts on users. If we don't make it easy for them, the coolness of the technology doesn't matter.

Tags: Identity, Convergence, Liberty Alliance, OpenID, Cardspace