Guidance

UK digital identity & attributes trust framework alpha v2 (0.2)

Updated 26 January 2023

**Please note, an updated ‘beta’ version of the trust framework was published on 13 June 2022. Read the most recent version of the framework.

1. Ministerial foreword

Matt Warman MP, Minister for Digital Infrastructure

On 11 February 2021 I oversaw the publication of the UK digital identity and attributes trust framework - alpha version. This was a huge step forward in setting the national approach for digital identity solutions, enabling people to prove who they are or something about themselves easily and securely. Such solutions will unlock improved user experience in the digital world, increase security, and boost economic growth.

This early prototype of the rules and standards for digital identity and attribute solutions was knowingly published unfinished to give interested parties the earliest opportunity to input, comment and shape its development. Thanks to that feedback, today I am pleased to publish this update, as well as announce the opening of expressions of interest for organisations to take part in the first live tests of the trust framework.

I was gladdened by the response from industry to both our approach and the first draft of the trust framework itself. Businesses are welcoming the direction of travel and investing time and expertise in helping us to get this right. It is clear that digital identity is being pushed up the agenda across a variety of sectors and services, and I will continue to ensure the government shows clear leadership in this space. The pace of progress means that the framework was recently complemented by our consultation on the legislation and governance needed to underpin the rules of the road. The consultation is open for responses until 13 September.

We have also taken on board the feedback from the online survey that accompanied the publication of the alpha version. This has been bolstered by extensive engagement sessions across the public and private sectors, civil society, and other experts. The result of this is the updated version today, which is expanded to detail the approach to certification; clarifies our intention for roles and relationships; and is better adapted to the needs of different services and use cases.

Also of note were the responses received from members of the public, which included concerns and misconceptions about the government’s intentions for the framework. Their voices have been heard and we recognise their concerns must be addressed. In order to do so, we must go further in our communications to explain how our work differs from the centralised databases and identity cards of other nations; why a rules based approach will improve security rather than increase risks; and how the framework seeks to ensure transparency and control for people over how their data is used. Testing real world services will also demonstrate how abstract rules become a reality and help us ensure our principles are protected under the framework.

This updated trust framework enables us to move forward with these testing plans. The next stage of alpha testing will look to the finer details of the content and processes around joining. This will involve working with eventual users of the trust framework to undergo a preliminary assessment against it, with opportunities for a range of organisations to participate and help shape the beta publication. Please see the alpha testing page for more information and submit the expression of interest form by Sunday 5 September if you want to be involved.

Equally important is ensuring continued support from stakeholders throughout the public and private sectors, academia, and civil society. Continued engagement, workshops and scenario testing will make sure developments increase consumer trust. The Government Digital Service’s One Login system for government will also align with and help inform trust framework rules as they develop.

Once the cycle of alpha testing is complete next year, we will move to the more dynamic beta phase - facilitating the secure checking of data in real world scenarios through sandbox style testing. The details of this testing will be shared at the earliest opportunity. The full trust framework will go ‘live’ once the legislative and governance measures are implemented. In the interim we will support the proliferation of digital identity services to enable them to transition smoothly to the national framework.

We are positive that timely, decisive progress can be made when the government works in partnership with the people and organisations that use and build identity and attributes products and services. We welcome your continued support and look forward to working with you as the framework develops.

Matt Warman MP

Minister for Digital Infrastructure, Department for Digital, Culture, Media and Sport

2. Feedback and updates

This document covers the feedback received from the alpha online survey, where the majority of feedback received came from members of the public. It also covers engagement sessions held with over 200 stakeholders from industry, civil society, the public sector and other experts over the last five months.

2.1 Feedback from organisations

Many organisations which responded to the survey or through other engagement channels gave positive feedback, commending the approach and direction from the government. A selection has been copied below:

• The Finance and Leasing Association (FLA) told us that: ‘DCMS has worked tirelessly to adapt both its Digital Identity Trust Framework and its GPG 45 best practice guidance in order to accommodate key regulatory standards Financial Services work to, in particular in relation to AML regulations. The Digital Identity agenda is key for FLA members, who appreciate Government support in this key area.’
• The Open Identity Exchange (OIX) saw the alpha as a ‘good step towards defining how Digital ID can work successfully to support the UK economy’.
• The Age Verification Providers Association (AVPA) commented: ‘Innovation is a team game, and it is all the more important to engage widely with experts when tackling ground-breaking technology projects. By working transparently with representatives from every corner of industry with knowledge and interest in this project, the team at DCMS has set a tremendous precedent for developing public policy in complex technical territory.’
• UK Finance expressed support for the publication, in particular commending the ‘close work with industry’ and ‘approach to technology neutrality’.

This enthusiasm has also been reflected by the investment the public and private sectors, civil society, and academia have given since publication to provide detailed feedback.

The feedback has informed many of the new and existing sections in this update. For example, the section explaining the rules for scheme owners has been expanded to explain how schemes will operate in more detail. We have also provided more definitions and examples for each of the trust framework roles to make it easier for organisations to understand which apply to them.

Some organisations felt the trust framework was too prescriptive in certain areas. We have assessed these on a case-by-case basis and updated many of the rules accordingly to further demonstrate the framework’s technology-neutral approach. Other changes include an updated privacy section to clarify the relationship to data protection legislation and where additional protections are in place.

2.2 Feedback from members of the public

There was a significant amount of feedback received from members of the public. In the main, this feedback told us that individuals have concerns about digital identity products, particularly around use of their data. Concerns around fraud, security risks and breaches of privacy were mentioned frequently, as well as worries that certain groups of society would be excluded by this type of technology in the future, for example older generations. There was a high level of repetition in the wording of many of these responses, indicating that individuals were being directed by a single source. Misconceptions were also common, with some respondents unsure of the difference between the trust framework approach and a centralised national identity card system.

The feedback has told us that public understanding is needed to progress this policy and reassure individuals that the trust framework is being developed to protect their data and improve access to services. The trust framework does not enable organisations to process personal data in new ways. Instead, its role is to facilitate smarter, privacy-focused checking of data for the benefit of users, as well as enabling organisations to work together more effectively. Practical digital solutions which meet the framework’s rules will help to evidence the government’s intentions and ensure members of the public feel safe in adopting digital identity solutions. Communications will be ongoing, beginning with publications such as this and working in partnership with industry, civil society, and other organisations to deliver consistent, accurate information.

2.3 Information Commissioner’s Office’s position paper

DCMS has noted the ICO’s recent position paper on the government’s proposal for a trusted digital identity ecosystem. We welcome the regulator’s active engagement as we develop the policy and their recognition that digital identity systems can be developed to ensure privacy for the public. On the recommendations contained in the paper, the alpha has now been iterated to highlight key areas such as automated decision-making and protecting children. We have also taken on board the proposal to develop a Data Protection Impact Assessment on the trust framework itself; this will be published alongside the beta version of the trust framework in order to incorporate learnings from alpha testing.

2.4 Certification

The most significant change for this update is the content on the certification scheme for the trust framework. Certification is essential if the framework is to be able to secure trust and the best way of delivering this is through a standard approach which organisations will recognise and be confident in using. We plan to appoint the UK Accreditation Service (UKAS) to accredit certification bodies to manage the certification process. The feedback received during engagement sessions was supportive of the approach, recognising this as a widely used method for achieving trust, and delivers independent assessment in line with industry standards.

There are two key areas where feedback has proved vital as we develop the policy. The first was our approach to relying parties. Relying parties in the context of the trust framework are organisations who consume information from identity and attribute service providers. These organisations will receive data which they can then use to grant access to a service. They will not provide identity or attribute services themselves, although organisations are permitted to play more than one role under the trust framework. Feedback has told us that it is disproportionate to expect relying parties to become certified against the trust framework. Given the wide variety of use cases for digital identity in the future, it does not appear realistic or necessary to expect all organisations who accept digital identity to be externally audited. For example, requesting independent shops go through the certification process before they could accept trust framework digital identities as proof of age. It could also delay the market developing by creating a bottleneck of organisations becoming certified. Given the UK already has strong data protection legislation in place, a more nuanced approach is required while still maintaining security of the ecosystem. In this new version, we have proposed that relying parties will need to sign flow-down conditions when agreeing terms with other trust framework participants, but would not need to become certified themselves.

The second most significant change is the approach to scheme certification. A scheme is made up of different organisations who agree to follow a specific set of rules around the use of digital identities and attributes, building on the foundational trust framework rules at a lower level of detail. Organisations may join the trust framework directly or via schemes. Feedback told us that more clarity was needed on how the two approaches interact and when organisations want to join more than one scheme. During the engagement sessions, organisations questioned whether they would need to undergo many different certification processes if they wanted to be part of different schemes, which would be costly and burdensome. Or if joining directly as an individual organisation would be meaningless, as it would not involve certification against scheme-level detail. This was not our intention and we have clarified the position in the rules for scheme owners section of this publication.

2.5 Trust mark

