Registration framework

[Friedrich Lindenberg]

Thanks for that message, I thought it was a wounderful outline of the
available tools for open web-based authentication and authorization.

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

Agreed.

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

I've never seen LDAP used in an open web-based distributed scenario,
so I agree with your criticism. Should LDAP be required in an
organizational context, I think that sufficiently mature OpenID
mappers are available.

> 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?

I feel like the idea of having a user associate multiple OpenID
identifiers with a single account is not very user-friendly and
essentially has the user solve a problem that should be handled by the
infrastructure. Adhocracy does support multiple associations, though.

> 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 is. Any recent implementation of OpenID supports Attribute
Exchange (http://openid.net/specs/openid-attribute-exchange-1_0.html)
and Simple Registration
(http://openid.net/specs/openid-simple-registration-extension-1_0.html).
Attribute Exchange (AX) is essentially a key-value system which allows
developers to specify attributes that can be exchanged between the
provider and consumer.

While my current proposal
(http://wiki.piratenpartei.de/Benutzer:Pudo/Liquid_Democracy_-_OpenID_Extensions)
only outlines a single signature, a later version might also define a
concept of domains (i.e. URIs) which discriminate different areas of
voting within an LD system and thus allow for more fine-grained access
control. A consumer would then only need to store the public keys of
all recognized authorizing entities and associate those with its
internal representation of the voting domains (e.g. Districts in
Votorola, 'Areas' in LiquidFeedback and 'Instances' in Adhocracy).

The advandtage of this is that the LD implementation essentially
remains ignorant as to the semantics of the domains (are they
counties, states, working groups, levels of a hierarchy?).

> 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 I believe.

You're completely right to say that all the standards for exchanging
an LD graph are in place, and creating a REST API ist one of my
upcoming priorities, but I still think we're working with
significantly different semantics in each of the concerned projects.

I think I'll put this into an extra message, though.

Cheers, Friedrich