<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Breno,<div><br></div><div>I agree completely RP discovery over https: or with dsig is the best option. </div><div>I have been pushing people to take RP discovery seriously for some time.</div><div><br></div><div>Some day we should stop talking about 2.1 and start work.</div><div><br></div><div>Until then we have to live with a number of "bone-headed" things in 2.0.</div><div><br></div><div>John B.<br><div><div>On 14-May-09, at 1:18 PM, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>The realm and return_to URL matching is the most bone-headed part of<br>the whole 2.0 spec.<br><br>If discovery on the realm were to produce an XRDS document that<br>contains a return_to URL and the return_to URL discovered matches the<br>one present in the authentication request, than this should be<br>considered a match. Prefix matching should be optional in general<br>(MAY) and only mandatory (MUST) _if_ the realm does not support XRDS<br>discovery.<br><br>We can then separate algorithmic considerations of correctness from<br>security considerations. The current approach in OpenID discovery is<br>not particularly secure and very inflexible. Opening up this issue for<br>discussion by making the above-suggested minimal change can only be a<br>good thing.<br><br><br>On Thu, May 14, 2009 at 9:29 AM, John Bradley <<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>> wrote:<br><blockquote type="cite">Luke,<br></blockquote><blockquote type="cite">From a URI point of view the two URI are different and it can't<br></blockquote><blockquote type="cite">be considered steeping up security.<br></blockquote><blockquote type="cite">I understand that is what would normally happen but it violates some basic<br></blockquote><blockquote type="cite">principals.<br></blockquote><blockquote type="cite">It also compromises RP discovery.<br></blockquote><blockquote type="cite">A wijldcard in the realm may be the better solution. Though you may not<br></blockquote><blockquote type="cite">want to include matching all protocols.<br></blockquote><blockquote type="cite">In the other thread we are discussing PPID like identifiers. If they are<br></blockquote><blockquote type="cite">based on the realm as people are discussing, introducing wildcards etc<br></blockquote><blockquote type="cite">introduces the question of realm normalization on that side.<br></blockquote><blockquote type="cite">John Bradley<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 14-May-09, at 11:25 AM, Luke Shepard wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So, RP delegation sounds like a very general solution to the problem, and<br></blockquote><blockquote type="cite">seems okay to push for. But I think there’s a much simpler solution that<br></blockquote><blockquote type="cite">solves the specific problem I described below:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">RULE:<br></blockquote><blockquote type="cite"> If the realm is http, then the return_to can be either http or https.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So this would be legal:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">realm: <a href="http://open.lukeshepard.com/">http://open.lukeshepard.com/</a><br></blockquote><blockquote type="cite">return_to: <a href="https://open.lukeshepard.com/openid/receiver.php">https://open.lukeshepard.com/openid/receiver.php</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This would NOT be legal – you can’t go the other way.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">realm: <a href="https://open.lukeshepard.com/">https://open.lukeshepard.com/</a><br></blockquote><blockquote type="cite">return_to: <a href="http://open.lukeshepard.com/openid/receiver.php">http://open.lukeshepard.com/openid/receiver.php</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">So, the receiver should be allowed to INCREASE its security level from the<br></blockquote><blockquote type="cite">realm, but not decrease.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This is analogous to wildcards for the protocol instead of just subdomain.<br></blockquote><blockquote type="cite">Another alternative would be to have explicit wildcards for the protocol, or<br></blockquote><blockquote type="cite">to allow realms with relative protocols, like:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">explicit wildcard: *://open.lukeshepard.com<br></blockquote><blockquote type="cite">relative protocol: //open.lukeshepard.com<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 5/14/09 7:19 AM, "John Bradley" <<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>> wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I agree that RP delegation should be possible and even desirable.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">To do that safely the OP needs to do RP discovery over SSL or discover a XRD<br></blockquote><blockquote type="cite">with detached sig for the RP.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Otherwise you open up Man in the Middle attacks.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">My point was that in the existing spec to prevent interception of tokens and<br></blockquote><blockquote type="cite">attributes, the Realm that is displayed by the OP to the user needs to<br></blockquote><blockquote type="cite">match where the assertion is sent.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I agree that this is something that should be addressed in openID 2.1 ether<br></blockquote><blockquote type="cite">for XRD with dsig or via XRDS with TLS.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">John B.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I don't see why a realm shouldn't be able to delegate to a return_to URL the<br></blockquote><blockquote type="cite">same way that a user id can delegate to an OP endpoint. This includes<br></blockquote><blockquote type="cite">delegating from http to https, or even to a different domain altogether.<br></blockquote><blockquote type="cite">Over on the XRI TC we've been talking about how to do this securely, e.g.,<br></blockquote><blockquote type="cite">by signing the XRD that does the delegation:<br></blockquote><blockquote type="cite"><a href="http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile">http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Dirk.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Wed, May 13, 2009 at 7:43 PM, John Bradley <<a href="mailto:jbradley@mac.com">jbradley@mac.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Luke,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Realm was called trust_root in 1.1, and is a bit like audience restriction<br></blockquote></blockquote><blockquote type="cite"> > in SAML.<br></blockquote><blockquote type="cite"><blockquote type="cite">It is the display version of the return_to, and also used for RP discovery<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">by the OP.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I am not certain what the problem is with it being https: if the return_to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is https:.<br></blockquote></blockquote><blockquote type="cite"> > There is explicitly no connection to be inferred by DNS authority between<br></blockquote><blockquote type="cite"><blockquote type="cite">URI differing in scheme.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Differentiating TLS by its own scheme is a decision we have to live with.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The user should consent to authentication for the site they are logging<br></blockquote></blockquote><blockquote type="cite"> > into.<br></blockquote><blockquote type="cite"><blockquote type="cite"><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></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">be different sites.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If the RP has both HTTP and HTTPS the best practice would be to always use<br></blockquote></blockquote><blockquote type="cite"> > the https: version for realm so that RP discovery cant be spoofed via<br></blockquote><blockquote type="cite">DNS.<br></blockquote><blockquote type="cite"><blockquote type="cite">Regards<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">John B.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On 13-May-09, at 2:10 AM, <a href="mailto:specs-request@openid.net">specs-request@openid.net</a> wrote:<br></blockquote></blockquote><blockquote type="cite"> ><br></blockquote><blockquote type="cite"><blockquote type="cite">Date: Tue, 12 May 2009 23:10:38 -0700<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: Luke Shepard <<a href="mailto:lshepard@facebook.com">lshepard@facebook.com</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Should we recommend that return_to url is always HTTPS? What<br></blockquote></blockquote><blockquote type="cite"> > about realm?<br></blockquote><blockquote type="cite"><blockquote type="cite">To: OpenID Specs Mailing List <<a href="mailto:specs@openid.net">specs@openid.net</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Message-ID: <<a href="mailto:C62FB26E.BCE7%lshepard@facebook.com">C62FB26E.BCE7%lshepard@facebook.com</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><<a href="mailto:C62FB26E.BCE7%25lshepard@facebook.com">mailto:C62FB26E.BCE7%25lshepard@facebook.com</a>> ><br></blockquote></blockquote><blockquote type="cite"> > Content-Type: multipart/related;<br></blockquote><blockquote type="cite"><blockquote type="cite">boundary="_004_C62FB26EBCE7lshepardfacebookcom_";<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">type="multipart/alternative"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--_004_C62FB26EBCE7lshepardfacebookcom_<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Content-Type: multipart/alternative;<br></blockquote></blockquote><blockquote type="cite"> > boundary="_000_C62FB26EBCE7lshepardfacebookcom_"<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--_000_C62FB26EBCE7lshepardfacebookcom_<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Content-Type: text/plain; charset="iso-8859-1"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Content-Transfer-Encoding: quoted-printable<br></blockquote></blockquote><blockquote type="cite"> ><br></blockquote><blockquote type="cite"><blockquote type="cite">In testing my relying party, it seems clear that the return_to url SHOULD<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">lways be HTTPS. Therefore, then, the realm will always need to be HTTPS as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">well.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">If the return_to is HTTP, then if the response comes in the form of a POST<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">=<br></blockquote></blockquote><blockquote type="cite"> > from a provider that supports SSL, then the user will see a browser<br></blockquote><blockquote type="cite">warning=<br></blockquote><blockquote type="cite"><blockquote type="cite">for posting to an insecure form.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Here's an example:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- realm: <a href="http://open.lukeshepard.com/">http://open.lukeshepard.com/</a><br></blockquote></blockquote><blockquote type="cite"> > - return_to: <a href="http://open.lukeshepard.com/openid/receiver.php">http://open.lukeshepard.com/openid/receiver.php</a><br></blockquote><blockquote type="cite"><blockquote type="cite">- provider endpoint: <a href="https://www.google.com/accounts/o8/ud">https://www.google.com/accounts/o8/ud</a><br></blockquote></blockquote><blockquote type="cite"> ><br></blockquote><blockquote type="cite"><blockquote type="cite">Let's suppose that the response is too long for a GET redirect, so the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">prov=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ider chooses to POST (as Google and others sometimes do).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The user would see a warning like this:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"> > [<a href="cid:3325014638_6495490">cid:3325014638_6495490</a>]<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To preserve the user experience and avoid that popup, relying parties<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">want to make sure their receiver is HTTPS.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Alternative<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">What do you think about loosening the realm/return_to protocol/domain<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">match=<br></blockquote></blockquote><blockquote type="cite"> > requirements?<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This kinda sucks though, since it means the REALM also must be HTTPS, even<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">though the HTTP version would seem to be "canonical". I wonder, would we<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">al=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">low an HTTPS return_to if the realm was HTTP? It seems that the HTTP<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">versio=<br></blockquote></blockquote><blockquote type="cite"> > n of the realm would be better, and should be able to mean "accept either<br></blockquote><blockquote type="cite">p=<br></blockquote><blockquote type="cite"><blockquote type="cite">rotocol". Or better yet, you should be able to specify a realm without a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">pr=<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">otocol at all.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thoughts?<br></blockquote></blockquote><blockquote type="cite"> ><br></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">specs mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:specs@openid.net">specs@openid.net</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><br></blockquote></blockquote><blockquote type="cite"> ><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">specs mailing list<br></blockquote><blockquote type="cite"><a href="mailto:specs@openid.net">specs@openid.net</a><br></blockquote><blockquote type="cite"><a href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><br><br><br>-- <br>--Breno<br><br>+1 (650) 214-1007 desk<br>+1 (408) 212-0135 (Grand Central)<br>MTV-41-3 : 383-A<br>PST (GMT-8) / PDT(GMT-7)<br></div></blockquote></div><br></div></body></html>