During engagement sessions, the majority of organisations were supportive of our proposal to have a trust mark associated with certification against the trust framework. When questioned whether one consistent trust mark or variations to show the role, scheme or level of assurance relevant to that organisation would be preferable, there was a strong consensus that a single trust mark would be most useful in building user trust and recognition. Understanding the target audience for the trust mark, whether that be organisations or members of the public, was also highlighted as being important. We plan for the trust mark to serve a dual purpose across both those groups.

There are further considerations around the implementation of the trust mark, which primarily centre around the risk of fraudulent use by criminal groups. While there is already legislation in place to deter such activities, it is recognised that it may be difficult to identify and take down scams quickly. One planned action is to ensure a published list of trust-marked organisations is available publicly for transparency. We will explore additional protections as we move closer to implementation.

2.6 Liability

Both the feedback survey and engagement sessions continued to demonstrate that clarity around liability is essential for the trust framework to work. Proposals for managing liability as it relates to redress for consumers are detailed in the consultation. The consultation also contains proposals for a statutory presumption to affirm that digital identities and digital attributes can be as valid as physical forms of identification or traditional identity documents. This should help to build confidence and clarify liability for all parties using digital identity solutions.

Further research conducted since the publication of the alpha in February concluded that the liability between organisations should be predominantly left to organisations to determine through contractual arrangements (which may be embedded into scheme-level terms and conditions). This is for three main reasons. Firstly, the varying sectors, use cases and risk appetites for organisations building and using digital identity solutions are so broad that it would be extremely difficult to agree conditions that work for all parties. Secondly, there is a desire from the market for the government to deliver what only the government can deliver; liability arrangements between commercial organisations would overstep this boundary. Lastly, industry is well-equipped to manage their liabilities in other areas and the trust framework will provide the foundation upon which to build these arrangements in a digital identity context. This thinking is reflected in the feedback received, although we have noted it is not unanimous, with some organisations expecting us to go further. The trust framework is still in the alpha phase of development, and therefore the position outlined may change post-testing. We would require clear proposals and evidence from industry before considering this point further.

Where the trust framework can help is by providing a backdrop to fault-based liability, whereby organisations are only liable to each other in most circumstances if they have not followed trust framework rules. This is a position we envisage organisations considering as they develop their commercial relationships.

2.7 Portability of digital identities

The right to data portability is part of existing data protection legislation. It allows individuals to obtain and reuse their personal data for their own purposes across different services. During engagement sessions, we explored how we might build on this right within the context of the trust framework to deliver increased value for individuals who may want to change identity service provider, or may need to if a provider leaves the framework.

It was recognised that some solutions by design naturally facilitate data portability, through providing a secure means to store or share attributes that have been issued by another organisation. For other solutions, such as those following a federated account-based model, data portability may be more difficult to implement and undermine their commercial model. It is also noted that data portability initiatives, such as those which fall under the government’s Smart Data work, are typically around encouraging competition and improving customer outcomes in established markets, as opposed to nascent ones; therefore rules beyond data protection legislation should be cautiously considered. For this iteration, we have highlighted data portability as a key consideration for auditors when assessing how organisations meet data protection rules and legislation. There could be scope for refining this approach when the market is more fully developed.

3. Introduction

This is the second iteration of the UK digital identity and attributes trust framework alpha, following the publication of the first iteration in February 2021. The trust framework aims to make it easier and more secure for people to use services that enable them to prove who they are or something about themselves. It is a set of rules for organisations to follow if they want to provide secure and trustworthy digital identity and/or attribute solutions.

This document explains what rules organisations will need to follow to be certified against the trust framework in the future. It does not supersede the requirements in any other contracts, policies or legislation that organisations already need to meet.

This document does not:

• explain what legislative or governance arrangements are needed to make sure the trust framework is ready for use in the economy - this is covered in the consultation
• provide a technical architecture for digital identity and attributes
• set commercial arrangements for organisations

3.1 Terms and definitions

Whenever ‘you’ is used in this document it refers to organisations, in the context of the specific service(s) they want to use under the trust framework.

We use ‘user’ to refer to people who will use digital identity or attribute services to prove their identity or eligibility.

The word ‘must’ is used for any rules that organisations have to prove they’ve met. How organisations do this will be explained during the certification process.

The word ‘should’ is used when it’s only recommended that organisations meet a rule.

Read the glossary for a full list of terms and definitions.

4. What are digital identities?

In the context of this trust framework, a digital identity is a digital representation of a person acting as an individual or as a representative of an organisation. It enables them to prove who they are during interactions and transactions. They can use it online or in person. Services and organisations that let users use secure digital identities can better trust that those users are who they say they are.

Digital identity products and services developed under the trust framework are not the same as centralised identity databases or digital ID cards. The trust framework will enable users to choose a range of services created by different organisations that use different technologies to meet diverse user needs.

Anyone can choose to create one or more digital identities (a user may choose to have different digital identities to use in different contexts). They do not have to create a digital identity if they would prefer not to.

Sometimes digital identities will be created for just one type of transaction at a specific point in time.

Example

Cliff needs to prove his identity to apply for a loan online. Doing this creates a digital identity.

Cliff can only use this digital identity to complete his application and open an account. He cannot use it to do anything else.

Other digital identities will be ‘reusable’, which means they can be used again and again for different interactions and transactions across organisations.

Example

Peggy is buying her first home. She creates a digital identity when she checks her credit score online with a credit scoring agency. The credit scoring agency is a participant of a scheme in the trust framework.

Peggy decides to apply for a mortgage from a bank. The bank is also a participant of a scheme in the trust framework. This means she can use her digital identity again to apply for the mortgage.

Peggy will need to prove who she is several times throughout the process of buying a house, for example when she interacts with the bank, estate agents and solicitors. She can do this online, or if any of these interactions happen in real life, Peggy can show her digital identity using an app on her phone.

Whether or not an identity is reusable will rely on organisations agreeing to work together and use identities in comparable ways under the trust framework.

Using digital identities will mean users do not have to rely on manual processes (such as by post or over the phone) to interact with organisations or access services. Digital identities will be able to be used both online and offline where the process is enabled digitally. Making these sorts of interactions and transactions available digitally can also:

• save organisations time and money
• reduce the risk of fraud to organisations and users
• be easier and quicker for users to complete
• reduce the risk of errors that come from managing data manually
• encourage data minimisation
• encourage innovation by helping organisations develop more services

Using digital identities This government is committed to delivering these benefits without the need for a national identity card. This means people will have the choice over when and how they use digital identities.

5. What are attributes?

Attributes are pieces of information that describe something about a person or an organisation. You can use a combination of attributes to create a digital identity. You must ‘bind’ attributes to a person before you can do this.

An attribute could be something:

• a person or an organisation is
• a person or an organisation has
• that’s issued to a person or an organisation

Attributes could be related to:

• physical or digital documents such as a bank statement
• devices such as a mobile phone
• credentials such as a university degree
• someone’s health condition

Some examples of attributes are:

• identity-related attributes such as name, address, or date of birth
• the number of children someone has
• someone’s bank account number
• someone’s National Insurance number
• someone’s NHS number
• the number of people that work for a company
• a Companies House company number
• that someone is over 18

Attributes are not only used to create digital identities. They can also help prove a user is eligible or entitled to do something. In some situations, this proof can be added to an existing digital identity. In others, there will be no need for you to know the identity of the user before they can complete an interaction or transaction.

An organisation can check attributes to see if someone is eligible to complete an interaction or transaction.

Example Carmen is a doctor and is moving to a new hospital to work. She must prove who she is and that she has the relevant qualifications before being able to start work at the hospital.

Carmen could get a digital version of her registration certificate that confirms her registration and licence to be a doctor in the UK.

The information from this registration certificate can be checked against an authoritative source, and then added as attributes to Carmen’s digital identity, which may take the form of a personal data store app (sometimes known as a ‘digital wallet’ - see glossary).

This attribute can be shared with the hospital when she arrives to work there. This will save Carmen and the hospital time, and mean she has to take fewer documents with her when she goes through the onboarding process.

Attributes can be created, collected and checked by an attribute service provider. An attribute service provider could be an organisation or a piece of software, like a personal data store or digital wallet.

Attribute service providers can share the attributes they keep with other organisations or individuals, as long as they have the user’s agreement.

Sharing attributes can mean:

• users can share information about themselves to access services more easily
• users and organisations do not have to update information in more than one place whenever something changes

Sometimes attributes will be used for just one type of transaction at a specific point in time.

In other situations the attributes will be ‘reusable’, which means they can be used again and again for different interactions and transactions.

6. What the UK digital identity and attributes trust framework does

The UK digital identity and attributes trust framework will let people use and reuse their digital identities. It will also give them a way to share their attributes with other people and organisations more easily.

One reason why this does not currently happen is because one organisation does not know how another creates digital identities or attributes. This means they’re not able to trust if the processes the other organisation followed are secure.

The trust framework is a set of rules that different organisations agree to follow to deliver one or more of their services. This includes legislation, standards, guidance and the rules in this document. By following these rules, all services and organisations using the trust framework can describe digital identities and attributes they’ve created in a consistent way. This should make it easier for organisations and users to complete interactions and transactions or share information with other trust framework participants.

6.1 Rules of the trust framework

