<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Paul,<br><br>> I’m not entirely sure how the Janrain code works, as I’ve<br>> not really looked at it. I’m pretty sure, though, that the<br>> OP code I wrote would complain if the “return to” URL is not<br>> a sub-domain of the specified realm. It even checks to<br>> ensure that the scheme matches (e.g., HTTPS or HTTP must be<br>> used in both places). So, I would assume that the example<br>> you give below would fail on my server. Not sure, of<br>> course… there’s always opportunity for a bug ;-)<br><br>I'm sure your code checks the return_to URL correctly, and<br>the Janrain code does too. The example was not about the<br>return_to URL. What I was trying to say is that, when an<br>application hosted at example.com uses the free Janrain<br>widget, the widget
uses the realm example.rpx.com, causing<br>the OP to ask the user to trust example.rpx.com. If the<br>user were knowledgeable about domain name syntax, he/she<br>would realize that this is not the domain of the application<br>that he/she is trying to use, and he/she would refuse to go<br>ahead and trust example.rpx.com. So the point is: users are<br>not knowledgeable about domain name syntax, and the widget<br>relies on the fact that they are not.<br><br>> I do agree that HTTPS ought to be used everywhere. There<br>> are two issues with meeting that requirement. Some argue<br>> that these issues are weak arguments, but they are truly an<br>> impediment to getting wide adoption:<br>> <br>> 1) TLS certificates are still more expensive than they ought<br>> to be. We’re talking about something that can be cranked<br>> out entirely automatically and in a fraction of a second and<br>> some people
believe this “work” is worth more than $100. The<br>> cheapest price I’ve seen is $13 per certificate, which is<br>> getting close to reasonable, but still too high. The domain<br>> name cost less than the certificate! This rip-off needs to<br>> end.<br>> <br>> 2) Many, many web servers still do not support Server Name<br>> Indication (SNI). So, many web sites cannot even provide<br>> proper support for TLS. It was for this reason that I wrote<br>> my OP server code such that the only piece of software that<br>> absolutely, really should be placed behind HTTPS was the one<br>> that handles password checks and cookies for<br>> checkid_immediate.<br>> <br>> 3) Many client libraries still do not support SNI, including<br>> those running OpenID RP code. The stock browser on Android<br>> and other browsers do not support SNI.<br>> <br>> Anyway, your
statement is correct, but I think there are<br>> practical reasons why the standard did not mandate HTTPS.<br><br>The point I was trying to make is not so much that SSL is<br>not required by the spec, it's that it is not recommended for the RP,<br>whereas it is strongly recommended for the OP. And there is<br>no discussion of the matter at all in the security<br>considerations. Somebody who reads the spec may think that<br>SSL is just unnecessary for the RP. An RP that has a<br>dedicated a server and an SSL certificate used for other<br>purposes, and that would have no difficulty receiving SSL<br>connections at the return_to endpoint, may not use SSL at<br>the endpoint just because nothing in the spec says that that<br>would be helpful.<br><br>Francisco<br><br><br></td></tr></table>