[OpenID] One-Click OpenID: A Solution to the NASCAR Problem

[Francisco Corella]

Melvin,

> > FYI:
> >
> > One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> > http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> 
> myopenid.com (Janrain)  has been doing this since 2008 I believe
> 
> Add an SSL Client Certificate
> 
> Click the button below to install a secure client certificate into
> your Web browser. Your browser will use your certificate to prove your
> identity to myOpenID using Transport Layer Security, or TLS. Using
> this certificate avoids the necessity to enter any sensitive
> information, such as your password.
> 
> I just checked I still have mine:
> 
> You have the following certificates:
> Label     Serial Number     Created     Revoked
> home     F05F     2009-01-13 10:53:04.808190     Revoke this
> Certificate
> 
> WebID also has done some work with X.509.
> 
> Francisco, have you had a look at BrowserID?  That is also a single
> button login.

I didn't know that myopenid lets you use a certificate.  That's cool,
I'll use it myself.  And I'll mention it in the pilot proposal.
Thanks for telling me.

Yes, I've looked at BrowserID, it's interesting.  There are things
that I don't like, but the core concept is good.

I don't like the positioning as the universal ID for the Web.  You may
want to log in to sites without disclosing your email address.

I don't like the idea of creating a new kind of public key certificate
and using JavaScript to submit it to the relying party.  It's
difficult to secure the JavaScript environment (if at all possible).

I like the idea of having a webmail service provider issue a
certificate that relying parties can use to verify the user's email
address.

Btw, in the long term, I think the best solution is for the browser to
present a certificate directly to the relying party (not necessarily
an email address certificate), so that the certificate issuer is not
informed of how the certificate is used.  (The certificate should be
submitted to the relying party as a TLS client certificate, with the
certificate sent after the handshake, as recently discussed in the TLS
WG.)  What I'm proposing can be seen as a way for the relying party to
offload certificate verification to the issuer.  That's simpler for
the relying party, and it provides an immediate solution to the
certificate revocation problem, while waiting for a better solution
down the road.

Francisco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120216/760060a0/attachment.html>