FAPI 2.0 Swiss Security Profile

Introduction

Financial-grade API (FAPI) is an API security profile based on the OAuth 2.0 framework suitable for protecting APIs in medium- and high-value scenarios. FAPI 2.0 Security Profile, and the underlying specifications, leave a number of choices open to implementors, deployers and/or ecosystems. The FAPI 2.0 Security Profile explicitly states in Section 5.1.2 Profiling this document that specific profiles may be defined. On this basis, the Common API specifies a Swiss Security Profile with limited choices that may further enhance security or facilitate implementation or interoperability.

This document concludes the specific implementation of FAPI 2.0 for Open Finance use cases in Switzerland.

Notational Conventions

The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 ISO/IEC Directives, Part 2 - Principles and rules for the structure and drafting of ISO and IEC documents.

These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.

Normative References

• FAPI 2.0 Security Profile - draft, https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html

FAPI 2.0 requirements

With FAPI the OpenID Foundation standardizes secure access use cases between the 3 parties:

• FI (OAuth terminology: Resource Server)
• FI's customer (OAuth terminology: Resource Owner)
• TPP (OAuth terminology: Client)

The FI has to provide an authorization service with the following capabilities:

• OAuth 2.0 Authorization Framework [RFC6749]
• OAuth 2.0 Bearer Tokens [RFC6750]
• Proof Key for Code Exchange (PKCE) [RFC7636]
• OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens [RFC8705]
• OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449]
• OAuth 2.0 Pushed Authorization Requests (PAR) [RFC9126]
• OAuth 2.0 Authorization Server Metadata [RFC8414]
• OAuth 2.0 Authorization Server Issuer Identification [RFC8414]

Core components

In this section we give a short introduction to FAPI 2.0's core extensions and their purposes.

Pushed Authorization Requests (PAR)

Pushed Authorization Requests (PAR) improve the security of OAuth and OIDC flows by moving authorization parameters from the front-channel (redirect URL in the browser) to the back-channel (direct machine to machine https calls on the back-end).

See RFC9126 for more details.

Demonstrating Proof of Possession (DPoP)

The Demonstration of Proof-of-Possession (DPoP) is a mechanism that supports sender constraint token. It gives you a way to tie an access token to the client who gets it. This means that the access token is no longer a bearer token, the client must provide a proof of possession in order to use the token.

The DPoP mechanism has been designed to be used in scenarios where stronger means of proof of possession cannot be used. For example, when the client is not able to utilize mutual TLS, such as Single Page Applications that do not have a back-end.

Additional components

Grant Management

Grant Management for OAuth 2.0 allows the Resource Owner to manage access permissions to their data on a specific Resource Server, which they have created using one or more consent flow

The Resource Owner creates authorisations (implicitly in the consent flow) and can then delete, replace or update them as required in a standardised way.

Rich Authorization Requests (RAR)

OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] is recommended when the scope parameter is not expressive enough to convey the authorization that a client wants to obtain, e.g. restricting the third-party application's access to only credit card transactions for a specific credit card (if several are available). This cannot be restricted with the OAuth 2.0 scope parameter.

The standard for Rich Authorization Requests (RAR) was developed based on this consideration. This defines an additional request parameter authorization_details by means of which extended information on authorization is transmitted and signed accordingly by the authorization server. The resource server can then use this information to perform a correspondingly fine-grained authorization.

In the context of FAPI 2.0 Swiss Profile the delivery method for RAR shall be PAR.

See RFC9396 for more details.

ℹ At the moment, there is no expressed urgent need to develop guidelines or specifications for the use of RAR.

FAPI Client Initiated Backchannel Authentication (CIBA)

FAPI Client Initiated Backchannel Authentication is recommended when support is required for decoupled or cross device flows. The RAR parameter authorization_details can be used instead of, or in addition to the scope parameter.

ℹ At the moment, there is no expressed urgent need to develop guidelines or specifications for the use of CIBA. If so, it should be included in the context of Strong Customer Authentication.

FAPI 2.0 Swiss Security Profile

Core components

The FAPI 2.0 Swiss Security Profile is based on the following standards and technologies:

Standard / technology	RFC	Implementation
OAuth 2.0 Authorization Framework	RFC6749	mandatory
OAuth 2.0 Bearer Token	RFC6750	mandatory
Proof Key for Code Exchange by OAuth Public Clients (PKCE)	RFC7636	mandatory
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (MTLS)	RFC8705	mandatory for SaaS clients
OAuth 2.0 Demonstrating Proof of Possession (DPoP)	RFC9449	mandatory for Offline TPPs, consumer devices, and other devices where the use of client certificates (for mTLS) is not a feasible option ℹ TO BE CHECKED: some of the above mentioned client types are public clients, e.g., Single Page Applications (SPA). FAPI 2.0 excludes public clients: How to cope with this fact?
OAuth 2.0 Pushed Authorization Requests (PAR)	RFC9126	mandatory
OAuth 2.0 Authorization Server Metadata	RFC8414	mandatory
OAuth 2.0 Authorization Server Issuer Identification	RFC9207	mandatory
OpenID Connect	OIDC	optional

• check whether or not OIDC should be an optional part of the Swiss profile
  ℹ It should be included as optional ✅
• check whether OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] is needed for SCA use cases, e.g., as a "container" for authorization details for CIBA requests
  ℹ it should also be allowed for the PAR preceding the authorization flow as an alternative to or as an addition to the standard OAuth2 request parameters (to be clarified).

Additional components

The Swiss Security Profile supports the following additional components (depending on the requirements of the API):

Standard / technology	RFC	Implementation
Grant Management for OAuth 2.0	Grant Management	mandatory
Rich Authorization Requests	RFC9396	optional, standardization by business API owner expected
FAPI 2.0 Message Signing	FAPI Message Signing	optional, standardization by SFTI or business API owner expected
FAPI Client Initiated Backchannel Authentication Profile	FAPI CIBA	optional

Additional Security Requirements

Additionally to the requirements based on the FAPI 2.0 Security Profile from OpenId the following requirements have to be met by Service Users and Service Providers as indicated:

Standard / technology	RFC	Implementation	Rationale
HTTP Strict Transport Security (HSTS)	RFC6797	mandatory	De-facto standard for websites
Domain Name System Security Extensions (DNSSEC)	RFC4033, RFC4034, RFC4035	mandatory	Broad support by hosters
DNS Certification Authority Authorization (CAA)	RFC8659	mandatory	Simple measure to reduce the risk of certificate spoofing

Deviations from the OpenID Security profile

In order to cover specific requirements and circumstances of the Swiss market, requirements from the OpenId Security Profile are adapted or supplemented accordingly.

Chapter 5. Profile

Section	Item	Change
Network Layer	5.2.1	DNSSEC and CAA shall both be implemented by Service Providers and Service Users
Profile	5.3.2	Ecosystems with a hub-and-spoke architecture may distribute discovery metadata (such as the authorization endpoint) via a directory. The directory shall be maintained by (or under the supervision of) the Registration Authority of the ecosystem. The directory must meet the network security requirements for Authorization Servers stated in 5.2.1. and 5.2.2 including the Network Layer deviations defined above. The token endpoint URL on the ecosystem's hub should be static (see Note1 below).

Note1: Attacker A4 from the Attacker Model (and consecutively attacker assumption A4 in the Formal Security Analysis of the OpenID FAPI 2.0) is not feasible for hub-and-spoke ecosystems where the server metadata is obtained from an authoritative source via a protected channel.

Security Considerations

Definition	Description	Existing examples	Proposal CH
Trust Decisions	MTLS ecosystems should provide the trust list of the certificate authorities.	eIDAS Qualified Trust Service Providers list	Governing bodies of ecosystems define trusted CAs
Signing and Encryption of requests/responses	Requests and responses are digitally signed and/or encrypted.	FAPI 2.0 Message Signing (draft)	Use FAPI Message Signing Profile
Cryptography and Secrets	Define list of accepted CAs, define list of accepted TLS cipher suites and signature algorithms, define access token parameter

Ressources

History of FAPI: https://medium.com/@hidebike712/fapi2-explained-8602e52596e5