| Expand | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
| Table of Contents | ||||||||||||||
| minLevel | 1 | |||||||||||||
| maxLevel | 6 | |||||||||||||
| outline | false | |||||||||||||
| style | none | type | ||||||||||||
| Expand | ||||||||||||||
| ||||||||||||||
|
1. Overview
...
1.4 Prerequisites for Payments with Delegated Authentication
1.4.1 Liability Model
For the case of Payments with Delegated Authentication refer to With the Delegated Secure Customer Authentication (SCA) model, the TPP is responsible for securely authenticating the user using a SCA process for each payment initiation, leveraging a long-lived consent agreement established with the user, that also triggers the liability shift (see Limitation of Liability Model . TPPs are expected to be liable for disputes with Users in relation to unauthorized payments.)for the SCA activities from the LFI. Authentication factors are categorized based on:
Knowledge: Something only the user knows
Possession: Something only the user possesses
Inherence: Something unique to the user’s physical characteristics
1.4.2
...
With the Delegated Authentication model the TPP will be responsible for ensuring that the user is securely authenticated using a Multi-factor Authentication(MFA) process for each payment initiation using the Long lived consent setup with the User. These Authentication factors are based on the use of elements, which are categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is). Examples of these Authentication factors to be used may be the following:
User biometrics, dynamic tokens (using Authenticator apps Authy, Google Authenticator, and Microsoft Authenticator etc. or RFID), mobile phone, plastic card, and other User identification (e.g. Emirates ID).
While authenticating the User The TPPs could
...
have their own MFA process where they onboard Users and manage their own MFA
...
Examples of these authentication factors include:
User biometrics on a mobile device: such as fingerprint or facial recognition executed on the customer’s device, where a TPP app is also bound
Dynamic tokens on a mobile device: generated by authenticator apps (e.g., Authy, Google Authenticator, Microsoft Authenticator) on the customer’s device, where a TPP app is also bound
NFC-based trigger on a mobile device: used as a possession factor through Near Field Communication for secure, contactless verification, on the customer’s device, where a TPP app is bound and logged in
NFC based trigger on another IoT device: The device holds credentials that can be used to verify the User identity, provisioned in conjunction with a TPP service.
The TPP application MUST support biometric authentication and a secondary authentication method, such as a PIN. If biometric authentication fails or is unavailable for the user, the secondary authentication method MUST be provided as an alternative.
In this model, TPPs can choose from the following approaches to authenticate the user:
Implement their own SCA solution, managing user onboarding and authentication.
Leverage SCA solution provided by a recognized Identity Service Provider (ISP), such as UAEPass or biometrics on mobile devices, to authenticate and verify the user for each transaction.
The factors used by TPPs MUST be in alignment with the list of required evidence that will be listed in the liability model. For more details on Multi-factor Authentication SCA please refer to Strong Customer Authentication Guidelines
...
# | Step | Rules & Guidelines |
|---|---|---|
MPCS-1 | Consent setup | Basic Consent Parameters TPPs MUST: 1.1 Enable Users to provide and review the parameters related to the initiation of a series of Multi-Payments they need to consent to. These parameters include:
|
Additional Consent Parameters 1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#7.-Is-Single-Authorization-flag ). 1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent. 1.4 Set the Risk Information Block (as perhttps://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
1.5 Enable Users to provide explicit consent for the initiation of future Payments from their online payment account held at their LFI as specified in the consent. | ||
Balance Check Permission 1.6 Request permission to check the balance of the payment account before initiating a payment. https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/edit-v2/210799644#4.-Balance-Check | ||
MPCS-2 | Consent Staging | |
MPCS-3 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and authorize your payments setup“. |
MPCS-4 | Authentication | LFI Authentication Only As per the following sections: |
Centralized Authentication and Authorization (Federated) Only | ||
MPCS-5 | Authorization | LFIs MUST: 5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the long-lived payment Consent. 5.2 Retrieve from the OFP the payment Consent details staged by the TPP using the unique Consent Identifier. 5.3 Allow Users to select a payment account for the initiation of the payments, if this was not provided in the retrieved staged Payment Consent details as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
5.4 Only present additional screens, if necessary to allow the validation and confirmation of the payment Consent. 5.5 NOT earmark (i.e. block) any funds related to the payment Consent in the Users' payment account at the point of Consent authorization. 5.6 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. 5.7 Display to Users the TPP Trading Name of the TPP that initiated the long-lived payment Consent.
5.8 Present to Users the following minimum required information for authorizing the long-lived payments Consent:
5.9 Request for Balance Check Permission: If the TPP has requested permission to check the balance of the User’s payment account. 5.10 Change the state of the payment Consent from Awaiting Authorization to Authorized when all Authorizers (one or more) have authorized the payment Consent. 5.11 Update the payment Consent details stored in the OFP with all the information included in the payment Consent authorized by the User. |
OFP MUST: 5.12 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210800446/Common+Rules+and+Guidelines#19.-Check-Authorization-Time-Window. 5.13 Confirm back to the LFIs that the payment Consent details have been updated successfully. 5.14 Start tracking the Consent Control Parameters for the Control Period at the Control Period Start Date, if provided, or the Consent creation Date otherwise. The Control Period starts from 00:00:00 of the day and ends at 23:59:59 of the Control Period end day, calculated based on the Control Period type as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final/pages/210798542/Multi-Payments#6.3.2-VRP-Consent-Control-Period-%26-Start-Date. | ||
Multi-Authorization Journey Only | ||
MPCS-6 | Hand-off back to the TPP | |
MPCS-7 | Confirmation to User |
...