I'm not an expert on this either - having only dabbled with coding in the relevant areas (see below), but what you are suggesting here does not "feel right" :) It looks like you are trying to implement a p2p/federated user and group registration system - from scratch so to speak? That seems like a no-no. Here would be the two approaches I'd suggest:<br>
<ul><li>Use LDAP. In earlier times I spent a good few months on this problem with a group of coders looking at wrapping LDAP in web services to make this easier to integrate. problem is it is a pin, complicated and relatively hard for people to add to their own servers. It should be fast though, and probably no harder than using any other distributed db schema. LDAP will allow all the address and geodata to be stored along side the authentication. I wouldn't go with LDAP<br>
</li><li>Use OpenID/oAuth. It seems to me this will do most of what you need here. A LD implementation can simply use the open ID url to authenticate the remote user using oAuth, and I guess group membership can be authenticated with a secondary url / openID? <br>
</li><li>AFAIK there is no current implementation to store any additional metadata with OpenID. The only easy thing to do would be to use additional uri's/ a uri naming convention), or doing a lookup for the authenticated URI with a meta-db. <br>
</li><li>There are however moves in this direction (so longer term whatever is implemented will need to move over to OpenID/oAuth):</li><ul><li><a href="http://wiki.openid.net/OpenID-Services-and-Metadata-Discovery-Coordination">http://wiki.openid.net/OpenID-Services-and-Metadata-Discovery-Coordination</a></li>
<li><a href="http://wiki.oasis-open.org/xri/XrdOne/SpecHome">http://wiki.oasis-open.org/xri/XrdOne/SpecHome</a></li><li><a href="http://wiki.idcommons.net/Existing_MetaData">http://wiki.idcommons.net/Existing_MetaData</a></li>
</ul></ul>My gut instinct is that we HAVE to go with oAuth anyway - then look to see how to associate the Open ID URI with the required metadata for LD, and this should be a basic requirement for all systems as it is in their interest to do so even without any benefit from cooperating with other LD implementations. In addition if we created a simple OpenID metadata database, we could then add an Resful API to it such that it used return the required minimal contact metadata. This could include sufficient information to create a basic LD graph. The relationship between the OpenID and the Restful API would be integrated using <a href="http://en.wikipedia.org/wiki/XRDS">XRDS</a> I believe.<br>
<br>As all of this identity commons stuff remains in flux, I think the best we can do is get up the basic minimum that is useful and keep an eye on the evolving standards based implementations, but it would seem that the core bits that have settled and can be used by everyone to mutual benefit are:<br>
<ol><li>OpenID 2.0 and oAuth</li><li>XRDS to map openID 2.0 to a metadata URI</li><li>A shared common project server where we can archive real world user data in an extensible way, and think about agreeing thngs like group mebership and geographical info. But basically not try to go to far with 3? Basing the shared a distributed db would seem to be a good idea for those implementations looking to go that way - maybe <a href="http://www.darold.net/projects/ldap_pg/HOWTO/">something like this</a> would kill a few birds :)<br>
</li></ol>The following aspect of openID 2.0 in addition to the XRDS integration above would seem useful to LD implementations:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
OpenID 2.0 introduced the use of XRIs as Identifiers that we can use instead of URLs.  XRI's come in two forms: i-names and i-numbers.  My i-name is =arnott, and my i-number is =!9B72.7DD1.50A9.5CCD. </blockquote><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
My i-name, like a domain name, only belongs to me as long as I maintain an account with the service I registered it with.  But my i-number that came with that i-name is universally unique and mine forever, long after I cancel my i-name.  Since RPs I log into using my i-name actually store my i-number as my Identifier, I can change my i-name anytime I like and still log in because my i-number is mine forever.  And a future owner of =arnott will not be able to impersonate me because their i-number must be different than mine.  And no I do not have to memorize my i-number.  I just remember =arnott, and the infrastructure does all the work of resolving that to an i-number and authenticating me.  Now even if I'm hosting my own IdP I can rest assured that no one can ever buy off my Identifier."<br>
</blockquote><br><br><div class="gmail_quote">2009/12/4 Michael Allan <span dir="ltr"><<a href="mailto:mike@zelea.com">mike@zelea.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">David Bovill wrote:<br>
> Not clear what the registration-facility is about? What is the realtion to<br>
> this and oAuth openID? Are you including geographic location, and/or real<br>
> world political voting constituencies, in addition to pseudo-anonymous<br>
> authentication?<br>
<br>
</div>Hopefully it will cover all those.  It should really be open to any<br>
form of personal ID (OpenID, email address), any type of registration<br>
property (residential, organizational) and any authentication method<br>
(authority, biometric, trust network).<br>
<br>
Here's where I think we are: We already have two designs (Votorola's<br>
and Pirate's) but neither is general enough to serve as common ground.<br>
The problem is as Friedrich says: we need something that all aircraft<br>
can safely land on, without dictating propeller sizes in advance. :-)<br>
<br>
So my own thinking is: be silent on what registration entails (leave<br>
that to registrar).  Registrations are generic data in opaque<br>
containers.  All we define are the requirements for moving containers<br>
from place to place.  (Just requirements to start, no design.)  The<br>
use cases are still kind of spotty - need to flesh those out:<br>
<div class="im"><br>
  <a href="http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework" target="_blank">http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework</a><br>
<br>
</div>I'm not really comfortable drafting this, on my own.  I just wanted to<br>
get something passable (?) out into the open where everyone could see<br>
it, and where problems could get aired.<br>
<br>
Best to all,<br>
<div><div></div><div class="h5">--<br>
Michael Allan<br>
<br>
Toronto, +1 647-436-4521<br>
<a href="http://zelea.com/" target="_blank">http://zelea.com/</a><br>
<br>
</div></div></blockquote></div><br>