[OpenID] http and https...again

[Joe Tele]

Hi Andrew,

No we aren't using the DotNetOpenId library.  It did not pass our security review (perhaps with time we could roll some ideas over into the library).  That said, the time to implement the library isn't dominating our time.  It's trying to wrap our heads around the vast differences afloat in the OP implementations. 

We are feeling like we have to put too many restrictions on OpenId to serve our purposes and may either alienate users, confuse them, or totally subvert the principles. 

Inconsistencies around claimed_id vs. user supplied identifiers at the OP, lack of http and https coherence, and concerns about recycled identifiers through HTML discovery have been uncovered in our first week of looking at OpenId.  There doesn't seem to be a gold-standard provider or known best practices for OPs.  RPs seem straight forward at this point.



--- On Fri, 9/5/08, Andrew Arnott <andrewarnott at gmail.com> wrote:

> From: Andrew Arnott <andrewarnott at gmail.com>
> Subject: Re: [OpenID] http and https...again
> To: pnwtele at yahoo.com
> Cc: general at openid.net
> Date: Friday, September 5, 2008, 3:46 PM
> 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
> >