IDP Core Specification

Note: For the use of Developer Assets, these Terms and Conditions apply. Please also read the Requirements Notation and Conventions.

1. Overview

This document specifies the services an IDP needs to implement in order to participate in the ecosystem and gives implementation guidelines. It is assumed the reader is familiar with the overall architecture of the ecosystem as documented in Ecosystem Architecture.

In the ecosystem, the IDP is an OAuth Authorization Server and an OpenID Connect OP and also provides the following services:

  • Account Information (according to PSD2),

  • Payment Initiation (According to PSD2), and

  • Remote Signature Creation Service (According to eIDAS).

The following picture shows a reference design for the IDP of an active bank.

Reference Design Active Bank IDP

The figure shows the different services and how they integrate with the core banking systems in order to utilize online banking credentials for authentication and expose banking information and services through account information and payment initiation services. The bank may also act as a Qualified Trusted Service Provider for its customer base, the architecture model also allows the bank to cooperate with a certified Qualified Trusted Service Provider for that purpose.

The figure also indicates the integration of the services with the platform (blue arrows). The AS/OP obtains the list of all RPs along with the respective metadata and certificates from the RP directory. All services integrate with the Mediation Service and report any service delivered to a RP. This data is used for settlement, clearing, and billing.

This document will first describe the building blocks of a IDP. They serve as the technical foundation for implementing the various use cases. Those use cases, e.g., Login, ID Verification, or access to account information, are described in detail in separate specifications along with details on how these use cases are realized using the IDP’s building blocks.

Note: this document and the related specifications attempt to use established terminology in the respective context. This might require to use different terms for the same entity in different contexts. For example, the “Client” in OAuth is called “Relying Party” in OpenID Connect.

2. Building Blocks

2.1. OAuth Authorization Server

Every IDP is an OAuth Authorization Server (AS). The AS allows clients (Relying Parties) to obtain the authorization to access services advertised in the scheme on behalf of the particular bank customer. Such services may be provided by the respective bank itself (such as identity providing or payment initiation) or by other parties. In the latter case, the set of all Authorization Servers will function as a virtual OAuth Authorization Server for such a service and provide user and account data to the service provider by way of access tokens.

The Authorization Server leverages the existing online banking user base and underlying strong identities to the services in the ecosystem. The Authorization Server uses the existing Online Banking Credentials to authenticate users, thus allowing bank customers to use -based services without the need to set up new credentials. The aim is to achieve a superior user experience and high conversion rates at the service providers.

Before a client can access a service on behalf of the user, the Authorization Server checks whether the user already consented to exactly the same scope, otherwise it MUST request the user’s consent. If the user denies the inquiry, access won’t be granted. If access is granted, the client is provided with an access token representing its permissions and carrying or referring to the user and account data needed to fulfill the particular service.

2.1.1. OAuth Profile

utilizes an OAuth Profile. Every AS MUST support the following features:

In addition, every AS MUST:

  • Return its own issuer URL in the iss parameter in the authorization response. This serves as foundation to allow clients to detect mix-up attacks.

It is recommended to utilize opaque (identifier-based) access tokens and OAuth 2.0 Token Introspection in order to allow the client to access multiple services using a single access token while ensuring the privacy preserving transfer of user and account data between AS and the respective service.

In case of remote signature creation (aka QES), the AS will need to support so-called hybrid access tokens, which contain some claims used to determine issuer and validity but the payload is retrieved using token introspection. For details, please consult the Signing Service Specification.

Moreover, all Authorization Servers MUST support external management of client ids and corresponding credentials and data by the platform (see Client Management).

Authorization Servers MUST implement a proper time synchronization.

2.1.2. User Authentication and Single Sign-On

The AS MUST use the existing online banking credentials and SCA methods to authenticate the user.

The AS MUST support user authentication on the following levels:

  • Single factor authentication using the primary online banking credentials.

  • Two factor authentication (strong customer authentication) utilizing existing online banking credentials and respective second factor or TAN approach.

The AS SHOULD implement authentication as frictionless as possible from a user perspective taking into account the particular use case (e.g., e-commerce and QES differ very much), regulatory/security requirements, and, for OpenID Connect (see below), the authentication level desired by the RP.

The AS SHOULD support a single sign-on experience (SSO), i.e., the user account is recognized securely in every subsequent authorization request, independent of the relying parties involved, and the user does not need to enter her user identifier and password with the bank again. If full SSO is not feasible due to the respective use case, the AS SHOULD utilize the existing user context to make the authentication experience as frictionless as possible. It can, for example, pre-fill the username field based on the pre-existing session and just ask the user to re-enter the PIN.

SSO support for selected use cases will become a mandatory requirement for the AS in the near future in order to enable banks to effectively compete.

2.1.3. Client Management

Client settings and credentials are managed centrally by the platform. ASs MUST query the respective data from the directory periodically, store it locally and put them into effect locally.

All client ids are generated automatically by the platform and used by the respective clients to identify themselves across all connected IDPs and services.

A -generated client id consists of two parts, a prefix and a v4 UUID, delimited by a :, as shown in the following example.

Example 1. Client ID

yes.com:3630BF72-E979-477A-A8FF-8A338F07C852

The prefix may serve as a selection criterion to distinguish locally managed and -managed client ids at the AS. It varies among different stages as follows:

Sandbox: sandbox.openbanking.verimi.cloud

Production: verimi.com

Clients register self-signed certificates (or a URL referring to a file containing such certificates) with the platform, which in turn are used to authenticate the respective client at the AS.

Every client record has a status field with the range of active, demo and inactive.

  • A client that is active can participate in the ecosystem with the permissions defined in the platform (see also below) and normal billing mediation.

  • A client set to demo can participate in the production environment of the ecosystem, but no billing mediation records will be written. This mode is intended for demonstration purposes, the last stages of the client integration into the ecosystem, and for the diagnosis of incidents in the production environment. IDPs MAY apply rate-limiting for demo clients and QTSPs may mark certificates used in signing processes as "not valid for legally binding signatures". IDPs MAY also show a warning message to users of demo clients, but for the sake of a faithful representation of the user interface, the warning message MUST NOT be in the screen area immediately visible to the user. An IDP MAY opt to not support demo mode. In this case, the IDP MUST nevertheless synchronize the clients with the status demo and treat them the same as inactive clients. The status demo is not used in the Sandbox environment.

  • A client that is inactive can not participate in the ecosystem.

The AS MUST NOT serve clients whose status is inactive. If a client in status inactive sends an Authorization Request to the AS, the AS MUST respond with an error response with error="access_denied". In case of a direct HTTP request, the AS MUST respond with an HTTP status code 403.

The claims and scopes every client is entitled to request are defined by its policy in the platform.

If a client requests claims or scopes it is not entitled to use, the AS MUST respond with an error response with error code unauthorized_client. In case of a token endpoint request, the AS MUST respond with an HTTP status code 403.

2.1.4. User Consent Handling

The AS MUST ask the user for consent to the entire scope of a particular authorization request and represent the scope of the consent in the issued access token (or related authorization data).

The AS MAY persist the user’s consent and ask for consent again only if the scope of a particular authorization request is not covered by the persistent consent or if the consent has been revoked by the user. The AS MUST indicate the persistence of the user consent to the user and clearly indicate to the user where this consent can be revoked if the user wants to do so.

If a particular authorization request’s scope differs from the persisted scope for the particular client and user account, the AS SHOULD ask the user for consent to the missing delta only. If the user denies the request, the state of the persisted consent remains unchanged. If the user gives her consent, the scope granted to the particular client is the union of the old and the requested scope.

The AS may decide to persist only certain scope values and omit others. For example, a scope value granting the client the right to initiate a payment on behalf of the user does not need to be persisted because the client is not supposed to ask for this particular scope again.

2.1.5. Token & Scope Handling

Clients can arbitrarily combine supported scope values in a single authorization request (e.g., access to user and account information or signing a document and initiating a payment).

The scope parameter is mandatory in the OAuth profile. As there is no default scope defined, the client is required to send a scope value in the Authorization Request. If the scope value is missing in the authorization request, the AS shall respond with an error authorization response (HTTP redirect) and error="invalid_request".

If the user consents to the request, the resulting access token is associated with the full scope and can be used by the client to invoke all services they grant access to (on the IDP and at other services).

For privacy reasons, IDPs should limit the data provided to the different services to the data they need to know by utilizing OAuth 2.0 Token Introspection.

Token leakage and replay (among services) is prevented by utilizing certificate-bound access tokens (OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens). Every IDP MUST constrain every access token to the certificate the client used to authenticate towards the token endpoint. Every service in the ecosystem MUST utilize TLS Client authentication (without trust chain validation) in order to verify the client’s certificate and subsequently check the certificate against the certificate associated with the respective access token (see OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens, Section 3).

Some services may interpret the access token as one time use only, e.g., for payment initiation.

A future version of this specification might require the AS to support refresh tokens.

2.1.6. User Interface Considerations

The user interface MUST work in browsers on typical end-user devices, such as smartphones, tablets, and PCs (e.g., by utilizing responsive design).

The handling of different languages is at the discretion of the IDP.

The implementation of the authentication and user consent flow is at the discretion of the AS. Options include (1) purely web-based flows, and (2) push notifications to mobile apps. Those are considered implementation details of the AS as long as the requirements of the OAuth protocol towards the client are fulfilled.

2.2. OpenID Connect OP (Identity Service)

Every IDP is also an OpenID Connect Provider (OP) which enables websites and apps, designated as Relying Parties (RPs), to leverage user and account data of the bank’s existing online banking user base.

For login with (ID Federation), the RP delegates the authentication process to the OP and relies on the user id asserted by the OP to log in the user locally. The RP will typically maintain a local user account, which is identified by the user id obtained from the OP.

The main benefit from a user’s perspective is an easy login without the need to set up a new password (or generally speaking any kind of credentials) with the RP. The RP, on the other hand, can rely on the fact that there is a verified person behind every user account asserted by a IDP (prevention of fake accounts).

Since “OpenId Connect is a simple identity layer on top of the OAuth 2.0 protocol”[1], the OP shares the authorization and token endpoints with the AS building block of the same IDP. OpenID Connect is simply “turned on” by passing a scope value openid in the Authorization Request.

An online banking user should not lose access to her RPs even if the responsibility for managing her user account within the scheme is moved to another IDP. To enable this, a protocol for User Account Migration is in place.

See Identity Service Specification for the detailed specification.

2.3. Account Information Service

The Account Information Service allows clients to access account information, such as the list of accounts, transactions and account balance.

The Account Information API is a profile of Berlin Group’s NextGenPSD2 XS2A Framework.

See Account Information Service Specification for the detailed specification.

2.4. Payment Initiation Service

The Payment Initiation Service as defined in this document provides clients with a capability to initiate SEPA credit transfers.

The Payment Initiation API is a profile of Berlin Group’s NextGenPSD2 XS2A Framework.

See Payment Initiation Service Specification for the detailed specification.

2.5. Remote Signature Creation Service

The Remote Signature Creation Services as defined in this document provides clients with the capability to electronically sign documents based on bank-verified identities.

The Remote Signature Creation API is based on the specification of the Cloud Signature Consortium and ETSi TS 119 432.

See Solution Design QES for the detailed specification.

3. Base Functions

3.1. Privacy Declaration and Terms of Service

Every Client MUST set up an HTTPS URL referring to its privacy declaration and SHOULD also set up an HTTPS URL referring to its terms of service along with the label of this particular document.

The IDP MUST show the link to the privacy declaration in every consent screen, so the user may obtain the necessary information about the way the client uses the data obtained via .

If the client has set up a URL for its terms of service, the IDP MUST show the link to this document in every user consent as well. That way, the user also accepts the terms of services of the respective client.

See the Implementation Guidelines to ensure the security of the IDP when handling RP-provided data.

3.2. Transaction-specific purpose

GDPR requires the IDP to present the user with a dedicated purpose for any inquiry for data transfer. The IDP Core Specification therefore requires RPs to present such a purpose with every transaction and it requires the IDP to display this purpose in the respective user consent screen(s) in order to inform the user about the designated use of the data to be transferred or the authorization to be approved.

To set a transaction specific purpose, the RP uses the OAuth authorization request parameter purpose.

In order to keep backward compatibility with OpenID Connect and for convenience, the IDP MUST use the default purpose provided in the RP configuration in case the RP does not include the purpose parameter in the authorization request.

The purpose MUST NOT be shorter than 3 characters and MUST NOT be longer than 300 characters. If these rules are violated, the authentication request MUST fail.

This is a generalization of the purpose parameter as introduced by OpenID Connect for Identity Assurance.

