Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

  1. shall perform client authentication using private_key_jwt;

  2. shall require requests of the type "pushed authorization requests" PAR;

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

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

  5. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause Requesting the "cnpj" Claim of this documentsection 5.2.2.3;

  6. should support the acr "urn:brasil:openbanking:loa3" as defined in clause Requesting the "cnpj" Claim of this documentsection 5.2.2.3;

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

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

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

  10. (withdrawn temporarily);

  11. shall support refresh tokens;

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

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

  14. shall support the response_type value code id_token;

  15. should offer the possibility to disable the rotation of shall not allow refresh token rotation;

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

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

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

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

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

  21. must require the use of Proof Key for Code Exchange (PKCE);

  22. must require the use of subject_type “public”;

  23. must require the use of response_mode “fragment”;

...

  1. Must encrypt the id_token returned by authorization endpoint before sending it to the customer; The id_token returned by token endpoint must be returned without encryption;

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

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

...

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

...

  1. shall support encrypted request objects;

  2. shall support Pushed Authorisation Requests PAR;shall use encrypted request objects if not using PAR;

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

  4. shall support refresh tokens;

  5. shall not populate the acr claim with required values;

  6. shall require the acr claim as an essential claim;

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

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

  9. shall send header x-fapi-interaction-id on FAPI endpoints;

...