Versões comparadas

Chave

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

...

  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 "cpf" as defined in clause 5.2.2.2 of [FAPI-BR]

  4. shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 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-BR

  6. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.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. The id_token shall have a minimum expiration of 180 daysshall 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;1

  18. shall not support CIBA push mode;

  19. shall not support CIBA ping mode;

  20. The "poll mode" shall be the only mode used to obtain a token for the payment sending via the bc-authorize endpoint.

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

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

  23. shall 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;

  24. Payload validation

Parameters

Validation

iss

- The Authorization Server must establish an identifier, or set of standard "iss" identifiers for use in CIBA transactions. - The Authorization Server should not accept "iss" different from its own identifier, or set of identifiers, standard.

sub

- The Authorization Server should check if the "sub" identifier in question has already been issued to a client/account, and if it is valid within its requirements.

aud

- The Authorization Server should not accept "aud" different from the client_id from where the authorization request for the CIBA flow originates.

exp

- "exp" should be established according to the risk policies of the Account Holder institution, provided that requirement 5.2.2.15 is respected (minimum of 180 days) - The Authorization Server should not accept authorization requests whose date/time is greater than "exp".

iat

- No specific validations

auth_time

- No specific validations

nonce

- No specific AS validations

acr

- If present, the AS should only accept values equal to or above the Holder's authentication requirements to authorize payment transactions.

amr

- If present, the AS should only accept values equal to or better than the Holder's authentication requirements to authorize payment transactions.

azp

- The Authorization Server should not accept "azp" different from the client_id from where the authorization request for the CIBA flow originates.

...