[OpenID] Community Reputation Services

[Nat Sakimura]

Hi Nate,

Interesting idea.

Note that not all the "being proposed" projects are on the wiki page.

OpenID Foundation now has a specific spec process called "Working Group (WG)".
This is to keep the spec free of proprietary IPR issues.
(For this matter, since the wiki is writable by anybody, it cannot be
used for the WG.)
We are currently sort of "debugging" the process with PAPE.

Once the bumps are removed, I would go forward and propose Reputation
Service as another Working Group, which will be a faster running
cousin to OASIS Open's Opren Reputation Management Systems (ORMS) TC
work, which I and one of the OpenID Foundation Corporate Board Member,
Tony Nadalin chairs.  Actually, Reputation has been a topic drawing
some interest in the community. In iiw2007b, it was talked over
several sessions. It included OP Reputation, RP Reputation, etc., and
it resulted in the ORMS TC. In iiw2008a, Dick had a session on the
method to gather the activity logs which may become one input to the
Reputation Service. I had two other sessions on reputation as well.

I have two suggestions:

1) Perhaps you can join me as an initial proposer of the Reputation
Service WG for OpenID.
2) Since Internet2 is a member of OASIS Open, perhaps you can join
ORMS TC as well.

Cheers,

Nat

On Wed, May 21, 2008 at 12:02 AM, Nate Klingenstein <ndk at internet2.edu> wrote:
> 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
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/