UK digital identity and attributes trust framework participants will be certified against a set of government-approved rules. This means that one organisation can trust that the information another shares with them is accurate and reliable.

To meet the rules of the trust framework, you will need to prove you’re able to safely manage users’ digital identities or attributes. The rules will be ‘outcome based’. By following them, you will achieve certain goals. The rules will not instruct you to use specific technologies or processes, but will recommend you follow open technical standards to strengthen interoperability between participants. This means you will be able to focus on innovating and developing products and services that work best for your users, without being restricted to using certain technologies.

7. What you get from being part of the trust framework

Being part of the UK digital identity and attributes trust framework will help your organisation:

• save time, effort and money
• improve the user experience of your existing services
• develop new services, which can create new revenue streams
• deal with data breaches, identity fraud and misuse
• show that you’re committed to creating trustworthy products and services that protect people’s data
• share digital identities and attributes with other organisations from a variety of countries, industries and sectors
• comply with regulation, such as data protection

8. Benefits for users

Being able to share their digital identities and attributes with different organisations, and between users, will make it easier for users when they choose to complete interactions and transactions digitally. This is because it will be much quicker and safer to prove their identity and eligibility when they interact with a new organisation. The UK government plans to make it possible for this to happen across different industries, sectors and countries where it’s safe and legal to do so.

The trust framework focuses on user choice and user control at the centre of its design. It includes privacy and data protection rules, which you must follow when developing and managing your products and services. These rules are designed to give users more control over what personal information they use to create a digital identity. You must also follow rules to develop accessible and inclusive products and services. These rules are designed to allow as many users as possible to create digital identities and manage their attributes.

In most circumstances, users will be able to choose which services and organisations can see and share their personal data, and how long they will have access to it for. They will not have a choice in specific situations, for example if they’re the subject of a police investigation. They’ll also know exactly who is involved in creating and maintaining their digital identity.

There will also be more opportunities for ‘data minimisation’. This is when information is only shared if it’s needed to give a user access to a service. For example, when buying age-restricted products, a retailer only needs to know that a user is over a certain age e.g. ‘over 18’. They do not need to see the rest of the information on their identity document. Making sure personal information is shared and managed securely will put users, services and organisations at a lower risk of identity fraud.

9. Who runs the trust framework?

The trust framework will be overseen by a governing body chosen by the UK government. The consultation, which is open until 13 September 2021, considers the roles and responsibilities of the governing body in greater detail. It includes proposals for the governing body to:

• manage the trust framework on an ongoing basis
• set up and provide oversight of accreditation and certification processes so qualifying organisations prove compliance with a trust mark
• monitor compliance and performance
• oversee member organisations and the management of schemes
• promote consumer protection by managing enforcement, complaints, and redress
• collaborate with stakeholders and other regulators
• maximise security and minimise fraud, and
• promote and encourage inclusion.

For further details please refer to the consultation. Please note the governing body is distinct from the role of scheme owner.

10. How organisations participate in the trust framework

Organisations can participate in the trust framework by:

• themselves as a single organisation
• setting up a scheme for multiple organisations, or
• joining as part of a scheme set up by another organisation

How organisations participate in the trust framework

A scheme is made up of different organisations who agree to follow a specific set of rules around the use of digital identities and attributes. These organisations might work in the same sector, industry or region, which means they will build products and services for similar types of users.

A scheme can help organisations work together more effectively for a number of reasons. For example, it could make it easier for them to comply with the rules of the trust framework, comply with broader rules and regulations specific to a sector(s), or share information amongst participants. They can do this by adding additional rules to the trust framework rules that may relate, for example, to a particular sector, scenario, or use case.

Example

An estate agent might want to find out the best way to check identities of potential house buyers. They can join a scheme with other organisations that play a role in the house buying process.

Being part of the scheme will mean they have access to operational, technical and commercial guidance that’s specific to their industry. This is more detailed than the rules of the trust framework.

Some schemes which could operate under the trust framework already exist or are being developed, while others could be developed in the future.

A scheme is created and run by a scheme owner.

10.1 Roles and responsibilities

Whether an organisation uses the trust framework on their own or as part of a scheme, they will need to perform at least one of the following roles:

• an identity service provider
• an attribute service provider
• an orchestration service provider
• a relying party
• a scheme owner

Roles and responsibilities in relation to the trust framework

The role(s) you choose to play in the framework will impact which trust framework rules are relevant and whether you need to become certified. If your organisation chooses to perform multiple roles, you must follow the rules for each role.

To be certified, an independent certifying body will need to check that you follow all the rules for the role(s) you want to perform. You’ll get a trust mark after you’ve been certified and approved. This will:

• show other organisations that you meet the rules, and
• help users feel more confident about using your product or service.

Further details on the certification process are in the certification section.

Identity service providers

Identity service providers prove and verify users’ identities. They can do this using online or offline channels, or a combination of both. An identity service provider can be a public or private sector organisation. They can either:

• specialise in proving and verifying users’ identities, or
• offer identity proving and verification alongside other services - an example of this might be a bank, solicitor, library or postal organisation.

An identity service provider does not need to do all parts of the identity checking process. They can specialise in designing and building components that can be used during a specific part of the process. For example, they could develop software to:

• validate identity evidence (e.g. mobile account validation)
• check identity evidence is genuine (e.g. passport chip reading)
• manage authentication
• provide biometrics-enabled identity verification (e.g. face biometrics)
• provide biometric authentication (e.g. fingerprint biometrics on a mobile device), and
• provide identity fraud services (e.g fraud database checking).

Identity service providers can be authorised by a user to share the verified digital identity with relying parties. The relying party can then use this to give them access to the service or create an account. Other identity service providers might choose to create an account associated with a user’s identity. The user can then use and reuse this account to do different things with different relying parties. For example:

• identity verification services (which offers a point in time verification, and the user may or may not have an account)
• reusable digital identity services with an account and authentication (federated, self sovereign identity (SSI), wallet), and
• reusable authentication services with an account and authentication (federated, SSI, wallet).

Digital identities and attributes can only be associated with a digital account with the user’s agreement. The trust framework sets no limits to the number of accounts a user can create, however organisations and schemes may set their own limits. It is possible for organisations to provide multiple roles under the trust framework. For example your organisation may be both an identity service provider and attribute service provider.

Attribute service providers

Attribute service providers collect, create, check or share pieces of information that describe something about a user. Attribute service providers can share their attributes with relying parties and identity service providers, when they must have the user’s agreement.

If an identity service provider is collecting, creating, checking or sharing attributes as part of their service, they will also be an attribute service provider. They will need to follow the rules for both roles.

Attribute service providers must be able to assess the quality of the attributes they keep. Relying parties and identity service providers will use this information to choose which attribute service provider they request attributes from. Examples of attribute service providers include:

• attribute issuers from the public sector - attributes found in documents such as passports, driving licences, birth certificates
• attribute issuers from the private sector - mobile number, bank account, credit score, mortgage, and
• attribute holders - including in organisational databases (e.g. a credit reference agency database); and in services controlled by a user such as personal data stores, wallet, apps, SSI services.

Orchestration service providers

Orchestration service providers make sure data can be securely shared between participants in the trust framework through the provision of their technology infrastructure. Examples of orchestration service providers include:

• identity and attribute broker service providers
• identity and attribute hub service providers
• identity access management service providers, and
• distributed ledger service providers.

An organisation is able to play more than one role in the trust framework and is not, for example, limited to just being an orchestration provider.

The technical options for orchestration of identity and attributes is broad and open to innovation. The trust framework sets out the outcomes for orchestration providers.

Relying parties

Relying parties are organisations that use (or ‘consume’) products or services from other participants in the trust framework. This means that organisations such as airlines, banks and retailers may not have to check users’ identities or attributes themselves.

A relying party might need to make sure a user is who they say they are before letting them do something. To do this, the relying party can ask an identity service provider to prove a user’s identity. A relying party might also need to check if a user is eligible to do something. They can do this by requesting attributes, or information about attributes, from an attribute service provider.

Relying parties do not need to be certified against the trust framework, but they will be subject to flow-down conditions from the trust framework organisation(s) they have a relationship with to ensure security of the ecosystem. Principles for these flow-down conditions will be defined when the trust framework moves to the beta stage of development.

The role of relying party in the context of the trust framework means an organisation that receives, interprets and - depending on the use case - stores information received from other trust framework organisations. Organisations which are providing additional functions related to the information received e.g. binding it to an individual will likely also be playing another role under the trust framework and may require certification.

Scheme owners

A scheme owner creates and runs a scheme under the trust framework.

The scheme owner sets the rules of the scheme. They must ensure their scheme follows the rules of the trust framework. This is known as a ‘scheme specification’.

It should include:

• what roles are available in the scheme
• how participants should work together
• how participants should process data about their users, and
• how participants can work to create interoperability between schemes.

The scheme owner is responsible for making sure all members follow the scheme specification. They will also be responsible for keeping an up-to-date list of all organisations that are part of their scheme, which they will share with the governing body.

All scheme owners must be licensed by the governing body before they can operate under the trust framework. The process for licensing will be outlined as part of the governance model design.

