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 http://openid.net/signon/1.0

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.