Versões comparadas

Versão antiga 13

changes.mady.by.user Renan Amorim Costa

Gravado em

comparado com

Nova versão 14

changes.mady.by.user Renan Amorim Costa

Gravado em

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 acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of FAPI-BR

  4. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of [FAPI-BR]]

  5. shall 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 6.3.1 OIDF FAPI WG Lodging Intent Pattern

  7. shall support refresh tokens

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

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

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

  11. shall support CIBA poll mode;

  12. shall not support CIBA push mode;

  13. shall not support CIBA ping mode;

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

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

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

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

  1. Parameters for signature validation

Parameters

Description

Condition

Recommended values

alg

The "alg" (algorithm) parameter identifies the cryptographic algorithm used to protect the JWS/JWE. The JWS Signature value is invalid if the "alg" value does not represent a supported algorithm or if there is no compatible key for the use of the algorithm associated with the entity that digitally signed the content.

Required

PS256 or PS512

kid

The "kid" (Key ID) parameter indicates which key was used to protect the JWS/JWE. This parameter allows senders to explicitly signal a key change to recipients. The "kid" value MUST be a case-sensitive string. When used with a JWK, the "kid" value is used to match a "kid" parameter value of the JWK.

Required

x5t | x5t#S256

The "x5t" or “x5t#S256” (X.509 Certificate SHA-1/SHA-256 Thumbprint) parameter is a base64url encoded SHA-1/SHA-256 thumbprint (hash) of the DER encoding of the X.509 certificate (RFC5280) corresponding to the key used to digitally sign the JWS.

Required

typ

The "typ" (Type) parameter is used by JWS applications to declare the media type (IANA.MediaTypes) of this complete JWS. It is intended for use by the application when more than one type of object may be present in an application data structure that can contain a JWS; the application can use this value to eliminate ambiguity between the different types of objects that may be present.

Optional

JWT

5.2.3. Confidential client

...