Guidance

How to create, bind and share attributes (1. 0) pre-release

Published 3 March 2026

0. Version and certification validity notes

0.a. This 1.0 publication of ‘How to create, bind and share attributes’ (‘the attributes guidance’) is valid from [date of final publication] to coincide with the date the 1.0 publication of the UK digital verification services trust framework (‘trust framework’) comes into force.

0.b. Services demonstrating compliance with the attributes guidance as part of certification against the 1.0 trust framework must comply with this version of the attributes guidance. You should refer to the version and certification validity notes in the trust framework to understand which version(s) of the trust framework you can undergo certification against.

0.c. This is the first version-controlled publication of the attributes guidance. The most recent non-numbered version of the attributes guidance was comprised of three different publications (titled ‘Understanding attributes’, ‘How to create and share attributes’ and ‘How to score attributes’) which can be found on GOV.UK. Those three publications are collectively, from the date of this publication, to be considered as the 0.4 version of the attributes guidance.

1. Introduction

1.a. An attribute is a piece of information that describes something about a person or an organisation. For example, it could be a person’s age, or an organisation’s VAT number. In the context of this guidance and the trust framework, attributes are about individuals only, though they may concern an individual’s relationship to an organisation.

1.b. Knowing how to create, bind, score and share attributes is vital for attribute service providers (ASPs) certified against the trust framework. It will also be important for other service providers and relying parties who want to work with ASPs, as it will help them determine whether to trust attributes created, bound and scored by those ASPs.

1.c. We use ‘you’ and ‘your service’ throughout to direct ASPs to the specific rules they must follow, and the recommendations they can follow, to be certified against the trust framework as an ASP.

1.d. Understanding attributes is also important if you want to handle attributes, either as a service certified against another trust framework role or as an organisation working with a certified service. These could include holder service providers, orchestration service providers and some kinds of component service providers.

1.e. The guidance is written for ASPs certified against the trust framework. Whilst it has been produced for this purpose, others may consider that its contents are instructive in a wider attribute checking context.

1.f. This guidance is maintained by the Office for Digital Identities and Attributes (OfDIA), which sits within the Department for Science, Innovation and Technology (DSIT) and is produced as an exercise of DSIT’s functions. If other government departments want to apply the guidance when exercising their functions, they should ensure it does not cut across any applicable legislation or statutory guidance that may be relevant.

1.1. Why is checking attributes important?

1.1.a. Being able to trust attributes is key to helping build and maintain trust in digital information and interactions, ensuring they are authentic and reliable. Being sure the attributes associated with a person have been checked gives us confidence when making use of these attributes. For example, it can give us confidence that the academic qualifications of a job applicant are genuine.

1.1.b. This document will take you through the process of:

• creating attributes;
• using or creating attributes that uniquely identify a particular person (e.g. a customer reference number), known as ‘identifiers’;
• establishing the link between an attribute and the identity or authenticator it belongs to, a process known as ‘binding’;
• assessing the quality of an attribute; and
• making sure the person claiming an attribute is the person to whom it was bound, a process known as ‘matching’.

1.1.c. This document describes a scoring methodology to assess the quality of an attribute. This takes a similar approach to the methodology described in the ‘How to check someone’s identity’ guidance (also known as ‘GPG 45’), breaking assessment of an attribute’s quality down into four different metrics:

• accuracy – how sure you are of the accuracy of the attribute, for example checking with an authoritative source;
• integrity – how sure you are of the integrity of the attribute, for example if it has been stored and shared securely;
• binding – how sure you are the attribute belongs to the identity of the person in question; and
• matching – how sure you are that the person who is claiming the attribute is the person to whom the attribute belongs.

Example

John has applied for a job, and the HR office at the organisation he’s applied to join wants to check that he holds the qualifications he claims.

They need to know how sure they can be that the qualifications have been awarded, for example, by checking with John’s university. This is an ‘accuracy’ check.

They also need to know how sure they can be that the university’s record of his qualification hasn’t been tampered with, for example, by being changed on an insecure system which someone, including John himself, could log onto. This is an ‘integrity’ check.

