<div dir="ltr">Of course, XRIs have most of these problems already solved. :)<br><br><div class="gmail_quote">On Tue, Aug 12, 2008 at 6:09 AM, Gerald Beuchelt <span dir="ltr"><<a href="mailto:beuchelt@sun.com">beuchelt@sun.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Martin Atkins wrote:<br>
> I apologise for the fact that I misunderstood what you were doing in my<br>
> initial response; I thought you were coming at this from the RP's<br>
> perspective, not the OP's.<br>
><br>
><br>
</div> Yes, I do mostly look at this issue from the OP/IdP site.<br>
<div class="Ih2E3d">> Really this is a specific form of the general problem of how to<br>
> automatically migrate from one identifier to another. Manually updating<br>
> all RPs you've used can be an arduous process, and some RPs don't even<br>
> allow the identifier(s) associated with an account to be changed.<br>
><br>
><br>
</div> Which is a huge problem, IMHO.<br>
<div class="Ih2E3d">> However, I really don't like the idea of OpenID contradicting the<br>
> established rules for URI normalization. I think if RPs are going to<br>
> have to change anyway, it'd be better to introduce some explicit and<br>
> general mechanism for automatic identifier switching on login. However,<br>
> until most RPs are updated, neither approach is going to be very useful.<br>
><br>
><br>
</div> As I said, I would most likely prefer a solution like that; at the<br>
same time it seems easier to me to only allow a simple mapping between<br>
http and https versions. I'd rather have a quick and dirty solution to<br>
problem that can be ultimately extended to a more graceful solution,<br>
than engineer the problem for 6 months and leave the security hole open.<br>
Nevertheless, a generic identifier re-association would probably be the<br>
best solution.<br>
<div class="Ih2E3d">> What we could really do with is a way to work around this where only the<br>
> OP would have to change. One approach could be to have the identifier<br>
> URL *not* redirect to the https: version, but have the OP UI give the<br>
> user the option of whether to use http: or https: for the eventual<br>
> assertion. Under OpenID 2.0, the OP is allowed to send an assertion to<br>
> and RP without an explicit request, so this would be permitted although<br>
> perhaps unexpected on the part of RPs. The OP could remember which sites<br>
> the user selected non-SSL for and make that the default next time. The<br>
> main downsite of this approach, of course, is that the discovery process<br>
> no longer has the protection of SSL, and is therefore vulnerable to<br>
> attacks such as the DNS one.<br>
><br>
><br>
</div> Yes. IMHO, for *any* future version of the protocol or its<br>
extensions, secure discovery should be REQUIRED--everything else leave<br>
the door open to more vulnerabilities.<br>
<br>
Best,<br>
<font color="#888888"><br>
Gerald<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<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>