Single sign-on: What we learned during our identity alpha
gds.blog.gov.uk
gds.blog.gov.uk
Something of an understatement. The project was red-flagged as'undeliverable' in 2019, after spending £154m
https://www.theregister.com/2019/07/18/verify_to_be_flagged_...
By 2020, and now at £200m sunk:
https://www.computerweekly.com/blog/Computer-Weekly-Editors-...
So now in 2021, we're back to informal tests and Post-It notes again?
This is a misleading paraphrasing of the article. With the full context, it becomes clear that it's specifically inclusiveness / accessibility that they're saying they didn't get right:
> Inclusion is a hugely important part of our work, because anyone should be able to prove their identity to access government services, and it’s often the most vulnerable people who are at most risk of being excluded. To be honest we didn’t get this right with GOV.UK Verify. We have an opportunity and obligation to do much better this time.
This means that the rest of your comment doesn't follow:
> Something of an understatement. The project was red-flagged as'undeliverable' in 2019, after spending £154m
The second sentence could be right or wrong, I don't know. But the first half doesn't make any sense in the (actual) context of what you're quoting. If it's understatement then that means that they got accessibility very wrong.
In Czechia we have a system where all sellers have to log bills to prevent tax evasion. IBM also provided the system. It cost ~ 15m$ to set up and ~15m$/y to run.
Given the rate of ~millions of bills submitted per day, of which the government only gets the total price and taxes, you have like ~hundred bills per second.
I could scale a gunicorn+sqlite on my 2014 MacBook Pro to be able to receive this rate of requests with a payload which could fit inside a single TCP packet. Sure, there is auth/backups/analytics... etc. Yet, I still just do not see how could IBM charge the extra 14m$ to set that up...
I’m not saying IBM is not still charging the government 14x more than necessary, but at least some of the expense is likely their own fault for having ridiculous requirements.
I don't know how it worked out in terms of budget, but the company ended up in a dispute over billions of euros in damages, mostly from lost revenue.
German Wikipedia source: https://de.wikipedia.org/wiki/Vergabeverfahren_zur_Lkw-Maut_...
Suppose that they decide that every single governmental system will use the same tech stack:
- front end: Vue and JavaScript, or whatever's popular and easy to use
- back end: Java with Dropwizard, or whatever has decent performance, decent maintainability (static types) and isn't too slow to write code for by the average developer (as opposed to something like Rust or C++)
- database: PostgreSQL, or whatever is suitable for its needs (though open source, so otherwise MariaDB could be considered)
- infrastructure: x86 servers, all running something like Ubuntu LTS or another popular, relatively stable distro
- communication: REST everywhere with OpenAPI, due to their abundance
- all of the code must be open source
- all of the discussions about the code and requirements must be public (a la GitLab's approach)
- all of the services must follow 12 Factor App principles, have fully automated CI and must run in containers (say, Docker or anything OCI compatible, with a simple orchestrator, like Nomad or K3s)
- all of the non-trivial services (e.g. files, reports etc.) must be separate, so not exactly monoliths, but not necessarily Netflix level of microservices
- all of the services must have at least 75% method code coverage, separation of concerns, all methods longer than X lines must have comments explaining what they're doing and *why*
- all of the services must use dependencies that are not older than X months, checked weekly
- all of the above can be checked by a bunch of shell scripts and the CI pipelines will fail if the goals are not met
Short of powers that be wanting to line their pockets, for what other reasons would the above fail? Why wouldn't open source and strict limitations of what can be developed and how it must be developed work?
Context:
In Latvia, we have a system called "E-Health", there have been around 14-15 millions spent on developing it so far, however the project has been widely regarded as a failure: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/par-e...
Now, they're planning on writing a new system instead, however it feels like they'll probably make the same mistakes, due to numerous companies having had their hand in the previous system's development, with no good leadership and bad technical implementation: https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/...
Surely there are both social and technical decisions that can be made make projects more successful?
All services need to go through an assessment where their openness, usability, accessibility and security are reviewed.
It's a modern, sensible approach that's constantly being improved.
[0] https://www.gov.uk/service-manual/service-standard
We could have done it all in $300K and so could have many other startups
If you go around quoting for projects without seeing the specifications outside of HN comments then your business is doomed.
If you make a system that is secure and flexible enough, you then work with other stakeholders to integrate with it over time. They each come up with a roadmap to migrate their systems to support your protocol.
The key is to skillfully negotiate the budgets and politics between teams, so as not to get stuck building the next healthcare.gov.
GDS is full of mostly django based systems, some legacy ruby and that's just the stuff from the last few years.
Going back further there are various C# systems, the amount of separate systems is staggering, it's not too surprising costs add up.
For every one of the systems you mentioned there is a fairly straightforward solution. And even if you can't solve them all you could gradually migrate everything.
Oftentimes because of management wanting to push liability to a private party, they don't want to invest into local dev teams, but instead want to buy a big enterprise solution.
The VA, NHS and the German systems all have these issues, but it's not because they're public institutions, it's because they work like enterprise.
What I've noticed is that "new style" government projects like the GDS seem to be suffering from using too many "innovation tokens" [2], probably due to the much cited lack of leadership.
It's not nice to be in a situation where you are stuck on a legacy Java 7 platform, and nothing else, but equally, it's not nice to be in a situation where you are trying to support and context-switch between too many stacks. One is too conservative, the other is chaos.
If there's no leadership, there's no-one to make decisions to limit proliferation of new technology. This might be unpopular for some developers looking to improve their CVs, but necessary for the organisation as a whole.
[1] https://www.bbc.co.uk/news/uk-politics-28464002 [2] https://mcfunley.com/choose-boring-technology
I don't believe this is the case at GDS, and wasn't the cause of the failure of the Gov.UK Verify project.
But I do think it is the case at the GDS, as evidenced by the comment on this page:
> GDS is full of mostly django based systems, some legacy ruby and that's just the stuff from the last few years. Going back further there are various C# systems, the amount of separate systems is staggering, it's not too surprising costs add up
And this blog post:
> ...quickly agreed that rather than try to settle on a single one of those we'd build each tool using whichever technology would most quickly get us to a relatively-durable prototype, and then "federate" them. We started with the python-based framework Django for the Department pages, added Ruby on Rails for a suite of tools focussed on specific tasks, and used Sinatra (another ruby framework) to glue together our search.
https://gds.blog.gov.uk/2011/05/12/a-brief-overview-of-techn...
The Government Digital Service (GDS) code is on GitHub (1.5K repos) and this includes the frontend code for GOV.UK.
They still use Python and Ruby languages, but it's not clear if they are still using Django and Rail frameworks.
Other languages include Javascript, Go and Java: https://github.com/alphagov
But, the problem here is that the issuer is the British government, so, what are you proving? "Here, you issued this passport". "Oh yes, so we did". I presume the British government does own a database of the passports they issued, so this isn't news to them.
A modestly smart device, such as a Yubico device, is capable of providing fresh proof of its identity. My Security Key doesn't prove "The security key that enrolled me with GitHub in fact exists" which is redundant - but "I am still the same security key that you enrolled". However the passport can't do that, your passport is inert, and the fact that Sarah Smith existed isn't the thing you presumably want to prove to a single-sign-on service. You want to prove that you are Sarah Smith, something the passport doesn't really do.
I think the GDS ignores this problem, which is to be fair no worse than lots of other systems, but the result isn't actually what it seems to be, all the digital technology isn't actually proving anybody's identity in this space.
It reminds me of the bad old days of the Web PKI where it was found that the "email validation" being used would accept automated "virus checking" of email. A CA sends the "Are you sure you want to issue a cert for mycorp.example?" message to somebody@mycorp.example and even though Somebody is on vacation in Barbados for two weeks, the automatic "virus" check reads the URL out of the email, follows it, ignores the page saying "Success, your certificate has been issued" and passes it to Somebody's inbox... All the "security" is doing what it was designed to do, but, what it was designed to do isn't what it should have been designed to do, and so it's futile.
It's a (weak) proof of ownership of such passport -- it has to be present to be read.
Some id cards can also function as smartcards and provide kind of challenge-response proof, which is better compared to reading signed document (which can turn out to be a copy).
>I presume the British government does own a database of the passports they issued, so this isn't news to them.
Actually maybe the don't.
It had to exist to be read once at some unknown point in the past, but the government already knows it exists because they issued it. Anything more (such as "it is present now") is speculation.
Cloning static data from NFC readers is something a physical penetration testing team does. Stand near employee in coffee shop, their ID badge says "Hi I'm employee badge #123456789 for site #98765" and you clone that, then walk in later, "Hi I'm employee badge #123456789 for site #98765" says your fake badge with your picture on it. Is it better than nothing? Yes. Would I like my government to aim a bit higher than "Enough know-how to bluff your way into a mid-size corp headquarters building" ? Yes please.
> Actually maybe the don't.
The UK government will issue you one document based on records from another document so long as it's timely. For example when my photo driving license expires, I just renew it with the photo from my new passport. Some people do the opposite way around. You can't renew everything forever because your photo expires and you need to provide a new one that resembles the previous one except now you're older. But the fact they can do this means they do have those records.
Even the resemblance checking presumably means somewhere a minimum wage employee is being shown pairs of images, "Young white guy with freckles and a beard" + "Older white guy, same freckles, no beard" => OK pass unless somebody has drunk way too much ML kool aid, but that can only work if they have the records.
Which is why I wrote "(weak)", as I don't know if the document in question supports active challenge-response or not. I have one that does (passport) and one that doesn't (id).
You’re talking about accessing someone’s house here. I don’t know anyone that carries their passport around.
It’s something you’ll have to deal with anyway, since you cannot issue new passports to your entire population. Not to mention those people that don’t have one in the first place.
> But the fact they can do this means they do have those records.
They certainly have all the records somewhere. But do they have all of them in the same place?
I'd guess that a high majority of passport owners do indeed carry them around when they travel, and places such as airports would be a fairly easy way to find such people carrying their passports.
A yubico device can say "I'm still the same security key that was enrolled" but it doesn't say at enrolment "I am being used by Fred Jones of <address> with passport no 123, NiNo ABC".
GDS verify / government gateway do support 'authenticators' (typically password + totp) to provide a level of assurance that the person logging into the account is the person the account belongs to.
The "document check" is part of the identity bit. That is, how confident are we that the person creating this account / performing this action is who they say they are and can do this thing or see that information. The document check is part of their solution but other parts are supposed to layer on top of it to provide a proportionate level of assurance. e.g. a video of you holding up the passport to check that it's you using it or asking you to provide answers to details you already have like 'how much tax did you pay last year' or checking multiple documents.
> I presume the British government does own a database of the passports they issued, so this isn't news to them.
The passport office (part of the Home Office) own that database. Part of this work is basically a web service to that database for the rest of the government to use.
A remote passport check might be suitable to claim an identity assurance level of 2, say, while getting to identity assurance level 3 would need an in-person visit with multiple forms of other government identification records.
In that way you might then constrain some actions to be taken remotely only by users who have provided strong assurance of their identity at enrollment (even if they login with strong non-phishable authentication... doesn't matter that the auth is ironclad if the user's identity is muddy).
> SP 800-63-3: Digital Identity Guidelines https://doi.org/10.6028/NIST.SP.800-63-3
> SP 800-63A: Enrollment and Identity Proofing https://doi.org/10.6028/NIST.SP.800-63a
> SP 800-63B: Authentication and Lifecycle Management https://doi.org/10.6028/NIST.SP.800-63b
> SP 800-63C: Federation and Assertions https://doi.org/10.6028/NIST.SP.800-63c
1. Verifies that you have the passport
2. Provides biometric info
Of course neither of these are a 100% guarantee of identity. (1) doesn't account for stolen or lost documents. (2) is only useful if the app doing verification is tamperproof and the camera isn't fooled by holding up a photo of you etc. However _nothing_ is a 100% guarantee. These steps, plus any other verification that's going on, can make it very hard to fake ID, which is all we are really able to hope for with these systems.
Because the data is static, it doesn't do that. It only verifies that you know the static passport data.
This was a key problem with the old magnetic stripe credit cards. You could easily clone the stripe. I don't see any substantial obstacle to cloning an NFC passport chip.
2. Provides biometric info
Sure, that is useful, but, this is a government application. The government does have this biometric info, that's why it's baked inside the passports. So this isn't something the passport is enabling for the government.
The caveat is that it's optional-- not all passports support it, and thus there are possible (depending on the reader software) downgrade attacks where a passport with active authentication could be cloned anyways if you can convince the reader not to perform the authentication step. And there are bad hardware implementations out there that don't adequately protect the private key material (leaving them susceptible to cloning anyways).
The key you need is basically the bottom row of the MRZ in your passport, the way a real system does this is to look at the photo page in your password, read the MRZ from it and use that to unlock the NFC chip. This feels intuitively reasonable since you either handed over the passport for inspection, or you showed the photo and identity page to an inspector, either of which reveals the same facts as the chip (by default).
So, we're not talking high entropy keys here. But, this is a real practical barrier compared to the badge cloning. It probably means, "Brush past somebody in a queue to clone their passport" is not in fact practical. On the other hand, if you ever have legitimate access you have enduring credentials, so that's not great.
Is it possible to fool? Like anything it is a trade-off. Acceptable security for an acceptable cost. Hopefully it fulfills your security requirements and you saved a physical visit.
For all Verify had/has real issues (mostly politically mandated pressure to use + key usability and accessibility issues) at least it had some people who understood key elements of the identity landscape.
That article appears to draw no distinction between the proving of the existence and of the ownership of an identity. If anything the examples conflate them which is a critical failure.
Identity is a really hard government problem, mostly because it is a government issue/need really not an individual's and government are insanely bad at addressing it.
While proving your identity was easy, they've had trouble achieving the next step of information sharing. Traditionally government departments under law were not able to share information. This has only recently changed and they're struggling to reach the next step.
We wanted to add it to our platform as an authentication mechanism. That would be good for individuals, and good for realme, as it would increase adoption.
However this is not allowed because ... Realme is paid for from taxes, so noone in the private sector can use it unless they pay.
This makes some sense, but also obviously it makes no sense for a web site to pay e.g Google for "sign in with Google". Google is obviously more than happy to underwrite the costs, since it means greater adoption of their identities and more power to their platform.
As a result realme is stuck in a public sector prison. It's a shame as some of it has been well executed.
They are an incredible product of the USDS, 18F, and GSA and it’s awesome watching them slowly but surely make digital identity with the US government better.
https://gds.blog.gov.uk/2015/07/29/same-but-different-a-comm...
Whereas in the UK to access gov.uk with Security Keys I have to use a third party (Digidentity) because the government out-sourced this problem.
Kudos to the login.gov team.
That's why most(all?) EU countries have ID cards which are (usually? sometimes? probably depends on the country) mandatory. Especially the new EU standard version, which will of course take time to be deployed everywhere, is pretty great with a chip containing the biometric and other data allowing for automatic verification ( via an app or device at certain places, like airports).
How this man is anywhere near Downing Street is a complete mistery to me.
Couple that with proof of identity being one of the few things that might have been issued 40, 50.. 60+ years ago (birth certificates) and never updated (unlike passports..) and when issued had no concept or sympathy that it might be used for digital verification in the future.
Without redefining the problem to avoid issues like birth certificates, i'm not sure this is solvable in the way stakeholders expect it to be. Stakeholders (like citizens paying for it) expect to be able to point technology at the problem and have it solved, 'its just an app right?' or 'lets use biometrics!' but so many other things have to adapt to make something like this successful.
Estonia had an interesting approach where they just issued everyone smartcards/certificates and used that as proof, this bypasses the 'birth certificate' problem but is expensive (Estonia has smallish population, newish government so ok) but such an approach itself has a root of trust problem.. who do I issue the smartcards to? It isn't directly transferable to other countries/governments.
You work around the root of trust problem by creating exceptions and alternate paths to verification, maybe do it in-person for people with disabilities etc. But then how long does that take to roll-out? How easily abused is such a system? How many of the identity moment can I use it for? Is in-person verification trusted less?
It is very easy for the resulting system to be quite brittle too and not reflect real use-cases, real world identity moments are very diverse and often have more flex than you'd think and it is very difficult to carve out the right chunk of the identity problem to solve and which to leave behind and still create something that improves the ecosystem.
learnt through pain, built digitalid.com
It's like "falsehood programmers believe about Names" combined with one about dates and all others too. Because sometimes including name of lunar month is more important than assigning a number to the document.
This could all be solved with a national ID card (and would save the public purse £millions, as shown by the Verify programme). The complexity isn't in the actual technology (which exists, and has done for a long time), but the sheer number of possible identity documents that need to be accounted for and the mechanisms for collecting that documentation for verification.
But Brits are too stubborn to accept it. These are the same swathes of people that share stuff on Facebook, install Ring doorbells, and throw bank statements in the bin un-shredded.
"Here's something indistinguishable from something I could have knocked together using Microsoft Word an hour ago."
There's a huge difference for example between identity/residency checks in Poland for people who are in PESEL database and people who aren't - and if you're in PESEL, you're going to have polish ID card as well.
things like
FIDO/ubi key as the basis for all authentication / identification
Once we do that how do we manage SSO - I dislike the idea of having a nice hardware module and then saying "great for the next x hours / days use this static string. All attempts to make that better (timers, usage countdown timers) just seem less good than client certificatest and certificates in HSMs
(simply, I am trying to design a ... company I guess )
That's effectively what FIDO/U2F are.
Facebook and GitHub both have records that allow them to authenticate that I'm still me, using FIDO Security Keys, but if they compare records they intentionally do not learn that they're authenticating the same person, even though that is in fact what they're doing.
The place you'd logically put an "identifier" (and in fact it's even called ID) in protocols like WebAuthn is chosen effectively at random for each enrolment. On your phone the ID is actually just a bunch of random bits, on a cheap Security Key it's much more complicated but the effect for relying parties is that it's random.
https://github.com/pomerium/awesome-zero-trust/
https://fidoalliance.org/fido2/fido2-web-authentication-weba...
(digital identity and IAM is a component of my work)