[OpenID] Community Reputation Services

[Peter Williams]

You cannot read the OpenID specs rigorously, Nate. The security engineering terminology is all over the place. Go for the thrust, not the literal meaning. OpenID4 can go to IETF on day, like SSL3 did, and defense types there can spend another 10 years years rewriting it all, if they want, once its widely adopted.

Try to remember, OpenID is counter-culture, riding whats left of the web2.0 wave. It's taking the 15+ year old world of million dollar identity management with SSO and attributes down to commodity pricing levels, for the 80% use cases that are brain dead easy to commoditize for the mass market... 15+ years later. Its claim to fame is its community value system - that encourages folks to believe that they CAN do trust management for themselves. Whether they will or not is a question for consumer analysts, not engineers. Timing, compute power, desire, personal involvement, cost, consumer attitudes, the age effect...and lots of other factors ... make for the perfekt sturm of adoption.

I think OpenID communities like .edu can adopt a pseudo-federation model, for walled-garden deployments of OpenID2. By doing so, OpenID standard will evolve and learn to contemplate and formalize a role for TTPs and other varieties of control authorities - though the traditional conflict between the the idealists and the wallists will ensue. All the hooks are actually already there, already, via the XRI integration. XRI brings its very formal authority model and trust resolution algorithm - based on very traditional, established Lampon-esque  secure name server theory (that surely galls W3C types politically, no end). Use it! Dont focus on arcane arguments about XRI characters and URI syntax: focus on the authority resolver. One can be as fascist or communist as one wants, in the design of the authority model. Its up to you. Let your personal politics roll.




_________________________
Peter Williams



From: Nate Klingenstein
Sent: Fri 5/23/2008 9:16 AM
To: Dick Hardt
Cc: general at openid.net
Subject: Re: [OpenID] Community Reputation Services


Dick,

> The OP is the users agent managing their identity and the  
> architecture is such that the user should be able to choose any OP  
> they want.
> You can trust the identifier from the OP the same as you can trust  
> the user in presenting their username and password.

Are you sure?  As a classical application, I request the username/ 
password directly from the user.  Nobody (should, heh) know the  
password besides me and the application, and it's (usually) protected  
in transit.

Introduce an RP and an OP.  The user visits the RP, and is redirected  
to the OP.  The OP receives the request, e.g. section 9 of the  
specs.  It's followed by a response in section 10.  This response is  
created and signed by the OP.  It could do so on a whim, if it so  
chose.  There isn't even a MUST for proper authentication of the user  
that I can see[1], so hypothetically it could do so without even  
breaking the specs.  Far be it from me to defend passwords or  
distributed identity, but I'm trying to be clear about who has which  
responsibilities and abilities.

[1] "When an authentication request comes from the User-Agent via  
indirect communication, the OP SHOULD determine that an authorized  
end user wishes to complete the authentication."

> Who the RP trusts is independent, and the user acquires claims from  
> parties the RP trusts and presents them to the RP. Note that this  
> lets the user acquire claims from multiple parties and present them  
> to the RP.

Yep, there are lots of use cases for attribute aggregation, and a lot  
of ways to do it.  This is one of them.  I'm pretty sure that's an  
orthogonal issue, though.

Take care,
Nate.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080523/5651a4e3/attachment-0002.htm>