[OpenID] Community Reputation Services

[Nate Klingenstein]

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.