While I thought it was clear what the BP doc #1 is about (logging in and obtaining a service list) I am not so sure anymore (hence my idea of first writing detailed use cases which I will begin tomorrow)

So my questions:

- Is this about logging in to a website you are already a member of or is it about registering for one?

- If it's for one where I am a member of why do I need to retrieve my profile again, I'd think that it's sitting on the SN now (once copied maybe and maybe edited) and might receive updates via some sort of mechansim we have to discuss

- Is this document about just logging in and obtaining a service catalog (= a list of URLs to some services in the end) or is it also about doing something with those services? What is the meaning of getting the contacts list e.g. via XFN then? I might then have a list of links to twitter friends but on some different service this might not make too much sense? (I acually would move this whole contact thing to some other BP doc while this here serves as the root of everything)

- Use Case #2 should maybe splitted into 2 separate ones: profile and contact list

- I personally like separate pages for use cases and technical docs better. Then you can nicely link to them also from other documents (e.g. I imagine we have some sort of story of one user using all this and we can link from within this story to use cases and maybe in the end to BPs). We can then also version use cases, technical docs and BPs separately. When we publish something as finished we can still copy everything into one page (or PDF) and "freeze" it that way.

- thinking about it a bit more maybe what's on here is more the technical sequence and not so much a use case, so this should probably stay on this page for linking all the technologies together.

- should we put the authorization bit extra? like it should be clear that for every endpoint discovered we might find a protected one.

Here is an example sequence for this in a simple use case style:

 Roles

System - a website the user wants to register for

User - the user who wants to join a website

 Main Success Scenario

1. The user logs in via OpenID.
2. The system authenticates the user as described in the OpenID spec
3. The system obtains the service catalog for the user as descibed in DP-IMPL-001
4. The system retrieves data from those service endpoints it is interested in

Exceptions

4a. A service endpoint is protected by OAuth
4a1. The system authorizes the access to a service endpoint as described in DP-REC-003

2a. The user cannot be authenticated
2a1. The process stops here unless the system implements other means of authentication such as providing the user with an OpenID of the system.

Remarks

 The list of available service endpoints defined for Data Portability can be found here. The best practice for using them can be found in the accompanying Best Practices document.

(or something like that)

Here's how I see it. 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.

Players

• 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)

Process

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.

Resulting Actions

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".

Nice to see *something* here, but I am a little concerned that -

1. it's not very web-friendly - it's describing the use of one single approach to implementation

2. this approach involves inventing/using new stuff - compare and contrast xrds discovery (with possible service type registry) and html discovery <link href="..."> ...

I just posted a list of all those issues to the group's list:

http://groups.google.com/group/dataportabilityactiontechnical/t/f211011bf9984d54