See the Implementation Guidelines to ensure the security of the IDP when handling RP-provided data.
RPs MUST NOT use the old parameter https://www.sandbox.openbanking.verimi.cloud/parameters/purpose together with the new parameter, purpose. IDPs MAY reject requests carrying both parameters with the error invalid_request or process only one of the parameters.

3.2.1. Consent Purpose error messages

The following errors MUST be redirected to the RP:

Example 2. RP redirect with error_code: 
<rp_redirect_url>?state=-ZBPQz_Rj5DA8c9X7Y9wzgiMsJYdtYoRpwOB0qdeyBQ&
iss=https%3A%2F%2Faccounts.example-bank.com%2Fissuer&
error=invalid_request&
error_description=invalid_purpose_length

Error:

Description

Param: error

Param: error_description

Invalid purpose length

The request contained a purpose with invalid length

invalid_request

invalid_purpose_length

3.3. Account Selection

The aim of is to provide users with an easy as possible and frictionless user experience. As a consequence, the account chooser memorizes the user’s bank selection and does not ask the user for her bank preference (or online banking account) again in the normal case. This means that the user is, in her perception, in most cases directly redirected to her bank after pressing the button at the RP.

There might be cases where the user wants to use another bank with a RP. In order to allow a use-case-related re-selection of the bank, the OP MUST offer the user an option in its user interface to go back to the account chooser and select another bank, for example a link with the text “Select another Bank”.

If the user chooses this option, the OP MUST terminate the process and send an error response with the new error code account_selection_requested.

3.4. Timeline

The IDP SHOULD keep the user informed about all transactions performed on a particular account. This gives users a sense of control and is an additional means to maintain the customer relationship, since users have more reasons to visit the bank’s app or web site.

The recommendation is to provide a history, which, for every consent, shows the RP, the requested scopes/claims, the date and the outcome (consented or declined).

4. Basic Service Protocol

Most services follow a common protocol based on the OAuth 2.0 client credentials grant and the OAuth 2.0 authorization code flow as laid out in the following. This basic service protocol also serves as the basis for services derived from NextGenPSD2 XSA.

For services that follow this protocol, only a description of the protocol parameters, details on the consent resource creation, and the resource access need to be provided.

A notable exception not following this protocol is the Identity Service.

4.1. Protocol Parameters

For each service, a number of parameters need to be known to the Client in order to run the service protocol. These parameters are as follows:

  • The Client creates a consent resource containing data about the request; for example, for a payment, this resource contains data like the amount that is to be transferred. To be able to create such a consent resource, the client uses the OAuth 2.0 client credentials grant to request an access token from the AS. A specific consent resource creation scope is needed for creating the consent resource as well as a consent resource creation endpoint to create the resource.

  • The Client derives a resource scope value from the id of the previously created resource and a consent base scope value specific to that service.

  • After acquiring an access token (see below), the Client uses it to connect to resource endpoints at the service provider (SP) in order to access the resources.

4.2. Protocol Flow

The protocol flow of the basic service protocol is as follows (see below for details):

  1. The Client uses the client credentials grant to obtain an access token needed to create consent resources from the AS.

  2. The Client creates a new consent resource. The creation of the consent resource is authorized using the access token obtained in the previous step.

  3. The Client initiates the authorization process with the user by sending an OAuth authorization request with the resource scope (derived from the base scope and the id of the consent resource created earlier).

  4. The AS authenticates the user.

  5. The AS obtains all data from the consent resource, displays information about the requested access to the user, lets the user determine the access granted to the Client, and (finally) lets the user authorize the access. This may require the user to perform an SCA.

  6. The authorization response provides the client with an authorization code.

  7. The client exchanges the code for an access token.

  8. The client uses the access token to access the actual resources at the resource endpoints of the SP.

4.3. Further Implementation Details

  • Access authorization is carried towards the resource server endpoints by using OAuth Access Tokens only thus the consent resource is used in the authorization process only.

  • Client Authentication: Certificate-based authentication is used at the AS’s token endpoint only. So in contrast to [NextGenPSD2 XSA Framework], creation of a consent resource is protected by a certificate-bound access token, which had been issued to the client based on its certificate registered with us.

  • Transport Security: all client interactions with AIS endpoints use certificate-bound access tokens issued by the Bank AS. Certificate-binding is implemented using mTLS.

  • For every registered client, maintains the redirect URI, so there is no need to register a redirect uri with every consent resource.

  • Payload encoding: JSON only.

  • Message authentication and integrity: based on TLS, no additional message signing

  • HTTP headers: (for the time being) does not require any of the request headers defined in the NextGenPSD2 XSA Framework (except Authorization for carrying access tokens)

