<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">Melvin,<br><br>> > FYI:<br>> ><br>> > One-Click OpenID: A Solution to the NASCAR Problem, blog post at<br>> > http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/<br>> <br>> myopenid.com (Janrain) has been doing this since 2008 I believe<br>> <br>> Add an SSL Client Certificate<br>> <br>> Click the button below to install a secure client certificate into<br>> your Web browser. Your browser will use your certificate to prove your<br>> identity to myOpenID using Transport Layer Security, or TLS. Using<br>> this certificate avoids the necessity to enter any sensitive<br>> information, such as your password.<br>> <br>> I just checked I still have mine:<br>> <br>> You have the following certificates:<br>> Label
Serial Number Created Revoked<br>> home F05F 2009-01-13 10:53:04.808190 Revoke this<br>> Certificate<br>> <br>> WebID also has done some work with X.509.<br>> <br>> Francisco, have you had a look at BrowserID? That is also a single<br>> button login.<br><br>I didn't know that myopenid lets you use a certificate. That's cool,<br>I'll use it myself. And I'll mention it in the pilot proposal.<br>Thanks for telling me.<br><br>Yes, I've looked at BrowserID, it's interesting. There are things<br>that I don't like, but the core concept is good.<br><br>I don't like the positioning as the universal ID for the Web. You may<br>want to log in to sites without disclosing your email address.<br><br>I don't like the idea of creating a new kind of public key certificate<br>and using JavaScript to
submit it to the relying party. It's<br>difficult to secure the JavaScript environment (if at all possible).<br><br>I like the idea of having a webmail service provider issue a<br>certificate that relying parties can use to verify the user's email<br>address.<br><br>Btw, in the long term, I think the best solution is for the browser to<br>present a certificate directly to the relying party (not necessarily<br>an email address certificate), so that the certificate issuer is not<br>informed of how the certificate is used. (The certificate should be<br>submitted to the relying party as a TLS client certificate, with the<br>certificate sent after the handshake, as recently discussed in the TLS<br>WG.) What I'm proposing can be seen as a way for the relying party to<br>offload certificate verification to the issuer. That's simpler for<br>the relying party, and it provides an immediate solution to the<br>certificate revocation problem,
while waiting for a better solution<br>down the road.<br><br>Francisco<br><br></div></body></html>