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

[John Bradley]

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.

Regards
John B.

On 13-May-09, at 2:10 AM, specs-requ...@openid.net wrote:

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.

Date: Tue, 12 May 2009 23:10:38 -0700
From: Luke Shepard <lshep...@facebook.com>
Subject: Should we recommend that return_to url is always HTTPS? What
        about   realm?
To: OpenID Specs Mailing List <specs@openid.net>
Message-ID: <c62fb26e.bce7%lshep...@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


well.


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


ider chooses to POST (as Google and others sometimes do).

The user would see a warning like this:

[cid:3325014638_6495490]


want to make sure their receiver is HTTPS.

Alternative


requirements?


otocol at all.

Thoughts?

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 = 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= Let's suppose that the response is too long for a GET redirect, so the prov= To preserve the user experience and avoid that popup, relying parties would= What do you think about loosening the realm/return_to protocol/ domain match= 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=

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs