Guidance

Identity assurance principles for building identity services in government

Updated 30 September 2024

1. The principles

The principles serve the interest of the individual. Here is an outline of the control given to a user under each principle, written from a user’s perspective.

User control

I can exercise control over identity assurance activities affecting me and these can only take place if I consent or approve them.

Transparency

Identity assurance can only take place in ways I understand and when I am fully informed.

Multiplicity

I can use and choose as many different identifiers as I want to.

Data minimisation

My interactions only use the minimum data necessary to meet my needs.

Data quality

I choose when to update my records.

Service user access and portability

I have to be provided with copies of all of my data on request; I can move or remove my data whenever I want.

Certification

I can have confidence in the identity assurance service because all the participants have to be certified against common governance requirements.

Dispute resolution

If I have a dispute, I can go to an independent third party for a resolution.

Exceptional circumstances

I know that any exception has to be approved by Parliament and is subject to independent scrutiny.

2. How to apply the principles 

2.1 These principles were developed by an independent advisory group to support the government in developing an identity assurance service. Originally developed by the Privacy and Consumer Advisory Group (PCAG), the principles continue to be supported and reviewed by the One Login Inclusion and Privacy Advisory Group (OLIPAG). This is an independent advisory group to the delivery of GOV.UK One Login. Any changes will be made in consultation with OLIPAG. 

2.2 The principles are designed around the needs of the individual, and seek to give real meaning to terms such as ‘individual privacy’ and ‘individual control’. They are not designed to meet the needs of any state body or commercial corporation. 

2.3 The principles are equal to each other and do not overlap. Each principle has a specific role and, in combination, they are all necessary to make sure people trust the identity assurance service.

2.4 The principles are limited in their application to the processing of data in an identity assurance service, for example: 

  • establishing and confirming the identity of a service user
  • conducting a transaction that uses an identity
  • maintaining audit requirements for a transaction within a service that needs identity verification 

They do not apply to other data, such as data that is used to deliver a service, or to measure its quality.

2.5 The 9 principles assume that an identity assurance service is mature and well established. However, in the early stages of a systems development, there may be a phasing-in period in relation to each principle, or a principle might need a degree of initial flexibility. Within a reasonable time frame, all of these principles should be fully implemented by the identity assurance service.

2.6 The principles recognise that special interests, such as law enforcement, may need exemptions and this is the purpose of the ninth principle. Such special interests should be explicitly defined and publicly reported.

2.7  These principles represent good practice guidance and the requirements of other legal duties under human rights and data protection legislation and the common law. The principles apply to all identity assurance activities described in ‘Requirements for secure delivery of online public services - Good Practice Guide (GPG) 43’. The architecture of the identity assurance service must be based on open standards.

2.8 OLIPAG recommends that this should ideally be enabled through legislation to establish the identity assurance service infrastructure, coupled with robust contractual terms that enforce all of the principles. It is not advisable to allow existing legislation to define access to any data from the identity assurance service since such legislation, when it was originally enacted, could not have been scrutinised in the context of an identity assurance service. Any exemption from these principles needs public scrutiny in order to gain credibility and maintain trust. However, in the absence of specific legislation establishing the identity assurance service, it is essential that other mechanisms be implemented to ensure transparency, scrutiny and, where necessary, debate. As these principles only apply to identity assurance data used by the identity assurance service, they have no impact on any operational matter of any law enforcement agency, except where the operational matter relates to obtaining such data from an identity assurance service. In such cases, the exceptional circumstances principle will apply.

2.9 The principles are limited in their application to the UK, with a particular emphasis on the UK government’s objective to deliver public services digitally. OLIPAG notes, however, that these principles could have international reach, especially in the USA, or in the European Union, Organisation for Economic Cooperation and Development (OECD) and Asia-Pacific Economic Cooperation (APEC) countries. However, the starting assumption has been that interchangeability with any other nationally based principles will only become relevant when the UK principles have established a proven track record in gaining the confidence of individuals who use a service. That said, OLIPAG believes that these principles are fully consistent with all national and international data protection laws.

2.10 The principles are drafted in a way that allows for a degree of precision. They are not drafted in a way that defines statutory principles, but the text could form the basis of a statutory code of practice, similar, for example to the model provided by the statutory code of practice on data sharing. A statutory code of practice would cover all types of organisation, of any size and in any usage context, which might wish to provide or consume any services from the identity assurance service.

3. Definitions

3.1 These principles are limited to the processing of identity assurance data (IdA data) in an identity assurance service (for example: establishing and verifying the identity of a service user, conducting a transaction that uses a user identity, maintaining audit requirements in relation to a transaction associated with the use of a service that needs identity verification). They do not cover, for example, any data used to deliver a service, or to measure its quality.

3.2 When applying the identity assurance principles to an identity assurance service, particular definitions and terms apply.

Identity assurance data (IdA data) 

This means any recorded information that is connected with a service user, including:

  • audit data - this includes any recorded information that is connected with any log or audit associated with an identity assurance service
  • general data - this means any other recorded information which is not personal data, audit data or relationship data, but is still connected with a service user
  • personal data - this takes its meaning from the Data Protection Act or subsequent legislation, for example, any recorded information that relates to a service user who is also an identifiable living individual
  • relationship data - this means any recorded information that describes (or implies) a relationship between a service user, identity provider or service provider with another service user, identity provider or service provider and includes any cookie or program whose purpose is to supply a means through which relationship data are collected

Identity assurance service

This includes relevant applications of the technology (such as hardware, software, database, documentation) in the possession or control of any service user, identity provider or service provider that is used to facilitate identity assurance activities. It also includes any IdA data processed by that technology or by an identity provider or by a service provider in the context of the service; and any IdA data processed by the underlying infrastructure for the purpose of delivering the IdA service or associated billing, management, audit and fraud prevention.

Identity provider 

The certified individual or certified organisation that provides an identity assurance service (for example, establishing an identity or verification of identity); it includes any agent of a certified identity provider that processes IdA data in connection with that identity assurance service

Participant 

Any identity provider, service provider or service user in an identity assurance service, or any other agent by definition.

Processing

In the context of IdA data this means collecting, using, disclosing, retaining, transmitting, copying, comparing, corroborating, correlating, aggregating or accessing the data and includes any other operation performed on IdA data.

Provider

This includes both identity provider and service provider.

Service provider 

The certified individual or certified organisation that provides a service that uses an identity provider in order to confirm the identity of a service user. It includes any agent of the service provider that processes IdA data from an identity assurance service.

Service user 

The person (dead or alive) or organisation (incorporated or not) who has established or who is establishing an identity with an identity provider. It can include an agent (such as a solicitor or family member) who acts on behalf of a service user with proper authority, for example a public guardian, a director of a company, or someone who possesses power of attorney. The identity may still need to be used once its owner is dead, for example by an executor.

Third party 

This means any person or organisation who is not a participant, such as the police or a regulator. Similarly, the US government’s National Strategy for Trusted Identities in Cyberspace (NSTIC) defines participants as “the collective subjects, identity providers, attribute providers, relying parties, and identity media taking part in a given transaction”. This way, third parties are not participants.

4. The principles in detail

4.1 User control

“I can exercise control over identity assurance activities affecting me and these can only take place if I consent or approve them.”

4.1.1 An identity provider or service provider must ensure any collection, use or disclosure of IdA data in, or from, an identity assurance service is approved by each particular service user who is connected with the IdA data.

4.1.2 There should be no compulsion to use the identity assurance service and service providers should offer alternative mechanisms to access their services. Failing to do so would undermine the consensual nature of the service.

4.2 Transparency

“Identity assurance can only take place in ways I understand and when I am fully informed.”

4.2.1 Each identity provider or service provider must be able to justify to service users why their IdA data are processed. Ensuring transparency of activity and effective oversight through auditing and other activities inspires public trust and confidence in how their details are used.

4.2.2 Each service user must be offered a clear description about the processing of IdA data in advance of any processing. Identity providers must be transparent with users about their particular models for service provision.

4.2.3 The information provided includes a clear explanation of why any specific information has to be provided by the service user (for example, in order that a particular level of identity assurance can be obtained) and identifies any obligation on the part of the service user (such as in relation to the user’s role in securing their own identity information).

4.2.4 The service user will be able to identify which service provider they are using at any given time.

4.2.5 Any subsequent and significant change to the processing arrangements that have been previously described to a service user requires the prior consent or approval of that service user before it comes into effect.

4.2.6 All procedures, including those involved with security, should be made publicly available at the appropriate time, unless such transparency presents a security or privacy risk. For example, the standards of encryption can be identified without revealing the encryption keys being used.

4.3 Multiplicity

“I can use and choose as many different identifiers as I want to.”

4.3.1 A service user is free to use any number of identifiers that each uniquely identifies the individual or business concerned.

4.3.2 A service user can use any of their identities established with an identity provider with any service provider.

4.3.3 A service user shall not be obliged to use any identity provider or service provider not chosen by that service user; however, a service provider can require the service user to provide a specific level of identity assurance, appropriate to the service user’s request to a service provider.

4.3.4 Where a service user chooses to register with more than one identity provider, identity providers and service providers must not link the service user’s different accounts or gain information about their use of other providers.

4.3.5 A service user can terminate, suspend or change identity provider.

4.4 Data minimisation

“My interactions only use the minimum data necessary to meet my needs.”

4.4.1 Identity assurance should only be used where a need has been established and only to the appropriate minimum level of assurance.

4.4.2 Identity assurance data processed by an identity provider or a service provider to facilitate a request of a service user must be the minimum necessary in order to fulfil that request in a secure and auditable manner.

4.4.3 When a service user stops using a particular identity provider, their data should be deleted. Data should be retained only where required for specific, targeted fraud, security or other criminal investigation purposes.

4.5 Data quality

“I choose when to update my records.”

4.5.1 Service providers should enable service users (or authorised persons, such as the holder of a power of attorney) to be able to update their own personal data, at a time of their choosing, free of charge and in a simple and easy manner.

4.5.2 Identity providers and service providers must take account of the appropriate level of identity assurance required before allowing any updating of personal data.

4.6 Service user access and portability

“I have to be provided with copies of all of my data on request; I can move or remove my data whenever I want.”

4.6.1 Each identity provider or service provider must allow, promptly, on request and free of charge, each service user access to any IdA data that relates to that service user.

4.7 Certification

“I can have confidence in the identity assurance service because all the participants have to be certified against common governance requirements.”

4.7.1 As a baseline control, all identity providers and service providers will be certified against a shared standard. This is one important way of building trust and confidence in the service.

4.7.2 As part of the certification process, identity providers and service providers are obliged to cooperate with the independent third party and accept their impartial determination and to ensure that contractual arrangements:

  • reinforce the application of the identity assurance principles
  • contain a reference to the independent third party as a mechanism for dispute resolution

4.7.3 There will be a certification procedure subject to an effective independent audit regime that ensures all relevant, recognised identity assurance and technical standards, data protection or other legal requirements, are maintained by identity providers and service providers.

4.7.4 In the context of personal data, certification procedures include the use of privacy impact assessments, security risk assessments, privacy by design concepts and, in the context of information security, a commitment to using appropriate technical measures (such as encryption) and ever improving security management. Wherever possible, such certification processes and security procedures reliant on technical devices should be made publicly available at the appropriate time.

4.7.5 All identity providers and service providers will take all reasonable steps to ensure that a third party cannot capture IdA data that confirms (or implies) the existence of a relationship between any participants. No relationships between parties or records should be established without the consent of the service user.

4.7.6 Certification can be revoked if there is significant non-compliance with any identity assurance principle.

4.8 Dispute resolution

“If I have a dispute, I can go to an independent third party for a resolution.”

4.8.1 A service user who, after a reasonable time, cannot, or is unable, to resolve a complaint or problem directly with an identity provider or service provider can call upon an independent third party to seek resolution of the issue. This could happen, for example, where there is a disagreement between the service user and the identity provider about the accuracy of data.

4.8.2 The independent third party can resolve the same or similar complaints affecting a group of service users.

4.8.3 The independent third party can cooperate with other regulators in order to resolve problems and can raise relevant issues of importance concerning the identity assurance service.

4.8.4 An adjudication or recommendation of the independent third party should be published. The independent third party must operate transparently, but detailed case histories should only be published subject to appropriate review and consent.

4.8.5 There can be more than one independent third party.

4.8.6 The independent third party can recommend changes to standards or certification procedures or can recommend that an identity provider or service provider should lose their certification.

4.9 Exceptional circumstances

“Any exception has to be approved by Parliament and is subject to independent scrutiny.”

4.9.1 Any exemption from the application of any of the above principles to IdA data shall only be lawful if it is linked to a statutory framework that legitimises all identity assurance services, or an identity assurance service in the context of a specific service. In the absence of such a legal framework then alternative measures must be taken to ensure transparency, scrutiny and accountability for any exceptions.

4.9.2 Any exemption from the application of any of the above principles that relates to the processing of personal data must also be necessary and justifiable in terms of one of the criteria in Article 8(2) of the European Convention of Human Rights: namely in the interests of national security; public safety or the economic well-being of the country; for the prevention of disorder or crime; for the protection of health or morals, or for the protection of the rights and freedoms of others.

4.9.3 Any subsequent processing of personal data by any third party who has obtained such data in exceptional circumstances (as identified by Article 8(2) above) must be the minimum necessary to achieve that (or another) exceptional circumstance.

4.9.4 Any exceptional circumstance involving the processing of personal data must be subject to a privacy impact assessment by all relevant data controllers (where “data controller” takes its meaning from the Data Protection Act).

4.9.5 Any exemption from the application of any of the above principles in relation to IdA data shall remain subject to the dispute resolution principle.