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

Dirk Balfanz balfanz at
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:


On Wed, May 13, 2009 at 7:43 PM, John Bradley <jbradley at> 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.
> and 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 wrote:
> Date: Tue, 12 May 2009 23:10:38 -0700
> From: Luke Shepard <lshepard at>
> Subject: Should we recommend that return_to url is always HTTPS? What
> about realm?
> To: OpenID Specs Mailing List <specs at>
> Message-ID: <C62FB26E.BCE7%lshepard at<C62FB26E.BCE7%25lshepard at>
> 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
> 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
> for posting to an insecure form.
> Here's an example:
> - realm:
> - return_to:
> - provider endpoint:
> Let's suppose that the response is too long for a GET redirect, so the
> 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
> want to make sure their receiver is HTTPS.
> Alternative
> What do you think about loosening the realm/return_to protocol/domain
> 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
> low an HTTPS return_to if the realm was HTTP? It seems that the HTTP
> n of the realm would be better, and should be able to mean "accept either
> rotocol". Or better yet, you should be able to specify a realm without a
> otocol at all.
> Thoughts?
> _______________________________________________
> specs mailing list
> specs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the specs mailing list