They finally need to know how sure they can be that the qualifications relate to John. They need to know two things to establish this: that the attribute relates to the identity that John is claiming – ‘binding’ the attribute – and that John is the person he is claiming to be – ‘matching’ John with the person to whom the attribute relates.

Once the HR office knows all four things, they know how confident they can be in John’s claimed qualifications.

2. Create an attribute

2.a. Exactly how you create attributes will depend on what you are trying to do or what your organisation does. For example, a new attribute might be created for a user if you:

• confirm that they are over 18 years old;
• are informed they started a new job;
• open a bank account for them; or
• confirm they opened a new email account.

2.1 Create an identifier

2.1.a.  An identifier is a type of attribute used by an organisation to:

• uniquely identify a person by linking to something that can only relate to them, e.g. biometric information such as their face or fingerprint; or
• identify a person by creating a new attribute, e.g. a unique identifier when registering a new user in the organisation’s database.

2.1.b. You can create a new identifier if you would like to. For example, a university might give a unique reference number to every new student that uniquely identifies them in the university’s academic records.

2.1.c. There are no restrictions on the identifiers you create. Other organisations will be less likely to trust them if you do not produce them in a reliable way. An identifier may be less reliable if it is possible for you to accidentally issue the same one more than once, for example by linking the same registration number to two individuals in your dataset.

2.2 Use existing information as an identifier

2.2.a. You can use various types of existing information as identifiers. This includes information that you ask for during the binding process or already have from authentication.

2.2.b. You can use information about the person as an identifier.

Example

Gurinder wants to change her mobile phone provider and get a new number. She decides to get a mobile phone contract with the company that provides her broadband at home.

When the company creates a new mobile number, they can bind it to Gurinder using her existing customer number as an identifier.

2.2.c. You can also use someone’s physical appearance as an identifier. This means they physically match a photo you hold or a photo from a piece of evidence that you trust.

2.2.d. If you and the person both have access to appropriate technology, you can use someone’s biometric information as an identifier.

2.3. Using existing attributes to create new attributes

2.3.a. Creating a new attribute can involve other attributes that already exist. Some of these might come from other attribute service providers or certified DVS providers.

Example

A credit reference agency gives people credit ratings based on their financial history. Each credit rating is an attribute that the agency creates.

When Joshua asks for his credit rating, the agency starts by collecting attributes from other attribute providers, like Joshua’s bank and credit card provider. The attributes they collect include things like Joshua’s overdraft limit.

The agency then combines all the information that it collects about Joshua and uses it to work out his credit rating.

2.3.b. Attributes can be combined or used alone. Where attributes are combined, this may include attributes from a UK government source, or registered, certified or uncertified services.

2.4. Storing attributes

2.4.a. You must record what your service did to create, manage, share or consume an attribute in line with trust framework rules on keeping records.

3. Bind an attribute

3.a.  The process of linking a person to an attribute is known as “binding”. If you then share the attribute, the recipient will be able to know who the attribute relates to. 

Example

When an employee starts a new job they are given a unique employee number, which is an identifier. This can be used to link the employee to another attribute, such as their job title.

The HR department uses the identifier to link the employee’s other attributes to the employee, such as their salary and how many hours they work a week.

For example, one office has two 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 the HR representative know which Daniel Jones they are talking to.

3.1. How to bind an attribute

3.1.a. To bind an attribute, you must have a process to record the link between the attribute and the identifier. Exactly how you record the attribute and identifier will depend on the system you use.

3.1.b. You must bind an attribute before you share it.This can be done when the attribute is created or later, as long as you bind it before you share it. 

3.1.c. You could use the trust framework data schema to support you to record the attribute and identifier in an interoperable manner.

3.2. Who to bind to

3.2.a. When you bind an attribute, you connect it with:

• the person that it relates to;
• someone that is acting on their behalf; or
• someone that is acting in their interest.

3.2.b. These will usually be the same individual, but not always. For example, someone might:

• have to show their parents’ income when they apply for a student loan;
• book a train ticket for a friend who does not have a computer;
• file a tax return on behalf of a client;
• use a subcontractor to help them with some work; or
• be representing someone else.

3.2.c. When you bind an attribute to a person, you must check their identity or use an authentication process.

3.2.d. Whether you bind an attribute to a person whose identity you have checked or use an authentication process will impact how confident you can be that the attribute is related to that person.

3.2.e. If you check the person’s identity, you must use GPG 45 as a methodology to explain your checks.

3.2.f. You can use an authenticator according to GPG 44 instead of having to check the person’s identity if:

• you have already proved their identity; or
• the person has a digital identity you can accept.

3.2.g.  As explained in GPG 45, checking the person’s identity will give you one of the following levels of confidence in the identity:

• low confidence;
• medium confidence;
• high confidence; or
• very high confidence.

3.2.h. If you checked the person’s identity, you must record the level of confidence you have in their identity in the attribute’s metadata. If you did not check the claimed identity or cannot meet the requirements of the low confidence profile, you must say you have ‘no confidence’ in the identity.

3.2.i. If you check a person’s authenticator instead of their identity, you must follow GPG 44. You must record the fact that you relied on an authenticator in the attribute’s metadata, as well as the level of confidence of the digital identity you accepted if this information is available to you.

3.3. Binding and matching

3.3.a. After an attribute has been bound, at a later time you can ‘match’ it to the person it is bound to.

Example

A data broker has bound an attribute to Catherine in their database. A relying party has a customer named Catherine. In order to share the attribute, the relying party has to check that the ‘Catherine’ in the data broker database is the same ‘Catherine’ that is the customer of the relying party. This process is called ‘matching’.

3.3.b. To match an existing attribute, you will need to know the identifier that was used in the original binding. Checking the identifier against your records should tell you which person the attribute relates to.

4. Assessing the quality of an attribute

4.1. How to assess the quality of an attribute

4.1.a. You must have a way to assess the quality of attributes you create or store which you use to describe their quality to anyone you share the attributes with. This will make it easier for those you share them with to use them.

4.1.b. To assess the quality of attributes, you must know:

• how reliable the attribute is;
• how well you have bound the attribute; and
• how well you have matched the attribute.

4.1.c. You must record an assessment of the attribute’s quality in the attribute’s metadata.

4.2. Meeting others’ requirements on the quality of attributes

 4.2.a. Before sharing attributes with a relying party or another service, you must agree what requirements you will meet regarding the quality of the attributes you share.

4.2.b. They might also set other requirements for the attributes you share. For example, they could ask you to make sure they were last updated within the past 3 months.

4.3. About scoring

4.3.a. Assessing and describing attributes in a consistent way helps relying parties and other services to understand the quality of an attribute you share.

4.3.b. You could use the scoring methodology described in the rest of this section to assess and describe the quality of the attributes you create or share. If you are scoring the attributes in accordance with the scoring methodology, you must use a separate field for each score and ensure that scores do not replace any other entries in the metadata.

4.3.c. The trust framework, including supporting documents such as this guidance, is based on outcomes, not specific technical approaches. This means that there are several ways to meet its requirements. This means the metadata organisations use could vary in format and content.

4.3.d. Relying parties and other attribute consumers might not know all the standards and technologies that attribute service providers can use. Using a scoring system means that attribute consumers can be confident the attributes they get will meet their needs.

4.4. How scoring works

4.4.a The attribute scoring approach described below has four parts to it. These describe:

• how confident you are that the attribute is accurate, which is known as the ‘accuracy score’;
• an assessment of if the attribute could have been tampered with, which is known as the ‘integrity score’;
• how the attribute is bound to an individual to whom it relates, which is known as the ‘binding score’; and
• how assured you are that the attribute is related to the right person in your database when you share it, which is known as the ‘matching score’.

4.4.b. This scoring methodology assigns one score to an attribute for each of these four parts.

4.4.c. Some attributes will meet the requirements of more than one score for some of these parts. When that happens, choose the highest score that applies.

4.5. The accuracy score: check the accuracy of the attribute

4.5.1. Check the accuracy of the attribute

4.5.1.a. The accuracy score shows how confident you are that an attribute is correct.

4.5.1.b. One way to increase your confidence in an attribute is to check it with an authoritative source (as defined in GPG 45).

