|I've been looking round a number of OpenID providers this morning. Almost all of them have kept up to date and are providing an XRDS file discovered though an http header when you GET the human memorable openid URL. I know I'm repeating myself but one way of looking at this is that they are all hosting a personal home page and then delegating from there to the actual openid server. This makes sense as it leaves their options open to add profile or other information to that page at some earlier or later date. So I'm still feeling the same way which is that the Service Catalogue should generally be the XRDS discovered at the home page. One of the entries will be the OpenID Server, either directly, or by a further redirection through the home page at the Service Provider. This makes it all a consistent method of finding it. And it allows us to attack the problem both at the OpenID Providers and via people's home blogs, or through their favourite Social Network. |
Now say I have an XRDS at Voidstar which points through to the XRDS at MyOpenID which then points to the MyOpenID server. And say both I and MyOpenid have XRDS entries for other Services. The Relying party site really needs to aggregate all the XRDS entries into one list. It could get the profile service from MyOpenID and the Contact List service from Voidstar.
What we really need is for the JanRain Yadis library (and others) to return all this metadata to the calling program as part of OpenID discovery. The list of XRDS URLs found along the way and a list of the services in each one.
I like this. It then doesn't matter if the Service provider, the blog or some other site, hosts bits of the Service Catalogue. They can each contribute what they know. They can each choose whether to play Home Page Provider. It means we're not dependent on the OpenID provider but they can play along too.
As well as the parsing problem, I really need help on constructing appropriate entries for services within the XRDS file.
[ << DataPortability May DIY Project ] [ XRDS Service Types >> ]
[ 04-May-08 1:37pm ] [ G ] [ # ] [ DataPortability ]