Version control

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.

It has been agreed that a common, open ECA Standard such as that already developed by OBIE would be beneficial to support a number of use cases, providing clarity around the data elements, presentation of consent to the customer, and provision of this data to relying parties. The ECA Standard is modelled on the principles used the within the PSD2 customer journeys for TPPs, for example, gathering of consent and authentication at the ASPSP. The prototype journeys provided within this standard are designed to reflect ECA example journeys, some of which may sit outside the PSD2 framework. Certain journeys may demonstrate a combination of PSD2 and ECA data sharing in which case certain PSD2 principles will directly apply. Design of the standard needs to be inclusive and OBIE will ensure a wide range of participation in developing the ECA Standard so that it reflects views of both providing (ASPSPs) and relying parties (other entities and/or TPPs).

This ECA Standard is being developed on behalf of seven contributing members (the 6 largest UK ASPSPs plus TSB Bank). The scope will be limited to producing a standard based on extending the latest OBIE Standard (https://standards.openbanking.org.uk/) to meet the set of use cases as defined below.

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:

1. Developed as an initial draft to enable any participating firms to launch MVP or pilot activity.

2. Aligned to the emerging UK Government Trust Framework model, albeit not necessarily initially constrained by this (as it still being drafted).

3. Published under the MIT Open Licence to ensure it is free from IPR claims so that it can be submitted to other standard bodies without issue.

4. Will be submitted to OBIE for inclusion (as an optional/premium API) into the OBIE Standard.

5. Out of scope of the CMA Order, thus OBIE will not mandate implementation for the CMA9 (or any other firms).

6. Must be aligned to (i.e. not conflict nor contradict) PSD2/RTS, CMA Order, GDPR or any other relevant regulation.

7. Should not re-invent the wheel, so should re-use rather than replicate other relevant standards wherever possible.

8. Will generate value for people and small businesses and be designed to avoid harm.

The initial ECA Standard will thus focus on a set of (relatively) simple extensions to the current OBIE Standard and Trust Framework as follows:

1. Be based on the current OBIE API interaction flows and FAPI security profile.

2. 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.

3. Initially focus on the provision (not consumption) of additional data (beyond CMA Order/PSD2 data) by ASPSPs.

4. However, this should be extensible (e.g. in a future version) to enable:

   1. data consumption by ASPSPs and potentially both provision and consumption by other data holders; and

   2. use cases which require access to data from multiple sources (e.g. bank accounts and government services).

5. Cover both personal and business accounts, in particular considering data attributes which relate to both:

   1. the authenticating user; and

   2. the owner(s) of the account.

   3. 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:

1. Do-ability: should be (relatively) easy for ASPSPs to build.

2. Market readiness: should meet one or more high priority, high value and/or high volume market needs.

3. Commercial value: should thus provide ASPSPs a strong commercial benefit (either directly or indirectly) which aligns to their commercial strategy/objectives.

4. Value for end users: use cases which help drive better outcomes and/or generate value for end (personal and business) users and/or bring broader societal benefits.

The following high level use cases have been identified as in scope for the initial ECA Standard:

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

For each of these data objects, we will also consider:

1. The date/time the field was last updated.

2. 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).

3. Whether the data relates to:

   1. the authenticating user; or

   2. the owner(s) of the account.

4. Not all providers will have all of these fields.

5. 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”.

Advantages of this specification include:

• Developed under the OpenID Foundation

• Builds directly on OpenID and FAPI so is sufficiently secure for data sharing.

• A fairly simple technical extension to OpenID and FAPI

• FAPI provides for Relying Party identification and signing mechanisms

• Privacy preserving through requests for specific claims in any combination

• Provides access to attributes directly from the OpenID provider via OpenID ID Token or UserInfo endpoint

• OpenID with eKYC & IDA Supports most use cases

• Age verification is in roadmap for Q1 2021 as part of eKYC & IDA Implementers Draft 3

• Will support use cases for both personal and business use cases

• eKYC & IDA base spec is already in production for similar use cases elsewhere in the world

• Can support use cases that require data from multiple sources

• Verified claims are presented in a JWT so a plethora of libraries are available

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.

Implementers Draft 2 supports the following use cases that the ECA Standard is intended to support:

1. Onboarding

2. Ongoing validation or data sharing

3. Ecommerce

4. Authentication as a service

The roadmap for the eKYC & IDA specification includes an Implementers Draft 3 which is scheduled for Q1 2021 and currently includes the addition of age verification features and could also include registration of additional attributes required for the ECA Standard. Roadmap items for the eKYC & IDA spec that are of interest to the ECA Standard are:

• 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.

There is discussion on-going within and between various bodies about how interoperability can be achieved with respect to more localised attribute requirements. The OIDF, IANA, OIX and other stakeholders are considering this matter. One suggestion is registration of a UK specific profile that contains attributes that are only relevant in a UK context (such as national insurance number).

The data model for ECA is being developed with four attribute types:

1. Natural person attributes

2. Session attributes

3. Legal entity attributes

4. Verification attributes: attributes about the verification of the "verified attributes"

Attributes

Natural Person attributes

Session attributes

Legal entity attributes