<div dir="ltr">Say... I just checked to see if I have a Claimed Identifier for each blog post I've written, courtesy of Google, who adds an openid.server tag to my blog for free... (which I never use, but hey)...<div><br>
</div><div>Their solution, since they couldn't very well redirect every specific post page back to my blog home page for the sake of openID, is to only include the openid.server REL tag on my home page and not any other.</div>
<div><br></div><div>That leads me to an interesting suggestion: rather than OPs redirecting identity pages to https: automatically, why not display their identity page at http: the way the user typed it, but tell them "this page only functions as your identity page when you use https:" The redirect is fine, unless the RP's DNS server is poisoned, then suddenly the user's "secure" identifier of "<a href="http://aarnott.pip.verisign.com">aarnott.pip.verisign.com</a>" is not secure any more because the http: that would normally redirect could be hosted by a bad server that doesn't redirect, pretend to be the OP and and phish the credentials from the user. </div>
<div><br></div><div>Contrast this to just not redirecting and not emitting openid identity tags or XRDS references on the non-encrypted identity page. Thus forcing the user into the habit of typing https:// in front of their URL, and protecting themselves <span class="Apple-style-span" style="font-style: italic;">always</span> from a DNS poisoning attack... especially for when the attack is actually in progress.</div>
<div><br></div><div>Thoughts?<br><div><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 1:32 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">Joe Tele wrote:<br>
><br>
> --- On Wed, 9/3/08, SitG Admin <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>> wrote:<br>
><br>
>>> We are using the claimed identifier as a key in our database to<br>
>>> identify credentials for a user.<br>
><br>
>> Ouch. This will make things confusing (and potentially a security<br>
>> risk) in the case of, for example, <a href="https://me.yahoo.com/" target="_blank">https://me.yahoo.com/</a> - I've been<br>
>> worrying over the same problem recently, and recommend borrowing an<br>
>> idea from MemCache: make a hash of each claimed ID *and* final ID<br>
>> (since Yahoo will declare a different actual ID) for lookup.<br>
><br>
> I don'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. The claimed id will be returned in the positive assertion. I'm eager to get our implementation correct, so I appreciate any other help to set me straight. I actually like the model where the OP selects the claimed id.<br>
<br>
</div>I think your understanding is correct. The specification distinguishes<br>
between an OpenID Identifier and an "OP Identifier";<br>
<a href="http://me.yahoo.com/" target="_blank">http://me.yahoo.com/</a> is the latter. As the spec describes, when the user<br>
enters an OP identifier the user's identifier temporarily becomes a<br>
magic value given in the spec and is later set to be the identifier<br>
provided by the OP in the positive assertion.<br>
<div class="Ih2E3d"><br>
>>> However, it seems that some sites have virtually infinite number of ><br>
>> claimed identifiers for the same OP Local Id.<br>
><br>
>> There was a thread last month (from the 3rd to the 5th) about "URI<br>
>> normalization and capitalization", I recommend that you look in the<br>
>> list archives and read that too.<br>
><br>
> Got it. Our URLs are following the normalization rules.<br>
><br>
> It seems that the OPs have a much greater obligation than they may realize to normalize their claimed identifiers. It will be to their user's detriment if they do not. I guess a power of OpenId is when the OPs which behave well to their users survive and the others whither.<br>
><br>
<br>
</div>It is true that many OPs are currently not doing much if any<br>
normalization on identifiers. However, since it is the OP that is<br>
responsible for parsing the identifier or otherwise mapping it onto a<br>
user account it seems to me to be most correct for the OP to be<br>
responsible for normalizing it too.<br>
<br>
This can cause some pain if the OP doesn't do it from the start; when<br>
LiveJournal.com initially implemented OpenID its users all had two or<br>
three different identifiers that were all distinct as per the OpenID<br>
specification. LiveJournal later switched to normalizing to a particular<br>
URL scheme, which caused pain for users that had already used the<br>
"wrong" URL scheme and were no longer able to access their accounts at RPs.<br>
<br>
This would be a good topic to address in a hypothetical "OP best<br>
practices" document. Hopefully it's being included in the OpenID book(s)<br>
that are currently being written.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br></div></div></div>