Consent Management

Overview

In today's open banking ecosystem, financial institutions face the critical challenge of sharing customer data with third-party providers while maintaining security, trust, and regulatory compliance. Consent management serves as the cornerstone of this data-sharing framework, enabling banks and financial institutions to:

• Protect customer interests and maintain trust in an increasingly open financial ecosystem
• Meet regulatory requirements for data privacy and customer protection
• Enable innovation through secure third-party integration
• Maintain control over data access while supporting customer choice
• Mitigate risks associated with unauthorized data access

The stakes are particularly high for financial institutions because:

• They handle highly sensitive financial data that could lead to direct monetary loss if compromised
• They operate in a heavily regulated environment where consent-related violations can result in significant penalties
• Their reputation and customer trust depend on demonstrating strong data governance
• They must balance security with the seamless customer experience expected in modern financial services

Basically, consent management is the explicit expression of the customer's will that something may be carried out in their name. In a sense, consent is an authorization (in which the intentions and consequences are made explicitly clear to the customer). In OpenBanking, where TPPs are in place in addition to FIs, a basic consent is the question to which extent a TPP may access customer data at the FI: Who is allowed to access what (service / data) for how long? How to revoke a given consent?

In sensitive use cases such as payment initiation, we can speak of an additional transaction consent for a one-time access, i.e., authorization in that the customer explicitly confirms the specific payment.

This page covers the implementation patterns with respective examples.

Detailed initial consent flow

Using FAPI 2.0, the consent flow can be handled via the integral authorization code flow. This means that the customer agrees to a well-defined scope (intention, consequences) and confirms this via the strong customer authentication mechanisms. Important is that the FI and/or TPP explicitly express the scope of the consent.

Initially, a pure OAuth 2.0 authorization code flow is used for the basic consent, i.e., the user allows the TPP to handle the user’s data at the FI within a specific scope (read, write, …). For the more fine-grained authorization of more critical transactions, e.g., payment initiation, FAPI’s concept of pushed authorization requests (PAR) is used to let the user directly authorize specific requests.

Initial consent flow and transaction authorization flow with FAPI:

1. Strong customer authentication on the portal of a TPP.
2. The customer wants to connect his FI with the TPP and initiates the consent flow.
3. The TPP authenticates itself to the FI (AS) via MTLS or DPoP and triggers a pushed authorization request (PAR).
4. The customer follows the link from the TPP (PAR) and authenticates to the FI (AS) (front channel).
5. The FI asks the customer if access shall be granted to the TPP.
6. The customer confirms and the FI provides the customer with an authorization code (front channel).
7. The customer is redirected to the TPP and provides the authorization code to the TPP, which in turn exchanges the authorization code to tokens (back channel) for later use.
8. The TPP manages the tokens for later API access to the FI. The established link between the TPP and the FI can be displayed in the TPP's portal.

Grant Management

With the above described Consent Management, coarse-grained authorization for accessing the APIs is defined. However, fine-grained access control to specific functionalities and data cannot be defined. Neither is it possible to manage already given consent. Therefore, the OpenID Foundation's FAPI Working Group specified Grant Management for OAuth 2.0.

Grant Management allows to define fine-grained access control for TPPs and efficient management of existing grants.

Following diagram provides a high-level overview of an authorization flow with grant_management_action=create to request the return of a grant_id:

To support this flow, the Grant Management Specification introduces the token response parameter grant_id. See 5.4. Token Response.

The Authorization Server (AS) will return a grant_id if it supports any of the grant management actions create, query, revoke, update, replace. Here is an example response:

Example: European Union

The following figure gives a highlevel-overview of establishing the linking between a TPP and an FI as it is done in the EU and many other countries across the world.

Before a TPP can participate in the PSD2 ecosystem, it must be registered by a competent authority. After successful registration, it receives an eIDAS (Electronic Identification, Authentication and Trust Services) certificate that must be used for the interaction with FIs

In contrast to the EU, Switzerland does not provide a central registration authority providing key material for secure encrypted communication between TPPs and FIs. Hence, commercial intermediaries or the FIs themselves must provide this role themselves. It is therefore crucial to clearly define corresponding standards that streamline the individual implementation.

Implementation patterns

This chapter describes the supported implementation patterns for accessing the APIs. The implementation is based on the Common API FAPI 2.0 Swiss Profile.

Direct implementation

In the direct implementation pattern, the FI takes additionally the role of the Trusted Central Authority. As such, the FI and the TPP have a direct relationship and share specific key material and certificates with each other. Therefore, this pattern is useful for use cases between few involved parties (TPPs and FIs) or if the FI wants to manage API access on its own.

