Page Comparison

Table of Contents

maxLevel	2

...

This document is based on the OpenID Foundations Financial API Read+Write specification document which in turn is based on the Read only specification document. The OpenBanking profile will further shape these two base profiles in some cases tightening restrictions and in others loosening requirements using key words

5.2 OB API Security Provisions

5.2.1 Introduction

Open Banking's API Profile does not distinguish between the security requirements from a technical level between "read" and "write" resources. The security requirements for accessing PSU resources held at ASPSPs requires more protection level than a basic RFC6749 supports.

As a profile of The OAuth 2.0 Authorization Framework, this document mandates the following to the OpenBanking Financial APIs.

5.2.2 Authorization Server

The Authorization Server

shall support confidential clients;
shall not support public clients;
shall support user authentication at appropriate level as defined in PSD2 be that LoA 3 or 2 or other.
shall require the response_type values code or code id_token or code id_token token;
shall authenticate the confidential client at the Token Endpoint using one of the following methods:
1. TLS mutual authentication [MTLS] https://tools.ietf.org/id/draft-ietf-oauth-mtls-02.xml; or (Recommended)
2. client_secret_basic or client_secret_post provided the client identifier matches the client identifier bound to the underlying mutually authenticated TLS transport session; or (Allowed)
3. JWS Client Assertion using the client_secret or a private key as specified in section 9 of [OIDC]; (Recommended)
shall issue an ID Token in the token response when openid was included in the requested scope as in Section 3.1.3.3 of OIDC with its sub value corresponding to the "Intent Ticket ID" and optional acr value in ID Token.
may support refresh tokens.

...

shall issue an ID Token in the token response when openid was included in the requested scope as in Section 3.1.3.3 of [OIDC] with its sub value corresponding to the authenticated user and mandatory acr value in ID Token.
must support Request Objects passed by value as in clause 6.3 of OIDC.

5.2.3 Public Client

OpenBanking OPs can support Public Clients at their discretion.

...

shall request user authentication at appropriate level as defined in PSD2 be that LoA 3 or 2 or other.

5.2.4 Confidential Client

A Confidential Client

may use separate and distinct Redirect URI for each Authorization Server that it talks to;
shall support the following methods to authenticate against the Token Endpoint:
- TLS mutual authentication [MTLS]; or
- JWS Client Assertion using the client_secret or a private key as specified in section 9 of [OIDC]; or
- client_secret_basic or client_secret_post provided the client identifier matches the client identifier bound to the underlying mutually authenticated TLS transport session
shall accept signed ID Tokens;

6. Accessing Protected Resources

6.2 Access provisions

6.2.1 Protected resources provisions

The resource server with the FAPI endpoints

shall mandate mutually authenticated TLS 1.2 or later as defined in RFC5246 with the usage following the best practice in RFC7525;
shall verify that the client identifier bound to the underlying mutually authenticated TLS transport session matches the client that the access token was issued to;

6.3 Client provisions

The confidential client supporting this document

...

may supply the customers authentication context reference (ACR) or applicable in the x-fapi-customer-acr header, e.g., x-fapi-customer-acr;

7. Request object endpoint

7.1 Introduction

OPs may not support request_uri, OIDC Request Object by Reference.
OPs must support Request Objects passed by value as in clause 6.3 of OIDC.

8. Security Considerations

8.1 TLS Considerations

Since confidential information is being exchanged, all interactions shall be encrypted with TLS/SSL (HTTPS) in accordance with the recommendations in RFC7525. TLS version 1.2 or later shall be used for all communications.

8.2 Message source authentication failure and message integrity protection failure

It is not mandated that the Authorization request and response are authenticated. Use of request object for the Authorization request and returning an ID token in the Authorization response should be considered to provide message source authentication and integrity protection.

8.3 Message containment failure

8.3.1 Authorization request and response

In this document, the authorization request is not encrypted. Thus, it is possible to leak the information contained if the browser was infected with virus, etc.

...

It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are compromised. Strict access control to the logs in such cases should be enforced.

8.3.2 Token request and response

It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are compromised. Strict access control to the logs in such cases should be enforced.

8.3.3 Resource request and response

Care should be taken so that the sensitive data will not be leaked through the referrer.

...

1. The PISP can query for the status of a Payment-Submission by invoking the /payment-submissions using the known PaymentSubmissionId. This can use an existing access token with payments scope or the PISP can obtain a fresh access token by replaying the client credentials grant request as per Step 2 - Setup Single Payment Initiation.

Request: payment-submissions/{PaymentSubmissionId}

Response: payment-submissions

Code Block

theme	Midnight

GET /payment-submissions/58923-001 HTTP/1.1
Authorization: Bearer SlAV32hkKG
x-fapi-financial-id: OB/2017/001
x-fapi-customer-last-logged-time: 2017-06-13T11:36:09
x-fapi-customer-ip-address: 104.25.212.99
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
Accept: application/json