<div dir="ltr">Inline...<br><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 2:04 PM, SitG Admin <span dir="ltr">&lt;<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I don&#39;t undersand your distinction between claimed Id and final ID. In the case of <a href="https://me.yahoo.com/" target="_blank">https://me.yahoo.com/</a> my understanding is that URL is not the claimed id. &nbsp;The claimed id will be returned in the positive assertion.<br>

</blockquote>
<br></div>
My understanding of what Yahoo! has done is limited, but the basic objection my mind gave to the logic was when, in transition from v1 to v2, we started losing track of what the user originally entered. I use (and insist on) cookies to keep track of the user so this can be remembered, because it just seems wrong to me that the user can type in a value that is critical to identifying them, and then we forget what that was by the time we have the new value that we&#39;re now being told is their *real* identity.</blockquote>
<div>There are multiple methods besides cookies one can use to remember the user-supplied identifier. And there is value in doing so, but only for user convenience in recognizing what they originally typed in. &nbsp;For example, if I type in &quot;=arnott&quot; to an RP, it&#39;s nice to see &quot;you&#39;re logged in as =arnott&quot; on the page instead of &quot;you&#39;re logged in as =!30ds!30df!30df!30df&quot;. &nbsp;The claimed identifier will never give you =arnott back, so it&#39;s nice to remember the user-supplied identifier.</div>
<div>I personally store the user-supplied identifier in the return_to URL as a query parameter. &nbsp;Security of it possibly being changed doesn&#39;t matter because the user typed it in in the first place, and because changing it would only change the appearance on the web page anyway...</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br>
<br>
My understanding now seems incorrect in light of what Martin Atkins said:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The specification distinguishes between an OpenID Identifier and an &quot;OP Identifier&quot;; <a href="http://me.yahoo.com/" target="_blank">http://me.yahoo.com/</a> is the latter. As the spec describes, when the user enters an OP identifier the user&#39;s identifier temporarily becomes a magic value given in the spec and is later set to be the identifier provided by the OP in the positive assertion.<br>

</blockquote>
<br></div>
The trick here is this - how do we ascertain when the user has entered a string into the single field we provide them with, that they have just entered an &quot;OP Identifier&quot; instead of their OpenID Identifier?</blockquote>
<div>That&#39;s what OpenID 2.0 spec goes in depth on. &nbsp;The answer is in there. OPs that support this feature are required to publish an XRDS doc that publish a service type URI that will tell the RP that it&#39;s an OP Identifier instead of a user identity.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
My expectation is that the value entered will BE their OpenID Identifier (or URI), and I can keep track of them this way even if their OP later (in the process) says &quot;Actually, use *this* instead.&quot; (an anonymity trick, but one that shouldn&#39;t work since the user only gets to that point after explicitly admitting its original URI to our RP!)</blockquote>
<div>No, heavens no! &nbsp;To consider the user-supplied identifier their identity opens up huge security holes. &nbsp;You cannot consider anything the user types in as their user-supplied identifier to be security safe or legally binding. &nbsp;And as in the case of directed identity, the user who types in &quot;<a href="http://yahoo.com">yahoo.com</a>&quot; has not revealed anything about their &quot;real identity&quot; to the RP before the OP asserts some &quot;anonymous&quot; URL to the RP. &nbsp;You certainly don&#39;t want to consider &quot;<a href="http://yahoo.com">yahoo.com</a>&quot; as the user&#39;s &quot;real&quot; identity URL in this case or else all Yahoo users will share one account on your RP.</div>
<div>You really must use the OP&#39;s &quot;use this instead&quot; URL. &nbsp;You&#39;ll never get the fragment if you ignore the OP&#39;s assertion, and your users will be vulnerable to URL recycling attacks and many many other issues. &nbsp;</div>
<div><br></div><div>Please, read the 2.0 spec and study the areas that discuss the security ramifications and re-discovery requirements that RPs must fulfill. It may save you and your users a lot of headache and potential bad press.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
-Shade<br>
</blockquote></div><br></div>