[OpenID] Community Reputation Services

[Eddy Nigg (StartCom Ltd.)]

Nate, I think this to be very interesting, but no replies have come 
forward so far. Does any of the spec editors consider something like this?

Regards
Signer: 	Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Phone: 	+1.213.341.0390



Nate Klingenstein:
> OpenID generals,
>
> The use case: we have a group of trusted IdP's (or OP's) and a set of
> trusted SP's (RP's) in a single common "federation", InCommon.  We
> have a lightweight legal framework, a set of guidelines regarding how
> to behave, what attributes to use, and so forth.  It works pretty
> well, and we like it.  We also have smaller sub-communities with
> different trust and special attributes.  An example is UCTrust, a sub-
> group formed by the University of California system.  They want to
> leverage InCommon's breadth and infrastructure, but add special rules
> just for them.  Several European countries have similar scenarios.
>
> I know there's a general dislike of whitelists and blacklists, but
> they're unfortunate realities of our requirements.  We've come up
> with a clever way to handle this scenario in SAML 2.0, but I want a
> way to do the same thing in OpenID so it can be another protocol with
> scalable trust for our communities.
>
> I'm not deeply familiar with OpenID/XRDS, and I found no specs at
> http://wiki.openid.net/Potential_Future_Projects.  I'd like to, from
> the RP's perspective:
>
> 1)  Perform standard OpenID authentication and validate the claimed
> identifier.  OP might suggest a community broker.
> 2)  Make a query of a community broker already trusted by the RP,
> maybe the recommended one.  Supply in the query string the claimed ID
> and the endpoint URL.
> 3)  Receive back:
> 	a)  Blacklisted by me
> 	b)  I don't know this guy
> 	c)  Checked by me...
> 		optional)  And part of community A
> 		optional)  And part of community B&  X
>
> However, we need community A, B, or X to be responsible for that
> claim, not the reputation broker.  UCTrust states the members of
> UCTrust, not InCommon.  We could just store signed blobs, but I don't
> like persistent blobs.  I'd prefer to represent communities as URL's,
> e.g. http://www.ucop.edu/uctrust/members.  That makes step 4:
>
> 4)  Recursively chase community URL's received to get "Vetted by me".
>
>   From the OP's perspective, the openid.return_to in a request could
> be validated in the same manner.
>
> Is there a standard way to do this?  I prefer it to the distributed
> white/blacklists that were proposed earlier, and we have experience
> there too.  If not, I'll take the above suggestion to the specs list
> and get it bashed.
>
> Thanks for your ideas and time,
> Nate.
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080521/549153db/attachment-0002.htm>