Continuation of Part-1…

Service Descriptions – The Yadis Resource Descriptor (XRD)

After all this fuss and running about, it’s easy to miss the point of Yadis – getting that final Yadis XRD document that describes the Services associated with a given ID. Sticking with our OpenID example, we know that in order to start authenticating a user on an OpenID Server, we need a few bits of information:

1. The OpenID Server URL; the URL to which HTTP requests will be made.
2. The OpenID Delegate: The ID of the current user on the OpenID Server (not their alias!)
3. The OpenID Service Types offered: For OpenID, this can include Signon 1.0, Signon 1.1 and Simple Registration (sreg) 1.0.

Here’s an example XRD document a website might fetch when performing Service Discovery:

[geshi lang=xml]
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">


http://openid.net/signon/1.0
http://openid.net/signon/1.1
http://openid.net/sreg/1.0
http://www.example.com/server
http://username.example.com/


[/geshi]

I’ll skip the details of parsing XML – you can use PHP dom or SimpleXML in PHP5. The XML document follows the XRD format, included in a current OASIS specification. At it’s most basic, the XRD document (noting these requirements are for Yadis 1.0 only) must contain a single XRD element composed of one or more Service elements. Each Service element defines a Service, as detailed in its child Type elements.

The Type element must always contain a valid URL or XRI (don’t worry yet about the XRI bit – it’s a proposed addition compatible with the current URI and IRI specifications). The URL should point to a Service specification, and contain a Version. If you check above, our example OpenID Provider is offering Signon 1.0-1.1 and Simple Registration 1.0.

The URI element must contain a valid URL – this is the URL the services described by the Type values are provided from, i.e. it’s where a website supporting OpenID logins would send its association and/or authentication requests.

Finally, there is an optional element “openid:Delegate”. This namespaced element contains the OpenID URL a user’s OpenID Provider knows them as (remember, any other URL can be an alias but the OpenID Provider does not know or care about such aliases).

Conclusion

At the end of this Yadis introduction, I’ll refer anyone who’s stuck with it to the official Yadis Specification 1.0. It’s not a huge document, but has a few nuances I’ve likely skipped mentioning.
http://yadis.org/papers/yadis-v1.0.pdf

Next up I’ll jump into the details of OpenID!

Related posts:

  1. Yadis: Service Discovery for Identities like OpenID (Part 1)
  2. OpenID library for the Zend Framework?
  3. OpenID support for PHP openssl extension? Yes, please.