<div dir="ltr">Are you using .NET? DotNetOpenId has a RequireSsl switch for its RP component that enforces SSL protection through the entire pipeline.<div><br></div><div>But whether you're using .NET or not, there is interestingly much more than you mentioned to ensure is protected with SSL. Here is the complete list that I built into DNOI: (I've bolded the couple that are less obvious but just as important)</div>
<div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <list></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item>User-supplied identifiers lacking a scheme are prepended with</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/// HTTPS:// rather than the standard HTTP:// automatically.</item></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item>User-supplied identifiers are not allowed to use HTTP for the scheme.</item></div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item><span class="Apple-style-span" style="font-weight: bold;">All redirects during discovery </span>on the user-supplied identifier must be HTTPS.</item></div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item><span class="Apple-style-span" style="font-weight: bold;">Any XRDS file found by discovery </span>on the User-supplied identifier must be protected using HTTPS.</item></div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item>Only Provider endpoints found at HTTPS URLs will be considered.</item></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item>If the discovered identifier is an OP Identifier (directed identity), the </div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/// Claimed Identifier eventually asserted by the Provider must be an HTTPS identifier.</item></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/// <item>In the case of an unsolicited assertion, the asserted Identifier, discovery on it and </div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/// the asserting provider endpoint must all be secured by HTTPS.</item></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/// </list></div>
<div><br></div><div>This, I believe, would be good for all RP libraries to implement.</div><br><div class="gmail_quote">On Fri, Sep 5, 2008 at 12:45 PM, Joe Tele <span dir="ltr"><<a href="mailto:pnwtele@yahoo.com">pnwtele@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I realize and buy the arguments that http and https claimed ids should represent separate identities. I am having some difficulty with various OPs in the wild and their differences.<br>
<br>
We want our RP to only accept secure identifiers: User supplied identifiers, claimed identifiers, and OP endpoints.<br>
<br>
Is there a recommended practice for when an OP can serve up a secure claimed identifer vs an insecure (https vs http)? I am encountering varying behavior. We would like to vet and white list acceptable OPs.<br>
<br>
Take myvidoop for example. If the user supplied identifier is <a href="https://whatever.myvidoop.com" target="_blank">https://whatever.myvidoop.com</a> then we resolve an https claimed id. However, if the user enters the OP identifer <a href="https://myvidoop.com" target="_blank">https://myvidoop.com</a> (secure), myvidoop returns an insecure (http) identifier. The protocol started out secure and subsequently downgraded. This seems unacceptable to me and confusing to the consumer.<br>
<br>
There seems to be wide latitude in how to represent the OP identifier when asking the OP to choose an identifier for the user. Yahoo will accept simply <a href="http://yahoo.com" target="_blank">yahoo.com</a>, the same with <a href="http://myvidoop.com" target="_blank">myvidoop.com</a>. But another OP we have tried <a href="http://myopenid.com" target="_blank">myopenid.com</a> does not have a valid certicate for that address, requiring the user to type in <a href="http://www.myopenid.com" target="_blank">www.myopenid.com</a>. I can only see user frustration arising out of this. I suppose users will learn what their provider's needs but certificate failures could chase away potential users from our site.<br>
<br>
I have been looking the provider list at <a href="http://openid.net/get/" target="_blank">http://openid.net/get/</a>, is this a good list for "top-tier" providers?<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</blockquote></div><br></div></div>