Updates have been made to the following paragraphs:
- Supporting Claims: guidance on claims related to contact details and the Contact Details data cluster
- Data language for profile scope and individually named claims: recommendations for amending consent requests
The data language outlined in the Profile Scope and Standard Claims section of the CX Standards was made to reflect data sharing requests, including the OpenID Connect (OIDC) "profile" scope or individually named contact detail claims supported in the technical standards. This requirement addresses the gap outlined in issue 404.
The profile scope and individual claims represent data of the authenticated user. For individual consumers this represents the consumer's name and contact details. For non-individual consumers, this represents the nominated representative's name and contact details.
Data holders must support the basic name claims but it is at the data holder's discretion whether to support the additional contact details for phone number, email address and mailing address.
These claims are advertised by the data holder using the "claims_supported" parameter in their OpenID Discovery Document endpoint. If a data holder does not offer that claim it ignores this requested claim during authorisation. If the requested claim is ignored then the data holder does not need to show the Contact Details data cluster in the authorisation flow.
Accredited Data Recipients (ADRs) can discover what each data holder supports and adjust the claims they request and their user experience accordingly. ADRs should identify claims the data holder supports before constructing a consent request. If the data holder does not support the claim(s), the ADR should not include the claim(s) in the request to the data holder or the consumer.
Data language for profile scope and individually named claims
ADRs must surface the outlined data language if they intend to request the OIDC profile scope data or one or more of the standard [OIDC] claims presented in the CX Standards from data holders.
Data holders must surface the outlined data language if an ADR requests the supported OIDC profile scope or one or more of the standard [OIDC] claims presented in the CX Standards.
The data cluster and all associated permission language need to be surfaced when this data is requested.
The 'Name' data cluster language and the 'Full name and title(s)' permission language must be surfaced if the OIDC profile scope or one or more of these claims has been requested: 'name', 'given_name', 'family_name', 'updated_at'.
If supported, the 'Contact Details' data cluster language and the ‘Phone number’, ‘Email address’, and ‘Mail address’ permission language must be surfaced if one or more of these standard OIDC claims has been requested: 'email', 'email_verified', 'phone_number', 'phone_number_verified', 'address'.
For example, even if the ADR only requests the single standard OIDC claim ‘address’, the following language must be displayed in full:
Data Recipients and Data Holders SHOULD expand on the proposed language where appropriate to communicate further details of what is being shared.
Additional details MAY include additional information in context, such as in-line help or tool tips, and/or additional permissions where they may exist.
Data language for profile scope and customer scopes
If both profile and customer scopes are requested, the data language for both must be surfaced to the consumer.
For example, if the ADR requests the following:
- OIDC Profile scope or one or more of these standard [OIDC] claims: name, given_name, family_name, updated_at; and
Then the ADR and DH are expected to surface the following to the consumer:
Full name and title(s)
- Name and occupation*
*See Issue 485 for information relating to a change request for customer data for the banking and energy sectors.
The DSB proposed a pragmatic cluster approach over a claims-based approach for the following reasons:
- Research findings: CX research showed that grouped data supported comprehension.
- Consistency: clustering is consistent with current data language structure.
- Timing and implementation effort: Introducing claims based consent was more complex and, at the time, a priority for urgent change called for a more practical and expedient build solution.
We will continue to examine this issue following implementation and will consider any change requests as necessary.