4.5.1.c. Before you accept any evidence, you must check if the evidence is genuine or valid, as set out in GPG 45, which is also known as doing a ‘validity check’.

4.5.1.d. The level of validity check you conduct for the attribute, or how well you check the attribute with authoritative sources, will determine the accuracy score you give it.

4.5.1.e.  You cannot give an accuracy score to an attribute that is ‘self-asserted’. This means it was given to you by the person it belongs to and has not been checked with any other source.

Example

A restaurant chain offers people a free dessert on their birthday. To get a voucher for a dessert, you submit a form on their website and tell them when your birthday is. They do not ask for evidence or check the date with any other sources. This attribute would not get an accuracy score.

4.5.2. Accuracy score 1

4.5.2.a. Give the attribute an accuracy score of 1 if you have seen 1 piece of evidence with a validity score of 1.

4.5.2.b. If you have seen 1 or more pieces of evidence but could not validate them to a validity score, you cannot give the attribute an accuracy score.

4.5.3. Accuracy score 2

4.5.3.a. Give the attribute a score of 2 if you have:

• confirmed the attribute with 1 authoritative source;
• seen 1 piece of evidence you have validated to a validity score of 2; or
• seen 2 or more pieces of evidence you have validated to a validity score of 1.

4.5.3.b. You can also give the attribute a score of 2 if it is contact details that you have confirmed yourself.

Example

A dating app sends users an authentication email to the email address they provide during account set up before it allows them to use the account. The email asks users to click on an activation link, which proves that they have access to the email address they provided.

This means people are less likely to create a profile using the wrong email address by accident. It also makes it harder to sign someone else’s email address up for a service they might not want.

4.5.4. Accuracy score 3

4.5.4.a. Give the attribute a score of 3 if you have:

• confirmed it with 2 or more authoritative sources;
• seen 1 or more pieces of evidence you have validated to a validity score of 3; or
• seen 2 or more pieces of evidence you have validated to a validity score of 2.

4.5.5. Accuracy score 4

4.5.5.a. Give the attribute a score of 4 if you either:

• are the authoritative source; or
• have seen 1 or more pieces of evidence you have validated to a validity score of 4.

4.6. The integrity score: check if the attribute could have been tampered with

4.6.a. The integrity score is about how an attribute has been managed and secured. It demonstrates how confident you are that nobody could have made unauthorised changes to the attribute or its metadata since it was created or collected  .

4.6.b. If you have evidence that an attribute has been tampered with at any time, you must stop scoring it and not share it.

4.6.1. Integrity score 1

4.6.1.a. Give the attribute an integrity score of 1 if it has ever been stored or shared in a way that cannot guarantee its integrity. For example, give it a score of 1 if it has ever been:

• sent using an insecure internet connection; or
• kept in an unlocked cupboard or desk drawer.

4.6.2. Integrity score 2

4.6.2.a. Give the attribute an integrity score of 2 if it has always been collected, stored and shared it in a way that protects its integrity.

4.6.2.b. For example, you can give the attribute a score of 2 if it has always been collected, stored and shared in a way that follows the National Cyber Security Centre’s 10 steps to cyber security.

4.6.3. Integrity score 3

4.6.3.a. Give the attribute an integrity score of 3 if it has always been collected, stored and shared in a way that meets recognised standards or frameworks for managing information security risk.

4.6.3.b. For example, an attribute will score a 3 if:

• you meet the relevant information security requirements in the trust framework; or
• you meet ISO/IEC 27001.

4.7. The binding score: how you have bound the attribute 

4.7.a. The binding score shows how well you have bound the attribute. It will depend on:

• what you used as the identifier; and
• how reliably you bound it to the person that it is about.

4.7.b. You can choose if you want to check the claimed identity in line with GPG 45 or use an authenticator in line with GPG 44 as part of the binding process. If you do not do either, you cannot give a binding score of more than 1.

4.7.c. You cannot give a bind score if:

• you have not checked that the attribute relates to the person; or
• you tried to bind the attribute without a unique identifier, even if you used information that is unique in your dataset.

Example

Linking other information about a person to that person’s hair colour would not get a binding score because that is an attribute a lot of other people will also have.

