<!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">
I'm not a spec editor, but this is interesting to me once we get
through other more basic issues.<br>
<br>
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'.)<br>
<br>
Eddy Nigg (StartCom Ltd.) wrote:
<blockquote cite="mid:4833619E.8030506@startcom.org" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
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 moz-do-not-send="true"
href="http://www.startcom.org">StartCom Ltd.</a></td>
</tr>
<tr>
<td>Jabber: </td>
<td><a moz-do-not-send="true" href="xmpp:startcom@startcom.org">startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<br>
</body>
</html>