Yes. The NSTIC Identity Ecosystem should encompass pseusonymity and also anonymity. Today most of your activity on the Web, other when you pay with a credit card, is anonymous. When you log in to a site with a username and a password, you are just proving that you are
On Tue, Aug 2, 2011 at 1:43 AM, Francisco Corella <fcorella@pomcor.com> wrote: the
same user who registered earlier with the site.
In practice this is not generally so, you leak identity information all over the place. For example:
* IP address * Recovery email address * Third party tracking cookies
* Usually the IP address only tells the site what ISP you are using * You may not need a recovery email address if you don't use a password * You can configure your browser to refuse third party tracking cookies, plus Congress is working on that problem.
and so on.
As we move away from passwords we should preserve this anonymity.
No, we need to improve on it.
A simple way to achieve that is to have the Web site itself issue you a "login certificate" when you register, which you use later to log in to the site. (The certificate binds a public key to a reference to the your account at the site, internal to the site. The public key is the public key component of a key pair generated by your browser for the specific purpose of registering with that particular site, so that it cannot be used to track you.)
This has been available in browsers forever, yet it is hardly used.
This could be made available relatively easily, but it is not available yet. The browser can store a TLS client certificate and present it to the site's TLS server, but there are two problems: 1. As you know, the server can only request the certificate during the TLS handshake, by sending a CertificateRequest message. That means the user is asked for the certificate whenever she accesses the site over a secure connection, whether or not she wants to log in. Instead, the server should be able to request a certificate when the user clicks on a login button. That is, when the server receives the HTTP request resulting from the click on the login button, the server should be able should be able to request a certificate (just like now it can request a password for basic or digest authentication---which, I know, are rarely used on the Web). The browser could then respond to the request by establishing a new TLS connection and sending the certificate. For more details of how this can be done, see sections 2 and 3 of Pomcor's proposed architecture for the NSTIC ecosystem. 2. The site must be able to issue a certificate automatically when the user registers. Until recently there was no pratical way of doing this. Certificate issuing protocols (CMP, CMC, SCEP) are too complicated to be implemented by an ordinary Web site. Recently, the W3C has resurrected the old Netscape <keygen> tag and added it to HTML5; it is now used by WebID. That should provide a practical way of issuing certificates automatically once it is implemented by all browsers. In section 2 of our architecture we propose an alternative method that has the virtue of also being usable for credentials other than PKI certificates, such as U-Prove tokens or Idemix anonymous credentials.
Why?
a) UI
b) Portability.
Why haven't the above two problems been solved earlier? First, because it was easier to just use passwords. Second, because once passwords proliferated and password reuse became a problem, companies such as Facebook and your employer found it convenient to adopt a solution based on OAuth where they are informed of all the user's logins, in addition to knowing all the user's friends and everything the user tells her friends on the social site and when visiting relying parties. Which brings me back to the issue of Google and Facebook requiring real names. That allows them to combine all the information they gather by simply watching the user's logins and activities, with all the public information that's associated with the user's name. They can then sell that thorough knowledge of the user to advertisers. By the way, Google seems to be pushing OAuth, and I think that's a strategic mistake. OAuth is Facebook's main asset. OAuth requires registration of the relying party with the social site, and more and more parties will take the easy route of just registering with Facebook. Some relying parties already have no other means of logging in than the "Login with Facebook" button. That gives users an additional incentive to get a Facebook account. And the more users get Facebook accounts, the easier it becomes for relying parties to just offer "Login with Facebook". So you have a positive feedback loop that ends when every user has a Facebook account (I mean, every user that Facebook is willing to accept), and every Web site has registered with Facebook. Facebook can then provide a search facility within Facebook, powered by Bing, that takes advantage of all the knowledge Facebook has about all Web users, and Google is in trouble.
Neither of these is simple. But at least I (and Google) offer a solution to b (http://www.links.org/files/nigori/).
Francisco Francisco Corella, PhD Founder & CEO, Pomcor Twitter: @fcorella Blog: http://pomcor.com/blog/ Web site: http://pomcor.com
________________________________ From: Ben Laurie <ben@links.org> To: Francisco Corella <fcorella@pomcor.com> Cc: Melinda Shore <melinda.shore@gmail.com>; Nicholas Crown <nick@thecrowns.org>; Mary Hodder <mary@hodder.org>; "community@lists.idcommons.net" <community@lists.idcommons.net>; "community@kantarainitiative.org" <community@kantarainitiative.org> Sent: Monday, August 1, 2011 8:45 PM Subject: Re: [community] Google+ "real" names and NSTIC
On Tue, Aug 2, 2011 at 1:43 AM, Francisco Corella <fcorella@pomcor.com> wrote:
Yes. The NSTIC Identity Ecosystem should encompass pseusonymity and also anonymity. Today most of your activity on the Web, other when you pay with a credit card, is anonymous. When you log in to a site with a username and a password, you are just proving that you are the same user who registered earlier with the site.
In practice this is not generally so, you leak identity information all over the place. For example:
* IP address * Recovery email address * Third party tracking cookies
and so on.
As we move away from passwords we should preserve this anonymity.
No, we need to improve on it.
A simple way to achieve that is to have the Web site itself issue you a "login certificate" when you register, which you use later to log in to the site. (The certificate binds a public key to a reference to the your account at the site, internal to the site. The public key is the public key component of a key pair generated by your browser for the specific purpose of registering with that particular site, so that it cannot be used to track you.)
This has been available in browsers forever, yet it is hardly used. Why?
a) UI
b) Portability.
Neither of these is simple. But at least I (and Google) offer a solution to b (http://www.links.org/files/nigori/).