<div dir="ltr">Ah. I think I understand where you're coming from a bit better now.<div><br></div><div>FYI, many non-anonymous Providers support directed identity -- I daresay any 2.0 OP either does or wants to support it for its convenience to users whether or not the claimed id becomes "anonymous". For example, I can type in "<a href="http://myopenid.com">myopenid.com</a>" to a RP 2.0 site and end up having logged in as "<a href="https://andrewarnott.myopenid.com">https://andrewarnott.myopenid.com</a>". In fact I never type in my claimed id any more. </div>
<div><br></div><div>Directed Identity can scale all the way from obvious-identity (like <a href="http://myopenid.com">myopenid.com</a> returning <a href="http://andrewarnott.myopenid.com">andrewarnott.myopenid.com</a>) to <a href="http://yahoo.com">yahoo.com</a>'s totally-crazy-looking-identity, to completely one-time-use-no-good-for-returning-to-this-RP claimedId, and an RP has no way of knowing which it is based on the OpenID protocol alone. Whitelist/blacklist of OPs is the only way to filter out OPs that make generating claimed ids too easy.</div>
<div><br></div><div>FWIW, in my opinion <a href="http://yahoo.com">yahoo.com</a> isn't any more 'anonymous' than <a href="http://myopenid.com">myopenid.com</a> Yahoo's claimed ids <span class="Apple-style-span" style="font-style: italic;">look</span> scarier, but user account names with <a href="http://myopenid.com">myopenid.com</a> could be just as meaningless. Although mine is andrewarnott, it could have been <a href="http://noGuy1.myopenid.com">noGuy1.myopenid.com</a>, which wouldn't help you any more than <a href="https://me.yahoo.com/a/cJASAdp4x5Rx6CU9olKi7rMkG1TX_7Yl1kQ-">https://me.yahoo.com/a/cJASAdp4x5Rx6CU9olKi7rMkG1TX_7Yl1kQ-</a> to figure out who this guy is or whether he's just trying to take advantage of your RP. In fact Yahoo <span class="Apple-style-span" style="font-style: italic;">can</span> issue ordinary-looking claimed IDs. It just recommends to its users when they first set up their OpenID account that the users opt out of that option.</div>
<div><br></div><div>What you're attempting in heuristically finding anonymous claimed ids is definitely interesting and in OpenID 1.x probably would have worked really well. I can't right now think of how to carry it over into 2.0 meaningfully though. :(</div>
<div><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 3:34 PM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="Ih2E3d">
<div>>No, heavens no! To consider the user-supplied
identifier their identity opens up huge security holes.</div>
<div><br></div>
</div><div>Yet that was my expectation, after looking at version 1.</div><div class="Ih2E3d">
<div><br></div>
<div>>And as in the case of directed identity,</div>
<div><br></div>
</div><div>Yes, that was one of the terms! Thanks!</div><div class="Ih2E3d">
<div><br></div>
<div>>the user who types in "<a href="http://yahoo.com" target="_blank">yahoo.com</a>" has not revealed anything
about their "real identity" to the RP before the OP asserts
some "anonymous" URL to the RP.</div>
<div><br></div>
</div><div>Exactly the problem, if I want to discourage "anonymous"
URI's; and I can track this sort of thing by looking for multiple
entries in the database that all share the same typed-in URI, enabling
me to identify URL's that are being used for Directed Identity, and
mark them to be filtered before getting to the Consumer process. This
lets me explain things to the user *before* making them go through
their authentication with Yahoo! or whoever (and whoever may be using
one-time passwords, which would *really* annoy the user).</div><div class="Ih2E3d">
<div><br></div>
<div>>You certainly don't want to consider "<a href="http://yahoo.com" target="_blank">yahoo.com</a>" as the user's "real"
identity URL in this case or else all Yahoo users will share one
account on your RP.</div>
<div><br></div>
</div><div>If that were the *only* URL that I was using, yes ;)</div><div class="Ih2E3d">
<div><br></div>
<div>>You really must use the OP's "use this instead"
URL. You'll never get the fragment if you ignore the OP's
assertion,</div>
<div><br></div>
</div><div>I assure you that I'm not ignoring it. I'm just using a standard
that suits my inadequate understanding by adding sanity checks and
erring in favor of not recognizing the same user when they switch
OP's. I figured this approach would give me time to improve my
understanding, and I wouldn't need to worry about things until I found
more than one entry with the same "use this instead" URL and
2 radically different "typed-in" URL's.</div>
<div><br></div>
<div>As described in my first reply to Joe Tele, the idea is to look
for (a hash of) the typed-in ("claimed") ID *and* the
Directed ("final") ID, requiring a match on *both* of those
strings to proceed. I designed mine this way because I didn't
understand what was going on with Directed Identity well enough to be
*certain* there weren't any risks in relying on just the Directed
identifier.</div>
<div><br></div>
<div>-Shade</div>
</div>
</blockquote></div><br></div></div>