Relationships between participants

It is up to individual organisations to determine commercial relationships and decide who to work with, but interoperability across the trust framework is highly encouraged.

When deciding who to work with, the expectation is that trust framework participants will only share and receive identity and attribute data with other trust framework participants (which may or may not be certified depending on their role). The feasibility of this is something which will be assessed as part of alpha testing.

The following are examples of some of the possible relationships between trust framework participants. Please note these are not exhaustive and are for illustrative purposes only.

Example 1

Relationships between participants - example 1

Example 2

Relationships between participants - example 2

11. Rules for identity service providers

Identity service providers must follow these as well as the rules for all trust framework participants.

11.1 Create a digital identity

All identity service providers must use the guidance on how to prove and verify someone’s identity as a methodology to explain their product or service. This is also known as Good Practice Guide (GPG) 45. If you claim your service meets particular levels of confidence or profiles detailed within the guidance, you will need to evidence how these are met during the certification process. If your service only meets one element of the identity checking process, such as biometric facial matching, you will need to accurately describe how your service aligns to that part of the guidance.

This approach is intended to be flexible enough to enable organisations to develop innovative services to meet their user’s needs, whilst providing a methodology in which to consistently describe their service offering. This will help to enable interoperability and assure relying parties that providers are meeting the level of confidence they require. The guidance will remain as best practice and will be iterated as required during the testing of the trust framework.

12. Rules for attribute service providers

Attribute service providers should follow these as well as the rules for all trust framework participants.

12.1 Understanding attributes

Attributes are pieces of information that describe something about a person or organisation.

Attributes can help people prove that they are who they say they are, or that they’re eligible or entitled to do something.

You should read the guidance on understanding attributes.

12.2 Create attributes

You should follow the guidance on how to create attributes.

You should:

• create the new attribute in an appropriate way
• bind it to a person or organisation, and
• show how reliable and secure it is.

All attribute service providers should link their attributes to a person or organisation using a process called binding. This involves using an ‘identifying attribute’ to make the connection. An identifying attribute, or ‘identifier’, is a unique attribute or combination of attributes that can be used to identify a person or organisation.

Example

When someone starts a new job they’re given a unique employee number, which is an identifying attribute. This links the person with their job title (another attribute).

The HR department uses the identifying attribute to link the employee’s other attributes to the employee. Their other attributes include their salary and how many hours they work a week.

For example, one office has 2 employees named Daniel Jones. When the HR department gets a phone call from one of them, the HR representative asks for their employee number. This helps them know which Daniel Jones they’re talking to.

If you do not bind your attributes, other organisations will not be able to tell who they belong to. This will make them harder to use and less valuable.

Sharing attributes

Before you share or allow checks against an attribute, you must check:

• when the attribute was last updated
• you’ll share it in a way that meets the privacy and data protection rules (including obtaining the user’s agreement), and
• if the person or organisation requesting it has the right to see it.

You can then share it in an appropriate way.

12.3 Assessing attribute quality

You should have a way of assessing the quality of attributes that you create or share. This could mean that you follow the guidance on how to score attributes or you could follow your own processes.

Relying parties can use your assessment to decide which attributes meet their needs.

13. Rules for all identity and attribute service providers

13.1 Create a reusable digital identity or attribute service

If you are an identity or attribute service provider who wants to create a reusable digital identity or attribute service, you must link the digital identity and/or attributes to an authenticator (such as a password, piece of software or device). You must follow the guidance on using authenticators to protect an online service. This is also known as GPG 44.

If someone has already been through an identity verification process to use another service you provide, you might be able to develop this into a trust framework service. For example:

• a bank could reuse a user’s details from when they signed up to online banking to help them create a trust framework digital identity service. To do this they must describe how their identity checking and authentication aligns with the following guidance: how to prove and verify someone’s identity and using authenticators to protect an online service. They must also meet the other relevant rules in the trust framework.
• an identity proofing and verification process has bound an identity to an qualified electronic signature by a qualified trust service provider

A service provider could rely on the identity verification process that was used by a qualified trust service provider (QTSP) to create a qualified certificate. This process could be used to create a trust framework digital identity service for a user. The service provider must describe how their identity checking and authentication aligns with the following guidance: how to prove and verify someone’s identity and using authenticators to protect an online service. They must also meet the other relevant rules in the trust framework.

• a strong authentication process has bound a user to an electronic signature issued by an advanced electronic signature provider

Where the service providers would like to provide a service under the trust framework, they must follow the relevant authentication requirements as described in using authenticators to protect an online service, and they must follow the guidance on how to prove and verify someone’s identity if they verify the identity of their users. They must also meet the other relevant rules in the trust framework.

• where simple electronic signature providers would like to provide a service under the trust framework, they must follow the guidance on using authenticators to protect an online service. If they want to verify the identity of the user they must follow the guidance on how to prove and verify someone’s identity. They must also meet the other relevant rules in the trust framework.

You must get the user’s permission before you use their data.

13.2 Manage digital identity and attribute accounts

A digital identity or attribute account is the software based service used to allow an identity or attribute to be asserted by a user multiple times.

If your service includes a user account, you should follow the rules in this section.

You should have a process to revoke, suspend, close, recover and make changes to accounts.

You should close an account if the user:

• has used the account to do something illegal
• has not followed the terms of use they agreed to
• wants to close it
• has died.

You should also close the account if you have evidence it’s being used by someone who should not have access to it. This usually happens because there’s been a data breach.

Recover digital identity and attribute accounts

You must have a process in place to take a user through an account recovery process This process must follow the guidance outlined in using authenticators to protect an online service. if you suspect someone who should not have access to the account has either:

• signed in to their account, or
• used their digital identity or attributes to do something.

You should have a process in place to let the user know what’s happened. It’s important to explain that they could be at risk of having their identity stolen, and ask the user to look at their recent account activity and check if there are any interactions they did not do.

If it’s a digital identity account, you should prove and verify the user’s identity again. You should aim to get a higher level of confidence than you did when you first set up the digital identity account. You should also consider alternative identity evidence and methods of identity verification. This will help you be sure that the user is not an impostor.

You should have a way to:

• suspend and then close down any accounts an impostor has created with your organisation
• give the user information about any interactions or transactions the impostor completed using these accounts
• give the governing body and relevant scheme owners information about the impostor and the things they did, and in alignment with legal and regulatory requirements, provide law enforcement agencies information about the impostor and the things they did.

If a user makes changes to their account

You should have a process in place to tell the user if any changes have been made to their account. You should also tell them if you’ve had a request to close their account.

If the user wants to change their contact details, you must do a verification check to make sure they’re the same person who created the digital identity. You will need at least a similar level of confidence to what you currently have.

13.3 Make sure your products and services are inclusive

Making your products and services inclusive means as many people as possible can use them no matter who they are or where they’re from. This includes people who do not have traditional identity documents such as passports, or who may find it difficult verifying their identity to access services online.

One of the aims of the trust framework is to make it as easy as possible for users to create and use digital identities (either online or in person). We are not expecting all services to be 100% inclusive, but they must have considered who they might be excluding and how they can mitigate against this. There are also notable reasons why someone might be legitimately excluded, such as it being fair to restrict service access on account of someone’s age e.g. you cannot buy certain products until you are 18.

Organisations must follow the Equality Act 2010 by considering how to make sure no one is excluded because of their ‘protected characteristics’. This applies to all organisations offering services. Public sector organisations or non-public sector organisations carrying out public functions will also need to meet the public sector equality duty (PSED) detailed in the Equality Act 2010.

How to make your product or service more inclusive

There are many reasons why a user may be excluded from using a product or service. One common reason is because users are asked to provide specific evidence as proof of their identity.

Example

A service that only accepts a UK passport as proof of someone’s identity will exclude users who do not have, cannot find or cannot afford a UK passport.

You can prevent this from happening by accepting a wide variety of evidence as proof of users’ identities and eligibility, provided they still combine to meet the relying party’s required level of confidence. You can also choose to accept a declaration from someone that knows the user (known as a ‘vouch’) as evidence.

Requiring information to be checked against certain authoritative sources can also exclude some users from creating a digital identity.

Example A service that only checks users’ information against a credit reference agency database will stop users who do not have much of a credit history from creating a digital identity. This could exclude users because of their age or income.

You can prevent this from happening by checking information about users against a wider range of sources.

Another reason why you might exclude users is if a product or service uses any software that’s only been tested with a specific user group.

Example A service might check users’ identities using an existing facial recognition system that was tested with a small sample of users. As most of these users were white men, the system was not taught how to recognise users of other genders or ethnicities.

By choosing this system, the service will exclude some users from proving their identity because of the way they look.

You can prevent this from happening by choosing software that you know has been performance tested with a variety of users from different demographics.

If your service involves the use of biometric technology, you should develop or use solutions which follow industry standards on developing inclusive and accessible biometric systems, such as ISO/IEC TR 29194:2015.

You must have a process in place to evaluate the risks of additional inclusion measures from a fraud and security perspective.

Submit an annual exclusion report

