How to create and share attributes
A guide for organisations interested in being an 'attribute service provider' certified against the UK digital identity and attributes trust framework.
0.a. Before you can begin acting as a certified attribute service provider under the UK digital identity and attributes trust framework, you will need to prepare the attributes that are involved. This makes it possible for the organisations that consume attributes to compare, trust and use them.
0.b. You will usually need to:
0.c. You can then share the attribute.
1. Create an attribute
1.a. Exactly how you create attributes will depend on what you are trying to do, or what your organisation does.
1.b. For example, a new attribute would be created when you:
-
open a bank account;
-
open an email account;
-
count how many people work for your business; or
-
assign VIP status to a customer.
1.1. Using existing attributes to create new attributes
1.1.a. Creating a new attribute can also involve other attributes that already exist. Some of these might come from other attribute service 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.
1.1.b. Collected attributes can be combined or used alone.
1.2. Storing attributes
1.2.a. Your organisation must have a records management policy, which will tell you how to manage attributes you create and store. This should include:
-
which attributes to keep;
-
your reason for storing the attributes; and
-
how long you can keep the attributes for.
1.2.b. You should have access to the policy for your organisation. If you do not know where to find it or have any questions about its contents, talk to your organisation’s records manager.
2. Bind an attribute to a person or organisation
2.a. Attributes describe something about a person or organisation. As a result, attribute service providers and relying parties need to be able to tell who each attribute relates to.
2.b. You will use a process called ‘binding’ to record this.
2.1. How it works
2.1.a. Binding links an attribute to the appropriate person or organisation.
2.1.b. It uses 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 are 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 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 them know which Daniel Jones they are talking to.
2.1.c. 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.
2.1.1. Binding and matching
2.1.1.a. After an attribute has been bound, you can ‘match’ it to the person or organisation it is bound to.
2.1.1.b. To match an existing attribute, you will need to know the identifying attribute that was used in the original binding. Checking the identifying attributes against your records should tell you which person or organisation the attribute relates to.
2.2. How to bind an attribute
2.2.a. You can bind an attribute by recording the attribute and identifying attribute together. Do this once you have:
-
checked the identity or authenticator of the person or organisation involved; and
-
decided which identifying attribute to use.
2.2.b. Exactly how you record the attribute and identifying attribute will depend on the system you use.
2.2.c. You can bind an attribute when it is created or wait until later, as long as you bind it before you share it.
2.2.1. Who to bind to
2.2.1.a. When you bind an attribute, you connect it with either:
-
the person or organisation who gave you the information; or
-
the person or organisation that it relates to.
2.2.1.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 impersonating someone else.
2.2.2. Checking the claimed identity
2.2.2.a. When you bind an attribute to a person or organisation, you will need either their identity or an authenticator.
2.2.2.1. Check a person’s identity or authenticator
2.2.2.1.a. First, you must check a person’s identity, use the separate guidance on how to prove and verify someone’s identity.
2.2.2.1.b. You can use an authenticator instead if either:
-
you have already proved their identity; or
-
they have a digital identity you can accept.
2.2.2.1.c. You might decide not to check the claimed identity or ask for an authenticator.
2.2.2.1.d. This can affect your ability to share the attribute.
2.2.2.1.e. Checking the person’s identity or authenticator will give you one of the following levels of confidence in the identity:
-
low confidence;
-
medium confidence;
-
high confidence; or
-
very high confidence.
2.2.2.1.f. 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.
2.2.2.1.g. You must record your level of confidence in the attribute’s metadata.
2.2.2.2. Check an organisation’s identity
2.2.2.2.a. First, check the identity of the person who claims to represent the organisation.
2.2.2.2.b. Once you have checked their identity, you must:
-
check the claimed identity’s relationship with the organisation.
2.2.2.2.c. You must record the results of these checks in the attribute’s metadata.
2.2.2.2.d. If you cannot confirm that the organisation exists and that the claimed identity represents it, you should not bind the attribute to them.
2.2.3. Choosing an identifying attribute
2.2.3.a. You can choose to either:
2.2.3.1. Create an identifying attribute
2.2.3.1.a. You can create a new identifying attribute if you would like to. For example, every company that registers with Companies House is given a new identifying attribute when they get a company registration number.
2.2.3.1.b. There are no restrictions on the identifying attributes you create. Other organisations will be less likely to trust them if you do not produce them in a reliable way. For example, if it is possible for you to accidentally issue the same registration number more than once.
2.2.3.2. Use existing information as an identifying attribute
2.2.3.2.a. You can use various types of existing information as identifying attributes. This includes information that you ask for during the binding process or already have from authentication.
2.2.3.2.b. If the attribute is about a person, you can use information about them.
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. The customer number is the identifying attribute in this case.
2.2.3.2.c. If the attribute is about an organisation, you can use information about it.
Example
An import and export business needs to link a company to a Dun and Bradstreet DUNS number. They can do this by using the organisation’s Companies House number. They will need to make sure the number in the Companies House register matches the number in the DUNS register.
2.2.3.2.d. You can also use someone’s physical appearance as an identifying attribute. This means they physically match a photo you hold or a photo from a piece of evidence that you trust.
Example
Someone working in a pub needs to check a customer’s age before they sell them an alcoholic drink. They need to link the customer’s age or date of birth to the person who’s trying to buy a drink. They can do this by checking the photo on a piece of evidence (such as a proof of age card) looks like the customer.
2.2.3.2.e. If you and the person both have access to appropriate technology, you can use someone’s biometric information as an identifying attribute.
Example
A house buyer can use their conveyancer’s app to scan their passport. The app will send their name and the image of their face to the conveyancer, who can then draw up property documents in their name.
Before the buyer completes the purchase, their face will be scanned and compared to the attribute on file using facial recognition technology. The conveyancer uses their biometric information as an identifying attribute so they can be sure it is the right person buying the house.
2.3. Responding to attribute confirmation checks
2.3.a. In some cases, you will not need to provide all the information that an attribute contains.
2.3.b. This usually happens when someone asks you to do a confirmation check on an attribute you hold.
Example
An online lottery ticket seller needs to know that a new customer, Jack, is old enough to buy a ticket. The minimum age limit for the lottery is 18. Jack’s date of birth is the attribute.
An attribute provider can send the seller a ‘yes’ or ‘no’ response that shows if Jack is aged 18 or over. The lottery ticket seller does not see their full date of birth or any other information.
If Jack is older than 18, the lottery ticket seller will let them create an online account to buy a ticket. They will also store the information about Jack’s age as an attribute.
Because they do not know Jack’s date of birth, the attribute the lottery ticket seller stores will be ‘over the age of 18’. They should treat the new attribute like any other attribute - for example, they can use it to create a new attribute.
2.3.c. Before you respond to an attribute confirmation check, you must follow the guidance on how to share attributes.
3. Share an attribute
3.a. Before you share any attribute, you must check:
3.1. Check when an attribute was last updated
3.1.a. You must include the date when an attribute was last checked or updated in its metadata.
3.1.b. Relying parties are more likely to use attributes that are:
-
up to date; and
-
valid (not expired or revoked).
3.1.c. Relying parties can decide how recently an attribute must have been checked before they will accept it.
3.1.1. Attributes that can be updated
3.1.1.a. 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, might change several times.
3.1.1.b. 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.
3.1.1.1. Check if an attribute has been updated
3.1.1.1.a. To check if an attribute has been updated, you can ask:
-
the person or organisation the attribute relates to;
-
another attribute service provider who has updated the attribute more recently; or
-
the ‘authoritative source’ - see how to recognise an authoritative source.
3.1.1.2. Keeping attributes you hold up to date
3.1.1.2.a. You will not usually be told when an attribute you hold is updated.
3.1.1.2.b. If you need the attributes you share to be as up to date as possible, you will have to set up a system to monitor them. The Information Commissioner’s Office (ICO) has several examples of when personal data should be kept up-to-date.
3.1.1.2.c. How you monitor changes will depend on your organisation’s needs and on industry-specific requirements, like the ‘know your customer’ (KYC) requirements for banks and other financial services.
3.1.1.2.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.
3.1.1.2.e. You can also ask people and organisations 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.
3.1.2. Attributes that expire
3.1.2.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 2019, which gave him the attribute ‘gym member’. A year later, on 30 August 2020, the attribute expired. As a result his membership card will no longer open the gym door.
3.1.2.1. Check if an attribute has expired
3.1.2.1.a. An attribute will not be valid if its expiry date has passed.
3.1.2.1.b. The expiry date can be found:
-
on a related physical document (like a driving licence or security pass), if there is one; and/or
-
as part of a digital record, for example in the metadata.
3.1.2.2. Sharing expired attributes
3.1.2.2.a. Expired attributes can be used for several things, such as ‘knowledge-based verification’ (KBV) challenges. If you share expired attributes, it must be obvious that they have expired.
3.1.2.2.b. Attributes that are documents, such as passports or photocard driving licences, should not be used for their original purpose once they expire. This means you cannot use them to prove someone’s right to travel or drive. Relying parties might choose to accept them as evidence to prove and verify someone’s identity.
3.1.3. Attributes that can be revoked
3.1.3.a. Many attributes can be ‘revoked’ (cancelled).
3.1.3.b. This often happens 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.
3.1.3.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 driving licence if they build up 12 or more penalty points in 3 years; or
-
an employee’s security clearance when they leave the company.
3.1.3.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.
Example
Felicity is going to visit Glasgow and is flying from London Heathrow airport. As well as checking her identity, airport staff at the security gate will check she has the right to fly to her destination.
In this case, they simply need to check that her name is not on any ‘no-fly’ lists. For other destinations, like the USA, they would also need to check that she has the right visa or other permissions.
3.1.3.1. Check if an attribute has been revoked
3.1.3.1.a. You must ask an authoritative source to find out if an attribute has been revoked.
3.1.4. Show the quality of an attribute
3.1.4.a. In some cases the recipient 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.
3.2. Check you can share an attribute
3.2.a. You must meet data protection requirements when you share attributes. This means you must have a ‘lawful basis’ for sharing them.
3.2.1. Getting consent
3.2.1.a. In many cases you must check that the right person or organisation has given their consent for you to share their attribute. Exactly who this is and how they give consent will depend on what the attribute is and how you are using it.
3.2.1.b. You should not collect or share any attributes without a clear purpose. This is true even if you have consent.
3.2.1.c. When someone gives you their consent, you might need to check their identity or authenticator before you can accept it. This will make it harder for someone to accidentally or intentionally get information about someone else.
3.2.1.1. Implicit consent
3.2.1.1.a. In some cases you can share attributes about someone without that person giving their explicit consent. You will need to have ‘implicit consent’ to do this.
3.2.1.1.b. This usually happens when they have asked you to do something and you need to share their attributes to do it.
Example
A mortgage broker has to share details about their customers’ income. They do not need to record each customer’s consent, because they cannot get quotes from mortgage providers without sharing the information.
3.2.1.1.c. You might still need to check someone’s identity or authenticator before you can accept their implicit consent.
3.2.1.2. When you do not need to check for consent
3.2.1.2.a. You do not need to check for consent in certain other situations, including when:
-
you are being asked to share attributes as part of a legal investigation; or
-
sharing attributes could save someone’s life.
3.2.1.2.b. The ICO has a list of lawful bases for processing, which has more information about when you can share attributes and other data without consent.
3.2.2. Check the person or organisation requesting the attribute has the right to see it
3.2.2.a. Once you know you can share an attribute, you must check that the person or organisation that is asking for it has the right to see it.
3.2.2.b. If you already have appropriate consent to share an attribute with a specific person or organisation, you do not need to ask for it again.
Example
Amal goes to a high street store to buy a new mobile phone. He decides to get insurance for it through the store’s recommended third-party provider.
When Amal gives his details, he consents to the salesperson sharing them with a particular insurance provider. This does not mean the salesperson can give Amal’s details to another insurance provider or a marketing company.
3.2.2.c. In most cases, the person or organisation the attributes are about should decide who can and cannot see their attributes. But in some cases they can be overruled.
Example
Rebecca works in an independent bookshop. The owner, Niall, gives everyone who works in the bookshop a £50 note as a Christmas bonus. Rebecca would prefer it if Niall did not report her bonus to HMRC.
A Christmas bonus in cash counts as earnings, so Niall must report it to HMRC and deduct tax in the usual way. He does not need Rebecca’s consent to do this because he’s required to do it by law.
3.2.2.d. You might face unexpected situations where it is not clear if you should share an attribute with the person or organisation that is requesting it.
3.2.2.e. To make this clearer, you can ask:
-
the person or organisation the attribute relates to; or
-
a security, privacy or legal expert in your organisation.
3.2.2.f. If you cannot get clear approval, do not share the attribute. Make sure that everyone who can access the attributes you hold understands this.
Example
Chris is an administrator at a primary school. A parent who does not have day-to-day care of their child contacts the school and asks for their child’s home address.
The parent is not listed as a contact in the pupil’s record. But they claim they need the address because there’s been an emergency.
Chris needs to establish that:
-
there is a genuine emergency that can only be solved by sharing the address; and
-
sharing the address would not have any negative consequences, for example the parent using it to harass their former partner.
3.3. Check how reliable and secure an attribute is
3.3.a. You must check how reliable and secure the attributes you create are. One way to do this is using scoring.
3.3.b. Use the separate guidance on how to score attributes to do this.
3.3.1. Checking attributes from other providers
3.3.1.a. If you use attributes from other providers to create your attributes, you might need to do additional scoring to check the attributes you are using are reliable and secure.
3.3.1.b. You might want to score the attributes you collected if they either:
-
did not come with scores;
-
came from the person or organisation that the attribute is about; or
-
came from another attribute service provider that is not certified against the UK digital identity and attributes trust framework.
3.3.1.c. Use the separate guidance on how to score attributes to do this.
3.4. How to share the attribute
3.4.a. Exactly how you share attributes is usually something you will consider when you build your service.