Wednesday, May 30, 2007

More on XRDS

In trying to answer Saronson01’s question I seem to fall into a total flow of consciousness that might make no sense to anyone but me… sorry. I will try to frame this more clearly soon. Keep the questions coming as that is what fuels the fire...

Saronson01 asked

When "adding" services to an XRDS document how are the services used, viewed, etc.? It seems that there is a missing piece regarding how a service is actually "consumed." How would the i-name @images*andy utilize a flickr feed?

Now I think I understand the question.. but if I’m answering the wrong question restate and I’ll try again…

For the sake of this answer I am going to refer to i-names but this is mainly true for any identifier that can be resolved to an XRDS. The reason I say ‘mainly’ is that i-names assume an abstraction between the human friendly i-name and the persistent i-number (canonical ID). The i-name resolution infrastructure supports both trusted resolution and CanonicalID Verification. These are qualities not shared by URLs that resolve to XRDSs. Once we start to use the richness of the XRDS for discovering services other than OpenID for URLs we will have to explore the security implications of these differences.

The simple pattern for XRDS usage is this:

  • I go to some application… it may be a web app or it may be a thick app… doesn’t matter.
  • I enter my i-name into the app.
  • The app knows what service it is looking for so it performs Service EndPoint (SEP) resolution for the service it is looking for and gets back the needed information about that service, where it can be found and how it can be accessed.

The most common current usage of this pattern, today, is to find authentication services, i.e. To enable SSO. In that case the ‘type’ that is looked for is

So to answer your question… why would I put my flickr feed into my XRDS. Here’s my answer…

I create a new Web Application that creates Flash photo albums for use on MySpace… It uses OpenID to authenticate people. A person comes and logs into my new service using their i-name. Once they have authenticated I need to know where to find their photos.. I could ask them, but if they have configured a service of type http://photo.feed/1.0 then I don’t have to ask them I just know… In fact if I know someone’s i-name I can look up their photo feed (just like I can look up their authN service) for whatever purpose I want.

Yes, XRDS is public, so you only want to put services that you are happy people knowing about related to your publicly know identifier.

Putting stuff in the XRDS rather than in AX (or XDI) makes sense when you are happy the information being public and you want the optimization of using a very light weight ‘resolve’ protocol on top of high availability backbone infrastructure.

The SEP schema (part of an OASIS spec) is specifically designed to describe this type of data. Sometimes there is goodness in using well defined, domain specific, schemas rather than abstract ‘can describe anything’ schemas.

Although resolution is designed to be public, we have devised several mechanisms to terminate public resolution in private realms for privacy and security reasons. These are useful for specific use cases.

Using i-names with CID validation and trusted resolution you can authenticate a user via OpenID and then access a service that they have in their XRDS (with the CID as the primary key) with a very high level of confidence that the service is truly related to, or providing information about the entity that authenticated. (Assuming that you trust the service, but that’s a whole other issue).

EZIBroker is in the process of building and rolling out an Age Claims Service that can be associated with an i-name… Any relying party who can provide the right credentials to the age claims service may have access (under the users control) to age claims about that i-name owner. The XRDS provides the glue between finding the authN service for the user to know they are who they claim to be (ok.. have access to the credentials for that account) and the Age Claims Service that provides necessary claims for the i-name user to buy their beer on-line.

Monday, May 28, 2007

Making use of the XRDS

The XRDS (eXtensible Resource DescriptorS) document is an XML document that you will find behind every OpenID 2.0 identifier, both urls and i-names. The XRDS contains a list of ‘Service End Points’ (SEPs ) that describe the services associated with the identifier, where they can be found and how they can be accessed. Notably the most important SEP from the OpenID 2.0 (yadis) standpoint is the authentication endpoint that tells the relying party where the OpenID service can be found.

Remember that XRDS was originally brought into the OpenID as part of yadis; a mechanism designed to provide interoperability between OpenID and LID, 2 http redirect authentication protocols that both use URL identifiers. Yadis, and therefore XRDS provided a way to describe which authentication protocol was associated with this particular url. Once we know that a specific URL can be resolved to an XRDS we can associate any number of services with that URL… SAML authN, XDI, Higgins Context Provider Factory Class, Flikr feed, reputation service, age claims, etc… All of this is a given for i-names but OpenID urls have the capability as well.

The problem is this; XRDS documents are XML documents, not particularly complex ones but XML none-the-less. Imagine my mother… I bought an i-name for her… I believe she can remember that Gillian.dale is her name (shameless i-name plug: no I don’t know that she could deal with any url for of her name reliably). So, she has her i-name and uses it to log into services that accept openID 2.0, she now only has to remember one username and password and I get a lot less support calls.

What happens when someone wants to sell her a new service? Lets say that someone launches a better authentication service (and I know a bunch of people working on that). They do not want to tell my mother to go edit her XRDS… if her OP even gives her access. So years back, I spec’d (with help from others of course) an XRDS provisioning protocol. It’s a very simple http redirect protocol… Mum goes to a new service and wants to get it… she clicks on the ‘get this service’ link… the would-be service provider looks into her XRDS for the provisioning endpoint… and redirects her to it together with the SEP details for this new service… Mum now sees a dialog, from her own OP (with all the same phishing controls that she is used to at her OP for logging in) that says… “Service X wants to become you new service provider, do you want to continue?” … this makes total sense to her as she got this message as a result of saying “get this new service”. Assuming she tells her OP to go ahead and add the service it can now add the SEP to her XRDS and she has a new service (probably something to do with grandkids).

Now I never completed the XPP (eXtensible Provisioning Protocol) spec as no one seemed to care enough about it... So here is that first draft, if anyone out there wants to work with me on finishing it I would love it. I wrote this originally for i-brokers but it would be trivial to generalize it to any OP.

Thursday, May 24, 2007

More to read...

This has very little to do with XDI except that it is a new channel through which I am trying to spread the meme of User Centrism and Digital Identity technology awareness to a less technical audience. has only been live for a couple of weeks but it is getting an average of 1000 unique visitors a day. I have a regular column on the site that I am hoping will raise awareness and understanding of the work that ‘we’, the people who read this blog, are involved in.

Here is the original launch announcement:



A new web magazine for these times of intense transition, Reality Sandwich launches today at

Reality Sandwich covers topics from sustainability to shamanism, alternate realities to alternative energy, remixing media to re-imagining community, holistic healing techniques to the promise and perils of new technologies. It hopes to spark debate and engagement by offering a forum for voices ranging from the ecologically pragmatic to the wildly visionary. Reality Sandwich includes news, reflective essays, arts, interviews, podcasts, and forums. Counteracting the doom-and-gloom of the daily news, the site is a platform for perspectives conveying a different vision of the transformations we face.

Among the more than 40 participating contributors are: Daniel Pinchbeck, Melinda Wenner, The Yes Men, Paul D. Miller aka DJ Spooky, David Rothenberg, Douglas Rushkoff, John Jay Harper, Kaliya Hamlin, Henri Poole, Andrew Boyd, Aline Duriaud, Ken Jordan, Jonathan Phillips, Elizabeth Thompson, Andy Dale and Michael Brownstein.

Reality Sandwich is built with Drupal, the popular open source online publishing system, by the free and open source software consultants CivicActions.

Wednesday, May 23, 2007


If you build software that is meant to be secure you might find the CAPEC site as informative and useful as I do.

Wednesday, May 02, 2007

Distributed Computing

I came across The Eight Fallacies of Distributed Computing today attributed to Peter Deutsch. The list is:
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

I'm glad to say that these are all issues that we have explicitly addressed in our xdi work, except maybe, number 7 that I don't really understand.