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.