[OpenID] XRI semantics and heavweight identity management

[Drummond Reed]

Peter,

 

You ask a good question. OpenID and XRI are adjacent, complementary
technologies. OpenID is one authentication option for a resource identified
by an XRI, and XRI is one identifier option for a resource that wants to use
OpenID authentication.

 

XRI Resolution 2.0 does support several trust models, including trusted
resolution and trusted synonyms, for resolution of an XRI. Due to the
extensibility of XRDS service types, it supports an even wider
(theoretically infinite) variety of authentication options. (It is ironic
that for 2+ years before OpenID came alone, we assumed SAML would be the
defacto authentication service for XRI-identified resources.)

 

In any case, one of the mantras of OpenID authentication has been that
"trust (between RPs and OPs) is out of scope". So using XRI
identification/resolution relationships to create an RP/OP trust model seems
as legitimate as any other approach. I know of several communities doing
just that (and ironically they consider it a relatively lightweight solution
vs. more heavyweight PKI-based approaches).

 

At the same time, it's only one approach, so it's hard to give much guidance
beyond that.

 

Hope this helps,

 

=Drummond 

 

  _____  

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: Saturday, April 19, 2008 10:28 PM
To: general at openid.net
Subject: [OpenID] XRI semantics and heavweight identity management

 

I'm reading
<http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution
-V2.0-cd-03.pdf>
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri-resolution-
V2.0-cd-03.pdf very carefully, aiming to fully understand OpenID2. My goal
is to then go enhance my RDF server so it can respond with some simple XRDS
files, augmenting its native metadata about service endpoints with FOAF data
(to allow for intelligent RDF-driven RPs). I don't aim to actually implement
XRI Resolution. I just want pretend to do so, for some simple XRDs and xri
queries. Its a good learning exercise; a good first step to get a feel for
the algorithm and how one tunes it all.

 

There are a lot of procedures and identity semantics in the specification.
Its essentially a toolkit. How literally should I take all the options, as
they reflect on OpenID2? Can any and all of the options in the document be
leveraged when building an actual OP->RP relationship? Are any and all the
options "compatible" with OpenID infrastructure vision?

 

For example, as a solution architect, I could specify that an OP will
operate a regime requiring only this or that durability of resources, that
equivID will be used in way X to accomplish Y per the spec,  that child and
parent authorities will and will not be able to do certain things - per
choice of policies and setup, etc, that XRI references between XRDs shall
occur in this or that way. As a result, I could easily take the toolkit and
build a very unique and particular trust model, addressing the full
lifecycle of identity management in a distributed authority model.

 

If I were to do all this "heavyweight identity management", can I still be
asserting at the end of the day that Im "doing OpenID", in a manner
"consistent with" the openid culture, vision and community goals?

 

I ask, as building such a trust model is rather different culturally to the
traditional context - in which a user goes stuff some meta tags into a
blogging HTML page, a user types in a URL at a URL, and OP->RP flows send
assertions over an authenticated channel! Such an  XRI-derived
infrastructure is an entirely different kind of trust management
infrastructure, very much focused on notions of authority and is very much
contingent on RP recognizing that various third parties authorities have
various rights to speak (in different ways) for a particular user identity.

 

Obviously, there is no one word sentence answer to this question set. Its
guidance I'm looking for

 

_________________________
Peter Williams

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080421/1f5871f6/attachment-0001.htm>