4.4. Detailed Protocol Steps

4.4.1. Obtaining Access Token for Consent Resource Creation

The Client obtains the access token needed to create the consent resource by sending a token request (HTTP POST) to the AS, carrying the following parameters

Request Parameter Type Description

client_id

String

the client’s universal id as issued by

grant_type

String

OAuth grant type for this request. MUST be set to client_credentials, since the client wants to obtain an access token for its own identity. This token can be reused for multiple transactions to create payment resources.

scope

String

Scope of the access token the client wants to obtain. MUST be set to the consent resource creation scope, e.g., https://www.openbanking.verimi.cloud/scopes/ais/consent

Example 3. Access Token Request for Consent Resource Creation 
POST /token
Host: as.example-bank.com
Content-Type: application/x-www-form-urlencoded

client_id=clients.yes.com:3630BF72-E979-477A-A8FF-8A338F07C852&
grant_type=client_credentials&
scope=https://www.openbanking.verimi.cloud/scopes/ais/consent

The client authenticates using TLS Client Authentication. It must use one of the certificates registered with for the particular client_id sent in the token request.

If the AS is able to authenticate and authorize the client successfully, it issues an access token to be used in the subsequent steps.

This is shown in the following example:

Example 4. Response to an Access Token Request 
HTTP/1.1 200
Content-Type: application/json;charset=UTF-8

{
   "access_token":"eyJraAAiOiJOQnlW...",
   "token_type":"Bearer",
   "expires_in":600
}

4.4.2. Consent Resource Creation

The client utilizes the access token to create a new consent resource.

The contents of the consent resource request are defined per-service.

The following request shows an example of a request to create a consent resource based on the account information service.

Example 5. Consent Resource Creation Request 
POST /consents
Host: as.example-bank.com
Content-Type: application/json
Authorization: Bearer eyJraAAiOiJOQnlW...

{
   "access":{
      "accounts":[],
      "balances":[],
      "transactions":[]
   }
}

The POST request only returns the id of the new consent resource (note that the parameter name for the id may differ).

Example 6. Response to a Consent Resource Creation Request 
HTTP/1.1 201 Created
Content-Type: application/json
Location: /consents/361200619b1f82f76

{
   "consentId": "361200619b1f82f76",
}

4.4.3. Initiate Authorization Process

The client needs to obtain authorization from the user in order to get access to the desired resources. It utilizes the AS for that purpose by sending an OAuth authorization request referring to the newly created consent resource.

The following table contains the authorization request parameters.

Parameter Type Description

response_type

String

MUST be set to code

client_id

String

universal client_id as issued by

scope

String

The scope is the reference to the consent resource, e.g., https://www.openbanking.verimi.cloud/scopes/ais:<consentId>.

state

String

A dynamic value used to prevent CSRF attacks.

code_challenge

String

PKCE challenge according to RFC 7636, used to prevent code injectionattacks.

code_challenge_method

String

Code verifier transformation method as defined in RFC 7636, is S256 or plain. S265 is recommended by this specification.

Example 7. Authorization Request
GET /authorize
   ?response_type=code
   &client_id=clients.yes.com:3630BF72-E979-477A-A8FF-8A338F07C852
   &scope=https%3A%2F%2Fwww.yes.com%2Fscopes%2F%0Aais%361200619b1f82f76
   &state= S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw
   &code_challenge_method=S256
   &code_challenge=5c305578f8f19b2dcdb6c3c955c0aa709782590b4642eb890b97e43917cd0f36
   HTTP/1.1
Host: as.example-bank.com

4.4.4. Obtain Access Token for Resource Access

The rest of the authorization process is standard OAuth. Once the AS redirects the user agent back to the client and passes the authorization code, the client uses this code to obtain an access token at the AS’s token endpoint. The client authenticates towards the token endpoint using TLS client authentication as described in Obtaining Access Token for Consent Resource Creation.

