<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Luke,<div><br></div><div>Realm was called trust_root in 1.1, and is a bit like audience restriction in SAML. </div><div><br></div><div>It is the display version of the return_to, and also used for RP discovery by the OP.</div><div><br></div><div>I am not certain what the problem is with it being https: if the return_to is https:.</div><div><br></div><div>There is explicitly no connection to be inferred by DNS authority between URI differing in scheme. </div><div>Differentiating TLS by its own scheme is a decision we have to live with.</div><div><br></div><div>The user should consent to authentication for the site they are logging into. </div><div><a href="http://open.lukesheppard.com">http://open.lukesheppard.com</a> and <a href="https://open.lukesheppard.com">https://open.lukesheppard.com</a> could be different sites.</div><div><br></div><div>If the RP has both HTTP and HTTPS the best practice would be to always use the https: version for realm so that RP discovery cant be spoofed via DNS.</div><div><br></div><div>Regards</div><div>John B.</div><div><br></div><div><div><div>On 13-May-09, at 2:10 AM, <a href="mailto:specs-request@openid.net">specs-request@openid.net</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: -webkit-monospace; font-size: 10px; ">Date: Tue, 12 May 2009 23:10:38 -0700<br>From: Luke Shepard <<a href="mailto:lshepard@facebook.com">lshepard@facebook.com</a>><br>Subject: Should we recommend that return_to url is always HTTPS? What<br><span class="Apple-tab-span" style="white-space: pre; "> </span>about<span class="Apple-tab-span" style="white-space: pre; "> </span>realm?<br>To: OpenID Specs Mailing List <<a href="mailto:specs@openid.net">specs@openid.net</a>><br>Message-ID: <<a href="mailto:C62FB26E.BCE7%lshepard@facebook.com">C62FB26E.BCE7%lshepard@facebook.com</a>><br>Content-Type: multipart/related;<br><span class="Apple-tab-span" style="white-space: pre; "> </span>boundary="_004_C62FB26EBCE7lshepardfacebookcom_";<br><span class="Apple-tab-span" style="white-space: pre; "> </span>type="multipart/alternative"<br><br>--_004_C62FB26EBCE7lshepardfacebookcom_<br>Content-Type: multipart/alternative;<br><span class="Apple-tab-span" style="white-space: pre; "> </span>boundary="_000_C62FB26EBCE7lshepardfacebookcom_"<br><br>--_000_C62FB26EBCE7lshepardfacebookcom_<br>Content-Type: text/plain; charset="iso-8859-1"<br>Content-Transfer-Encoding: quoted-printable<br><br>In testing my relying party, it seems clear that the return_to url SHOULD a=<br>lways be HTTPS. Therefore, then, the realm will always need to be HTTPS as =<br>well.<br><br>If the return_to is HTTP, then if the response comes in the form of a POST =<br>from a provider that supports SSL, then the user will see a browser warning=<br>for posting to an insecure form.<br><br>Here's an example:<br><br>- realm:<span class="Apple-converted-space"> </span><a href="http://open.lukeshepard.com/">http://open.lukeshepard.com/</a><br>- return_to:<span class="Apple-converted-space"> </span><a href="http://open.lukeshepard.com/openid/receiver.php">http://open.lukeshepard.com/openid/receiver.php</a><br>- provider endpoint:<span class="Apple-converted-space"> </span><a href="https://www.google.com/accounts/o8/ud">https://www.google.com/accounts/o8/ud</a><br><br>Let's suppose that the response is too long for a GET redirect, so the prov=<br>ider chooses to POST (as Google and others sometimes do).<br><br>The user would see a warning like this:<br><br>[<a href="cid:3325014638_6495490">cid:3325014638_6495490</a>]<br><br>To preserve the user experience and avoid that popup, relying parties would=<br>want to make sure their receiver is HTTPS.<br><br>Alternative<br><br>What do you think about loosening the realm/return_to protocol/domain match=<br>requirements?<br><br>This kinda sucks though, since it means the REALM also must be HTTPS, even =<br>though the HTTP version would seem to be "canonical". I wonder, would we al=<br>low an HTTPS return_to if the realm was HTTP? It seems that the HTTP versio=<br>n of the realm would be better, and should be able to mean "accept either p=<br>rotocol". Or better yet, you should be able to specify a realm without a pr=<br>otocol at all.<br><br>Thoughts?</span></blockquote></div><br></div></body></html>