Even More on XRDS.

Phil Windley picked up the XRDS conversation with a great post. I just want to reiterate my concern about misunderstanding of XRDS usage. You may have all already groked this in which case I apologize for the redundancy but I want to make sure that this is really clear.

The problem is this:

Lets say that I have 2 services listed in my XRDS, an OpenID authentication service and a photo service. I go to a dating service and log in using my OpenID. The dating service now looks for a photo service in my XRDS and finds it and presents the photos found as photos of me. The danger here is that because I logged in using one service listed in my XRDS that there is the impression that the there is some validation that the photos really are of me, this simply isn’t true.

All you can derive from the fact that multiple services are listed in a specific XRDS is that one of the entities that have access to edit that XRDS want to associate that service with that identifier. Service endpoints in XRDS documents should be treated like any other self asserted claim.

At this point I want to give a big thanks to Steven Churchill, ooTao’s CTO. I recognized this vulnerability of XRDS and discussed it with Steve, he then went ahead and solved the problem at least as it pertains to i-name resolution and services in XRDS. His solution is now a part of the XRI resolution specification, lookup Canonical ID verification.

Some things that do work:

If you know that services use the Canonical ID as their ‘key’ then you can use canonical ID verification to ensure that the same i-number is the subject of both your authentication request and your service access request. Assuming the service has authenticated and validated the user correctly when the service was provisioned you can use this mechanism to create trusted service bindings. The trouble here is knowing which service providers to trust, both in intent and implementation.

A simpler case that does work is the case like EZIBroker’s Claim Services. In this case the semantics of the services itself asserts the relationship between the services and the identifier. This works equally well with URLs or i-names (I think). A user authenticates (demonstrates their access to the credentials for a given identifier) using a specific OpenID identifier. The relying party then looks up the ‘claims service’ (could be WS-*, SAML, AX, XDI, etc…) The assertions that are generated by the claims service specifically assert the claim and the related identifier. For Example: signed {=andy is over 21}. If you find this claim from a service in =andy’s XRDS then it makes a lot of sense… If you find it from =jim’s XRDS you know there may be a problem. (of course if =andy and =jim resolve to the same canonical ID then it’s all good). A service that presents the claim; signed{this person is over 21} is obviously not useful in the context of an XRDS unless there is an additional authentication step that lets the user assure the Relying Party that they are ‘this person’.

NOTE: The EZIB claims service will be providing one-time opaque identifiers that can be used with claims so the relying party only need know that !2003!1928.2746 is over 21 and !2003!1928.2746 is the person logged in. This will satisfy some of the privacy concerns but not all, we are not claiming that we are building a zero knowledge system.