Comparação de Páginas

...

1. shall support a signed and encrypted JWE request object passed by value or shall require pushed authorization requests PAR;

2. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in OIDD and [RFC8414] (".well-known");

3. shall support the claims parameter as defined in clause 5.5 OpenID Connect Core;

4. shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 "sub" Claim clarifications of this document;

5. shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 Requesting the "cpf" Claim of this document if the institution provides accounts for legal person;

6. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 Requesting the "cnpj" Claim of this document;

7. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 Requesting the "cnpj" Claim of this document;

8. shall implement the userinfo endpoint as defined in clause 5.3 OpenID Connect Core;

9. shall support parameterized OAuth 2.0 resource scope consent as defined in clause 6.3.1 OIDF FAPI WG Lodging Intent Pattern;

10. may support Financial-grade API: Client Initiated Backchannel Authentication Profile;

11. (withdrawn temporarily);

12. shall support refresh tokens;

13. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds;

14. shall always include an acr claim in the id_token;

15. shall support the response_type value code id_token;

16. may support response_type value code in conjunction with the response_mode value jwt;

17. should offer the possibility to disable the rotation of refresh token;

18. 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;

19. 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;

    1. shall keep in your settings the methods for which there are still active clients;

    2. shall update the records that use non-certified methods, through bilateral treatment between the institutions involved;

20. shall refuse requests, for the Open Finance environment, that are outside the modes of operation to which the institution has certified its Authorization Server;

21. must refuse authentication requests that include an id_token_hint, as the id_token held by the requester may contain Personally Identifiable Information, which could be sent unencrypted by the public client;

22. the minimum expiration time of request_uri must be 60 seconds;

23. shall deny all requests without header x-fapi-interaction-id on FAPI endpoints;

...

1. should not return sensitive PII in the ID Token in the authorization response, but if it needs to, then it shall encrypt the ID Token;

2. Personally Identifiable Information may include, but is not limited to,:

   1. Claim sub if you use information that makes it possible to identify the natural person;

   2. The default Claims defined in clause 5.1 OIDC, which may contain data such as date of birth, address or telephone;

   3. The new Claim CPF, defined in the next section.

3. If a Claim containing Personally Identifiable Information is requested:

   1. If this is marked as essential, if there is no encryption key registered for the Customer, the request must fail if requested at the Authorization Endpoint. There are no impediments if the request is made by the Confidential Client through the Token Endpoint;

   2. If this is not marked as essential, the Authorization Server must omit it on the Authorization Endpoint, and it can be answered on the Token Endpoint called by the Confidential Client.

      Âncora
      clarifications clarifications

4. For the encryption of the id_token, a key available in the JWKS informed in the jwks_uri parameter during the client registration must be used, indicated through the kid header of the JWT document;

5. 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.

"sub" Claim clarifications

Âncora
cpf cpf

This profile uses the official openId definition found at: Analise requisitos de criptografia ID_TOKEN. 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.

...

If the cpf Claim is requested as an Essential Claim for the ID Token or UserInfo response, the Authorization Server shall return a cpf Claim Value with the authenticated user cpf value.

If this is an Essential Claim and the requirement cannot be met or is not compatible with the one requested, then the Authorization Server shall treat that outcome as a failed authentication attempt.

...

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.

...