[LINK] Mozilla BrowserID to kill pseudonymity?
Roger Clarke
Roger.Clarke at xamax.com.au
Sat Jul 16 16:59:48 AEST 2011
[Lauren Weinstein picked this announcement up very quickly.
[Kick me if I'm being unduly sceptical, but it seems to me that:
(1) the individual's private key is now one-to-one associated with
the instance of the browser that the person runs
(2) that browser is uniquely identified by fingerprinting methods
(3) the individual's private key is also one-to-one associated with
the individual's email-address
(4) ergo the email-address, browser-instance and IP-address are all
tightly and reliably correlated
[So, by using this system, a person volunteers highly reliably
linkages among all elements of their identity.
[Possible reactions of the inveterate paranoid:
- 'I thought it was supposed to be Google that the CIA owned;
but maybe it's Mozilla as well'
- 'I thought the open-source crowd had shown serious signs of
becoming marketer-driven with HTML5 and all the other features
of the recent releases of their browser; but now they've made
clear that their products are marketer-friendly / consumer-hostile'
- 'I don't think onions will be a sufficient antidote to this one'
[Someone please show me I've got this all wrong.
Mozilla's BrowserID aims to simplify authentication on the Web
By Ryan Paul
Published 15 July 2011 ... about 3 hours ago
http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars
Mozilla aims to simplify account registration and authentication on
the Web with a new technology called BrowserID. It is a decentralized
authentication system allows the Web browser to manage the user's
identity.
https://browserid.org/
http://identity.mozilla.com/
The system relies on asymmetric keys and ties the user's identity to
their e-mail address rather than conventional usernames and
passwords. The browser handles the authentication process for the
user, enabling relatively secure single-click logins on websites that
support the scheme.
The login flow is relatively straightforward. The user navigates to
the website of their identity authority provider and logs in
conventionally. The authority provider website calls a browser
JavaScript API that generates a key pair. The browser sends the
public key to the identity provider and gets back a signed identity
certificate. The browser will then store the private key and
certificate in its secure keyring.
When a website wants a user's identity, it calls a JavaScript
function that will cause the browser to initiate the authentication
process. The browser will prompt the user to determine which identity
to use and whether to log in at all. If the user agrees, the browser
will send the requesting website an identity certificate signed with
the user's private key. The website then obtains the user's public
key from the identity provider and uses it verify the authenticity of
the provided identity information.
The authentication process is largely transparent to the end user.
All you will have to do is click a user interface element in the
browser to approve the login. BrowserID conceptually similar to
OpenID in a lot of ways, but without the usability problems and some
of the other pain points.
Of course, the authentication process described above makes several
assumptions: the user's browser implements the relevant JavaScript
APIs, the website that the user wants to sign into supports the
service and handles the verification step on its own, and the user's
e-mail host serves as an identity provider. That's obviously the
ideal scenario, but the protocol supports some other variations on
the authentication process that will simplify a few of the challenges.
If the user's e-mail host doesn't act as an identity authority, it's
possible to use a trusted secondary identity authority that does the
job. In the absence of native BrowserID support in the user's Web
browser, it's also possible to use an implementation hosted on a
website. It's also worth noting that the actual process of verifying
the identity can be performed by a trusted third-party, thus vastly
reducing the amount of effort involved for Web application developers
to support BrowserID logins.
Mozilla has set up a website called BrowserID.org that supplies these
services. This will make it possible to start testing and
implementing BrowserID right away without having to wait for adoption
by e-mail providers and other browser vendors.
The concept is pretty good, but there are still some unanswered
questions. It's unclear if major e-mail hosts and browser vendors are
going to be interested in supporting the system. The specifications
are still being finalized, so the effort to encourage adoption is
obviously still at a very early stage. It's also not entirely clear
yet what steps e-mail hosts will have to take to support BrowserID.
It's generally understood that they will have to host public keys and
make them accesible in a standardized way, but how exactly that will
work hasn't been specified yet.
Another question is how BrowserID authentication will be handled in
native desktop and mobile client applications outside of the Web
browser. Individual applications may need to operate as BrowserID
user agents and have their own internal implementation of the
protocol. The application would provide an embedded browser window in
which the user would log into their identity authority account so
that the app can get the keys.
That will get really complicated and sort of ugly, but the problem
could eventually be solved better by having the underlying operating
system itself implement BrowserID and store the keys in a central
keyring. There could be platform-level APIs for developers that allow
a third-party client application to log into Web services with
identities from the system keyring. The process could be mediated by
the operating system so that the user has the opportunity to select
an account or deny the login. The mobile platform vendors could
probably do it without much trouble, but it will likely take more
time for this to be supported on the desktop.
You can get more information about the protocol by visiting
BrowserID.org or Mozilla's new identity website.
--
Roger Clarke http://www.rogerclarke.com/
Xamax Consultancy Pty Ltd 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au http://www.xamax.com.au/
Visiting Professor in the Cyberspace Law & Policy Centre Uni of NSW
Visiting Professor in Computer Science Australian National University
More information about the Link
mailing list