Registration framework

[David Bovill]

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:

   - 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
   - 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?
   - 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.
   - There are however moves in this direction (so longer term whatever is
   implemented will need to move over to OpenID/oAuth):
      -
      http://wiki.openid.net/OpenID-Services-and-Metadata-Discovery-Coordination
      - http://wiki.oasis-open.org/xri/XrdOne/SpecHome
      - http://wiki.idcommons.net/Existing_MetaData

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
XRDS<http://en.wikipedia.org/wiki/XRDS>I believe.

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:

   1. OpenID 2.0 and oAuth
   2. XRDS to map openID 2.0 to a metadata URI
   3. 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 something like
this<http://www.darold.net/projects/ldap_pg/HOWTO/>would kill a few
birds :)

The following aspect of openID 2.0 in addition to the XRDS integration above
would seem useful to LD implementations:

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.

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


2009/12/4 Michael Allan <mike at zelea.com>

> David Bovill wrote:
> > Not clear what the registration-facility is about? What is the realtion
> to
> > this and oAuth openID? Are you including geographic location, and/or real
> > world political voting constituencies, in addition to pseudo-anonymous
> > authentication?
>
> Hopefully it will cover all those.  It should really be open to any
> form of personal ID (OpenID, email address), any type of registration
> property (residential, organizational) and any authentication method
> (authority, biometric, trust network).
>
> Here's where I think we are: We already have two designs (Votorola's
> and Pirate's) but neither is general enough to serve as common ground.
> The problem is as Friedrich says: we need something that all aircraft
> can safely land on, without dictating propeller sizes in advance. :-)
>
> So my own thinking is: be silent on what registration entails (leave
> that to registrar).  Registrations are generic data in opaque
> containers.  All we define are the requirements for moving containers
> from place to place.  (Just requirements to start, no design.)  The
> use cases are still kind of spotty - need to flesh those out:
>
>  http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework
>
> I'm not really comfortable drafting this, on my own.  I just wanted to
> get something passable (?) out into the open where everyone could see
> it, and where problems could get aired.
>
> Best to all,
> --
> Michael Allan
>
> Toronto, +1 647-436-4521
> http://zelea.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20091204/71515d01/attachment-0006.html>