Should we recommend that return_to url is always HTTPS? What about realm?

Dirk Balfanz balfanz at google.com
Thu May 14 04:24:51 UTC 2009


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:
http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile

Dirk.

On Wed, May 13, 2009 at 7:43 PM, John Bradley <jbradley at mac.com> wrote:
> Luke,
> Realm was called trust_root in 1.1, and is a bit like audience restriction
> in SAML.
> It is the display version of the return_to, and also used for RP discovery
> by the OP.
> I am not certain what the problem is with it being https: if the return_to
> is https:.
> There is explicitly no connection to be inferred by DNS authority between
> URI differing in scheme.
> Differentiating TLS by its own scheme is a decision we have to live with.
> The user should consent to authentication for the site they are logging
> into.
> http://open.lukesheppard.com and https://open.lukesheppard.com could
> be different sites.
> 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.
> Regards
> John B.
> On 13-May-09, at 2:10 AM, specs-request at openid.net wrote:
>
> Date: Tue, 12 May 2009 23:10:38 -0700
> From: Luke Shepard <lshepard at facebook.com>
> Subject: Should we recommend that return_to url is always HTTPS? What
> about realm?
> To: OpenID Specs Mailing List <specs at openid.net>
> Message-ID: <C62FB26E.BCE7%lshepard at facebook.com<C62FB26E.BCE7%25lshepard at facebook.com>
>
> Content-Type: multipart/related;
> boundary="_004_C62FB26EBCE7lshepardfacebookcom_";
> type="multipart/alternative"
>
> --_004_C62FB26EBCE7lshepardfacebookcom_
> Content-Type: multipart/alternative;
> boundary="_000_C62FB26EBCE7lshepardfacebookcom_"
>
> --_000_C62FB26EBCE7lshepardfacebookcom_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> In testing my relying party, it seems clear that the return_to url SHOULD
a=
> lways be HTTPS. Therefore, then, the realm will always need to be HTTPS as
=
> well.
>
> If the return_to is HTTP, then if the response comes in the form of a POST
=
> from a provider that supports SSL, then the user will see a browser
warning=
> for posting to an insecure form.
>
> Here's an example:
>
> - realm: http://open.lukeshepard.com/
> - return_to: http://open.lukeshepard.com/openid/receiver.php
> - provider endpoint: https://www.google.com/accounts/o8/ud
>
> Let's suppose that the response is too long for a GET redirect, so the
prov=
> ider chooses to POST (as Google and others sometimes do).
>
> The user would see a warning like this:
>
> [cid:3325014638_6495490]
>
> To preserve the user experience and avoid that popup, relying parties
would=
> want to make sure their receiver is HTTPS.
>
> Alternative
>
> What do you think about loosening the realm/return_to protocol/domain
match=
> requirements?
>
> This kinda sucks though, since it means the REALM also must be HTTPS, even
=
> though the HTTP version would seem to be "canonical". I wonder, would we
al=
> low an HTTPS return_to if the realm was HTTP? It seems that the HTTP
versio=
> n of the realm would be better, and should be able to mean "accept either
p=
> rotocol". Or better yet, you should be able to specify a realm without a
pr=
> otocol at all.
>
> Thoughts?
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090513/b7ac2841/attachment.htm>


More information about the specs mailing list