In order to demonstrate how you have sought to make your product or service inclusive, we propose that identity and attribute service providers must submit an annual exclusion report as part of the ongoing certification process. The governing body will use organisations’ exclusion reports to monitor exclusion across the trust framework and make recommendations when appropriate. We are consulting on this requirement in the consultation.

13.4 Make sure your attribute products and services are accessible

You must follow the accessibility regulations if you’re a public sector organisation that’s developing apps or websites. This includes any products or services that help users create digital identities or manage their attributes.

If you are an organisation that develops products or services for the public in Wales, you’ll likely be subject to the Welsh Language Act 1993 or the Welsh Language (Wales) Measure 2011. You should check your exact legal obligations carefully so you can plan for English<>Welsh bilingualism from the outset of all relevant service development processes. The Welsh Government has published a detailed Bilingual Technology Toolkit to help organisations provide a good user experience in both Welsh and English.

You should also aim to develop products and services that everyone can use if you’re not a public sector organisation. To help do this, we suggest you follow the:

• Web Content Accessibility Guidelines (WCAG)
• the European Telecommunication Standards Institute (ETSI) standard for accessibility requirements EN 301 549 V3.2.1 (2021-03), and
• accessibility requirements suitable for public procurement of ICT products and services in Europe EN 301 549 V1.1.2 (2015-04).

Further useful guidance for meeting the requirements of the Equality Act 2010 which states that web products must be accessible to all can be found in BS 8878:2010 Web accessibility Code of practice.

You and/or the organisations you work with should make sure users have more than one way to use a product or service. For example, a user should have a manual way to access a service if they’re unable to use the online service.

13.5 Retiring your product or service

If you decide to retire your product or service, you should have a transition plan and:

• notify any users that manage their attributes with your product or service
• provide users and relying parties with a reasonable period of time to migrate to other providers
• notify any relying parties that consume attributes you’ve created, and
• notify the governing body (and the scheme, if you’re part of a scheme)

14. Rules for orchestration service providers

Orchestration providers must follow the rules for all trust framework participants). There are no orchestration provider specific rules.

15. Rules for scheme owners

Scheme owners must have a licence to operate a scheme under the trust framework. The process for obtaining a licence will be outlined as part of the governance design model. To obtain a licence all scheme owners must meet the following rules:

• have publishable documentation that can articulate their scheme, which demonstrates alignment with trust framework rules
• have a complaints, redress and escalation process - the detailed rules for this process will be outlined after the outcome of the consultation
• have a scheme-wide fraud and security management and information sharing process
• have completed a Data Protection Impact Assessment (DPIA) for your scheme (your scheme’s participants will also need to complete their own DPIAs but they may use yours as a baseline)
• not have a conflict of interest in their relationship with scheme participants, and
• not prevent organisations from being part of more than one scheme.

There are two options for scheme owners to manage the certification process for their scheme’s participants.

Option 1

The scheme is accredited by UKAS using a standard such as ISO/IEC 17065:2012. Scheme participants are certified directly to the scheme - rather than directly to the trust framework - by independent certification bodies. Scheme participants may use their scheme certification as proof they are compliant with trust framework rules when joining other schemes.

Option 2

The scheme uses the trust framework certification process outlined in the certification section for its scheme participants. Scheme participants are certified directly to the trust framework. It is up to the scheme owner how they manage compliance with additional scheme rules on top of those covered by the trust framework certification. They could have their own ‘add-on’ certification for additional rules or rely on scheme terms and conditions.

This policy will continue to be tested during the alpha phase of the trust framework.

16. Rules for all identity, attribute and orchestration service providers

Anyone that wants to be an identity service provider, attribute service provider or orchestration service provider must meet these rules.

16.1 Making your products and services interoperable with others

The trust framework recommends technical guidance is followed to encourage interoperability between organisations and schemes, in the UK and internationally. This means it will be easier for organisations and schemes to share digital identities and attributes with each other, as well as supporting mutual recognition.

The technical guidance is relevant for:

• attribute service providers
• identity service providers
• relying parties, and
• scheme owners which develop technical guidance for their scheme’s participants.

The guidance initially covers OpenID Connect and W3C’s Verifiable Credentials data models. To enable open and collaborative development, the drafts have been uploaded to Github. To contribute, please refer to the following link.

If you are sharing data under the trust framework, you must be able to validate you are receiving messages from another trust framework participant organisation or scheme. How you are able to do this will be defined closer to implementation.

How digital identities and attributes will be shared

Each organisation will need to provide enough information for another to be able to:

• identify the person, and/or
• decide if the person or organisation is eligible for something.

If the digital identity or attributes belong to a person, the organisation might need to provide a:

• date of birth
• first name
• last name, and
• process that uniquely identifies the user, such as a user or account number

To check if a person is eligible to do something, a relying party might also ask an organisation for more information. This could include their:

• nationality
• place of birth
• previous name(s)
• email address
• address
• phone number
• gender
• occupation
• income
• citizen registration number (for people resident outside the UK or non-UK nationals)
• tax reference number
• biometric information
• passport number
• qualifications
• employment history
• non-UK identity card number, and/or
• role in an organisation.

An organisation should meet the privacy and data protection rules when undertaking attribute checks and sharing attributes. This should include consideration of data minimisation and zero knowledge proof approaches.

The relying party will need to decide if the information is sufficient for what they need. Knowing where the attribute comes from and how it has been checked could help them make this decision.

If the digital identity and attributes are linked to a UK or international business, the organisation may need to provide:

• its legal name, and
• a registered identifier, such as a Companies House number.

To check if an organisation is eligible to do something, a relying party might also ask them for more information. This could include:

• any email addresses associated with the business
• any addresses associated with the business
• the country of its incorporation
• its VAT number
• its turnover
• its Legal Entity Identifier (LEI)
• its Standard Industrial Classification (SIC) code
• its Economic Operators Registration and Identification (EORI) number
• its Excise Authorisation Verification (SEED) number
• its Data Universal Numbering System (DUNS) number
• its data protection registration number.

16.2 Check if a user can act on behalf of an organisation or another person

Be aware that some users might be acting on behalf of an organisation or another person when they interact with your organisation. This is known as ‘delegated authority’. There are a number of reasons why this might be appropriate, such as:

• the user might have been formally appointed using a lasting power of attorney (LPA) to look after someone else’s money and property
• the user may be a parent acting on behalf of a child where the child is not old enough to access a service themselves, or
• the user might be appointed to act on behalf of a business. To do this they need to be able to: assert proof of their identity; have this linked to the business that they are representing; and have attributes that show that the business exists.

A user will only have delegated authority if they have been given permission to make decisions and complete tasks on behalf of the other person. A user may have delegated authority on a one-time basis, related to one specific task or service, or something more comprehensive. A user does not necessarily have delegated authority if they’re helping someone do something. This could include:

• a user helping a friend who’s not confident using a computer to fill in an online form
• anyone who offers ‘assisted digital support’ to users of a product or service

Where delegated authority is used, you must check if the user has authority to act on someone’s behalf. The details of their agreement with the other person might exist as an attribute.

If your service permits delegated authority of any type, you must follow this guidance.

16.3 Respond to complaints and disputes

You must have a process for dealing with complaints and disputes. Disputes could involve your users or other trust framework participants. Due to the link to the development of the governance framework, further rules for this process will be developed once the government has concluded the consultation.

16.4 Staff and resources

Your organisation must have a way to:

• make sure your staff (including contractors) have the right experience, training (such as data protection training), and qualifications needed to do their job
• do background checks on your staff
• make sure any personal, cryptographic or sensitive information you keep can only be accessed by authorised staff

You can help to demonstrate you have met these rules by:

• following the ‘applicable skills and security awareness’ control of ISO/IEC 27001:2017, or equivalent industry standards such as the National Cyber Security Centre (NCSC) Cyber Assessment Framework (CAF), and National Institute of Standards and Technology (NIST) Cybersecurity Framework
• following BS 7858:2019 on screening individuals

16.5 Encryption

You must follow industry standards and best practice for encryption and cryptographic techniques. The standards and best practice will vary depending on the maturity of the technical approach. These could be the following standards such as:

• NIST FIPS 140-3 - Security Requirements for Cryptographic Modules
• NIST SP 800-175B - Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms
• NIST SP 800-67 - Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
• ETSI TS 103 458 - Application of Attribute Based Encryption (ABE) for PII and personal data protection on Internet of Things (IoT) devices, WLAN, cloud and mobile services

Additional guidance can be found in the following family of standards:

• ISO/IEC 18033-1:2015 - Information technology - Security techniques - Encryption algorithms - Part 1: General
• ISO/IEC 18033-2:2006 - Information technology - Security techniques - Encryption algorithms - Part 2: Asymmetric ciphers
• ISO/IEC 18033-3:2010 - Information technology - Security techniques - Encryption algorithms - Part 3: Block ciphers
• ISO/IEC 18033-4:2011 - Information technology - Security techniques - Encryption algorithms - Part 4: Stream ciphers
• ISO/IEC 18033-5:2015 - Information technology - Security techniques - Encryption algorithms - Part 5: Identity-based ciphers

