Table of Contents |
---|
Version control
Note |
---|
This is a draft standard published by OBIE. This standard is subject to change at any time and is optional for implementation by any firm who choses to use it. |
Version | Date | Author(s) | Comments |
---|---|---|---|
DRAFT 0.1 |
| OBIE Standards Team | Initial draft for review by ECA Working Group |
DRAFT 0.2 |
| OBIE Standards Team | Version for formal consultation |
DRAFT 0.3 |
| OBIE Standards Team | Including updates from consultation for approval by ECA Working Group |
RC1 |
| OBIE Standards Team | DRAFT 0.3 Approved by ECA Working Group and uplifted to Release Candidate 1 (RC1) |
DRAFT 1.0 | TBC | OBIE Standards Team | Approved by ECA Working Group and ready for submission to OBIE and other standards bodies |
Introduction
Background
The aim of this work is to design an open Extended Customer Attribute (ECA) Standard to support the sharing additional customer data, which is not required under PSD2 nor the CMA Order, and which can be surfaced by ASPSPs and provided to relying parties on a commercial basis. This data can be used for a number of identity verification use cases and is of particular relevance to the UK government’s work (in particular the proposed trust framework for digital identity) as well as the OpenID Foundation’s eKYC & Identity Assurance work.
...
This work is not covered by the activity defined by the CMA’s Revised Roadmap but is an area of interest to many participants and it is hoped that extending the OBIE Standard to cover such data will allow the ecosystem to continue to innovate and flourish.
Key design principles
A number of key design principles were agreed for the development of the ECA Standard, namely:
...
Be based on the current OBIE API interaction flows and FAPI security profile.
Make use of the existing OBIE Directory, so that the APIs can be accessed by existing authorised TPPs, without the need for OBIE (or any other body) to create nor validate additional roles or scopes (e.g. Digital Identity Service Providers). Albeit this should not necessarily restrict access by other firms under contract with an ASPSP.
Initially focus on the provision (not consumption) of additional data (beyond CMA Order/PSD2 data) by ASPSPs.
However, this should be extensible (e.g. in a future version) to enable:
data consumption by ASPSPs and potentially both provision and consumption by other data holders; and
use cases which require access to data from multiple sources (e.g. bank accounts and government services).
Cover both personal and business accounts, in particular considering data attributes which relate to both:
the authenticating user; and
the owner(s) of the account.
but perhaps leaving more complex multi-user accounts out of scope for now.
Use cases
The initial use cases have been prioritised based on the following considerations:
...
ID | Use Case | Notes |
---|---|---|
1 | Onboarding | Provision of one or more data attributes which can be shared with a relying party (e.g. a utility company) to facilitate account opening with that party. |
2 | Ongoing validation or data sharing | Provision of long lived consent to the relying party for either basic attribute validation and/or data sharing. |
3 | E-commerce | Provision of validation and/or data attributes specifically in the context of ecommerce, to include ‘PISP plus' and Gift Aid examples. |
4 | Authentication as a service | e.g. Register/Login with BankID |
5 | Attribute verification | No data provided back, rather a binary Y/N verification by ASPSP of data provided by relying party (e.g. Is the user over 18? Is this the correct postcode?). |
Data model overview
To facilitate these use cases, the following data should be covered by the ECA Standard. This is further developed in the Attributes section below
...
The date/time the field was last updated.
The level of assurance at the time of update (e.g. the method by which it was checked), however, this should be aligned to emerging standards in this regard (e.g. GPG 45).
Whether the data relates to:
the authenticating user; or
the owner(s) of the account.
Not all providers will have all of these fields.
The above list of fields is not exhaustive and may change as the project progresses.
Intellectual Property Rights (IPR)
As per key design principle #3, any work produced as a result of this activity will be published under an open licence and may be shared with and submitted to other standards bodies. Therefore any contributions to this work must be made with the understanding that there are no IPR associated with any such contributions and the contributor warrants that their contributions are free from any IPR claims.
All contributions are made in accordance with the IPR Policy set out below in Appendix 1.
Regulatory considerations (PSD2/GRPR)
The ECA standard and ECA customer journeys have been developed to replicate the design principles of the OBIE Standard. OBIE has used a design approach which leverages on the current PSD2 principles and overlays them to support the ECA use cases. It is important to note that while the principles of consent and authentication will feature in each of the use cases, they may not necessarily be underpinned by a relevant regulatory requirement under PSD2 as they may not be linked to a payment activity within the regulation. It is the sole responsibility of participants to consider applicable regulatory obligations and ensure that they have been appropriate met for any of the use cases they are engaging in. This is especially important in use cases which combine payment services under PSD2 and data sharing under ECA. Participants must also ensure that they meet any applicable regulatory obligations under GDPR in relation to processing personal data.
API Specification
The ECA Standard will use the specification that is under active development by the OpenID foundation eKYC & IDA Working Group, namely, the “OpenID for Identity Assurance” specification. There is an associated specification that will add support for legal entity use cases called “OpenID for authority”.
...
The OpenID for Identity Assurance specification already supports a majority of the use cases defined in the ECA scope and will support the remaining in scope use cases in the future. The specification has also been developed in a way that means it is highly flexible with regard to use cases and can be readily extended with new attributes. It also allows requesting parties to be very specific about which attributes are required thus addressing data leakage and privacy concerns at a protocol level.
The specification (OpenID for Identity Assurance)
The work of the eKYC & IDA Working group is still underway and currently has an approved Implementers Draft 2 specification.
...
Attribute verification
Support for legal entity use cases
Conformance testing facilities
Data Model
In the context of the OpenID for Identity Assurance specification attributes can be used in a flexible fashion but there are a set of attributes in the specification that are going to be registered into the IANA JSON Web Token Registry to ensure consistent use internationally. It is appropriate for globally relevant attributes identified as part of the ECA Standard to be added to that set.
...
Natural person attributes
Session attributes
Legal entity attributes
Verification attributes: attributes about the verification of the "verified attributes"
Attributes
Natural Person attributes
Description | attribute name | Registration context | Comments |
---|---|---|---|
Full Name | name | Registered IANA via OpenID Connect Core 1.0, Section 5.1 |
|
| given_name | Registered IANA via OpenID Connect Core 1.0, Section 5.1 |
|
| middle_name | Registered IANA via OpenID Connect Core 1.0, Section 5.1 |
|
| family_name | Registered IANA via OpenID Connect Core 1.0, Section 5.1 |
|
phone_number | phone_number | Registered IANA via OpenID Connect Core 1.0, Section 5.1 | not strongly formatted |
| msisdn | Proposed by OpenID for Identity Assurance in scope of Implementers Draft 3 | Defined to use ITU-T E.164 format |
Phone number(s) | phone_numbers |
| Re-use phone number and msisdn singular claims Establish a structured object that is an array including:
|
e-mail address | Registered IANA via OpenID Connect Core 1.0, Section 5.1 |
| |
e-mail addresses | emails |
| Re-use email Establish a structured object that is an array including:
|
Date of birth | birthdate | Registered IANA via OpenID Connect Core 1.0, Section 5.1 | represented as an ISO 8601:2004 [ISO8601‑2004] |
age | age |
|
|
age verification | age_is_at_least | Proposed by OpenID for Identity Assurance in scope of Implementers Draft 3 |
|
age verification | age_is_at_most | Proposed by OpenID for Identity Assurance in scope of Implementers Draft 3 |
|
Previous/maiden name | birth_family_name | Proposed by OpenID for Identity Assurance in Implementers Draft 2 | is family name what is intended or should this be a structured object with given, middle and family? |
Previous names | previous_names |
| is this needed? should it be a structured object with given names and middle names and family names? what about date periods? |
Current Address | address | Registered IANA via OpenID Connect Core 1.0, Section 5.1.1 | start date not supported in current definition
|
Previous address(es) | previous_addresses |
| suggest an array of address objects with additional date to and from for each |
End-User’s place of birth | place_of_birth | Proposed by OpenID for Identity Assurance in Implementers Draft 2 | The value of this member is a JSON structure |
End-User’s nationalities | nationalities | Proposed by OpenID for Identity Assurance in Implementers Draft 2 | in ICAO 2-letter codes [@!ICAO-Doc9303], e.g. "US" or "DE". 3-letter codes MAY be used when there is no corresponding ISO 2-letter code, such as "EUE". |
Residence Status | residence_status | From gov.uk alpha on digital identity structured object with array of status and nations | |
End-User’s salutation, e.g. “Mr.” | salutation | Proposed by OpenID for Identity Assurance in Implementers Draft 2 |
|
End-User’s title, e.g. “Dr.” | title | Proposed by OpenID for Identity Assurance in Implementers Draft 2 |
|
Stage name, religious name or any other type of alias/pseudonym | also_known_as | Proposed by OpenID for Identity Assurance in Implementers Draft 2 |
|
Gender of end user | gender | Registered IANA via OpenID Connect Core 1.0, Section 5.1 |
|
Qualifications | qualifications | From gov.uk alpha on digital identity structured object with array of qualification and level of attainment | |
Employment history | employment_history | From gov.uk alpha on digital identity structured object with array of job titles and employer | |
Income | income | From gov.uk alpha on digital identity | |
Citizen registration number | From gov.uk alpha on digital identity | ||
Biometric information | From gov.uk alpha on digital identity | ||
Details of authority that the end user has over another entity | authority | Proposed by OpenID for Authority draft | Structured object containing data about the authority the end user has over another entity (such as a legal entity) Includes sub-elements:
|
Session attributes
Description | attribute name | Registration context | Comments |
---|---|---|---|
Authentication Context Class Reference | acr | Registered IANA via OpenID Connect Core 1.0, Section 2 | Trust framework possibly appropriate to define valid values for this claim |
Authentication Methods References | amr | Registered IANA via OpenID Connect Core 1.0, Section 2 | Trust framework possibly appropriate to define valid values for this claim |
Legal entity attributes
Description | attribute name | Registration context | Comments |
---|---|---|---|
Company name | organization_name | Proposed by OpenID for Authority draft | |
organization_type | Proposed by OpenID for Authority draft | discuss | |
trading_as | Proposed by OpenID for Authority draft | ||
Registered address | registered_address | Proposed by OpenID for Authority draft | |
Trading address(es) | trading_addresses | array of address objects | |
Company Registration Number | registration_number | Structured object that contains issuing body, country and registration number | |
VAT Reg Number | tax_details | structured object with types? | |
Legal Entity Identifier | lei | Proposed by OpenID for Authority draft | |
Name of regulatory Jurisdiction under which the legal entity is registered | registered_jurisdiction | Proposed by OpenID for Authority draft | |
Legal status of legal entity | organization_status | Proposed by OpenID for Authority draft | |
Date of incorporation of the legal entity | incorporation_date | Proposed by OpenID for Authority draft | |
Date last accounts were submitted | last_accounts_date | Proposed by OpenID for Authority draft | |
Turnover | last_annual_turnover | From gov.uk alpha on digital identity | |
Standard Industrial Classification (SIC) code | uk.sic_code | From gov.uk alpha on digital identity | |
Economic Operators Registration and Identification (EORI) number | eu.eori_code | From gov.uk alpha on digital identity | |
Excise Authorisation Verification (SEED) number | eu.seed_number | From gov.uk alpha on digital identity | |
Data Universal Numbering System (DUNS) number | uk.duns_number | From gov.uk alpha on digital identity | |
data protection registration number | dprn | From gov.uk alpha on digital identity Structured object that contains issuing body, country and appropriate data protection registration number |
Verification attributes
Description | attribute name | Registration context | Comments |
---|---|---|---|
Date first account opened | first_account_open |
| |
Has active account(s) - Y/N | has_active_account | the important consideration is that the account itself is still being used (i.e. has inbound or outbound transactions) and not simply that it has been accessed. | |
Time the End-User's information was last updated | updated_at | Registered IANA via OpenID Connect Core 1.0, Section 5.1 | |
There has been account activity seen in this 3 month period consisting of inbound or outbound payments | account_activity |
| derived from GPG 45 Proposal that this is a structured object with information about the period (in predefined threshold number of months) for which the account has seen activity (however that is defined in the trust framework) “account_activity”: { “active”: true; “active_duration”: 9 } |
Evidence used in verification process | evidence | Proposed by OpenID for Identity Assurance in Implementers Draft 2 | Structured object containing data about the evidence used when verifying the end-user’s identity e.g. details of passport, details of driving license, details of utility bill, details of any vouch |
| gbr.nino | Registration of local or scheme prefixes is being discussed in the standard bodies | Consensus is that National Insurance number is a piece of verification data Using the evidence structure of the OpenID for IDA spec allows a typed structured object including the type of document and attributes of the document (such as card number) |
...
"time":"2021-01-02T18:25Z",
Use Case technical examples
Relying Party is any entity that is permitted to interact with a provider so could be an intermediary or end consumer of data attributes.
...
The end User has an established relationship with the OpenID Provider but not necessarily with the Relying Party
Onboarding Use Case sequence diagram
Onboarding use case requires delivery of specific verified claims and specific verification metadata including some details of evidence used for verification of the end user and requests those claims to be delivered via the ID Token.
...
Expand | ||
---|---|---|
| ||
|
Age Verification Use Case sequence diagram
Note: Precise syntax for age verification request and response is actively being worked on by the OIDF eKYC & IDA Working Group and is unstable at the point of writing
...
Expand | ||
---|---|---|
| ||
{ } } } |
Payment, Name and Address Use Case sequence diagram
...
Expand | ||
---|---|---|
| ||
title participant PSU note over PSU, ASPSPRS note over PSU, ASPSPRS note over PSU, ASPSPRS PISP -> PSU: HTTP 302 (Found), Redirect (ConsentId\n + eKYC claims parameter) note over PSU, ASPSPRS |
...
Expand | ||
---|---|---|
| ||
|
Bank as attribute provider with multiple events
This example is as per the “Onboarding Use Case“ above from a sequence perspective but is intended to reflect a more current reality of the information that a bank may have available today and how the events that a customer may have been through could be reflected using the JSON schema defined within OpenID for IDA.
...
Expand | ||
---|---|---|
| ||
{ |
Customer Experience Guidelines (CEGs)
The following wireframes and prototypes, unlike other examples in the OBIE CEGs, are not not intended to be prescriptive but rather to:
...
No elements of these CEGs are mandatory and implementers are free to innovate.
Example 1: Age verification
...
In our first demo of innovative use cases for bank verified ID, the customer shares the minimum information which is necessary to verify their age via their ASPSP. A venue or merchant that requires age verification presents a QR code. The user scans the code to link to their mobile banking app, via search / menu of available providers. In this scenario the venue does not need the actual age or data of birth, the need only a binary response from the ASPSP that the customer is indeed over 21, for example.
View prototype
Example 2: Onboarding for a service
...
Onboarding journeys present the primary friction for users of online services and mobile apps. With the need for good anti-fraud measures onboarding can even become asynchronous while a human verifies uploaded documentation. Here the bank provides information to optimise sign-up, and good assurance of identity via their own login protocols, eg. biometric.
View prototype
Example 3: Secure login via QR code
...
In a non-cookied state, the ID provider uses registered bank account to offer a secure login journey. Embedded QR code instructions trigger an app-to-app redirect to the PSU’s mobile banking app.
View prototype
Example 4: Persistent login
...
Similar to Google suite, our third party ID provider is maintaining a persistent logged-in state, so access is frictionless.
View prototype
Example 5: Account sign-up with AIS
...
In this example, the merchant streamlines account onboarding and identity verification via a third party facility, including an AIS service for checking affordability. This reduces the need for manual user input and asynchronous verifications, including email and identification documents.
View prototype
Example 6: eCommerce checkout with PIS
...
Here the third party assurance provider streamlines a standard checkout, to reduce user friction and fraud, using a PISP to make the payment.
View prototype
Implementation considerations/risks
This ECA Standard does not include any Operational Guidelines, such as those included with the OBIE Standard.
...
The ECA standard does not constitute legal advice. While certain aspects have been designed to relevant regulatory provisions and best practice, they are not a complete list of the regulatory or legal obligations that apply to ASPPSs and/or relying parties. Although intended to be consistent with regulations and laws, in the event of any conflict with such regulations and laws, those regulations and laws will take priority. ASPSPs and relying parties solely responsible for their own compliance with all regulations and laws that apply to them, including without limitation, PSRs, PSD2, GDPR and consumer protection laws. ASPSPs and Relying Parties that choose to implement the ECA Standard will need to assess for themselves their own risks and regulatory obligations prior to doing so.
Appendix 1: ECA Intellectual Property Rights Policy
This Extended Customer Attributes (“ECA”) Intellectual Property Rights Policy (“IPR Policy”) defines the intellectual property rights and obligations of Contributors (as defined below) in relation to Contributions (as defined below) proposed to Open Banking Limited (“OBL”) for the creation of Specifications.
...