4.4.5. Resource Access

The Client then uses the access token to access the resources at the resource server.

The client MUST send an access token with every request in the authorization header using the Bearer scheme as defined in RFC 6750. The resource server MUST verify that the privileges of the access token are sufficient to perform the particular request. If this check fails, the resource server MUST refuse the request.

The client MUST authenticate on every request using TLS Client Authentication with the certificate used to obtain the access token according to OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens.

The Resource Server (SP) MUST verify that the fingerprint of the TLS certificate obtained from the TLS stack matches the fingerprint linked to the access token in order to prevent access token leakage. If this check fails, the SP MUST refuse the request.

Example 8. Resource Access (abbreviated) 
GET /accounts HTTP/1.1
Host: ais.example-bank.com
Authorization: Bearer eyJraAFE65JQWJ..
Example 9. Response with Resource (abbreviated) 
HTTP/1.1 200 OK
Content-Type: application/json

{
   "accounts":[
      {
         "resourceId":"3dc3d5b3-7023-4848-9853-f5400a64e80f",
         "iban":"DE2310010010123456789",
         ...
      }
   ]
}

5. Implementation Guidelines

5.1. Security: Avoiding Cross-Site Scripting in IDPs

The following data is provided by the RP to the IDP and then used in the web interface of the IDP:

  • Terms of Service URI and Link Label

  • Privacy Terms URI

  • Purpose text

  • In the case of QES: Document labels and Terms of Service Links of the QTSP

In order to prevent injection attacks (cross-site scripting, defacing), the IDP MUST expect special characters in this data and MUST ensure that any special characters in the data cannot be used to inject code into the web interface of the IDP. Proper escaping MUST be applied by the IDP. The IDP SHALL NOT resort to removing characters from the data to this end, as this is detrimental to the user experience, and can lead to insufficient escaping and new attack vectors.

For URLs (TOS, Privacy terms), the IDP MUST ensure that the URLs provided by the client cannot be used to execute code in the web interface of the IDP, for example via javascript:-links (note, however, that there are other vectors as well; it is not sufficient to filter out javascript:”-links). To this end, the IDP MUST check that the data provided by the client is a well-formed URL, that it starts with https://, and ensure that only characters from the regular expression character range [A-Za-z0-9+&@#/%?=~-_|!:,.;\(\)\[\]] are contained in the URL. If any of these checks fail, the authentication request MUST fail. After these checks, escaping as above MUST be applied. The IDP MUST NOT remove any characters from the URL.

5.2. IDP config data to register

In order to activate an IDP in the sandbox or production, the following IDP data needs to be provided to the platform team:

  • OpenID Connect Issuer URL of the respective IDP

  • All bank identification codes (BICs) of the bank represented by this particular IDP. BICs serve as the identifier to select an IDP in the account chooser during the flow.

  • A certificate (may be self-signed) for accessing the platform APIs (RP directory and Billing Mediation). Alternatively, the RP may also register a URI (so-called JWKS_URI) pointing to a file containing its public key certs.

5.3. Client Enrollment

The IDP MUST obtain all client data periodically from the platform’s RP and SP directories.

For details see Platform API documentation.

5.4. Billing Mediation

The IDP MUST create a mediation record everytime it provides a service to a client. The following is a list of services and the respective places, where the mediation record should be created:

  • Identity/Token Endpoint: before the ID Token is sent to the RP in the token response

  • Identity/User Info: before the User Info response is sent to the RP

  • QES [cf. QES Solution Design]:

    • IDP: before the Introspection Response containing the user and transaction data is sent to the QTSP

    • QTSP: before the Signature Object is sent back to the RP

  • Account Info: before the Account Info response is sent to the RP

  • Payment Initiation: after the SEPA transfer has been successfully initiated by the IDP. Depending on the payment system, this might already happen during the authorization request processing

Note: whether the client is charged for a particular service is decided during settlement, when all the mediation records are matched against the product database and the respective price points.

6. References

7. Document Control