ISO/IEC 18033-2 and ISO/IEC 18033-5 are devoted to two different classes of asymmetric ciphers, known as conventional asymmetric ciphers (or just asymmetric ciphers), and identity-based ciphers. ISO/IEC 18033-3 and ISO/IEC 18033-4 are devoted to two different classes of symmetric ciphers, known as block ciphers and stream ciphers.

You should also follow current Digital Signature Standards (DSS), such as either:

• NIST FIPS 186-5 - Digital Signature Standard (DSS)
• ETSI TS 119 312 - Electronic Signatures and Infrastructures (ESI); Cryptographic Suites

For guidance on hash functions, you can read the following NIST standards:

• NIST FIPS 180-4 - Secure Hash Standard (SHS)
• NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
• NIST SP 800-107 - Recommendation for Applications Using Approved Hash Algorithms

You should also follow NCSC guidance on:

• using IPsec to protect data, and
• using TLS to protect data.

You must also have an encryption and cryptographic controls policy document.

16.6 Quality management

You must have a quality management system (QMS) that follows a recognised industry standard, such as ISO 9001:2015. A QMS is a collection of documents that describe your organisation’s objectives and explain how it will achieve them. These objectives could be about:

your processes, for example you might aim to investigate and fix all faults within 2 hours your staff, for example you might want to make sure every member of staff completes 5 hours of security training every month

Your QMS should include information such as:

• who in your organisation is responsible for meeting the objectives
• what standards you will follow
• how you’ll measure how well you’ve met your objectives
• what tools, funding, people and other resources you need
• how you’ll plan to improve the quality of your products or services on an ongoing basis (known as ‘continuous improvement’)

16.7 Information management

An information management system is a collection of documents that will need to explain:

• why your organisation needs to keep the information it keeps, covering both personal and non-personal data
• how you create, organise and store information
• who has access to the information
• how you share information (including why it’s shared, who it’s shared with, how often it’s shared, what format it’s in and how it’s protected)
• how you archive information

Your organisation must have an information management system that follows an industry standard, such as ISO/IEC 27001:2017. If you don’t follow this particular standard, you must still ensure your information management system meets the criteria detailed in this section.

Archiving information

Your organisation must have have an archiving policy that:

• follows any legislation or regulations that your organisation needs to follow
• meets any rules that an auditor has decided your organisation needs to meet
• follows any standards or best practice relevant to the industry or sector your organisation is part of

It must also explain:

• how archived information is used to support your organisation’s work
• why your organisation needs continued access to archived information
• what are the risks of not having access to archived information
• how archiving information protects the interests and legal rights of your organisation and others you work with
• the relationship between this information and any other records, data or evidence you keep

Disposal schedule

You must have a disposal schedule that records how you manage and delete information. It should show:

• that your organisation meets any legislation or regulations about keeping and deleting information
• what information was created but later deleted
• what format the information is in (for example if it was physical or digital)
• where information is located
• how information is transferred for disposal, if this is relevant

Data management

You must have a data management policy that explains how you create, obtain, transform, share, protect, document and preserve data. It should include:

• file naming conventions
• how you create metadata
• how your organisation makes sure data is available when it’s needed
• how you know data is accurate and complete
• how you maintain and secure your data

Your data management policy must cover the full data lifecycle. It should explain how architectures, policies, practices and procedures are implemented and maintained.

16.8 Information security

Information security incorporates cyber security as well as broader security considerations. Your organisation must have an information security management system that follows an industry standard, such as ISO/IEC 27001:2017. If you don’t follow this particular standard, you must still ensure your information management system meets the criteria detailed in this section.

It must be based on the principles of:

• confidentiality
• integrity
• availability

You’ll also need a number of security documents to support your information security policy. These include:

• technical controls
• organisational controls
• physical security controls

Confidentiality

You must make sure any information your organisation keeps can only be accessed by authorised users. For example, you could make it so users need an authenticator (such as a password) to access the information.

You could also use an access-control list or role-based access control to protect your organisation’s information. These must specify:

• which users or systems can access your information
• how they are granted access
• what they can do with your information

This should be explained in your organisation’s password control policy or access control policy.

Integrity

You must be able to show that you’ve done everything you can to maintain the integrity of any information your organisation holds. You might need to prove this for legal reasons, for example if you suffer a breach. Your organisation must have an information security policy that explains how you’ll:

• stop information from being modified, either by accident or on purpose (including how you’ll protect it against malicious acts)
• keep information in its ‘correct state’ - the format or reason for collecting the information should not change
• restore information to its correct state if you suspect it’s been tampered with

Availability

You must make sure that any information your organisation keeps is available to those that need it.

You will need:

• tools and processes that can cope with the amount of requests you expect to get
• a backup policy, in case you need to recover any information

You should explain how these work in your:

• data support and operations plan
• policy and business/organisation continuity plan
• disaster recovery plan
• information security policy

Technical and security controls

You must have a document that explains what hardware and software your organisation uses to protect information, such as firewalls, intrusion detection systems and encryption techniques. It must also explain what software you use to monitor and control access to information.

You should follow NCSC guidance on Secure Design Principles and the NCSC Cyber Assessment Framework (CAF).

Organisational controls

You must have a document that explains how your organisation will continue to meet security rules. For example, it could explain what information security training your staff will regularly have to complete. It should also explain what roles are in your organisation and what parts of the information security process they’re responsible for.

Physical security controls

You must have a document that explains what security controls protect the physical locations where the following things are kept:

• any information your organisation has
• any technology that helps you provide your products or services

It could include how you:

• assessed the risks of hosting information in different locations
• secure any data centres or locations you use that are operated by third parties
• protect information and technology when they are accessed from a remote location (i.e. outside of the usual place of work)

Security governance

You must make sure your information security policy is followed at all times and that you have a way for managing security risks. This is also known as ‘security governance’.

You must:

• make a security plan based on security risks you’ve identified
• have a process for investigating and responding to security risks
• report security risks in a way that’s proportionate to your organisation and product or service, and
• have a robust assurance and review process.

Use security measures to protect the information you collect

You must use technical and organisational safeguards to protect personal data. Your security measures must guarantee the confidentiality and integrity of information. This means they need to reliably protect information from:

• loss or misuse
• unauthorised use, access, modification or disclosure
• fraud

To do this, you must make sure that you:

• use safeguards (for example, pseudonymisation, anonymisation and encryption) that are robust
• use security measures that guarantee confidentiality, integrity and availability
• test your security measures regularly, using the same tests each time, and improve them whenever you can
• can quickly restore access to personal data if there’s a physical or technical incident, and
• know how you’ll tell people if there’s a security breach, so they can protect themselves from potential identity theft.

You must also show how you meet these rules in your ongoing internal audits.

16.9 Risk management

Your organisation must have a risk management framework that follows industry standards, such as:

• ISO/IEC 27005:2018
• ISO 31000:2018

If the standard you follow is not one of the above, your risk management framework must still include guidance about how to:

• identify risks to your organisation, including where they can come from and the impact they could have
• identify risks to your users, such as phishing attacks
• find out how likely it is that risks could happen
• measure how effective your current processes are at managing risks
• compare any risks you’ve identified to the established risk criteria
• monitor risks
• report risks to your stakeholders
• measure residual risk
• write, implement and maintain your organisation’s risk strategy, and
• protect your organisation from internal risks, including writing a bribery and corruption policy.

NCSC guidance on cyber security-related risk management can support you in the development of your risk management framework.

You should set out and communicate the risks your organisation will and will not take in pursuance of its business goals. This is often referred to as a statement of risk appetite and it will help those who are responsible for making risk management decisions understand where the risk management boundaries lie.

16.10 Fraud management

Anyone that’s part of the trust framework must follow best practice guidance on fraud management. For example, this could be:

• guidance from the Chartered Institute of Public Finance and Accountancy (CIPFA)
• Government Functional Standard GovS 013: Counter fraud
• Government Internal Audit Agency's standards
• guidance from the Association of Certified Fraud Examiners (ACFE)

As well as best practice, you must meet the following rules.

Fraud monitoring

You must have a process in place to regularly monitor threats and fraud to your service. This includes for example account misuse, account takeover, harvesting data, identity and document fraud and coercion. This must be assessed during internal audits, fraud audits and exceptional audits conducted by an independent internal auditor or a third party.

You must also have a process to identify, notify and support a user whose identity, attribute or account has been compromised.

Legal, policies and procedures for fraud management

You must make sure you have all relevant legal, policy and procedures for the sectors you work in or with including:

• thresholds for investigating
• data sharing agreements
• fraud dispute and resolution process, and
• interacting with individuals you believe or suspect have committed fraud.

You must also have a clear understanding of legislative mechanisms for sharing fraud data. What these are will depend on which industry or sector you’re working in.

Fraud reporting

You must:

• define a set of contra-indicators to make sure reporting and analysis is consistent
• have a standardised, structured, clear reporting process for all connected services, organisations, users, regulators and agencies
• have minimum operational rules for monitoring fraud and threat alerts
• send regular reporting and analysis to the relevant authorities to help manage the threat of identity fraud and identity misuse
• keep a log of any revoked or suspended accounts (if applicable)
• keep a log of any breaches, and
• advise when an external source has been breached.

