[OpenID] Supporting OpenID

Sun Apr 13 21:39:51 UTC 2008

Interestingly, the term access (as in access control) only appears once in http://openid.net/specs/openid-authentication-2_0.html - and its used in a negative clause, at that.

The only use of trust is in the context of the terms trust_root and realm. I *know* I don't understand the theory of the protocol and its signal handling requirements in these areas. I suspect the designers have again shifted the goals posts, aiming for a paradigm shift (even if it is a paradigm "revisited"). For example, the nature of trust_root appears to be tied up with the notion of  releasing a different ClaimedID per user and Sreg attribute set (and possibly a different claimedID per user session) to each RP site or RP subsite (where subsites controls support the "hosted RP" world). And this apparently goes to the whole crux of the directed identity law and the notion of privacy control (in a UCI model)  If I now cast it all in terms I do understand, leaving the directed identity twist aside, its all playing with similar ideas that SSL/https addressed , when a server's X.509 cert's CN field has *.verisign.com as wildcarded reliance pattern, affecting how sites applying inbound Host-Headers would or could not act as authorized SSL endpoints for those virtual-hosting sites.

Trust - as in the traditional and endless discussion of authorization, access control, key management, authority to assert, delegation models, (X.518 chaining models for X.511 signed DAP assertions passing across naming contexts) - seems almost unOpenID. The notion of trust is however used in a specific way - as embodied in the phrase.. "URL pattern the OP SHOULD ask the end user to _trust_".

Given that the trust notion is very much tied to using the web and SSL certs as a giant name server, and given that XRIs are OpenIDs, and given XRI has very specific authority and authority-delegation models that will impact such URI patterns in the handlers addressing "naming realms", I'm not sure that its appropriate to say that OpenID (v2) has a "lightweight" trust model. Lightweight may have been true descriptor for OpenID1, I'd grant you that. But in OpenID2 + XRI, we have anything but lightweight. Don't we now have a full power authority-revolver (and name-revolver) infrastructure built into every conforming OpenID2 RP? One only has to look at the uses of wildcard XRIs in the XRDs from i-name servers accessed via YADIS (or HXRIs) to get a feel for what's going on, here.

Now what is interesting is that the term trust seems to be being reserved for use only in that authority/name revolver context. Reputation is entirely a different issue, distinguished from trust (as above) and is of course a Work in Progress. One day, Ill break my rule, and go sneak a peek at the various WG drafts on these "additional areas of ongoing normalization".

I think we are just starting to discover the explicit trust model  and the explicit authority/delegation model built already into OpenID2 Auth. Rather than be tied to proxy chaining (as in X.518 and SAML2 protocol-level chaining controls), its tied to naming context delegation (as in X501 http://sec.cs.kent.ac.uk/x500book/Chapter.4/Chapter4.htm#4.5%20DISTRIBUTED%20NAME%20RESOLUTION)

Peter

From: Nate Klingenstein
Sent: Sun 4/13/2008 1:33 PM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] Supporting OpenID

Peter, 

I think its germane to address the apparently sensitive issue at the heart of the thread: gatewaying, particularly in this highly doctrinal UCI forum.

I don't think it's relevant because there's a lightweight trust model here.  I receive and validate an identifier from this OP.  I make a decision how to trust it.  I may decide that it's "equivalent" to a Google account, or I may not, but that's totally independent.  It'd still be independent if this were a google.com address(all kinds of interesting things happen in *.edu domains).

>From my brief reading, OpenID doesn't have any formal notions of gateways or proxies in its protocol.  If this conversation were in the context of such support or a stronger trust model, we'd have something to talk about, and you hint at that in your last paragraph.  

Until there are reputation services or federations or something, ultimate access control decisions are solely the SP/RP's to make.  It alone must decide how to trust the inputs.  There's just nothing else to go by.

Hope this makes sense,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080413/00c5fcfc/attachment-0001.htm>