Following diagram gives a conceptually high-level authorization flow with regard to the interaction between a TPP and an FI in such a point-to-point approach. It outlines the authorization code flow with grant_management_action=create. Here, the TPP must provide always the identification information that has been agreed with and defined by the corresponding FI, e.g. client certificate for mTLS.

First, the TPP must register with the FI, in order to receive, for example, a certificate which it can use to identify itself to the FI. After having completed the registration process and obtained a certificate to prove his identity, the TPP must use this certificate as part of the OAuth 2.0 Authorization flow.

Each TPP must complete the registration process for each FI where a customer wishes to access their bank details or make payments via the TPP as shown in following diagram.

Central registration authority

For large-scale use cases (many TTPs accessing many FIs), certificates should be managed and provided by a central registration authority (could also be an FI agreed upon) to avoid point-to-point direct relations and corresponding efforts in managing the key material.

One example of this approach is the bLink Platform, which offers service users (TPPs) and service providers (FIs) a Public Key Infrastructure (PKI) to facilitate the secure electronic transfer of information in a Multibanking ecosystem. Here, the bLink platform acts as the “Competent Authority” responsible for the supervision, registering and authorization of financial service providers (FIs and TPPs).

The bLink Consent Management 2.0 outlines how the consent management flow should be implemented using a central registration authority. See Consent Management 2.0 Flow.

However, a disadvantage of this implementation is that it does not support ‘Grant Management for Auth 2.0’, so existing consents cannot be updated via the bLink APIs.

Following diagrams show a high-level implementation architecture, and a high-level OAuth Authorization Flow, which uses the central registration authority and supports “Grant Management for OAuth 2.0”.

Each TPP and FI must complete the registration process with the central registration authority once to participate in the multibanking ecosystem. The central registration authority issues, e.g. a client certificate for each participant, which must be used for identification to each financial institution so that customers can access their banking data or make payments via this participant.

Following is the high-level overview of an authorization code flow with Pushed Authorization Requests (PAR) and grant_management_action=create. Here, the client sends a PAR directly to the authorization server, as required by the FAPI 2.0 Swiss Security Profile. In response, the authorization server sends a request URI value, request_uri, which must be used when calling the /authorize endpoint in order to initiate the actual OAuth 2.0 authorization code flow.

PAR passes authorization requests on the back channel, which means:

• The authorization server can trust where the request is coming from, and the requests have not been modified by an end user.
• The request details have not been exposed at the browser bar or history and privacy is preserved at that point of the chain.

High Level Consent Management Flow

The following sequence diagram outlines a high-level consent management flow that support “Grant Management for OAuth 2.0” and where the registration authority is a central entity such as the bLink platform.

This example illustrates the OAuth 2.0 Authorization Code Grant Flow with Pushed Authorization Requests (PAR) as defined by the FAPI 2.0 Swiss Security Profile for the use case “Create a fresh grant (grant_management_action=create).

The registration process of each TPP and/or FI with the central registration authority is not part of this diagram.

Implementation Notes

• The Grant Management specification defines a new endpoint called “grant management endpoint”, which enables a to query and revoke a grant. To access the endpoint, a pre-issued access token is necessary
• The request parameter grant_management_action may control the way the authorization server shall handle the grant when processing an authorization request. A token response may contain a grant_id only when the preceding authorization request contains the grant_management_action parameter with value create, grant_management_action=create

Authorization Server Configuration

OAuth 2.0 and FAPI Requirements

• Implement OAuth 2.0 authorization code flow with PKCE
• Use FAPI-compliant security profiles:
  • Require private_key_jwt client authentication
  • Enforce PAR (Pushed Authorization Requests)
  • Implement JARM (JWT Secured Authorization Response Mode)
  • Use signed request objects

Consent Endpoints

POST /consent/create
GET  /consent/{consentId}
PUT  /consent/{consentId}
GET  /consent/status/{consentId}
POST /consent/revoke/{consentId} 

Token Configuration

• JWT token for access tokens (FAPI-compliant access tokens must be JWTs (RFC 9068))
• Include consent ID in tokens:

