Comparação de Páginas

Foreword

Este documento também está disponível em português:

[PT] Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3

The Open Finance Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Finance Legislation as originally outlined by the Brasil Central Bank. There is a possibility that some of the elements of this document may be the subject to patent rights. OFBIS shall not be held responsible for identifying any or all such patent rights.

Open Finance Brasil Financial-grade API Security Profile 1.0 consists of the following parts:

• Open Finance Brasil Financial-grade API Security Profile 1.0

• Open Banking Brasil Dynamic Client Registration Profile 1.0

These parts are intended to be used with RFC6749, RFC6750, RFC7636, OIDC, FAPI-1-Baseline and FAPI-1-Advanced

...

"sub" Claim clarifications

This profile uses the official openId definition found at: https://github.com/OpenBanking-Brasil/specs-seguranca/tree/main/idtoken_review . This means the sub is a never reassigned identifier for the end user. The value for a given user should never change within an institution, even across diferents consents.

Requesting the "cpf" Claim

...

1. JWS standad defined in RFC7515 shall be adopted to ensure integrity and non-repudiation of information processed in sensitive API's (message sign requirement is indicated at API's documentation/swagger), which includes:

   • Header (JSON Object Signing and Encryption - JOSE Header), which defines the algorithm used and includes information about the public key or certificate that can be used to validate the signature;

   • Payload (JWS Payload): content itself as detailed in the API specification;

   • Digital signature (JWS Signature): digital signature, performed according to header parameters.

2. Each of elements above must be encoded using the Base64url pattern RFC4648 and the elements must be concatenated with "." (JWS Compact Serialization method as defined in RFC7515).

3. The payload of signed messages (request JWT and response JWT) shall include the following claims as defined at RFC7519:

   • aud (in the JWT request): the Resource Provider (eg the institution holding the account) must validate if the value of the aud field matches the endpoint being triggered;

   • aud (in JWT response): the API client (eg initiating institution) shall validate if the value of the aud field matches its own organisationId listed in the directory;

   • iss (in the JWT request and in the JWT response): the receiver of the message shall validate if the value of the iss field matches the organisationId of the sender;

   • jti (in the JWT request and in the JWT response): the value of the jti field shall be filled with the UUID defined by the institution according to [RFC4122] version 4;

   • iat (in the JWT request and in the JWT response): the iat field shall be filled with the message generation time and according to the standard established in RFC7519 to the NumericDate format.

   • cty (in the JWT request and in the JWT response): the cty field shall be filled in the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter is not recommended. In the case that nested signing or encryption is employed, this Header Parameter must be present; in this case, the value must be "JWT", to indicate that a Nested JWT is carried in this JWT. While media type names are not case sensitive, it is recommended that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations.

4. The HTTP content-type of requests and responses with JWS messages shall be defined as: "application/jwt".

5. The JOSE header must contain the following attributes:

   • alg - shall be filled with the value PS256";

   • kid - shall be filled with the key identifier value used for the signature;

   • typ - shall be filled with the value JWT.

...

1. The receiver shall validate the consistency of the JWS message's digital signature exclusively based on the information obtained from the directory, that is, based on the keys published in the institution's JWKS in the directory.

2. Signatures must be performed using the digital signature certificate specified in the Open Finance Brazil Certificates Standard;

3. the iat claim must be numeric in Unix Time format GMT+0 with a tolerance of +/- 60 seconds;

4. the jti claim must be unique for a clientId within a time frame of 86,400 seconds (24h), and cannot be reused within this period. In case of reuse, the HTTP error code 403 shall be return. Any other case must follow RFC 6749 instructions in item 5.2.

...