Intelligence and fraud analysis

You must have a way to:

• look for suspicious activity
• monitor transactions, and
• carry out threat intelligence.

Sharing threat indicators (‘shared signals’)

You must:

• have a structured ‘shared signals’ framework that you can use to send and receive relevant identity data and intelligence
• notify all relevant parties, including the victim, if there’s a fraud incident
• sign up to an agreed shared signals approach for threat and fraud intelligence across the trust framework
• have a process for sharing information around detected and mitigated fraud threats, and
• have a process for reporting communication cyber security and fraud incidents.

If fraud or crime is suspected (both during initial interaction with the user and on an ongoing basis) that meets the approved threshold for your industry or sector, you must save the relevant metadata and artefacts (allowing for data protection and legal considerations) for investigation.

16.11 Respond to incidents

You must have a process for dealing with incidents that could have an impact on your product, service or users. These incidents might be related to:

• fraud, for example if a user’s identity is being used by someone else to sign in to your service
• service delivery, for example if users cannot use your product or service because it’s temporarily unavailable
• a data breach

Your process must follow industry best practice, such as the NCSC guidance on incident management, in addition to any legislative requirements.

You should follow the NCSC’s best practice on logging monitoring.

You must have a process in place to manage requests from law enforcement agencies, the governing body or another organisation in the trust framework if they’re investigating an incident.

Respond to a fraud incident

You must follow industry best practice and established guidance if you suspect that fraudulent activity has taken place, for example if a user is:

• using a ‘synthetic’ (made up) identity
• pretending to be someone they’re not, alive or deceased

You must have an incident response plan that:

• makes sure effective and timely action is taken if fraud happens
• explains who in your organisation will be involved in responding to the incident
• minimises losses
• collects the evidence for future investigations
• notifies the relevant organisations if an attribute is found to be fraudulent, and
• covers any necessary communication security rules.

Respond to a service delivery incident

You must have a process for managing and responding to service delivery incidents. This process must follow industry good practice, such as the Information Technology Infrastructure Library (ITIL) service management processes. Your process should cover how you will:

• log, categorise, prioritise and assign incidents
• create and manage tasks
• manage and escalate service level agreements (SLAs), and
• resolve and close incidents.

Responding to data breaches

You must follow data protection legislation on data breaches, as explained in the Information Commissioner Office’s (ICO’s) guidance on how to respond to data breaches.

Data breaches can lead to:

• identity theft
• threats to a user’s safety or privacy
• emotional or financial damage to a user

If a data breach happens, you must tell any users whose personal data might have been affected. You must contact them using a method that’s appropriate for your users, product or service. You must also inform the governing body and any relevant scheme owners.

Taking part in an investigation

You might be asked to provide specific information as part of an investigation into an incident. Who’s carrying out the investigation will depend on the industry or sector where the incident happened.

You will get some information about the user or transaction and will be asked to provide identifiers that match it. You might also be asked to provide any of the following information, if you have it:

• a user’s name, date of birth, address or gender
• the IP address, phone number or email address a user was using during a specific time period
• the ‘device fingerprint’ and geolocation of the device a user was using during a specific time period
• the calling line identifier (CLI) a user was using during a specific time period
• the reference numbers assigned to the user’s account
• unique references that identify the request you received
• contra-indicators and failure codes
• unique identifiers related to a piece of evidence (for example a passport number)

To make sure you are following the Data Protection Act 2018 and the UK GDPR (which make up the ‘data protection legislation’) you must check that whoever’s asking you for the information has a lawful basis for processing this data.

16.12 Tell users about your product or service

You must make sure your users know exactly what your product or service does. You must clearly explain:

• any terms and conditions of use that the user needs to be aware of
• any fees that the user will need to pay to use your product or service, and
• how your organisation makes money from your identity or attribute service (‘business monetisation statement’), where relevant.

16.13 Privacy and data protection rules

Personal data is information that relates to an identifiable living person. You must follow data protection legislation whenever you do anything with users' personal data. The Information Commissioner's Office (ICO) has a guide to Data Protection that explains what requirements you must meet.

Due to the importance of personal data to digital identity and/or attribute services, as part of the trust framework certification process you will be audited to ensure you meet the following legislative requirements or related best practice. This list is not exhaustive of all data protection legislative requirements and instead highlights areas which are particularly important for trust framework services:

• You have appointed a data protection officer to carry out the tasks defined in article 39 of the UK GDPR. This could be in addition to legislative requirements if you do not meet the circumstances outlined in article 37 of the UK GDPR.
• You have completed a Data Protection Impact Assessment (DPIA), also known as a 'privacy impact assessment', for your digital identity and/or attribute service(s). This must include justification for your lawful basis for processing and detail all forms of personal data which may be created as a result of your service e.g. analytics data.
• You have processes in place to maximise 'data minimisation', particularly when sharing data with other organisations, within the parameters of your particular service or use case.
• You have a clear process to manage requests related to 'right of access', 'right to rectification' and 'right to data portability'. To note these rights have been highlighted for auditing but you must have a clear process for all of the data protection rights.
• You have given consideration to how your service safely accommodates and protects children. Where relevant this will involve conforming to the Age Appropriate Design Code.
• Where automated decision-making is part of your service, you have met the requirements in the ICO guidance.
• Where your service processes biometric or other special category data, ICO guidance is followed.

Privacy compliance framework

To help demonstrate you have met privacy best practice, you must use a 'privacy compliance framework' (sometimes known as a privacy information management system, or PIMS). You must be able to show that your privacy compliance framework follows an industry standard such as:

• BS 10012:2017 from the BSI (British Standards Institution)
• ISO/IEC 27701:2019 from the ISO (International Organization for Standardization)

Getting your users’ agreement

Whichever lawful basis you are using to process personal data, you must get customers to provide positive confirmation that they have understood how their personal data will be stored and in what conditions their digital identities or attributes will be shared or disclosed. You can ask for customers’ positive confirmation in any way, as long as you’re able to show that you’ve done it.

If you make substantive changes to the way your product or service handles users’ data, you must ask the user to renew their agreement. You must have a way for the user to renew their agreement if:

• you make any changes to how your product or service handles users’ data
• your product or service starts offering something different to what users might expect

Prohibited processing of personal data

Under the trust framework, you must not collect and process personal data to:

• ‘profile’ users of any age for marketing purposes
• create aggregate data sets could reveal sensitive information about users
• process digital identities or attributes without the user’s agreement

16.14 Keep records

You must record what you did to create, manage, share or consume a digital identity or attribute. How you do this will depend on which legislation is relevant to the industry or sector your organisation is part of. You must, however, do this in a way that meets the requirements in article 30 of the UK GDPR.

You must keep your own copies of any records. You must dispose of these records when you no longer have any use for them.

If an identity or attribute service provider is sharing information with a relying party, they might need to make sure the relying party gets a copy of any records about that digital identity or attribute.

Before you start keeping records, you must have:

• clear rules for keeping, managing and disposing of them
• a records management policy and a disposal statement, and
• a named person in your organisation who oversees records management.

You must have rules that cover your day-to-day records management. For example:

• which records to keep
• who should keep them
• how to keep them, covering the formats and media you use
• when to dispose of records - this is usually covered in a disposal statement

The rules for your organisation can be as detailed as you need them to be. These rules can be a part of your records management policy or maintained separately.

Records management policy

You must have a regularly updated and internally published records management policy. The policy must include:

• a commitment to managing records, including what’s covered and why
• the policy’s objectives (for example, to help you meet standards or legal rules)
• how the records management policy relates to your organisation’s other policies, such as data security or fraud policies
• the job roles in your organisation and what their management responsibilities are, and
• specific plans for records that are particularly important or sensitive.

It must be easy for anyone in your organisation to find and use the policy. This will help everyone understand why it’s important to follow the management rules and keep records correctly.

The records management policy must have been agreed at a senior level. It will usually be part of your wider information management strategy. You must choose a named person to check it’s being followed and regularly review it.

Your other responsibilities

You must also:

• have guidance on common issues that the rules do not cover, such as naming conventions
• know how (and how often) you’re going to check that your records are being managed according to your policy, and
• make sure that access to records is controlled and monitored.

Disposing of records

Your organisation must have clear rules on how long to keep records which meet requirements in data protection legislation. When it’s time to stop keeping them, you must dispose of them in an appropriate way. Before you decide whether to keep or dispose of a record, you must consider if you need it for:

• legal reasons
• performance analysis
• fraud analysis
• audits or other investigations

You might need to keep just part of the record. For example, a medical research organisation might need a record of someone’s symptoms and what treatment they had. They can keep this and dispose of any other information that was part of the record.

Disposal statement

Your organisation must have a formal written disposal statement. It must include the types of record you handle and:

• how long you keep each type
• how you dispose of each type, and
• your processes for archiving and destroying records.

What people in your organisation need to do

Anyone who handles records must follow the records management policy. This includes temporary staff and contractors. Everyone who works for your organisation must know:

• which information needs to be added to the record-keeping system
• what your records management policy is
• what they must do to follow data protection legislation and (if your organisation is a public authority) the Freedom of Information Act

