Yesterday, I posted about my planned work on writing a PHP5 OpenID library. As I mentioned towards the end, I would be blogging about specific topics required for such a library. This first entry is an examination of Yadis, a Specification which is relied upon by OpenID. Of course Yadis is a topic of its own, since it is also used by Light-Weight Identity (LID), sxip Identity, and mIDm. You can bet more will join in once Yadis becomes more firmly established.

This post is mainly to introduce Yadis, and what my upcoming effort towards a Zend_Service_Yadis would entail performing. Part 2, later, will briefly examine the format of a Yadis XRD document and how it should follow the Yadis Specification 1.0.

So what is Yadis?

The purpose of Yadis is to specify a standard for enabling any party ("the Relying Party") to obtain an XML document containing relevant details of a specific Service ("the Yadis Resource Descriptor") which describes Service details such as Type, Url, and other optional data to be included in Service requests. If that's mumbo jumbo, it's easily explained with an example.

Let's take OpenID. In OpenID, the Yadis ID is simply your OpenID URL. If you have a Livejournal Blog, for example, you can use your blog URL as an Identity for other websites which support OpenID authentication. These will fire off a request to your Identity Provider to check you out. The problem is that the website doesn't know where to send the request - it needs to discover your Provider's authentication service, a process called "Service Discovery". Service Discovery is what Yadis is all about since it defines a standard HTTP GET process, and a standard Service data format (XML XRDS syntax) anyone can use.

Service Discovery

The Yadis Specification 1.0 describes all the steps a Relying Party needs to perform in order to obtain a description of the services associated with an ID. In our example, an OpenID URL will be associated with an OpenID Server URL which can be used by any website to authenticate a user.. Service Discovery describes the steps in finding out where that OpenID Server is located, i.e. its URL. In case you're wondering, an OpenID URL could be subdomain on your OpenID Provider's website, or even your own personal website URL - this is very different from the Service URL.

Performing discovery relies on finding a Yadis Resource Descriptor which details the Services associated with any Yadis ID. This document will be XML, using the Extensible Resource Descriptor (XRD) format (an OASIS specification). It's a bit tricky to find the end YRD XRDS document, so bear with me as I describe the process.

The first step is to make a simple HTTP GET request to the ID (if a URL). For example, our OpenID URL. The response now needs to be examined. There are broadly three types of valid responses detailed in the specification:

1. An HTML document with a "head" element that includes a "meta" element with a http-equiv
attribute of "X-XRDS-Location". The "content" attribute of this element should contain a URL pointing to the Yadis ID's associated Yadis XRD Document. For example:


2. Any document, so long as the response-headers contain an "X-XRDS-Location" response-header whose value should contain a URL pointing to the Yadis ID's associated Yadis XRD Document.

3. A document of MIME media type, "application/xrds+xml". We'll hit gold when we receive this one! It means we just received the XRD document we were looking for. The MIME type will typically be contained in the "Content-Type" response-header.

The Bread Crumb Trail

In the above, two of the valid responses to an initial HTTP GET request to a Yadis ID (the OpenID URL in our example) don't provide the needed Yadis XRD document, but provide a means of figuring out its actual location. Typically Service Discovery under Yadis will require at least two HTTP GET requests - the first to find the XRD location, the second to actually fetch it.

The first valid response is often used when an OpenID URL is an alias. You can actually create any number of aliases (and hence any number of aliasing OpenID URLs) based on a personal URL using this method since the aliases can simply inform a website (via either a response-header or "meta" element) where to look for the underlying Service Provider's XRD document. Of course

Truncated by Planet PHP, read more at the original (another 1023 bytes)

When I designed the back-end for this blog, I built in the capability for understanding multiple authentication sources. It currently supports three different sources: one of which is local and the other two are CVS servers. By supporting remote authentication sources, I spare myself from having to implement a lot of the user management gumph that is needed to support it (email address verification, password management and so on). While this is good for me, if the authentication is perceived as happening on my site, people don't feel quite so comfortable entering their off-site credentials, because they don't really know what I do with their data.

I'm currently going through one of those phases where I'm thinking about what I'd put into "netevil 2.0", and one of those things is adopting support for authenticating against well-known external sites. Ideally, I'd like people to be able to login to Yahoo or Google and then have some way for my blog to determine a subset of their profile data when they post a comment.

This single-sign-on (SSO) concept is nothing new; Microsoft's passport has been around for quite some time now, and there are newer open specifications being designed by SXIP and the Libery Alliance. Both of these projects are working on IETF draft standards for identity management and federation protocols to facilitate SSO. SXIP is very open and has an implementation in PHP that you can download and use. Liberty feels somewhat closed, and has no reference implementation in any scripting language, which immediately creates quite a high barrier to entry for a large portion of the web developer population.

So, we have one established SSO provider (MS passport) and two entities developing SSO technology. Why haven't I seen any sites, aside from passport enabled sites, using anything like this stuff? I think part of the problem is that SXIP and Liberty are providing the technology but not providing the actual authentication services. Taking SXIP as an example, if I want to SXIP enable my site I need to direct users to a SXIP homesite where they can create an identity, and which can then authenticate them with my blog. The problem is that there aren't really any SXIP homesites out there, so I'd need to implement one myself, and we're back at square one.

I think it would be a huge thing if the big guys (yahoo, google) could implement something like SXIP and allow third-party applications to authenticate users against them. Yahoo is almost there already--if you look at the Flickr API you'll see that you can have flickr authenticate users and provide your application with an authentication token (subject to approval from the user). From that token you can obtain the name of the user, and use that to render the name of the person submitting comments to your site.

It'll be interesting to see what, if any, developments are made in this area.

Why Frameworks Suck | devdev2040

Here’s an interesting blog entry which I picked up off John Herren’s 360 Blast.

It is a bit of a rant, but offers good defense of the humble library vs. the Enterprise frameworks.

I’m a library guy, I like a big set of tools available to call upon at need, I like to have a favorite hammer and a favorite saw and know the tricks for making them both fit on my belt without running into my legs when I am working on something. Framework people like the 5-in-1 lathe-press-drill-saw-grinder and figuring out the tricks to fit the piece of wood they are working on into the machine. When you have a framework everything will be lathe-press-drill-saw-grinded into submission, and you better read the manual otherwise the machine won’t even turn on.

…

Frameworks suck because they are an avatar of enterprise, frameworks suck because they take away your freedom, frameworks suck because they build walls between coders, frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library.

And Long Live PEAR!

Zak Greant, the well-known MySQL advocate and co-founder of the PHP QA team has joined the Sxip team in the role of an "evangelist", pretty similar to his prior job as MySQL's "Community Advocate".
Very probably another clever step by Dick Hardt (whom I met at the FOAF workshop in Galway) and his team - and the really promising idea of sxip.

Zak Greant, the well-known MySQL advocate and co-founder of the PHP QA team has joined the Sxip team in the role of an "evangelist", pretty similar to his prior job as MySQL's "Community Advocate".
Very probably another clever step by Dick Hardt (whom I met at the FOAF workshop in Galway) and his team - and the really promising idea of sxip.