Even if a make-up artist only has one customer with red hair, using ‘red hair’ as the only identifier in their records would not get a bind score.

4.7.d. You can also not give a binding score if the identifier can easily be transferred between people.

Example

Someone who has an access all areas (AAA) pass for a concert can go into any part of the venue, including backstage. AAA passes for some venues come on a lanyard, rather than a sticker or wristband, and they do not include photos. This means that someone who is named on one could give it to someone else.

4.7.e. Not having a binding score means it would be easy for someone to ‘match’ the attribute if they are not bound to it.

4.7.1. Binding score 1

4.7.1.a. Give a binding score of 1 if any of the following are true:

• you used a unique reference number as the identifier;
• you have confirmed that the user can access a service or account that has GPG 44 low protection authenticators which you know belongs to the person you are binding the attribute to;
• you have GPG 45 low confidence in the identity you are binding the attribute to; or
• the attribute is bound to an identity validated to a GPG 45 validity score of 1.

4.7.1.b. A binding score of 1 means it would be reasonably easy for someone to be bound to the attribute even if it does not relate to them.

4.7.2. Binding score 2

4.7.2.a. Give the attribute a binding score of 2 if any of the following are true:

• you have confirmed that the user can access a service or account that has GPG 44 medium protection authenticators which you know belongs to the person you are binding the attribute to;
• you have GPG 45 medium confidence in the identity you are binding the attribute to; or
• the attribute is bound to an identity validated to a GPG 45 validity score of 2

4.7.2.b. A binding score of 2 means you have a medium level of confidence in the binding of the attribute.

4.7.3. Binding score 3

4.7.3.a. Give the attribute a binding score of 3 if any of the following are true:

• you have confirmed that the user can access a service or account that has GPG 44 high protection authenticators which you know belongs to the person you are binding the attribute to;
• the identity you are binding the attribute to was created based on evidence that was validated to a validity score of 3; or
• you have a GPG 45 high confidence in the identity you are binding the attribute to.

4.7.3.b. A binding score of 3 means you have a high level of confidence in the binding of the attribute.

4.7.4. Binding score 4

4.7.4.a. Give the attribute a binding score of 4 if either:

• you have a GPG 45 very high confidence in the identity you are binding the attribute to; or
• the attribute is bound to an identity that was validated to a GPG 45 validity score of 4.

4.7.4.b. A binding score of 4 means you have a very high level of confidence in the binding of the attribute.

4.8. The matching score: show how you have matched the attribute

4.8.a. As an attribute service provider, you must assess how confident you are that the attribute you have been asked to share is related to the same person an attribute has been requested for.

4.8.b. Your matching score may reflect your own process or take account of the verification process of a relying party, or another service, that you work with.

4.8.1. Confirming the attribute belongs to the person

4.8.1.a. One way to increase confidence in a match is to check if the person who is being matched in the relying party or consuming attribute service, is the same as the one being described in the attribute.

4.8.1.b. You can do this by asking them to do a ‘verification check’ using the information in the attribute. This will give you a ‘verification score’ between 1 and 4.

4.8.1.c. A higher verification score will give you a higher matching score for the attribute.

4.8.2. Check the matching you have done

4.8.2.a. The matching process could require you to check the claimed identity or the authentication process used to relate an attribute to the right person in your database.

4.8.3. Matching score 1

4.8.3.a. Give the match a score of 1 if you matched the person to the attribute using a unique reference number.

4.8.3.b. You can also give the match a score of 1 if both of the following apply:

• you have at least a GPG 45 low confidence in the person’s identity; and
• the binding score for the attribute is at least 1 (or, if there is no binding score, you know the person who bound the attribute had at least low confidence in the person’s identity).

4.8.3.c. A score of 1 means it would be reasonably easy for someone to match to the attribute even if it does not relate to them.

4.8.4. Matching score 2

4.8.4.a. Give the attribute a matching score of 2 if you matched the person to the attribute using a verification check based on the attribute that scores 2.

4.8.4.b. You can also give the attribute a matching score of 2 if both of the following apply:

• you have at least a GPG 45 medium confidence in the person’s identity; and
• the binding score for the attribute is at least 1.

