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

Luke Shepard lshepard at facebook.com
Wed May 13 06:10:38 UTC 2009


In testing my relying party, it seems clear that the return_to url SHOULD always 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 provider 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 allow an HTTPS return_to if the realm was HTTP? It seems that the HTTP version of the realm would be better, and should be able to mean "accept either protocol". Or better yet, you should be able to specify a realm without a protocol at all.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090512/a6479555/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 96374 bytes
Desc: image.png
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090512/a6479555/attachment-0002.png>


More information about the specs mailing list