...
shall perform client authentication using private_key_jwt;
shall require requests of the type "pushed authorization requests" PAR;
shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in OIDD and [RFC8414] (".well-known");
shall support the claims parameter as defined in clause 5.5 OpenID Connect Core;
shall support the acr "urn:brasil:openbanking:loa2" as defined in clause Requesting the "cnpj" Claim of this documentsection 5.2.2.3;
should support the acr "urn:brasil:openbanking:loa3" as defined in clause Requesting the "cnpj" Claim of this documentsection 5.2.2.3;
shall implement the userinfo endpoint as defined in clause 5.3 OpenID Connect Core;
shall support parameterized OAuth 2.0 resource scope consent as defined in clause 6.3.1 OIDF FAPI WG Lodging Intent Pattern;
may support Financial-grade API: Client Initiated Backchannel Authentication Profile;
(withdrawn temporarily);
shall support refresh tokens;
shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds;
shall always include an acr claim in the id_token;
shall support the response_type value code id_token;
should offer the possibility to disable the rotation of shall not allow refresh token rotation;
shall ensure that, in case of sharing the Authorization Server for other services, in addition to Open Finance, it does not disclose and/or allow the use of non-certified methods in the Open Finance environment;
shall ensure that the settings disclosed to other participants through OpenID Discovery (indicated by the Well-Known file registered in the Directory) are restricted to the operating modes to which the institution has certified;
shall keep in your settings the methods for which there are still active clients;
shall update the records that use non-certified methods, through bilateral treatment between the institutions involved;
shall refuse requests, for the Open Finance environment, that are outside the modes of operation to which the institution has certified its Authorization Server;
the minimum expiration time of request_uri must be 60 seconds;
shall deny all requests without header x-fapi-interaction-id on FAPI protected resources endpoints;
must require the use of Proof Key for Code Exchange (PKCE);
must require the use of subject_type “public”;
must require the use of response_mode “fragment”;
...
“fragment”;
shall issue exclusively opaque refresh_tokens with no associated expiration date;
5.2.2.1. ID Token as detached signature
The Authorization Server shall support the provisions specified in clause 5.2.2.1 of Financial-grade API Security Profile 1.0 - Part 2: Advanced
Must Shall encrypt the id_token before sending it to the customerin callback and token endpoint calls;
For the encryption of the id_token, a key available in the JWKS informed in the jwks_uri parameter, with the attribute “use”:”enc”, during the client registration must be used, indicated through the kid header of the JWT document;
The use of other headers to indicate the key used, such as x5u, x5c, jku or jkw is prohibited as defined in clause 2 OIDC.
...
This profile uses the official definition found at: Analise requisitos de criptografia ID_TOKEN. This means that the sub is an identifier that is never transferred or changed to the end user within the Account Servicing Payment Service Provider (ASPSP).
5.2.2.
...
3. Requesting the "urn:brasil:openbanking:loa2" or "urn:brasil:openbanking:loa3" Authentication Context Request
This profile defines "urn:brasil:openbanking:loa2" and "urn:brasil:openbanking:loa3" as new Authentication Context Request (ACR) classes.
...
In accordance to Art. 17 of Joint Resolution nº 01 - Open Banking Brasil, institutions must adopt procedures and controls for client authentication compatible with those applicable in their electronic service channels.
In accorcdance accordance with the regulation, it is suggested that:
For Read-Only APIs (Phase 2): the Authorization Servers should adopt, at least, an authentication method compatible with LoA2; and
For Read-Write API's (subsequent phases): the Authorization Servers should adopt an authentication method compatible with LoA3 or higher.
...
To performe a MFA authentication is necessary that the end user presents at least two different methods as listed above. A unique method used more than once - ie. presenting passwords - is not accepted as MFA.
5.2.
...
A confidential client shall support the provisions specified in clause 2.4 Mandatory scopes on the well-known endpoint
The authorization server must declare the scopes below in its well-known endpoint, regardless of whether the institution provides the products related to the scopes listed below:
invoice-financings
financings
loans
unarranged-accounts-overdraft
bank-fixed-incomes
credit-fixed-incomes
variable-incomes
treasure-titles
funds
exchanges
The scopes not listed above must be declared if the institution provides products related to them
(i.e.: accounts, payments)
5.2.3. Confidential client
A confidential client shall support the provisions specified in clause 5.2.3 of Financial-grade API Security Profile 1.0 - Part 2: Advanced,
In addition, the confidential client
...
client
shall support Pushed Authorisation Requests PAR;shall use encrypted request objects if not using PAR;
shall support parameterized OAuth 2.0 resource scope consent as defined in clause 6.3.1 OIDF FAPI WG Lodging Intent Pattern;
shall support refresh tokens;
shall not populate the acr claim with required values;
shall require the acr claim as an essential claim;
shall support all authentication methods specified in clause 5.2.2-14 of Financial-grade API Security Profile 1.0 - Part 2: Advanced including diferent combinations of the methods to send requests (using PAR or not - item 11)not populate the acr claim with required values;
shall require the acr claim as an essential claim;
shall not allow refresh tokens rotation feature;should not request authentication requests that include an id_token_hint, as the id_token to be used may contain Personally Identifiable Information, which could be sent unencrypted through the public client;
shall send header x-fapi-interaction-id on FAPI endpoints;
...
6.1. Message Content Signing Considerations (JWS)
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.
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).
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.
The HTTP content-type of requests and responses with JWS messages shall be defined as: "application/jwt".
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.
In case of error in signature validation by Resource Provider the API provider shall return HTTP error message with status code 400 and the ResponseError content shall include, in the code property, the content BAD_SIGNATURE.
Errors in validating the signed messages received by the client application (eg payment initiator) must be logged and the Resource Provider (eg account holding institution) must be notified.
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.
Signatures must be performed using the digital signature certificate specified in the Open Finance Brazil Certificates Standard;
the iat claim must be numeric in Unix Time format GMT+0 with a tolerance of +/- 60 seconds;
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.
...
For JWS, both clients and Authorization Servers
shall use PS256 algorithm;
6.1.2. Encryption algorithm considerations
For JWE, both clients and Authorization Servers
shall use RSA-OAEP with A256GCM
6.1.3. Secure Use of Transport Layer Security considerations
...
string 'consent'; and
delimiter of a colon ":"; and
Consent API REST Resource Id as returned by a successful creation of Open Finance Consent Resource;
In addition:
the Consent Resource Id must include url safe characters only;
the Consent Resource Id must be namespaced;
the Consent Resource Id must have the properties of a nonce Nonce;
7.1.3. Dynamic Consent Scope Example
...