Comparação de Páginas

...

1. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in OIDD and [RFC8414]

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

3. shall support the oidc standard claim "cpfacr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.2 4 of [ FAPI-BR]shall

4. should support the oidc standard claim "cnpjacr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.3 4 of [FAPI-BR] if providing access to resources where the resource owner is not a natural person]]

5. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of FAPI-BRshould support the acr "urn:brasil:openbanking:loa3" implement the userinfo endpoint as defined in clause 5.3 OpenID Connect Core

6. shall support parameterized OAuth 2.0 resource scope consent as defined in clause 56.2.2.4 of [FAPI-BR]]

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. shall support refresh tokens

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

11. shall always include an acr claim in the id_token

12. shall require the Signed Authentication Request to contain nbf and exp claims that limit the lifetime of the request to no more than 10 minutes

13. shall issue ciba auth request acknowledgements with a minimum expiry of 6 minutes;

14. The acceptance time of consent on the Authorization request received via CIBA shall remain the same as defined for the flow via Hybrid Flow, of 5 minutes;

15. shall ensure that ‘exp’ in all issued id_tokens is at least 180 days from the time of issue;

16. The id_token shall be used in the authorization call through the "id_token_hint" parameter

17. shall support CIBA poll mode;

18. shall not support CIBA push mode;

19. shall not support CIBA ping mode;

20. The cancellation of the id_token shall be carried out by the account holder institution in cases 3.1 OIDF FAPI WG Lodging Intent Pattern

21. shall support refresh tokens

22. The acceptance time of consent on the Authorization request received via CIBA shall remain the same as defined for the flow via Hybrid Flow, of 5 minutes;

23. shall ensure that ‘exp’ in all issued id_tokens is at least 180 days from the time of issue;

24. The id_token shall be used in the authorization call through the "id_token_hint" parameter

25. shall support CIBA poll mode;

26. shall not support CIBA push mode;

27. shall not support CIBA ping mode;

28. The cancellation of the id_token shall be carried out by the account holder institution in cases of fraud or for security reasons.

    1. is going to be added – The routine rotation of signing keys of id tokens SHALL NOT BE a reason to reject a non-expired id token signed with the older key. The authorization server should be prepared to use signing keys with similar validity periods to the ones of the id token.

29. Error table “HTTP 400 Bad Request”:

    1. invalid_request: The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, contains more than one of the hints, or is otherwise malformed.

    2. invalid_scope: The requested scope is invalid, unknown, or malformed.

    3. expired_id_token_hint: The id_token hint provided in the authentication request is not valid because it has expired.

    4. unknown_user_id: The OpenID Provider is not able to identify which end-user the Client wishes to be authenticated by means of the hint provided in the request (id_token_hint).

    5. unauthorized_client: The Client is not authorized to use this authentication flow.

    6. invalid_id_token_hint: The id_token is invalid and can’t be used in the flow

30. Shall issue ciba auth request acknowledgements (response of the consultation of auth_req_id) with a maximum expiry of 5 minutes, as defined for the flow via Hybrid Flow;

31. Payload validation

...

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

2. shall support refresh tokens

5.2.3.1.1. Authorisation Server Generated - Login Hint Token

This login hint can be used where it is not possible for the Resource Owner to provide a Login Hint to the Consumption Device or where the Resource Owner wishes to claim the authentication request by independently reaching out to the Authorisation Server out of band to claim this authentication request.

urn:brasil:openbanking:ciba:login-hint-token-type:as-generated

The use of a binding message is mandatory if this token type is to be leveraged.

5.2.3.1.1.1. Authorisation Server Generated - Login Hint Presentation

Presentation of the Authorisation Server Generated Token must be in the format of a JWE displayed as a QR Code with the following properties in the following way.

JWS Creation

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

• aud the Authorization Servers advertised issuer as per OIDD;

• iss the receiver of the message shall validate if the value of the iss field matches the clientId of the sender;

• jti the value of the jti field shall be filled with the UUID defined by the institution according to [RFC4122] version 4;

• iat the iat field shall be filled with the message generation time and according to the standard established in RFC7519 to the NumericDate format.

• *exp the exp field shall be filled with the message expiry time and according to the standard established in RFC7519 to the NumericDate format with an maximum value not greater than 5 minutes;

• auth_request_id the authentication request id returned from the Authorisation Server CIBA requst.

2. 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 listed on the software statement keystore on the Open Finance Brasil Directory of Participants;

   • typ - shall be filled with the value cibabr+jwt.

JWE Creation

1. The JOSE header must contain the following attributes:

   • alg - shall be filled with the value RSA-OAEP";

   • enc - shall be filled with the value A256GCM";

   • kid - shall be filled with the encryption key identifier kid value used to encrypt the JWE with the encryption key advertised on the authorisation servers jwks endpoint;

   • cty - shall be filled with the value JWT.

5.2.4.1.2. Authentication Device Generated - Login Hint Token

This login hint token should be used when Client has requested a unique identifier be provided by the Resource Owner to the Consumption Device. It is recommended that this identifier be dynamic, time based, have sufficient entropy and short lived to prevent replay attacks.

{ "format": "urn:brasil:openbanking:ciba:login-hint-token-type:ad-generated", "id": "11112222333344445555" }

The use of a binding message is mandatory if this token type is to be leveraged.

5.2.4.1.2. Authentication Device Generated - Login Hint Token

This login hint token should be used when Client has requested a unique identifier be provided by the Resource Owner to the Consumption Device. It is recommended that this identifier be dynamic, time based, have sufficient entropy and short lived to prevent replay attacks.

{ "format": "urn:brasil:openbanking:ciba:login-hint-token-type:ad-generated", "id": "11112222333344445555" }

...

6. Security considerations

...