4.8.4.c. A matching score of 2 gives you medium confidence that the attribute relates to the right person.

4.8.5. Matching score 3

4.8.5.a. Give the attribute a matching score of 3 if you matched the person to the attribute using a verification check based on the attribute that scores 3.

4.8.5.b. You can also give the attribute a matching score of 3 if both of the following apply:

• you have at least a GPG 45 high confidence in the person’s identity; and
• the binding score for the attribute is at least 2.

4.8.5.c. A matching score of 3 gives you high confidence that the attribute relates to the right person.

4.8.6. Matching score 4

4.8.6.a. Give the attribute a matching score of 4 if you matched the person to the attribute using a verification check based on the attribute that scores 4.

4.8.6.b. You can also give the attribute a matching score of 4 if both of the following apply:

• you have a GPG 45 very high confidence in the person’s identity; and
• the binding score for the attribute is at least 3.

4.8.6.c. A matching score of 4 gives you very high confidence that the attribute relates to the right person.

5. Share an attribute

5.a. Before you share an attribute, you must have already bound the attribute in line with section 3. Then, when you share it, you must conduct a process of ‘matching’: confirming the person you are dealing with is the same as the person bound to the attribute. You could use the scoring methodology described in section 4 to assess how well you’ve matched an attribute.

Example

A relying party asks you to send them the insurance policy for Gemma Taylor. Because you hold attributes for several people named ‘Gemma Taylor’, you use the details provided by the relying party and, if necessary, you reverify attributes with Gemma herself, to ensure you share the right insurance policy.

5.b. Before you share any attribute, you must also check:

• when the attribute was last updated;
• if the attribute has expired;
• if the attribute has been revoked;
• if you have the right to share it;
• how reliable and secure it is; and
• how you intend to share the attribute.

5.c. Exactly how you share attributes is up to you. It will usually be something you consider when you build your service.

5.d. The trust framework data schema provides guidance for certified services and relying parties on how they could organise and exchange information in a consistent way to enable interoperability.

5.1. Attribute metadata

5.1.a. All the attributes you collect, store or share must include metadata, which is information about the characteristics of the data. Examples of metadata that could be included are:

• who created the attribute;
• when it was created;
• what evidence was used to create the attribute; and
• when it was last checked for updates.

5.2. Check if the attribute is in the right format

5.2.a. Some attributes will need to fit a standard format or have other limits. For example, someone’s date of birth cannot be ‘23/101/1980’ or ‘32/10/1980’.

5.2.b. Attributes with a standard format include:

• UK postcodes;
• mobile phone numbers; and
• unique identifiers (such as account numbers) from some organisations.

5.2.c. Attributes can be inconsistent for several reasons. Someone might have:

• made a mistake;
• deliberately given a false attribute, for example by saying their phone number is 00000 000 000; or
• had a reason for using an unexpected format, for example if their preferred title was not shown as an option in a form.

5.2.d. You can change the format of an attribute to meet your needs, or those of an organisation you share the attribute with. For example, you could change a date from an American ‘mm-dd-yy’ format to a British ‘dd-mm-yy’ format or a phone number to add an area code (e.g. by replacing a ‘0’ with a ‘+44’).

5.2.e. If an attribute is not in the format you expect, you could have a process for finding out why it is inconsistent or ask for another version.

5.2.f. The trust framework data schema provides guidance for certified services and relying parties on how to organise and exchange information in a consistent way.

5.3. Check when an attribute was last updated

5.3.a. You must include the date and time when an attribute was last checked or updated in its metadata.

5.3.b. Relying parties are more likely to use attributes that are:

• up to date; and
• valid (not expired or revoked).

5.3.c. You must agree with relying parties or other services you work with how recently attributes will have been checked when you share them with them.

5.3.d. Some attributes, like a person’s date of birth or National Insurance number, will almost always stay the same throughout their life. Others, like someone’s home address or passport number, are likely to change several times.

5.3.e. For attributes that are likely to change, up-to-date versions are usually more useful and valuable than older ones. Relying parties can also choose to consume less valuable attributes, which might be out of date, and check them themselves. 

