Eric,<br><br>There is indeed a bug somewhere in the OpenID auth process for <a href="https://ejnorman.protectnetwork.org/" target="_blank">https://ejnorman.protectnetwork.org</a>. Here is what's going on:<br><ol><li>Discovery on <a href="https://ejnorman.protectnetwork.org/" target="_blank">https://ejnorman.protectnetwork.org</a> tells the RP the following information (among other unlisted data):</li>
<ol><li>The Provider implements OpenID 1.x (a 2.0 RP recognizes that this is a 1.0 Provider because the tag is openid.server instead of openid2.provider)<br></li><li>The OP Local Identifier is <a href="https://ejnorman.protectnetwork.org">https://ejnorman.protectnetwork.org</a>, because there is no openid.identity tag in the identity page and therefore the Claimed Identifier implicitly assumed per the spec.<br>
</li></ol><li>The RP crafts an OpenID request asking the provider to assert an identity for <a href="https://ejnorman.protectnetwork.org/" target="_blank">https://ejnorman.protectnetwork.org</a></li><li>(user authentication at the OP, beyond control of the RP)<br>
</li><li>The OP is then sending a positive assertion for <a href="http://ejnorman.protectnetwork.org">http://ejnorman.protectnetwork.org</a> (note the <b>lack</b> of the HTTPS scheme). This means the Provider doesn't support sending assertions for HTTPS claimed identifiers because although the RP asked it to, it refused and changed it to an insecure claimed identifier.</li>
<li>The RP receives the assertion, notices that the local identifier (openid.identity) has changed from HTTPS to HTTP. This contradicts what the RP's earlier discovery told it about the HTTPS claimed id and therefore fails because the spec mandates that the asserted info matches the discovered info.<br>
</li></ol>As far as I can brainstorm right now, there is exactly one correct solution to this problem:<br>Add an openid.identity tag to your identity page with a value of <a href="http://ejnorman.protectnetwork.org">http://ejnorman.protectnetwork.org</a> so that the discovery data matches the asserted data.<br>
<br>At first I thought that I could fix dotnetopenid so that when dealing with 1.0 OPs it could perform discovery again on the new openid.identity value and allow that new data to match the asserted data and then let the user log in. But on further thought I don't think this would be a secure and true interpretation of the spec. See, if the user types in <a href="https://ejnorman.protectnetwork.org/" target="_blank">https://ejnorman.protectnetwork.org</a>/, then the claimed identifier in this case is exactly that URL because no redirects occur. When the assertion comes back for the non-SSL openid.identity, even if the RP did discovery on the <a href="https://ejnorman.protectnetwork.org/" target="_blank">http://ejnorman.protectnetwork.org</a> (non-SSL) url, that would be of no use to the original Claimed Identifier. The only thing the RP could safely do at that point is proceed to log in the user as if their claimed identifier was the HTTP one rather than the HTTPS one. But this isn't what the user typed in or presumably wanted.<br>
<br>So what we have here is a misconfigured identity page, in my opinion. And the fix is (happily) quite easy.<br><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Thu, Jan 1, 2009 at 2:18 PM, Eric Norman <span dir="ltr"><<a href="mailto:ejnorman@doit.wisc.edu">ejnorman@doit.wisc.edu</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"><br>
On Jan 1, 2009, at 2:45 PM, Andrew Arnott wrote:<br>
<br>
> Eric,<br>
> <br>
> I believe it is exactly the problem that Peter is facing.<br>
> <br>
> Regarding the behavior you saw, Eric, DotNetOpenId doesn't ever demote<br>
> https to http (or if so it would be a bug), but it will go through all<br>
> endpoints listed for a given OpenID and chooses from among that list. <br>
> So if your OpenID has multiple service endpoints listed (through an<br>
> XRDS file) can you check whether a non HTTPS OP Endpoint is among the<br>
> list?<br>
<br>
</div>The address bar said http, but I might have looked<br>
to quickly. It could have been protectnetwork that<br>
did the demotion.<br>
<div class="Ih2E3d"> <br>
> I'd very much like to know the particular OpenID you were trying it<br>
> with so I can examine the behavior if you'd care to share (perhaps off<br>
> the list if you wish).<br>
<br>
</div><a href="https://ejnorman.protectnetwork.org" target="_blank">https://ejnorman.protectnetwork.org</a><br>
<br>
This has worked at some OpenID sites in the past.<br>
<br>
In any case, there's certainly a bug somewhere since<br>
the error message I quoted is complaining about<br>
something I never typed.<br>
<div><div></div><div class="Wj3C7c"><br>
Eric Norman<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>