Follow-up re GOV.UK accounts
Just before the holidays I wrote a blog post about the new GDS experiment, GOV.UK accounts. While it’s definitely a break with the original GDS concept of stateless transactions, I’m definitely not against the idea on principal and will be interested to see how it develops built on what I’m sure will be extensive user research. It’ll be particularly interesting to see how it evolves to support transactions that reach across organisation boundaries, supported by the ongoing developments in the data sharing and API communities as well as what it will mean for the future of the government’s digital identity strategy — whatever that turns out to be (notably the entire section of the blog post discussion potential options for digital identity doesn’t mention GOV.UK Verify at all).
Today GDS posted another blog on the topic — The technical architecture behind a GOV.UK account. It’s very good to see front and centre discussions on how citizens can see and control which services their data is shared with. Perhaps this will eventually lead to the creation of a government data sharing platform like Estonia’s X-Road which it’s high level of data sharing transparency. Although, notably, the including technical diagram doesn’t currently extend beyond the boundaries of GDS — it’s early days. The proposed “preferences and consent management service” sound excellent and very much in keeping with the kind of thing that Register Dynamics and others have been proposing for some time.
However, what I want to pick out to discuss is the following:
A simple example of how this could be useful is the common action of filling in an address across many different government services. A well architected solution would allow users to fill their address in once and then, should the user choose to, share that data when they next need to fill in their address in a journey through a government service.
And
An attribute store — a centralised location that holds some common data about a user that every GOV.UK service might need.
As I said in my previous blog post on this topic, this immediately runs directly into all the issues highlighted by the NO2ID / Database State campaign from all the way back in the early 2000s.
It’s always seemed to me that there’s been a tacit understanding that specific government organisations have a good justification for collecting data related to their remit. In addition many people see the collection of basic personal data (name(s), addresses(s), date of birth, etc) in multiple places as a feature rather than a bug. It’s certain not good from a user experience point of view but having a single-source-of-truth database with the names and addresses of everyone who interacts with the government is an exceptional cyber-theft target and raises all kinds of risks related to corruption, malicious viewing / updating and being accidentally exposed.
These risks might be considered to be low compared to the value gained by having everything in one place (like Estonia). Views on this are bound to vary a lot. To be honest these days I’m on the face and see good arguments on both sides.
The huge issue here though is, if I’ve understood this correctly, GDS is at the start of a plan to create this kind of comprehensive data store without explicitly opening up the concept for debate. Yes, the work is being done in the open — and that’s great — but this is a big deal and people and organisations that have previously expressed an opinion on this kind of centralisation of personal data, both for and against, need an opportunity to discuss the pros and cons in public.
