I don't see why a realm shouldn't be able to delegate to a return_to URL the same way that a user id can delegate to an OP endpoint. This includes delegating from http to https, or even to a different domain altogether. Over on the XRI TC we've been talking about how to do this securely, e.g., by signing the XRD that does the delegation: <a href="http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile">http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile</a><br>
<br>Dirk.<br><br>On Wed, May 13, 2009 at 7:43 PM, John Bradley <<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>> wrote:<br>> Luke,<br>> Realm was called trust_root in 1.1, and is a bit like audience restriction<br>
> in SAML. <br>> It is the display version of the return_to, and also used for RP discovery<br>> by the OP.<br>> I am not certain what the problem is with it being https: if the return_to<br>> is https:.<br>
> There is explicitly no connection to be inferred by DNS authority between<br>> URI differing in scheme. <br>> Differentiating TLS by its own scheme is a decision we have to live with.<br>> The user should consent to authentication for the site they are logging<br>
> into. <br>> <a href="http://open.lukesheppard.com">http://open.lukesheppard.com</a> and <a href="https://open.lukesheppard.com">https://open.lukesheppard.com</a> could<br>> be different sites.<br>> If the RP has both HTTP and HTTPS the best practice would be to always use<br>
> the https: version for realm so that RP discovery cant be spoofed via DNS.<br>> Regards<br>> John B.<br>> On 13-May-09, at 2:10 AM, <a href="mailto:specs-request@openid.net">specs-request@openid.net</a> wrote:<br>
><br>> 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>
> about 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%25lshepard@facebook.com">C62FB26E.BCE7%lshepard@facebook.com</a>><br>
> Content-Type: multipart/related;<br>> boundary="_004_C62FB26EBCE7lshepardfacebookcom_";<br>> type="multipart/alternative"<br>><br>> --_004_C62FB26EBCE7lshepardfacebookcom_<br>> Content-Type: multipart/alternative;<br>
> 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: <a href="http://open.lukeshepard.com/">http://open.lukeshepard.com/</a><br>
> - return_to: <a href="http://open.lukeshepard.com/openid/receiver.php">http://open.lukeshepard.com/openid/receiver.php</a><br>> - provider endpoint: <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>
> [cid:3325014638_6495490]<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?<br>
><br>> _______________________________________________<br>> specs mailing list<br>> <a href="mailto:specs@openid.net">specs@openid.net</a><br>> <a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><br>
><br>><br><br>