This is an interesting topic.<div><br></div><div>Another approach that has been suggested is two preserve the identifier formats, but assign different security levels depending on how they were authenticated (assuming that the RP is security-sensitive at all).</div>
<div><br></div><div>One level could be assigned to http identifiers and https identifiers based on discovery without signatures.</div><div><br></div><div>A higher security level could be assigned to http and https identifiers where discovery was validated via signatures.</div>
<div><br></div><div>So, if an RP notices that an account is usually logged in through a higher security mechanism but now it is following a lower security one, then this could be considered a downgrade of security level. Typically one would employ a suitable account recovery process to validate that this is a legitimate login attempt as opposed to a possible hijacking.</div>
<div><br><div class="gmail_quote">On Thu, Jul 16, 2009 at 7:21 AM, Manger, James H <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-AU" link="blue" vlink="purple">
<div>
<p>If we do end up with dual discovery paths:</p>
<p style="text-indent:-18.0pt"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span>making a GET request directly to an OpenID identifier; or</p>
<p style="text-indent:-18.0pt"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span>following a decoupled discovery path (eg request to Google) backed by trusted signatures on the resultant XRDS files;</p>
<p>then an OpenID login can be compromised by either path.</p>
<p> </p>
<p>A motivation for path #2 was that it is hard for a small business to make its website extremely secure from attacks that could modify web pages. However, even RPs that try path #2 will also try path #1 (unless we totally ditch OpenID 1.1
& 2.0 support!) so attacks modifying a small business’s web pages can still compromise their OpenID logins.</p>
<p> </p>
<p> </p>
<p>One way to prevent dual paths reducing security for each other would be if each path applied to different OpenID identifiers. That is, only use path #1 for http & https OpenID identifiers; and use some other form of OpenID identifier for
path #2.</p>
<p> </p>
<p> </p>
<p><b><span lang="FR" style="font-size:12.0pt">James Manger</span></b><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
<br>
</span><u><span lang="FR" style="font-size:10.0pt;color:blue"><a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.com</a></span></u><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
<br>
</span><span style="font-size:10.0pt">Identity and security team</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
</span><span style="font-size:10.0pt">—</span><span style="font-size:10.0pt"> Chief Technology Office</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
</span><span style="font-size:10.0pt">—</span><span style="font-size:10.0pt"> Telstra</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
</span></p>
</div>
</div>
<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>
<br></blockquote></div><br><br clear="all"><br>-- <br>--Breno<br><br>+1 (650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A <br>PST (GMT-8) / PDT(GMT-7)<br>
</div>