Tuesday, May 22, 2007

AOL supports simple federation with SAMLv2

In addition to the work AOL is doing to support OpenID, we've also been working with SAMLv2 to provide a simple federation profile for our partners. This allows users to federate an account at a partner to an account at AOL so that SSO is enabled from the partner to AOL or vise-versa.

This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.

The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...

  1. User goes to browser and loads site A
  2. User authenticates at site A using the account credentials associated with site A
  3. User clicks on link to partner site B
  4. Site A generates the SSO Assertion for site B using site B's pre-determined federation identifier
  5. Site A uses the http POST method to post the SSO Assertion to site B
  6. Site B validates and verifies the SSO Assertion
  7. User is “signed-on” to site B with site B's federated identifier

Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.

Tags: , ,

Thursday, May 17, 2007

Wednesday @ IIW 2007

Thankfully Wed. was not quite so intense, at least for me. The main items of interest for me were a review of Pythia (a reputation system that Phil Windley has been working on), the results of the OSIS interop event, and a discussion about user experience and identity.

Pythia
Phil Windley lead a session on the reputation system (pythia) he's been working on with his graduate students over the last year and a half. The system is based on evaluating transactions between identities. Reputation scores are calculated on a “personal” basis meaning that I can define my own ruleset for calculating reputation that might be different than someone else's ruleset. This, I think, is important because it allows me to value the information I receive about another identity according to my own view of what's important. For example, just because an identity has a great reputation within the drug culture doesn't mean that I want to ascribe a high reputation to them. Reputations are very contextual and I ascribe different levels of value to the different contexts.

In a very concrete example, there was a fair amount of discussion by relying party implementors (both during and after the session) about how to get transaction data (i.e. initial reputation) when a new identifier shows up at their site. The basic question being, is there a way for a relying party to know whether they can “trust” the 3rd party OpenID to be a genuine user. If there was a way to convey transaction data such identifier creation date, date of last use, number of “publish” transactions (meaning blog posts, comments, etc) then RPs could make a much better decision on whether to just let the identifier use their site, or whether they need to do some additional “verification” of the user. In this specific case there is immediate value in identity providers providing some additional attributes about the identifier that relying parties can use to make business decisions. For OpenID this probably means adoption of the Attribute Exchange extension or some additions to SREG.

OSIS interop event
I didn't participate in the OSIS event but was interested in the issues that arose from the event. Being an “outsider” it seems that while a number of issues were found, over all the event was a success. I think a next step is to get more RP's and IdP's involved especially where RP's are bridging identity meta-systems. Things like namespace mismatches, claim mismatches, and certificates are small hurdles that can easily be fixed.

User Experience
This was a very interesting discussion as it did not focus on computer user experience and UI for interacting online. Instead it was much more about how people use identity in the offline world and how does that map into the online world. One of the interesting points to me is that in the offline world, there is a lot of context available as part of the interaction. These could be visual clues (body language, facial expressions, etc), auditory clues (tone of voice, distance from sound, etc), olfactory clues (smell, etc) and the list goes on. In online social interactions much of this additional context is lost and hence a “distance” in the communication is created. This “distance”, or incompleteness in the context, causes some to feel safe to say anything and others to hold back and mask themselves. As more transactions and social interactions move online, it will be increasingly important for consumers to understand these dynamics. A more complete summary will likely be appearing on Heather's blog.

Tags: iiw2007, Reputation, OSIS, Offline Identity

Wednesday, May 16, 2007

Tuesday @ IIW 2007

Tuesday was a very full day at IIW. The sessions I attended are listed below with a brief summary.

AOL OpenAuth -- Overview
Srinivas Lingutla from AOL gave an overview of the AOL OpenAuth API's and discussed the differences between the OpenAuth capabilities and existing OpenID authentication. The key additions of OpenAuth are the ability to retrieve a “security token” that represents the authentication and can be used in a back-channel way with other AOL services (e.g. instant messaging), and the consent model that is structured around the use of the “security token”.

HTTP binding for identity web services
This discussion was intended to gage interest in a standard framework for invoking identity based web services using HTTP as the core binding. The focus being support of browser based applications that make use of AJAX and XSS. The session was not well attended so the group present ended up covering many different issues relating to HTTP based invocation of services. John Panzer from AOL discussed some work he's done extending the HTTP support for authentication and authorization to support authentication use of ATOM/APP interfaces. There was some consensus that for REST based API's extending the existing HTTP mechanisms is the best solution. For AJAX based applications, this method does not work well so another method is required. I discussed the simple framework that AOL has defined for its Open Services APIs (e.g. Web Instant Messaging). We also discussed a couple of different invocation models that can be used (front-channel based vs back-channel based) with HTTP.

Rich Client Authentication
In this group we discussed the issues around allowing device specific applications (i.e. not a browser) to authenticate the user and then invoke identity based web services on the user's behalf. From the client developer perspective, the general consensus was that they didn't want to deal with implementing this and would rather the environment provide a consistent API that could authenticate the user and return the appropriate token. Of course this sort of just pushes the problem to a different layer. One idea was to look at OSIS and Cardspace as possible client side systems that could be used to do the authentication though this requires the user to adopt a new model of authentication. It is not clear to me how long that sort of user “training” is going to take.

Another aspect of client authentication is the desire to provision the authentication credentials in such a way that they are specific to the device. This way if they are compromised, they are not valid outside the context of the device. One solution here would be to use PKI provisioned through some “installation/setup” step. What that would be was not discussed, though one could use the Liberty Alliance Advanced Client specifications if willing to implement SOAP web services.

OpenID Token Exchange extension
Srinivas Lingutla also did a session on a proposed extension to OpenID that will allow relying parties (RP) to request an authentication token from the OpenID Provider (OP) at the time of authentication. The token can then be used to access identity based web services. AOL has implemented this proposed extension and demoed it during the “speed geeking” session on Monday by using an AOL OpenID to launch a buddylist using the AOL Web IM APIs. There were a number of questions around how to support different token types (simple support already present in the proposed extension), and whether some level of application id (or provider id) is required. The next steps include evaluating the other related proposed extensions and seeing if these can be combined into a single extension to support token request and validation. The proposed extension should be posted to the OpenID list/wiki in the next week or so.

What's broken with OpenID 2.0
Dick Hardt led a session on what is broken with the existing OpenID 2.0 spec. I'm sure the details will be appearing on his blog in the near future. The session of course grew beyond just what is broken to business issues and next generation feature requests. It was a very lively discussion. The “really broken” things were tackled during sessions on Wed. At the closing session on Wed. Dick promised that the 2.0 specification would be ready “real soon now”.

Tags: iiw2007, OpenAuth, OpenID

Tuesday, May 15, 2007

Identity issues at IIW 2007

Something “new” happened at IIW 2007 yesterday. Instead of the normal “state-of-identity” talks and “introduction to the issues”, Monday afternoon focused around “speed geeking” and collective identity issues. We divided into groups and each group came up with a set of issues that they felt were important. Kaliya collected all the different issues/questions into a mind map (picture of it came be found here). Other summaries can be found here and here.

Of noticeable interest to me was the commonality of a lot of the questions/issues.
  • privacy
  • trust
  • reputation
  • delegation
  • user experience
  • interoperability between identity systems
  • identity relationships (parental controls was brought up and not by me:) )
  • and the list goes on
These issues are at a different level that just figuring out how the technology will work to do SSO or authentication. It should be a good conference.

Tags: iiw2007

Wednesday, May 09, 2007

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