As you might know I attended the London DataPortability Lunch last week and met cool people like Chris Saad, Julian Bond, John Breslin, Tom Morris and others. Among other things we have been discussing the maybe first use case to tackle for Data Portability which is Discovery.
As you also might know there was some discussion about how to approach the DataPortability problem space and one of the ideas which came out of that was my idea of dividing it into fields and levels. Now this general discovery use case nevertheless makes much sense because it seems to be a general starting point for every field we might address. So how does it work?
Imagine you signup for a new social network and you want to import your data from elsewhere. The most important part now is to find out where data is available for you. Of course you can enter a set of URLs but I guess we agree that this is not particularly user friendly.
The service catalogue
Thus the idea of a service catalogue was invented which contains all the locations and types of information you have on the web. This service catalogue can be an XRDS file, following the XRDS-simple specification. Such a file could look like this:
<XRDS xmlns="xri://$xrds"> <XRD xmlns:simple="http://xrds-simple.net/core/1.0" xmlns="xri://$XRD*($v*2.0)" version="2.0"> <Type>xri://$xrds*simple</Type> <Service priority="10"> <Type>http://www.w3.org/2006/03/hcard</Type> <URI simple:httpMethod="GET">http://pownce.com/mrtopf</URI> <LocalID>jane<LocalID> </Service> <Service priority="20"> <Type>http://gmpg.org/xfn/11</Type> <URI simple:httpMethod="GET" priority="10">http://twitter.com/mrtopf</URI> <URI simple:httpMethod="GET" priority="20">http://pownce.com/mrtopf</URI> <LocalID>janedoe<LocalID> </Service> </XRD> </XRDS>
In this example the endpoint for an hcard and an xfn list are defined (if I actually understood xrds right, I only skimmed the spec and changed the example. Also the types might not be correct).
So the flow we are discussing is like this:
- A user logs in with her OpenID (this might involve retrieving an XRDS file first which describes which authentication mechanisms are actually available and under which URLs. This is also known as YADIS and part of the OpenID 2.0 specification)
- The network asks the OpenID provider for the location of the service catalogue which is an XRDS file as described above. It does this via the Attribute Exchange extension of OpenID (AX). This XRDS file can additionally be protected by OAuth to allow more control by the user who got to see it.
- The network then processes the list of service types it found in the XRDS file and can retrieve the information available there. These ressources can be protected by OAuth as well so that e.g. not everybody is able to look at your friends list.
While this workflow seems simple of course not all open questions are answered. E.g. it is unclear how the AX part might work as it seems that it’s not widely used and not many examples are around. The question is also what benefits it has over existing standards (like hCard). There is also the question if there might be alternatives to using AX to retrieve the service catalogue location.
So there are some discussion points open but I guess we can solve them quite quickly. What is obvious here though is that we really try to reuse existing standards instead of defining our own. OpenID, OAuth, XRDS (and simple), AX, hCard, XFN etc. are all available already although maybe sometimes an implementatin is missing. But the hope is that DataPortability will also give an incentive to create such libraries.
Plone and DataPortability
My plan is to try to implement these things for Plone. Right now I am working on a microformats parsing library for Python (more on that later) and my plan is to get OAuth and XRDS in Plone working. I am not sure yet how to solve the AX part because apparently some OpenID provider implementing this is needed (beside that I have no idea about how AX works yet as there are simply too many standards out there which need to get read).
What it also means for Plone is maybe a different way of handling OpenID. Right now there is no way to attach an OpenID to an existing user/profile. Instead they are separate (somewhat virtual) users. This eventually means adding a different OpenID implementation to Plone which allows people to attach one or more OpenIDs to their user accounts.
Another question is if Plone should become an OpenID provider, too. OTOH there are already too many out there. So it might depend on how much work it is.
Having OAuth in Plone is not only interesting for DataPortability but for any means of accessing data from the outside in a controlled fashion and as a basis for other web services.
So all in all I hope we get very fast going with this first use case so that people know what to implement.