

Gov.uk quietly disrupts the problem of online identity login - chestnut-tree
http://www.theguardian.com/technology/2014/nov/06/govuk-quietly-disrupts-the-problem-of-online-identity-login

======
jacalata
They disrupted the problem? What the fuck is that supposed to mean?

~~~
test1235
I think 'disrupt' is a candidate for embarrassing corporate buzzword of the
year.

It sounds like PR-speak for being cool and edgy and running against the grain.

------
kennu
Curiously this went the other way round in Finland. The government tried (10
years ago) to develop a centralized, smart card based authentication system.
Nobody wanted to use it, and meanwhile, all the banks had simultaneously
developed their own secure authentication methods (based on one-time password
lists sent to homes by mail). So now, if you want to authenticate for
submitting tax data, changing your official address etc., you always sign in
via one of the online banks.

~~~
danpalmer
The government here (UK) tried the centralised ID card system, and the public
backlash at the idea caused it to be scrapped. Verify is very much _not_ that
ID card system, and takes steps to ensure that it doesn't have the same
negative privacy implications.

------
chestnut-tree
Here's a video showing the steps a user goes through to use the Identity
Assurance service. This is from June 2014 so the design or process for the
service has probably been revised since then. However, it gives you an idea of
what's involved for a user:

[http://www.youtube.com/watch?v=WHoq1l8vFNo](http://www.youtube.com/watch?v=WHoq1l8vFNo)
(7 mins)

------
nly
If they ever release an API and push for adoption outside of *.gov.uk, this
will be a catastrophe. Banks and other services will inevitably adopt it. If
they do, then the Government will have one click access to all of those
accounts. Federated login is single point of failure on a scale paralleled
only by email password resets (but worse, since password resets can't go
unnoticed by the user).

~~~
danpalmer
That's not quite how it works.

The idea behind this is that the government shouldn't have access to data they
don't need. The services they provide are all isolated, and you are
authenticated entirely separately to each one. This means that You can sign up
for a driving licence, and you can sign up for a passport, but neither the
DVLA (/DMV) or the Passport office know that you have done the other thing.
There is no central database of user details. There was a huge backlash
several years ago against national ID cards for this reason, and the Verify
system was designed specifically to make this impossible.

It's very like OAuth in some respects. Just because I have signed in to two
services with Twitter, does not mean that one of those services can access the
other in my name. In the same way, if banks used Verify for authentication,
the government wouldn't know, and wouldn't be able to do anything even if they
did.

I've had the system explained to me before by GDS engineers, and I can
honestly say it's a wonderful piece of engineering, and in some ways, an
amazing piece of policy.

~~~
nly
> It's very like OAuth in some respects. Just because I have signed in to two
> services with Twitter, does not mean that one of those services can access
> the other in my name.

Who cares? Twitter can still access _both_ in your name, without your
intervention. This system will have the same weakness, because it doesn't
provide a means of allowing users to retain or leverage secrets. Your password
and the mandatory second factor are all 'secrets' known to your identity
provider.

BrowserID has/had the same lovely privacy properties but still gives your
identity provider (e.g. Mozilla if you were to use Persona) complete access,
even if they don't know when or to whom that access is being granted when
you're using it.

If you can show me technical details regarding the zero-knowledge proofs being
exchanged in the protocol then I'm all ears, but afaik, in current browsers,
it's simply not feasible without resorting to Javascript. The Web Crypto API +
DH primitives might be enough to construct such a protocol, but if you're
cobbling together the client side implementation using those primitives and
running it from server-supplied Javascript then you're already lost.

All federated login systems are fundamentally flawed outside of a close-knit
contexts where shared authentication makes sense (like universal login for all
.gov.uk websites), because you're delegating control over multiple services to
an identity provider. Freedom to choose an identity provider in this case
bullshit because there's a fixed set of organisations who actually have access
to passport data, the electoral roll etc. This system is just giving those
(some government run) organisations further power

