Technology convergence or seamless integration?

A while ago I wrote that users want convergence not interoperability. I still hold that this is true, however “convergence” in this case, is “convergence of the user experience” not necessarily the technology. Paul describes the issues very well in his recent post. For users, the experience has to be that using one identity meta-system is all that is necessary to interact with the entire set of services on the web. Forcing a user to know about which meta-system is needed for which online services will never succeed. This means that the industry has to solve the problem somehow “under the covers”.

I applaud Sun's entry into the OpenID space. However, I disagree with some that this will lead to technological convergence. The existing meta-systems are too entrenched in their existing deployments to change to something new. Some believe that convergence will come through domination of a single protocol, but I have a hard time excepting that. So that leaves determining how to interoperate between the different identity meta-systems.

I don't think this is unsolvable but it will likely NOT be simple. There are issues with token exchange, token transformation, provider discovery, etc. With a number of good choices for back-channel web services (WS-*, ID-WSF), front-channel communication (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...), and SSO (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...) it seems the time has come for the industry to slow down the spec development work and instead focus on seamless interoperability.

Here are some starting use cases...

1. User uses Cardspace to authenticate to a picture services that uses ID-WSF with it's billing partner(s)
2. User authenticates with her college library using SAML and then wants to SSO into zooomr.com
3. User users OpenID to sign in to their favorite hiking site which wants to display their buddy list as part of the site experience

Tags: Convergence, Interoperability, OpenID, SAML, ID-WSF

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