5.3.f. To check if an attribute has been updated, you can ask:

• the person the attribute relates to;
• another part of your organisation that holds other data sets;
• another attribute service provider who has updated the attribute more recently; or
• an ‘authoritative source’ – see how to recognise an authoritative source.

5.4. Keeping attributes you hold up to date

5.4.a. You will not usually be told when an attribute you hold is updated.

5.4.b. If you need the attributes you share to be as up to date as possible, you must set up a system to monitor them. The Information Commissioner’s Office has several examples of when personal data should be kept up-to-date.

5.4.c. How you monitor changes will depend on your organisation’s needs and on sector and industry-specific needs, like ‘know your customer’ requirements for banks and other financial services.

5.4.d. If other attribute service providers share information with you, you might be able to use it to update the attributes you hold.

Example

Employers have to send a Real Time Information (RTI) update to HM Revenue and Customs (HMRC) every month. This includes payroll information and some employees’ addresses and postcodes.

If an employee’s postcode in the RTI does not match HMRC’s records, HMRC can change the employee’s address in their system.

5.4.e. You can also ask people to tell you about any changes directly. This is often used for changes to contact details.

Example

The Driver Vehicle and Licensing Agency (DVLA) holds the addresses of UK driving licence holders. DVLA asks licence holders to contact DVLA if they move house and cannot pick up post from their old address.

If someone moves and does not tell DVLA about the change, they can be:

• charged for late payment if they miss a parking or speeding ticket; and/or
• fined up to £1,000.

5.5. Attributes that expire

5.5.a. Some attributes expire. This means they stop being valid after a set time.

Example

A gym offers a year’s membership for the fixed price of £450.

Ahmed signed up for the membership on 31 August 2024, which gave him the attribute ‘current gym member’. A year later, on 30 August 2025, the attribute expired. As a result, his membership card will no longer open the gym door.

5.6. Check if an attribute has expired

5.6.a. An attribute may not be valid if its expiry date has passed.  

5.6.b. The expiry date may be found:

• on a related physical document (like a driving licence or security pass); and/or
• as part of a digital record, for example in the metadata.

5.7. Sharing expired attributes

5.7.a. Expired attributes can be used for some purposes, including as ‘knowledge-based verification’ (KBV) challenges.

5.7.b. If you share expired attributes, you must make it clear that they have expired, for example in metadata shared with the attribute.

5.8. Check if an attribute has been revoked

5.8.a. Attributes can be revoked or cancelled.

5.8.b. This may happen when a physical item, like a bank card or passport, is lost or stolen. The attribute (in this case, the unique reference number on the card or passport) is revoked to stop the item being used for fraudulent purposes.

5.8.c. It also happens for many other reasons. For example, an organisation might revoke:

• a customer’s ‘VIP’ status if they spend less than an agreed amount in a year;
• someone’s right to drive if they build up 12 or more penalty points in 3 years;
• an employee’s security clearance when they leave the company; or
• a digitally-issued verifiable credential if the organisation finds it has been issued fraudulently.

5.8.d. If an attribute can be revoked, it can be revoked at any time. This means a relying party might ask you to check if the attribute is still valid when they request it.

5.8.e. You must have a process to check if an attribute has been revoked.

5.9. Show the quality of an attribute

5.9.a. In some cases, the relying party or other recipient of an attribute will also need details about the quality or security of an attribute before they can use it. For example, a financial service might have specific requirements. Requirements and recommendations on assessing attribute quality are described in section 4 of this guidance.

5.10. Check you can share an attribute

5.10.a. You must meet data protection requirements when you share attributes, including ensuring you have a lawful basis for sharing them.

5.10.b. You must confirm the user’s understanding of how their attribute data will be shared and disclosed as described in 10.3 in the trust framework.

5.11. Checking attributes from other providers

5.11.a. If you use attributes from other providers to create your attributes, you might need to score them yourself to check the attributes you are using are reliable and secure.

5.11.b. You might want to score the attributes you collected if they:

• did not come with scores;
• came from the person that the attribute is about; or
• came from another attribute service provider that is not certified against the trust framework.

5.11.c. Use the section in this document on how to score attributes to do this.