[OpenID] Community Reputation Services

[Paul Madsen]

Hi John, if I read you correctly, the 87% refers to the probability that 
the user is not a bot - this assessment performed by the OP based on its 
understanding of its own processes? And the RP would weight this 87% 
score by the OP's own reputation for correctly assessing such odds?

In Nate's use case it's the OP's reputation he is specifically 
interested in, which you seem to defer on how the RP might obtain?

paul

John Panzer wrote:
> I'm not a spec editor, but this is interesting to me once we get 
> through other more basic issues.
>
> I had been toying around with an OP-based reputation model where the 
> OP can optionally provide some type of reputation claims along with 
> the identifier.  In the cases I'm thinking of, everything is very 
> probabilistic, so you would end up with claims like "not a bot: 87%".  
> Or more holistic claims.  Which would be judged according to the OP's 
> reputation for accuracy of course.  This is similar to the verified 
> email idea (is there a standard AX schema for that?) but fuzzier.  
> (Even email verification is fuzzy of course, as the verification event 
> fades into the past the probability should actually 'decay'.)
>
> Eddy Nigg (StartCom Ltd.) wrote:
>> 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.
>>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>   
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 7.5.524 / Virus Database: 269.23.21/1458 - Release Date: 21/05/2008 7:21 AM
>   

-- 
Paul Madsen            e:paulmadsen @ ntt-at.com
NTT                    p:613-482-0432
                       m:613-282-8647
                       aim:PaulMdsn5
                       web:connectid.blogspot.com