Updated: Pat points out I forgot SAML 'Lightweight'. Added below.

Eve Maler and Pat Patterson, both at Sun, have been spending quite some time contemplating (and coding!) where SAML and OpenID meet. Or where they could meet. Or where they should meet. While it probably will be some time until the final word is spoken, it's great to see progress! Repeat after me: "Standards wars are bad. Multiple right, converging answers are good!"

In a bit of blog ping-pong, Eve picks apart ;-) my responses to her previous post. Of course, I can't leave this unchallenged ;-) She writes:

I suspect the world doesn't have enough aggregate experience yet to know how people will use their (one or more) identifiers; the promise implied in the notion of having many URL-based identifiers governed by oneself hasn't been thoroughly explored yet.

That's very clearly true at this point. While OpenID keeps growing impressively, there are many, many things we don't know yet, in particular with respect to how average people (non-techies) are going to make use of URL-based identity. (Some of this keeps coming up in the context of the OpenID User Experience discussion that was recently started and that was already featured in a podcast, with more to come.)

She goes on to describe that one actual identity (of me) can be managed by several, independent identity providers (which may not be sure they all talk about me), each of which can expose several different subsets of the information about me to relying parties. This is an interesting way of looking at what's emerging here. I'd only add that one IdP might accept assertions from another IdP, e.g. in order to reuse their strong authentication. In that case, some of those IdPs can correlate me for sure (e.g. because I want to do single-sign-on across identity providers), but that's just a bit more icing on the cake that she describes.

Then, on one hand she's of course correct to assert, on identifiers:

But I see no structural reason for it [the identifier] to be a URL; the RP can get it from the IdP as part of the exchange of identity verification information. (This is, in fact, how SAML does it when a pseudonym is requested.)

However, that would only allow us to address use cases where this identifier never needs to be dereferenced. (That may be all use cases Eve, or anybody, is interested in.) As a very simple example for a use case where having URLs instead of other handles is substantially more useful is the following:

Consider using SSO with a community site. Using a non-URL as an identifier, Eve could log onto this site just fine, and the site could mark all of Eve's posts on that site with Eve. However, that leaves me, a casual visitor to the site, quite in the dark about Eve. Specifically, it doesn't help me to find out more about Eve, if I wanted to (and Eve wanted to give me that opportunity). If she had authenticated with her blog's URL, on the other hand, then it is trivial for the community site to show Eve instead of just Eve, and suddenly I get context, because I can click on that link. Getting that context — just like the context HTML links provide anywhere, compared to traditional "stovepipe documents" — is so fundamental for many identity-enabled activities on the net, we thought identity technologies should be built on that foundation when we came up with using URLs for digital identity. This is, in my mind, where Web 2.0 and identity meet: context beyond stovepipes.

Pat has been burning the midnight oil on code that will actually get SAML and OpenID closer together, starting with the notion of using a URL as identifier with SAML. I'm trying to talk him into using Yadis for discovery, marking a URL as valid SAML identifier with a variation of the following XRDS (aka Yadis) file:

<?xml version="1.0" encoding="UTF-8"?>
<XRDS xmlns="xri://$xrds" xmlns:xrd="xri://$xrd*($v*2.0)">
 <xrd:XRD>
  <xrd:Service>
   <xrd:Type>urn:oasis:names:tc:SAML:2.0:metadata</xrd:Type>
   <xrd:URI>http://saml-idp.example.com/</xrd:URI>
  </xrd:Service>
 </xrd:XRD>
</XRDS>

Imagine if you could use the same URL for authenticating:

• with OpenID Authentication (which is light-weight, Diffie-Hellman key exchange-based)
• with LID/GPG Authentication (which is light-weight, public key-based)
• with SAML 'Lightweight' (which is only a little bit heavier and uses a simple 'blob' signature)
• with SAML (which is a bit heavier and uses XML Signatures)

with the same user experience, and without having to know at all which protocol was actually used... But then, isn't that exactly how digital identity on the open internet has to look like?

I'm looking forward to discussing SAML and OpenID convergence more next week at the Internet Identity Workshop. Hope to see you all there.