{
    // Core JWT claims (All defined in RFC 7519)
    "iss": "https://auth.bank.com",           // Issuer - Required
    "sub": "user-123",                        // Subject identifier - Required
    "aud": "client-123",                      // Audience - Required
    "exp": 1583167531,                        // Expiration time - Required
    "iat": 1583163931,                        // Issued at - Required
    "jti": "jwt-id-123",                      // JWT ID - Required
    
    // OAuth 2.0 claims
    "client_id": "client-123",                // OAuth 2.0 client identifier - RFC 6749
    "scope": "accounts payments",             // Space-separated scopes - RFC 6749
    
    // FAPI-specific claims (FAPI Security Profile 1.0 - Part 2)
    "authorization_details": {                 // Rich authorization data - RFC 9396
        "type": "openbanking_intention",
        "locations": ["https://api.bank.com"],
        "actions": ["read", "write"],
        "datatypes": ["accounts", "payments"]
    },
    
    // Consent-specific claims (Organization-specific, not in RFCs)
    "consent_id": "consent-456",              // Custom claim for consent reference
    "sharing_duration_ends": 1583250331,      // Custom claim for consent expiration
    
    // Proof-of-Possession claims
    "cnf": {                                  // Confirmation method - RFC 7800
        "x5t#S256": "client-cert-hash"        // Certificate thumbprint
    }
}

Claim explanations and normative references:

1. Standard JWT Claims:

• All core claims (iss, sub, aud, exp, iat, jti) are defined in RFC 7519 Section 4.1

2. OAuth 2.0 Claims:

• client_id: From RFC 6749 Section 2.2
• scope: From RFC 6749 Section 3.3 (space-delimited format specified in Section 3.3)

3. FAPI & Rich Authorization Claims:

• authorization_details: Structure defined in RFC 9396 Section 2
• Format and requirements specified in FAPI Security Profile 1.0 - Part 2

4. Proof-of-Possession:

• cnf: Defined in RFC 7800 Section 3.1
• Certificate thumbprint format specified in RFC 7800 Section 3.2

5. Custom Claims:

• consent_id and sharing_duration_ends are organization-specific extensions
• Must use collision-resistant names as per RFC 7519 Section 4.2

Claim explanations and sources:

1. Standard JWT Claims (RFC 7519):

• iss: Identifies the authorization server
• sub: Identifies the user
• aud: Identifies the intended recipient
• exp: Token expiration timestamp
• iat: Token issuance timestamp
• jti: Unique identifier for the JWT

2. OAuth 2.0 Claims:

• client_id: From RFC 8693 (Token Exchange)
• scope: From RFC 6749 (OAuth 2.0 Core)

3. FAPI-specific Claims:

• authorization_details: From FAPI 2.0 Security Profile
• Rich authorization data structure follows RFC 9396

4. Custom Claims (not standardized):

• consent_id: Organization-specific identifier
• sharing_duration_ends: Consent-specific expiration

API Security Configuration

Endpoint Protection

• Use TLS 1.2 or higher
• Implement mutual TLS (mTLS) for TPP connections
• Configure allowed cipher suites according to FAPI:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Additional Implementation Notes

The following areas are subject to FI specific processes that are not further elaborated in this guide:

• Consent Data Model: The consent data model must capture all user permissions, access rights, and temporal constraints in a structured format, typically storing them as JSON objects in your database. It should include consent status, validity period, permitted actions, affected accounts, and access frequency limits. The model must also maintain references to both the client application and end-user, along with comprehensive audit trails.

• Consent validation process: Every API request must undergo consent validation by extracting the consent ID from the access token and verifying its status, scope, and temporal validity. The validation process must check if the requested operation is permitted within the consent's scope and whether any frequency or amount limits have been exceeded. Validation results should be cached briefly to improve performance while maintaining strict security.

• Consent storage: Consent records must be stored in a highly available, encrypted database with strict access controls and audit logging enabled. The storage solution should support quick retrieval for validation checks while maintaining an immutable audit trail of all consent modifications. Consider using a separate time-series database for consent usage patterns and audit logs.

• Monitoring: Implement real-time monitoring of consent-related events including creation, modification, usage, and revocation, with alerting for suspicious patterns. Track key metrics like consent usage patterns, revocation rates, and API response times to identify potential security issues or performance bottlenecks. Set up dashboards to visualize consent lifecycle events and configure alerts for anomalies like unusual access patterns or high revocation rates.

Resources

• FAPI 2.0 Security Profile (Draft)
• The OAuth 2.0 Authorization Framework (RFC 6749)
• JSON Web Token (JWT) (RFC 7519)
• Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) (RFC 7800)
• JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (9068)
• OAuth 2.0 Rich Authorization Requests (RFC 9396)
• Grant Management for OAuth 2.0
• Grant Management for OAuth 2.0 by Takahiko Kawasaki
• Grant Management for OAuth 2.0 by Authete
• Authorization Code Flow with Pushed Authorization Requests (PAR)