Glossary and terminology

This glossary covers the essential concepts, technologies, and roles involved in Open Finance, particularly concerning API access and security. Understanding these terms is crucial for anyone working within or interacting with the Open Finance ecosystem.

Open Finance

• Account Information Service Providers (AISPs): Third-party providers that can access and aggregate data from various financial accounts with the customer’s consent. They provide services such as financial dashboards or spending insights.

• Payment Initiation Service Providers (PISPs): Third-party providers authorized to initiate payments on behalf of customers, directly from their bank accounts.

• Customers: Individuals or businesses who own financial accounts and whose data can be shared with third-party providers with their consent.

• Financial Institutions (FIs): Banks, credit unions, and other organizations that hold financial accounts and provide APIs for third parties to access customer data or initiate payments.

• Third-Party Providers (TPPs): Companies or applications that access customer data from financial institutions via APIs to offer services such as budgeting tools, investment advice, or payment services.

• Regulators: Government or independent bodies that oversee the compliance and security of open finance practices, ensuring that data sharing occurs in a secure and controlled environment.

API Access and Security

• OAuth 2.0 (Open Authorization): An open standard for access delegation commonly used in Open Finance to grant third-party applications limited access to a user's resources without exposing credentials. OAuth 2.0 facilitates secure API access.

  • Authorization Server: The server that issues access tokens to third-party applications after successful authentication and authorization by the resource owner.

  • Resource Server: The server hosting the protected resources, such as financial data, which are accessed using access tokens issued by the Authorization Server.

  • Resource Owner: The entity (typically the end-user) that owns the data and grants permission to access it.

  • Client: The application requesting access to the resources on behalf of the resource owner.

  • Access Token: A token provided by the authorization server that allows the client to access the resource server on behalf of the resource owner.

  • Refresh Token: A token that can be used to obtain a new access token without requiring the resource owner to re-authenticate.

  • Scope: Specifies the level of access the client is requesting (e.g., read-only access to transaction history).

  • Redirection URI: The endpoint where an authorization server redirects the user after they have authenticated and authorized a client application. This URI must be pre-registered with the authorization server to prevent unauthorized access.

  • Authorization Code Flow: A process where the client first receives an authorization code, which is then exchanged for an access token. This flow is often used for applications where the client can securely store secrets.

• PAR (Pushed Authorization Request): A security enhancement to the OAuth 2.0 protocol where the client sends the authorization request directly to the authorization server instead of through the user-agent (like a browser). This reduces the risk of interception or tampering.

• RAR (Rich Authorization Requests): Extends the OAuth 2.0 framework to support complex authorization requirements by allowing clients to request specific access to granular resources. It enables the specification of detailed access requests, like requesting access to a particular account or service. RAR can be used instead of or in combination with OAuth 2.0 scopes.

• DPoP (Demonstration of Proof of Possession): A security mechanism that binds the access token to a particular client by requiring the client to demonstrate possession of a private key associated with the token. It prevents token replay attacks, where an attacker uses a stolen token to access resources.

• PKCE (Proof Key for Code Exchange): An OAuth 2.0 security extension that mitigates the risk of authorization code interception attacks. PKCE is particularly useful in mobile and single-page applications (SPAs) where the client cannot securely store secrets.

• Consent Management: The process and systems involved in obtaining, storing, and managing consumer consent for accessing their financial data. It is crucial for ensuring compliance with regulations and maintaining consumer trust.

Technologies and Standards

• FAPI (Financial-grade API): A set of security and privacy standards designed to protect sensitive financial data in APIs, developed by the OpenID Foundation. FAPI is built on OAuth 2.0 and OpenID Connect (OIDC), ensuring secure and private interactions between financial institutions and third parties.

• OpenID Connect (OIDC): An identity layer built on top of OAuth 2.0 that allows clients to verify the identity of end-users based on the authentication performed by an authorization server, as well as to obtain basic profile information about the user.

• SCA (Strong Customer Authentication): A regulation under PSD2 (Second Payment Services Directive) that requires multi-factor authentication for certain transactions, ensuring that the person initiating a transaction is the legitimate account holder.

• JWT (JSON Web Token): A compact, URL-safe token used to securely transmit information between parties as a JSON object. JWTs are often used in OAuth 2.0 for authorization and access tokens.

• JWS (JSON Web Signature): A standard for signing data (like a JWT) to ensure its integrity and authenticity. JWS is widely used in OAuth 2.0 to secure tokens and authorization requests.

• Claims: Pieces of information asserted about an entity (usually the resource owner), typically included in tokens like JWTs. For example, a claim might state the user's email address or roles.

• Token Revocation: The ability to invalidate tokens issued by the authorization server, ensuring that access can be immediately revoked if a token is compromised or no longer needed.

• Revocation Endpoint: A URL provided by the Authorization Server where clients can revoke tokens (both access and refresh tokens), terminating the session and access rights granted by that token.

• Token Introspection: A method by which a Resource Server can validate the metadata of an OAuth 2.0 token (e.g., its status, scopes, expiration) by querying the Authorization Server.

• Token Binding: A technique that ties tokens to a specific client, often using cryptographic methods, to prevent misuse if the token is intercepted or stolen.

• Consent Granularity: The ability to provide very fine-grained consent options to the data subject, allowing them to control exactly what data is shared and with whom.

• MTLS (Mutual TLS): A security protocol where both the client and server authenticate each other using TLS (Transport Layer Security) certificates. In open finance, MTLS is often used to secure communication channels between financial institutions and third-party providers.

• API Gateway: A server that acts as an entry point for API requests, handling tasks like request routing, rate limiting, authentication, and monitoring. It ensures secure and scalable API management in Open Finance ecosystems.

• OpenID Connect: An identity layer on top of OAuth 2.0 that allows clients to verify the identity of end-users based on the authentication performed by an authorization server. It is widely used in conjunction with OAuth 2.0 in Open Finance for secure identity verification.

• PSD2 (Second Payment Services Directive): An EU directive aimed at increasing competition and innovation in the financial services sector while enhancing the security of electronic payments and protecting consumers.

Security Practices and Protocols

• Encryption: The process of converting data into a code to prevent unauthorized access. Encryption is vital for protecting sensitive financial data shared through Open Finance APIs.

• Access Control: Mechanisms that ensure only authorized entities can access certain resources or data. This includes implementing roles, permissions, and access tokens within Open Finance APIs.

• Audit Logs: Records that capture detailed information about API requests, including who accessed what data, when, and why. Audit logs are essential for maintaining transparency and accountability in Open Finance.

External References

• FAPI 2.0 Security Profile, chapter 3
• OAuth2 Terminology Reference