Here's some thoughts on one of the primary Use Cases. This is aimed at initial population of a profile during signup to a service and the automatic finding of existing contacts already on the service.
* User U
* User's Home site/page H
* XRDS at the Home Page URL SC (For Service catalogue)
* New site where the user is signing up. N
* XRDS at the new site NX
* User's OpenID provider S (For Service Provider)
1) The User goes to the N Site's Signup page, where there's a field for OpenID.
2) The User puts their Home Page URL into the OpenID field.
3) The new site N uses XRDS discovery to retrieve the user's Service catalogue SC.
4) N reads and parses the SC looking for three things. Some of these may be combined.
* OpenID Service Provider and delegated ID
* Service providing Profile information SP
* Service providing Contact lists SCL
* Service providing a profile page URL list SCP
5) User is redirected to the OpenID Service Provider
6) The Service Provider looks up the N site's XRDS NX and confirms on screen that everything looks ok.
7) The User confirms that they want to sign in to the new site N
8) The user is redirected back to a profile form on the new site.
9) The new site N uses the Profile Service to retrieve the profile and populates the profile form with the data.
10) The User confirms that the profile data is correct
11) A new account is created with the profile data, the home site URL, the home site XRDS location and the OpenID key passed back from the service provider.
12) The new site N uses the Contacts list service SCL to retrieve the user's contacts.
13) The contact list is matched off against the existing member base. The new site can do whatever fits their business model. eg
* Make connections automatically
* Offer to follow all or some of them
* Send friend requests to all or some of them
14) The new site uses the profile page service SCP to retrieve the list of the user's other profile pages. Optionally it tells the SCP that there is a new entry for the user's new profile page on the New site. It can then do additional work on this eg - Store a link to the list that can be displayed dynamically on their new profile
* Store the profile pages locally
* Query them for RSS
Notes, Options and Issues
1) XRDS discovery should use that described in XRDS-Simple. Priority should be given to the http header method since this requires the minimum bandwidth.
2) The XRDS file should follow at least XRDS-Simple
3) This process requires that the user has a home page that can provide XRDS and has a simple enough URL to be used as the OpenID login. This may be a private blog, or a hosted service. This is a bottom up approach and the larger systems that provide hosted personal home pages should be encouraged to host an XRDS file for their member's profile pages.
4) The three services SP, SCL, SCP should be widely used, formal standards with libraries available for consuming them. Priority should be given to RDF-XML FOAF with additional namespaces. Not least because common usage of FOAF can handle all three services in a single file. However, there is a lack of a de facto standard in these areas. It is hoped that libraries appear to hide the complexity and to query and return common structured data from other systems such as the OpenSocial APIs, Google Contact APIs, MS Live Contacts and so on. hCard and XFN can be used providing ways can be found to parse them reliably and to encode all the required information.
5) The Contacts List service should provide at least one (and preferably more than one) common Inverse Functional Property such as mbox_sha1sum to aid matching with the existing members.
6) FOAF (like Atom and RSS) already has an auto-discovery method. This could be used in addition to XRDS. But work should be done to encourage moving to XRDS- Simple as a single auto-discovery method.
7) Standards, documentation and examples are needed to define how to code the three services in an XRDS file. And this has to allow for several possible service types for each entry. So a Profile Service entry might have several service entries of different protocols in a priority order
8) Properly parsing FOAF requires an RDF approach. It may be possible to recommend a structure that uses FOAF-XML and other preferred namespaces (such as vCard) into a form that is parsed by a simple XML parser.
9) It is assumed above in the process description that the three services do not require authentication. If they do then each should use their own authentication and discovery methods and work should be done to try and make this seamless to the user. It is recommended that oAuth is used by these services.
10) No attempt is made here to provide alternate personas through a single home page URL. The simplest solution is to use a different home page URL for the 2nd Persona.
11) It is also assumed that the OpenID provider concentrates on authentication and not profile/contact list management as well. OpenID Service providers may choose to do this. If they do then the service should be defined separately in the XRDS service catalogue. This goes against the development direction OpenID was taking with sReg and AX to combine this into a single service and so may cause some push back.
1) Work with the XRDS-Simple people to define, document and give examples of entries for common services.
2) Work with and encourage the DiSo (and others) people to develop plugins that create and manage an XRDS file for the common blog platforms. Work with them also to build plugins to create other related systems such as the microformatted list of the blogger's profile URLs. Help them to document these plugins as they are written, with examples.
3) Work with the OpenID people and JanRain to enhance and extend the Yadis auto- discovery libraries to parse XRDS and provide the service entries in an easily digestible form during the OpenID discovery process. Document recipes and examples that build on the Plaxo OpenID consumer guide on implementing a DP aware OpenID consumer
4) Work with the FOAF people to come up with a recommended set of namespaces, best practice and file layout-structure that is easy to create and read. Help and encourage the development of parsers that understand this best practice layout in all major languages. Work to define, document and give examples of putting private FOAF behind oAuth.
5) Work with the microformat people to define, document and give examples of best practice use of microformats. Help and encourage the development of parsers that understand this best practice in all major languages.
6) Work with the people developing the other major profile and contact list standards to make sure their standards work well with the "Profiles and Contacts population during initial signup" use case. include them in 1) above.
7) Develop and demonstrate prototypes of all of the above.
8) Encourage bloggers and the smaller hosted services and networks to implement the above. In particular, working one to one with the so called "Alpha-Bloggers".
[ << White Heat of Technology ] [ DataPortability May DIY Project >> ]
[ 03-May-08 4:45pm ] [ G ] [ # ] [ DataPortability ]