<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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?<br>
<br>
<div class="moz-signature">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td colspan="2">Regards </td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td>Signer: </td>
<td>Eddy Nigg, <a href="http://www.startcom.org">StartCom Ltd.</a></td>
</tr>
<tr>
<td>Jabber: </td>
<td><a href="xmpp:startcom@startcom.org">startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org">Join the Revolution!</a></td>
</tr>
<tr>
<td>Phone: </td>
<td>+1.213.341.0390</td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
Nate Klingenstein:
<blockquote
cite="mid:B63B9C64-8451-4B17-9206-B71583BBB1BE@internet2.edu"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="http://wiki.openid.net/Potential_Future_Projects">http://wiki.openid.net/Potential_Future_Projects</a>. 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. <a class="moz-txt-link-freetext" href="http://www.ucop.edu/uctrust/members">http://www.ucop.edu/uctrust/members</a>. 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.
</pre>
</blockquote>
</body>
</html>