7.1. Changes

  • renamed to IDP Core Specification

  • changed description format for claims and scope in user info and account info to use tables

  • consolidated description of design concept for Q/AES Profile

  • consolidated description of design concept for SEPA Transfer

  • consolidated description of ID Verification

  • added text on billing mediation

  • added terms of service and privacy declaration

  • removed document consent

  • Added two API design options for SEPA Transfer

  • Changed Login to require user consent, added recommendation to support persistent user consent

  • reworked document completely - enhanced scope to cover target picture (architecture, feature set), covers different roles of an IDP, split account and user information, added ID Verification section

  • replaced standard OpenId Connect scope and claim address with idp-specific scope and claims - rationale: add street number field

  • removed gender from person claim

  • reworked Login (ID Federation) to cover different authentication levels and the ways the RP can influence and get information about the authentication process.

  • reworked and detailed ID verification

  • reworked QES to be a service provided by the IDP

  • reworked and completed payment initiation

  • completed account information

  • updated remote signature creation (e.g. config value remote_signature_creation_endpoint)

  • Substitited https://www.openbanking.verimi.cloud/claims/date_of_birth by OIDC standard claim birthdate

  • Added section on account (re-)selection

  • Streamlined structure for verified person data and added support for different verification methods

  • Reverted address representation to the OpenID Connect standard claim address

  • Added IDP Reference Design Diagram

  • Removed https://www.openbanking.verimi.cloud/acrs/sso

  • Added note on mandatory SSO support in the near future

  • Added openid-configuration fields to let OP advertise its capabilities regarding verified person data

  • Extended metadata for agent-based person identification

  • Added tax_id to user information

  • Added https://www.openbanking.verimi.cloud/claims/preferred_iban to user information

  • Added legal_context to verified person data

  • Enhanced description of handling of country field for identity documents

  • Detailed description of transaction_id

  • Added platform and integration points to the reference design figure

  • 16.08.2018

    • removed early ideas re AML-compliant person identification

  • 27.08.2018

    • Flushed out AIS section

  • 12.09.2018

    • Added max_age requirement for verification.date

  • 14.09.2018

    • Adjusted document to service discovery concept

  • 15.10.2018

    • Added security requirement to return issuer URL in authorization response

  • 26.11.2018

    • Incorporated feedback of Daniel Keijsers and Daniel Fett

  • 28.01.2019

    • Added section on User Account Migration

  • 31.01.2019

    • Added details on billing mediation to login, user information and verified person data

    • Added transaction_id to mediation records

    • Increased the maximum length of the transaction purpose to 300 characters

    • Replaced text in Remote Signature Creation Section with Reference to QES Solution Design

    • More precise syntax and requirements for phone_number and phone_number_verified claims.

  • 04.02.2019

    • Added birth_name claim

    • Removed QES identification method for now since it is not broadly used at the moment. Will be incorporated again if/when this changes.

  • 22.02.2019

    • replaced “city” by “locality” in some examples within the “place_of_birth” claim

    • Changed Billing Mediation descriptions to new typed mediation record structure

  • 25.02.2019

    • added requirement to publish /.well-known/oauth-authorization server to OAuth section

    • added iss response parameter to section “Consent Purpose error messages”

    • added explanation on the use of transaction-specific purpose parameter

    • mention option to register JWKS_URI instead of public key/certificate values for a RP

  • 08.03.2019

    • Made billing mediation a mandatory feature, since “on us” business is implemented within the platform

  • 01.04.2019

    • Added note about hybrid access tokens to overview of required AS features

  • 04.04.2019

    • Modularization: Introduced the Basic Service Protocol

    • Moved the definitions of the AIS, PIS, and RIS to separate files

  • 12.04.2019

    • Added support to mark claims in verified_person_data as “essential”

    • Added requested_claim_names and request_acr_values to identity mediation record

    • Added text to make locality, zip_code, and street_address required address fields for IDPs

    • Removed https://www.openbanking.verimi.cloud/scopes/verified_person_data and https://www.openbanking.verimi.cloud/scopes/person_data

  • 22.04.2019

    • renamed legal_context to trust_framework

    • reworked identifier for id documents, trust frameworks, and verification methods - moved identifier definition to appendix

    • added support to express restrictions on id documents and verification methods

  • 09.05.2019

    • Finalized interim revision for upcoming version of IDP Specification

  • 24.05.2019

    • Reversed changes regarding legal_context and id document and verification method identifiers to produce a MVP baseline revision

  • 28.05.2019

    • finalized migration to AsciiDoc

  • 25.06.2019

    • ID Service Specification moved into a separate repository.