How To

DCR 3.3 Tech Implementation Guidance

Page Contents

1. TPP Onboarding
2. Private Key JWT Token Authentication Method
3. MTLS Client Authentication and Certificate Bound Access Tokens
4. TLS Ciphers Support
5. FAQ

1. TPP Onboarding

Our current DCR has been uplifted to version 3.3. High level changes that are part of this uplift are:

Introduction of new claims and token authentication methods

As part of the DCR uplift we have introduced the following:

tls_client_auth_subject_dn

tls_client_auth_subject_dn claim is now supported in request JWT on POST register API. This claim must contain your TLS MA network certificate (OB Legacy Transport/OBWAC/QWAC) full subject DN details. This claim is MANDATORY to provide for tls_client_auth token authentication method. Not providing the same in expected format will result in failing the registration process.

Below is the list of certificate attributes that are currently supported

CN, OU, O, C, 2.5.4.97

Note: Short name "organizationIdentifier" of numeric oid 2.5.4.97 is currently not supported.

Expected order of the attributes for different types of certificates:

OB Legacy:
CN={common name},OU={organization unit},O={organization name},C={country}

OBWAC/QWAC:
CN={common name}, 2.5.4.97={organization identifier details},O={organization name},C={country}

Examples of tls_client_auth_subject_dn for different certificates:

private_key_jwt Authentication Method

New token authentication method private_key_jwt is now supported. Token_endpoint_auth_signing_alg must be provided in request JWT if private_key_jwt is selected. Only supported alg is PS256. Not providing the same will result in failing the registration process.

Corrected discrepancies around some claims and their lengths.

Request JWT claims have been corrected to meet OBIE DCR 3.3 specifications.

For more details around the new changes please refer to OBIE DCR 3.3 release specifications.

2. Private Key JWT Token Authentication Method

With the DCR 3.3 uplift, a new token endpoint authentication method private_key_jwt is now supported.

Access tokens can now be acquired using this new method or with tls_client_auth method which is currently supported. This method is implemented following RFC 7523 standards and mandatory request parameters must be sent as defined in the standards.

client_assertion and client_assertion_type are the new mandatory parameters added to the token API for private_key_jwt flow which when passed will determine token journey requested is private_key_jwt journey.

More details around the parameters and the claims supported in client-assertion JWT can be found in our sandbox portal.

3. MTLS Client Authentication and Certificate Bound Access Tokens

Our APIs are now protected with OAuth 2.0 Mutual-TLS Client Authentication and all access tokens generated will be certificate bound.

As part of it TPP's who are on tls_client_auth are expected to provide their transport layer certificate information at the time of on-boarding and the same will be validated at the time of issuing access tokens and accessing our AISP, PISP, CoF APIs. 

Notes: 

• Certificate bound access tokens will be generated for both types of token authentication methods supported.
• In case you acquire a new transport layer certificate because of various reasons (revoked, expired, or migrating from non-eIDAS to eIDAS), your new certificate information must be updated with us using PUT onboarding endpoint if it shares different subject DN details (immutable parts) than with the one already registered. Failing to do the same will block your access to APIs.
   

4. TLS Ciphers Support

For all TLS MA protected APIs, the following are the only TLS 1.2 ciphers that will be supported in order to align with FAPI standards.

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

5. FAQ

View our FAQ page for further guidance on known issues.