Gov.uk quietly disrupts the problem of online identity login(theguardian.com)
theguardian.com
Gov.uk quietly disrupts the problem of online identity login
http://www.theguardian.com/technology/2014/nov/06/govuk-quietly-disrupts-the-problem-of-online-identity-login
4 comments
They disrupted the problem? What the fuck is that supposed to mean?
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.
It sounds like PR-speak for being cool and edgy and running against the grain.
Seriously, I did not understand this article. Hype.
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.
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.
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 (7 mins)
http://www.youtube.com/watch?v=WHoq1l8vFNo (7 mins)
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).
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.
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.
> 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
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
"the system does not retain (identifying) pieces of information, and the (identity) checking companies do not know what service is being used."