When we designed the identity assurance architecture we wanted to protect users from identity theft and fraud, to secure their data as it is used online, and to reduce the amount of information needed from the user to a minimum.
To help us to achieve these goals we created a hub service that sits between online government services and the identity providers to help users to authenticate with an appropriate identity provider, facilitate matching of users to services, and to enforce policy e.g. only allowing trusted services to make requests.
Services need some data to identify you but we want to keep that data safe…
One of the consequences of transacting with government services is that we need to connect the user wanting to access a service with records or identifiers that mean something in the context of that service. For example, we want to make sure that a service retrieves your records, such as your driver licence details, rather than those for the other John Smith who lives just a few streets away.
To do this services need data that we can trust so integrity and provenance are important to the service providers. We also need to move that data from a trusted identity provider across the internet safely. To achieve this we only send data we really need to help you access a government service, and we use powerful cryptography to ensure that only the intended recipient can read the data and that no one can change that data in-flight.
The data we send about you when you log-in is limited to something called a Matching Data Set which is made up of your Name, Address, Date of Birth, and Gender (if you provided it*). This data is verified by your choice of Identity Provider and is used to access government services by matching to the data they already have such as your driver licence in the example above.
We want to minimise the data we need…
We don’t keep your identity data centrally; in fact we don’t keep it at all, or even get to see it ourselves: it is held by the identity providers on your behalf.
Some people think “it’s the government, they know me…” but largely it’s only the service or department you are interacting with that know your details and even then the data they hold could well be out of date if you haven’t used their services recently, or incomplete if they didn’t need to keep all of your information as part of the process.
To protect your privacy the hub service only has access to a small amount of your data when you want to access a service, which is only released to us when you consent to that happening, and the identity provider of your choice verifies it in advance. We call this small set of identity data the Matching Data Set and we make sure that services don’t keep this data or re-use it for any other purpose unless they first gain your consent.
We don’t let identity providers know what service you are accessing…
One advantage of our hub service is that we can prevent identity providers from knowing which government service you are about to use. We appreciate that our identity providers are commercial organisations and we don’t think it’s appropriate for them to know what service you are trying to access. Unless you choose to tell your identity provider, they won’t know with which service you’re using, and they certainly won’t be able to see what you’re doing there, they will simply know that you are accessing a government service.
We want to make sure you can protect your identity…
Identity theft and account takeover are real-world problems and whilst we might not be able to completely stop this happening we do want to provide users with the ability to repair identities or to recover accounts depending on the situation.
Identity providers play a major part in this, but the hub service and our architecture allows us to identify potential problems as they happen, or investigate when and where identities have been used should an incident be reported.
In short, we care about your identity and we want to protect it but we realise that you also want a great service. Minimising the data we need, protecting it at all times, and making sure that we get your consent should we need to use your data as part of a service helps us to ensure that protection and still provide great services.
Fig.1 - The data you enter, where we process it, what data is stored, and by who
In simple terms there are three services that you will encounter when accessing a government service: the government service itself, the hub service, and an identity provider of your choice where you prove your identity or simply login. In the diagram you can see the type of data these three services ask you to provide, where this date might be processed, and where it may be stored. You are only asked to enter what we need, we minimise what is stored, and we always gain your consent to proceed.
Users are asked to provide their gender but it's not mandatory. If a user does say what their gender is, it may be useful in some cases as part of the set of data that's used to match them to the correct record in a department. But it's optional, relies on data asserted by the user (ie it is definitely gender, not sex), and unlike some of the other elements of the matching set, IDPs certainly don't ask for any history of gender (unlike, say, recent address history which is needed to help identify some people).