Profiles and Contacts population during initial signup: Proposal
Julian Bond
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)
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.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Suitable For Vegetarians
Julian Bond
>
>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.
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".
Julian Bond
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.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Serve At Room Temperature
Christian Scholz / Tao Takashi (SL)
I like this as well as it means we are not dependant on any openid
provider to do anything.
In fact it was also my plan to provide my own XRDS file which points
to my OpenID provider
but also contains more services.
The question is though how many XRDS files should the Data Consumer
read? If it's too many
it might get slow at some point (it also needs to read the actual
services then afterwards).
-- Christian
--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T