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.

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>
> 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090513/bec08eda/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1722 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090513/bec08eda/attachment-0002.bin>