Accountability for records management

You must choose a named person with accountability for overseeing your records management. They will be ultimately responsible for making sure your records are accurate, accessible and secure. They will need to:

• check your records are being managed according to the records management policy and disposal statement
• make sure you meet your legal and regulatory requirements
• set up or maintain your record-keeping systems
• identify important or sensitive records that need specific management plans
• set up a way to document who has accessed, added or changed a record, and
• act as a single point of contact for records management issues.

16.15 Prohibited conduct

When doing anything related to the trust framework, you (including any third party using services from the framework) must not do anything that’s illegal in the UK. This could include:

• selling illegal goods, substances or services
• promoting acts of violence or terror
• bribery
• fraud
• conspiracy
• copyright infringement
• breaching data protection legislation
• breaching financial regulations
• breaking the law in any other way

You must not:

• be misleading or deceptive
• contradict the terms of use
• target, with the intention to exploit, users who are suffering from physical, emotional or financial distress (for example promoting services like unaffordable loans to users that are in financial trouble)
• damage the reputation, image, goodwill or trustworthiness of the trust framework or the trust mark

---

In addition to this trust framework, please also read the document on certification.

---

17. Table of standards, guidance and legislation

This is a table of all standards, guidance and legislation referred to in the trust framework for ease of reference. Not all will be applicable to every trust framework participant and we recommend you read the relevant rules for your organisation in full.

STANDARD/GUIDANCE/LEGISLATION

---

Rules for identity service providers

Government guidance on how to prove and verify someone's identity

---

Rules for attribute service providers

Government guidance on understanding attributes

Government guidance on how to create attributes

Government guidance on how to score attributes

---

Rules for all identity and attribute service providers

Government guidance on using authenticators to protect an online service

ICO guidance onqualified trust service providers (QTSP)

---

Make sure your products and services are inclusive

Equality Act 2010

Government guidance on how to accept a vouch as evidence of someone’s identity

ISO/IEC TR 29194:2015 - Information Technology — Biometrics — Guide on designing accessible and inclusive biometric systems

---

Make sure your attribute products and services are accessible

Government guidance on understanding the accessibility regulations

Welsh Language Act 1993

W3C Web Content Accessibility Guidelines

EN 301 549 V3.2.1 (2021-03) - ETSI standard for accessibility requirements

EN 301 549 V1.1.2 (2015-04) - Accessibility requirements suitable for public procurement of ICT products and services in Europe

BS 8878:2010- Web accessibility Code of practice

---

Making your products and services interoperable with others

OpenID Connect

W3C Verifiable Credentials

---

Staff and resources

ISO/IEC 27001:2017

NCSCs Cyber Assessment Framework (CAF)

NIST Cybersecurity Framework

BS 7858:2019 - Screening of individuals working in a secure environment. Code of practice

---

Cryptography and encryption

FIPS 140-3 - Security Requirements for Cryptographic Modules

SP 800-175B - Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms

SP 800-67 - Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher

ISO/IEC 18033-1:2015 - Information technology — Security techniques — Encryption algorithms — Part 1: General

ISO/IEC 18033-2:2006 - Information technology — Security techniques — Encryption algorithms — Part 2: Asymmetric ciphers

ISO/IEC 18033-3:2010 - Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers

ISO/IEC 18033-4:2011 - Information technology — Security techniques — Encryption algorithms — Part 4: Stream ciphers

ISO/IEC 18033-5:2015 - Information technology — Security techniques — Encryption algorithms — Part 5: Identity-based ciphers

FIPS 186-5 - Digital Signature Standard (DSS)

ETSI TS 119 312 - Electronic Signatures and Infrastructures (ESI); Cryptographic Suites

FIPS 180-4 - Secure Hash Standard (SHS)

FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions

NIST SP 800-107 - Recommendation for Applications Using Approved Hash Algorithms

NCSC guidance onusing IPsec to protect data

NCSC guidance on using TLS to protect data

---

Quality Management

ISO 9001:2015 - Quality management systems — Requirements

---

Information Security Management

ISO/IEC 27001:2013 - Information technology — Security techniques — Information security management systems — Requirements

BS 7858:2019- Screening of individuals working in a secure environment. Code of practice

Information Technology Infrastructure Library (ITIL)

---

Technical and cyber security controls

NCSC guidance on Secure Design Principles

NCSC Cyber Assessment Framework (CAF)

---

Risk Management

ISO/IEC 27005:2018 - Information technology — Security techniques — Information security risk management

ISO 31000:2018 - Risk management

NCSC guidance on phishing attacks

NCSC guidance on cyber security-related risk management

---

Fraud management

Chartered Institute of Public Finance and Accountancy (CIPFA)

Government Functional Standard GovS 013: Counter fraud

Government Internal Audit Agency's standards

Association of Certified Fraud Examiners (ACFE)

---

Incident management

National Cyber Security Centre (NCSC) guidance on incident management

NCSC's best practice onlogging monitoring

Information Technology Infrastructure Library (ITIL)

ICO guidance on how to respond to data breaches

---

Privacy and data protection requirements

Data Protection Act 2018

UK GDPR

BS 10012:2017 - Data protection. Specification for a personal information management system

ISO/IEC 27701:2019 - Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines

18. Glossary of terms and definitions

Term	Definition
Accreditation	The independent, third-party evaluation of a conformity assessment body against recognised standards, conveying formal demonstration of its impartiality and competence to carry out specific conformity assessment tasks.
Audit	The independent verification activity, such as inspection or examination, of a product, process or service, to ensure compliance to requirements.
Attributes	Pieces of information that describe something about a person or an organisation.
Attribute service providers	Individuals or organisations that collect, create, check or share attributes.
Authenticator	Something that users can use to access a service. It could be some information (like a password), a piece of software or a device.
Calling line identifier (CLI)	Something that lets whoever's receiving a phone call see the caller's number.
Certification	Represents a written assurance by an independent third party, accredited by UKAS, of the conformity of a product, process or service to specified requirements.
Communications Security	A way of preventing unauthorised people from accessing telecommunications or written information that's transmitted or transferred.
Contra-indicators	A way of categorising any wrong or contradictory information that you might get from, or about, users.
Cryptographic	A way to guarantee the integrity and confidentiality of data transmitted over a public network. This is done by a combination of encryption and signing.
Data minimisation	Data minimisation means collecting the minimum amount of personal data needed to deliver an individual element of a service.
Delegated authority	When a user is authorised to act on behalf of someone else.
Digital identity	A digital representation of who a user is. It lets them prove who they are during interactions and transactions. They can use it online or in person.
Digital signatures	A type of electronic signature that's used to validate the authenticity and integrity of a message, like an email, credit card transaction or a digital document.
Digital wallet	An electronic device, online service or software program that allows one party to make electronic transactions with another party for goods and services.
Encryption	Encryption is a mathematical function that encodes data in such a way that only authorised users can access it.
Firewall	A network security system that monitors and controls incoming and outgoing network traffic.
Hash function	When data is converted into a fixed-length value. A hash cannot be reversed to reveal the original data.
Identifier	A piece of information that can be used to make a connection between an attribute and a person or organisation.
Identity service providers	Identity service providers prove and verify users' identities. They might not need to do all parts of the identity checking process. They can specialise in designing and building components that can be used during a specific part of the process.
Internet Protocol (IP) address	A numerical label assigned to any device connected to a computer network that uses Internet Protocol.
Intrusion detection system	Software that automatically looks for possible incidents during events in a computer system or network.
Metadata	Data that provides information about other data.
Orchestration service providers	Orchestration service providers make sure data can be securely shared between participants in the trust framework through the provision of their technology infrastructure.
Personal data store	Service which lets an individual store, manage and deploy their key personal data in a highly secure and structured way.
Phishing	When criminals attempt to trick users into submitting personal information by asking them to click on links within for example scam emails or text messages.
Pseudonymisation	A security technique that replaces or removes information in a data set that identifies an individual. It does not change the status of the data as personal data (ICO Guidance).
Public Key Infrastructure (PKI)	A way to implement secure electronic transactions over insecure networks, such as the internet. It's used to authenticate identities for the purposes of data encryption and signing.
Qualified trust service	A service offered by a qualified trust service provider that meets the rules in the UK electronic identification and trust services (eIDAS) regulation.
Relying party	Organisations that rely on (or 'consume') products or services from trust framework participants.
Scheme	A group of different organisations who agree to follow a specific set of rules around the use of digital identities and/or attributes.
Scheme owner	An organisation that creates, runs and sets the rules of a scheme.
Shared signals	When intelligence is shared across the trust framework to reduce the impact of fraud on its participants and users.
Trust framework	A set of rules and specifications that organisations agree to follow in order to achieve a common purpose.
Unique identifier	Unique data used to represent someone's identity and associated attributes.
User	People who use digital identity and attribute products and services to prove their identity or eligibility to do something.
User agreement	Something that confirms users have understood how their personal data will be stored and how their digital identities or attributes will be shared.
Zero knowledge proof	A mathematical method by which one party can prove to another party that they know the same thing, without conveying any information apart from the fact that they know it.