[OpenID] Community Reputation Services

[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.