[OpenID] http and https...again

Andrew Arnott andrewarnott at gmail.com
Fri Sep 5 22:46:32 UTC 2008


Are you using .NET?  DotNetOpenId has a RequireSsl switch for its RP
component that enforces SSL protection through the entire pipeline.
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)

/// <list>
/// <item>User-supplied identifiers lacking a scheme are prepended with
/// HTTPS:// rather than the standard HTTP:// automatically.</item>
/// <item>User-supplied identifiers are not allowed to use HTTP for the
scheme.</item>
/// <item>All redirects during discovery on the user-supplied identifier
must be HTTPS.</item>
/// <item>Any XRDS file found by discovery on the User-supplied identifier
must be protected using HTTPS.</item>
/// <item>Only Provider endpoints found at HTTPS URLs will be
considered.</item>
/// <item>If the discovered identifier is an OP Identifier (directed
identity), the
/// Claimed Identifier eventually asserted by the Provider must be an HTTPS
identifier.</item>
/// <item>In the case of an unsolicited assertion, the asserted Identifier,
discovery on it and
/// the asserting provider endpoint must all be secured by HTTPS.</item>
/// </list>

This, I believe, would be good for all RP libraries to implement.

On Fri, Sep 5, 2008 at 12:45 PM, Joe Tele <pnwtele at yahoo.com> wrote:

> 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.
>
> We want our RP to only accept secure identifiers:  User supplied
> identifiers, claimed identifiers, and OP endpoints.
>
> 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.
>
> Take myvidoop for example.  If the user supplied identifier is
> https://whatever.myvidoop.com then we resolve an https claimed id.
>  However, if the user enters the OP identifer https://myvidoop.com(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.
>
> 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 yahoo.com, the same with myvidoop.com.  But another OP we have
> tried myopenid.com does not have a valid certicate for that address,
> requiring the user to type in www.myopenid.com.  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.
>
> I have been looking the provider list at http://openid.net/get/, is this a
> good list for "top-tier" providers?
>
>
>
>
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080905/0dac7e03/attachment-0001.htm>


More information about the general mailing list