Thursday, May 15, 2008

XRDS for Information Cards?

One of the topics that came up at the most recent IIW (IIW2008a) in a couple of sessions, is the concept of allowing an RP/SP to describe it's services and requirements in a passive way. The goal being to allow "Identity Agents" to provide a progressively better user experience. A user should be able to interact with the RP in a normal "dumb" browser session, but also allow tools (e.g. an Identity Agent) to provide a much more seamless experience.

In an InfoCard Capabilities session, lead by Pamela Dingle, there was some discussion about how to do this technically. The following is a proposal for one way this might be accomplished.

The "Relying Party" would need to...
  • define an XRDS file describing identity protocols supported, services provided, and other metadata
  • allow for discovery of the XRDS file through normal XRI resolution (section 6)
  • additionally allow for discovery by adding a
    <link rel=”xrds.metadata” target=”location-of-xrds-file”/>
    in the <head> section of the pages provided by the relying party

The "Identity Agent" would need to...
  • look in web page dom for the xrds.metadata link
  • retrieve and parse XRDS document
  • find supported identity mechanisms and endpoints
  • invoke card selector
  • allow user to select card
  • post card to endpoint specified in the XRDS document


What could the XRDS markup look like for an InfoCard relying party?

First we need to define some <Type> URIs to represent different metadata characteristics of the relying party relating to InfoCards. Here are some possible examples...

<Type>http://infocardfoundation.org/policy/1.0/login</Type>
This type identifies the service/endpoint describing the claims required for login.
<Type>http://infocardfoundation.org/policy/1.0/registration</Type>
This type identifies the service/endpoint describing the claims required for registration.
<Type>http://infocardfoundation.org/service/1.0/login</Type>
This type identifies the service/endpoint where the login token should be sent.
<Type>http://infocardfoundation.org/service/1.0/registration</Type>
This type identifies the service/endpoint where the registration token should be sent.


An example XRDS document could look like...

<?xml version=1.0 encoding=UTF-8?>
<XRDS xmlns=xri://$xrds>
<XRD xmlns=xri://$XRD*($v*2.0) version=2.0>
<Type>xri://$xrds*simple</Type>
<!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
<Service>
<Type>http://infocardfoundation.org/policy/1.0/login</Type>
<URI>http://sp.example.com/policy/login.xml</URI>
</Service>
<!-- Service specification that identifies the endpoint of the infocard policy for registration claims -->
<Service>
<Type>http://infocardfoundation.org/policy/1.0/registration</Type>
<URI>http://sp.example.com/policy/registration.xml</URI>
</Service>
<!-- Service specification that identifies the endpoint for submitting login claims -->
<Service>
<Type>http://infocardfoundation.org/service/1.0/login</Type>
<URI>http://sp.example.com/login</URI>
</Service>
<!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
<Service>
<Type>http://infocardfoundation.org/service/1.0/registration</Type>
<URI>http://sp.example.com/registration</URI>
</Service>
</XRD>
</XRDS>

No comments: