> 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

* 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/).