Privacy & Authentication
Most mainstream websites today authenticate users by asking them to login with an E-mail address. That E-mail address is used for a few "good" reasons:
It is easy for the user to remember when they need to login
It is easy for the user to prove they own it to create an account
It is easy for the user to prove they own if they need to reset the password on their account
If it easy for the user to remember if they call the company's help desk and need to give an identifier for their account
It is easy for the website to use to communicate with the user
It is easy for two users to exchange invitations to access resources on websites, such as meeting invitations through an online calendar, social network "friend" requests, invitations to view photo albums, etc. For example, if the user logs into their calendar service account that has their E-mail address, then the calendar service can show all the outstanding invitations sent to that E-mail address in relation to the rest of their calendar events. Or if the user logs into their social network account that has their E-mail address, then they can see the list of "friend" requests with information about the user's relationship to that potential "friend" such as any friends they have in common.
Unfortunately E-mail has well known downsides:
The website can maliciously or mistakenly give the E-mail address to spammers/phishers
Websites can collude to use the E-mail address as a common identifier to track a user's activity across websites
Hackers can impersonate E-mail from the website and use it to phish the user, or trick them into performing other actions
Websites frequently send more mail then users want, and even if the website lets the user control their preferences about receiving mail, it can be hard for users to change those preferences
The security/privacy community has suggested some other alternatives for authentication that are more privacy preserving. Three of the more common are:
URLs as identifiers (OpenID 1.x)
Opaque IDs as identifiers (an option in OpenID 2.0)
Self-controlled certificates (software based or hardware based, even including government issues certificates)
The primary problem with these alternatives is that most mainstream websites are unwilling to give up all the big "good" advantages of E-mail based authentication. The security/privacy industry is evaluating other ways to enable websites to keep some of these advantages. For example:
Per-website E-mail addresses: Some software and identity providers can issue individual E-mail addresses to each website that a user wants to login to, and then the user can easily revoke one of these E-mail addresses if the site is too spammy, or the E-mail gets in the hands of spammers. These websites can also allow a user to lookup the E-mail address that was used to identify them to a particular website in case the user needs to call their help desk and provide it over the phone.
E-mail signatures: Standards already exist to enable websites to prove they are the originators of an E-mail message, however most websites cannot digitally sign all the E-mail they send. Thus other groups are working on ways to enable websites to publicize the fact that at least all the mail of a certain type they send to a specific E-mail address will be signed, and that would allow the user's E-mail provider/software to block any other messages of that type which are not signed by the website who was given that unique E-mail address.
Combined per-website E-mails with signatures: One technique is for the user to authorize their E-mail provider to issue the RP website an OAuth token that has the right to send the user a message, and the token itself is a per-website token.
Domain based federated login: OpenID 2.0 allows users to give only the domain name of their identity provider to an RP website, and then they will be redirected to their IDP who can verify their identity and issue a per-website E-mail address. Google and others are working on usability research to make this even simpler for users.
Browser based extensions: Client-side software can be used to authenticate a user to a website instead of using a central identity or E-mail provider who might track the user's action. That software might even be able to interface with the user's E-mail provider to request an OAuth token that it would give a website if the user was willing to receive E-mail from that site. The primary downside of this type of approach is that it is hard for the user to configure this software on different machines if they travel and many Internet connected devices do not support this type of software (most mobile phones, Tivos, Playstations, etc.). However eventually the security/privacy industry may find ways around that problem as well.
Unfortunately, most of these approaches do not provide any advantage to mainstream websites, so it is very hard to get them to switch. That pressure may eventually come from government regulation or widespread consumer pressure, but the "switch" would happen faster if the industry could find other advantages for those mainstream websites. For example, one potential advantage is that if websites support digital signatures with per-website E-mails, then the user's E-mail provider is less likely to mark E-mail from that website as spam.
In the meantime, some options do exist for users, and others are starting to become available.
The simplest option for users is to sign up for a second free web-based E-mail account, and give that to most websites that the user wants to log into. The user can simply not check that E-mail inbox, or only do so in rare occasions such as resetting passwords. If a website becomes "worthy" of the users trust, then most websites allow user's to change the E-mail address associated with their account, and in that case the user can switch to their primary E-mail address. This approach still allows multiple websites to correlate a user's activity based on the fact that the end-user logs in with the same E-mail address on multiple sites.
For end-users who are willing to do a bit more work, there are also disposable E-mail address services (and software) which will help the issue setup a unique E-mail address for each website they visit. However for the average user, this type of service is difficult to use. In addition, if the end-user ever needs to call up the help desk of the website/company and is asked to identify themselves using their E-mail address, that user will quickly become aware of one of the major disadvantages of this approach.
Even if we cannot solve all these privacy problems immediately, it would be a big step forward just to get websites to support federated login via protocols like OpenID & SAML, even if the IDPs need to provider the user's E-mail address. That at least provides the potential for those IDPs to generate per-website E-mail addresses in a manner that requires little work by the user. Unfortunately, if the user had a pre-existing account at that website which was associated with their E-mail address, then they need a simple way to (1) proove they own that E-mail, (2) give the RP the new RP specific E-mail address for the user, & (3) convince the website to erase their old E-mail address. Getting RPs to support that type of E-mail "swap" will require more work, but may be simpler then just getting them to support federated login using E-mail addresses themselves since that idea has been around for years and never taken off.
Evolving from that point to digitally signed E-mail and browser based identity extensions may take longer, but there is certainly consumer demand for this type of privacy, we just need to develop ways to achieve those goals without creating such huge burdens on users (and RP websites) that they are unwilling to use them.
Ben Laurie, Software Engineer, Google Security
Eric Sachs, Product Manager, Google Security