<HTML>
<HEAD>
<TITLE>Should we recommend that return_to url is always HTTPS? What about realm?</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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.<BR>
<BR>
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.<BR>
<BR>
Here’s an example:<BR>
<BR>
- realm: <a href="http://open.lukeshepard.com/">http://open.lukeshepard.com/</a><BR>
- return_to: <a href="http://open.lukeshepard.com/openid/receiver.php">http://open.lukeshepard.com/openid/receiver.php</a><BR>
- provider endpoint: </SPAN></FONT><FONT SIZE="2"><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:10pt'><a href="https://www.google.com/accounts/o8/ud">https://www.google.com/accounts/o8/ud</a><BR>
<BR>
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).<BR>
<BR>
The user would see a warning like this:<BR>
<BR>
<IMG src="cid:3325014638_6495490" ><BR>
<BR>
To preserve the user experience and avoid that popup, relying parties would want to make sure their receiver is HTTPS.<BR>
<BR>
<B>Alternative<BR>
</B><BR>
What do you think about loosening the realm/return_to protocol/domain match requirements? <BR>
<BR>
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.<BR>
<BR>
Thoughts?</SPAN></FONT></FONT>
</BODY>
</HTML>