<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
A good point that I would address by proposing not full equality of
the <a class="moz-txt-link-freetext" href="https://">https://</a> and <a class="moz-txt-link-freetext" href="http://">http://</a> identifiers, but instead have the RP perform
a one-time security 'upgrade': <br>
<br>
Assuming that the RP recognizes a particular <font
face="Courier New">claimed_id</font> e.g. <a class="moz-txt-link-freetext" href="http://openid.sun.com/user">http://openid.sun.com/user</a>.
Whenever there is a login with the same identifier over HTTPS (i.e. <font
face="Courier New">claimed_id</font> is <a class="moz-txt-link-freetext" href="https://openid.sun.com/user">https://openid.sun.com/user</a> in
the example), the RP can 'upgrade' the account to an HTTPS-only
account. <br>
<br>
On the OP side, any account for <a class="moz-txt-link-freetext" href="https://x.y.z">https://x.y.z</a> should trigger the
complete block for any <a class="moz-txt-link-freetext" href="http://x.y.z">http://x.y.z</a> ids. <br>
<br>
Best, <br>
<br>
Gerald<br>
<br>
Sam Alexander wrote:
<blockquote cite="mid:AAE016F3-9BC6-46D6-80DC-63DBE5CDBAAB@vidoop.com"
type="cite">I've had some chats about this, and it would seem one
problem would be that if an OP does not require HTTPS-only, a user
using their HTTPS identifier exclusively would suddenly become
vulnerable because if their HTTP identifier were comprised, their
entire account would be.
<div><br>
</div>
<div>-Sam</div>
<div><br class="webkit-block-placeholder">
</div>
<div>
<div>
<div>On Aug 11, 2008, at 2:44 PM, Gerald Beuchelt wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000"> In light of the recent
security issues, we have decided to <a moz-do-not-send="true"
href="http://blog.beuchelt.org/2008/08/11/Securing+OpenIDWork+Again.aspx">improve
the security</a> of our OpenID@Work service/experiment. <br>
<br>
In a nutshell, we would like to require all users to use <a
moz-do-not-send="true" class="moz-txt-link-freetext" href="https://">https://</a>
prefixed OpenID identifier, so that RPs normalize and discover over
HTTPS, instead of HTTP. The obvious issue is that -- to my knowledge --
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://openid.sun.com/user">https://openid.sun.com/user</a> != <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://openid.sun.com/user">http://openid.sun.com/user</a>. At
this point I see an opportunity for the OpenID community to address
some of the recent vulnerabilities: if RPs started to recognize both <a
moz-do-not-send="true" class="moz-txt-link-freetext" href="https://">https://</a>
and <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://">http://</a> prefixed identifiers as the same entity, or
at least allowed easy linking, users could migrate with a lot more
ease. <br>
<br>
This would be less than a mandate for SSL, but make migration a lot
less painful... Your thoughts?<br>
<br>
Gerald Beuchelt<br>
Sun Microsystems, Inc. <br>
</div>
_______________________________________________<br>
general mailing list<br>
<a moz-do-not-send="true" href="mailto:general@openid.net">general@openid.net</a><br>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>