Comparação de Páginas

The Payment Initiation Service of Open Finance Brazil implements the consent flow with redirection for payment authorization. This redirection can be carried out via redirect between applications or websites <> applications. CIBA provides an alternative for this flow where there's a decoupling of the process and the channel for the authorization can come from a push-notification, SMS, email, WhatsApp, etc.

Adhesion

After a regular redirection, the user, in an account holder with CIBA enabled, can adhere to this form of authorization when accepting consent.

Settlement

In the payment initiator's environment, the user can select the saved account and receive the authorization request via push-notification, SMS, email, WhatsApp, etc. The user must still authorize the consent for the payment to be successfully executed.

Guidelines for this option:

Payment initiators and account holders should consider the id_token, obtained in the FAPI Hybrid Flow, as user and account identification to be used at the endpoint to retrieve the payment authentication token.
The id_token must have a minimum expiration of 180 days.
Payment initiators should display, in the payment flow, the user and account data to be selected. This query can be done by fetching the data from the Payment Consent endpoint (GET /payments/v2/consents/{consentId}, data /data/debtorAccount/number).
Use the UX guide as a reference where there will be a checkbox for "save account for future transactions" (UX guide and figma link).
The id_token should be used in the authorization call through the "id_token_hint" parameter.
Only the "poll mode" will be used to obtain the token for sending the payment via the CIBA Backchannel Authentication Endpoint described in the account holder's well-known.
The id_token's cancellation can be carried out by the account holder in fraud cases or for security reasons.
The id_token's cancellation can be performed by the payment initiator in cases of fraud or for security reasons, by removing the id_token of the client in its database. Based on FAPI and OIDF protocols, only the removal of the id_token is enough to interrupt the use of the CIBA flow since, after removal, the payment initiator will not be able to reference the client.

Information and validations of an id_token

Information contained in an id_token

...

Parameters	Description	Recommended Values
alg	The "alg" (algorithm) parameter identifies the cryptographic algorithm used to secure 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 available for the algorithm associated with the entity that digitally signed the content.	PS256 or PS512
jku	The "jku" (JWK Set URL) parameter is a URI (RFC3986) that points to a resource for a set of public keys encoded in JSON, one of which matches the key used to digitally sign the JWS. The keys MUST be encoded as a JWK Set. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the JWK Set MUST use Transport Layer Security (TLS); and the server's identity MUST be validated, according to Section 6 of RFC6125. (OPTIONAL)
jwk	The "jwk" (JSON Web Key) parameter is the public key that matches the key used to digitally sign the JWS. This key is represented as a JWK. (OPTIONAL)
kid	The "kid" (Key ID) parameter indicates which key was used to secure 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 matches a "kid" parameter value of the JWK. (OPTIONAL)
x5u	The "x5u" (X.509 URL) parameter is a URI (RFC3986) pointing to a resource for the X.509 public key certificate or certificate chain (RFC5280) corresponding to the key used to digitally sign the JWS. (OPTIONAL)
x5c	The "x5c" (X.509 Certificate Chain) parameter contains the X.509 public key certificate or certificate chain (RFC5280) corresponding to the key used to digitally sign the JWS. (OPTIONAL)
x5t	The "x5t" (X.509 Certificate SHA-1 Thumbprint) is a base64url encoded SHA-1 thumbprint (hash) of the DER encoding of the X.509 certificate (RFC5280) corresponding to the key used to digitally sign the JWS. (OPTIONAL)
x5t#S256	The "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) is a base64url encoded SHA-256 thumbprint (hash) of the DER encoding of the X.509 certificate (RFC5280) corresponding to the key used to digitally sign the JWS. It can be used alternatively to "x5t". (OPTIONAL)
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 can be present in an application data structure that might contain a JWS; the application can use this value to disambiguate between the different types of objects that could be present. (OPTIONAL)	JWT
cty	The "cty" (Content Type) parameter is used by JWS applications to declare the media type (IANA.MediaTypes) of the secured content (payload). It is intended for use by the application when multiple types of objects might be present in the JWS Payload; the application can use this value to disambiguate between the different types of objects that could be present.	use “example” instead “application/example”
crit	The "crit" (Critical) parameter indicates that extensions to this specification and/or [JWA] are being used and MUST be understood and processed. Its value is an array containing the names of the Header Parameters present in the JOSE Header that are using these extensions.

Step by step to save an id_token

Informações
Remember, the flow for generating an id_token is a regular FAPI Hybrid-Flow consent! The Payment Initiator should save the id_token that comes in the redirection back from the holder via query parameters.

Follow the steps of the Sequence Diagram of a Payment Initiation via Hybrid-Flow.
At the stage of receiving the code, state, id_token on the redirectURL (redirection back from the holder to the initiator), the initiator must save the id_token that also comes in the URL's parameters. Pay attention to item 4 of the sequence diagram link above.
Execute the payment as usual because only in the next payment will it be possible to use the CIBA channel to communicate with the client to authorize a consent.

Step by step for a Payment Initiation with the saved id_token

Create a phase 3 consent for standard Payment Initiation.
Receive a response from the creation of the consent with AWAITING_AUTHORISATION status.
Request the CIBA Backchannel Authentication Endpoint for consent authorization, check the payload below:

...

The account holder (detentora) must validate the id_token according to the tables referenced above.

Error table “HTTP 400 Bad Request”:

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.
invalid_scope: The requested scope is invalid, unknown, or malformed.
expired_id_token_hint: The id_token hint provided in the authentication request is not valid because it has expired.
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).
unauthorized_client: The Client is not authorized to use this authentication flow.
invalid_id_token_hint: The id_token is invalid and can’t be used in the flow.

...

Bloco de código

HTTP/1.1 403 Forbidden
Content-Type: application/json
{
    1. "error": "authorization_pending",
    2. "error_description": "The user has not yet been authenticated, and the authorization request is still pending."
}

List of possible errors:

Error Code	Error Description
authorization_pending	The user has not yet been authenticated, and the authorization request is still pending
slow_down	The authorization request is still pending, and the client must increase the interval for polling requests by at least x seconds
expired_token	The transaction (auth_req_id) has expired. The client must start over with a new Authentication Request
access_denied	The user did not consent to the authorization request

...

Continue with the payment initiation process and make calls to the payment API, if access is successfully granted.

CIBA flow sequence diagram

...

Versões comparadas

Versão antiga 8

Nova versão Atual

Chave

Option 1: Payment Initiation using an Identification Token (id_token) in the Initiator