Wireframe ref | Type | Requirement level | Statement | Reference | Checklist ref | Focus area |
|---|---|---|---|---|---|---|
01 | Common Standard | MUST | Where Redirect to App is unable to be used for the purposes of CDR authentication, and Decoupled Authentication is not supported, data holders MUST continue to support the 'Redirect to Web with OTP' flow in accordance with the relevant consumer experience authentication and security profile standards. | Authentication Schedule Standard, Fallback Authentication Flows | 2AU0.00.01 | |
02 | Common Standard | MUST | If a data holder provides an app, the data holder MUST implement Redirect to App in accordance with the relevant consumer experience authentication and security profile standards. Data holders MAY implement Redirect to App ahead of the date specified in the Future Dated Obligations schedule. Note: As per the future dated obligation schedule, data holders subject to this standard are required to implement Redirect to App on and from 10 May 2027. | 2AU0.00.02 | ||
03 | Common Standard | MUST | Data recipients MUST implement Redirect to App in accordance with the relevant consumer experience authentication and security profile standards. Data recipients MAY implement Redirect to App ahead of the date specified in the Future Dated Obligations schedule. Note: As per the future dated obligation schedule, data recipients subject to this standard are required to implement Redirect to App on and from 10 May 2027. | 2AU0.00.03 | ||
04 | Common Standard | MAY | Where Redirect to App is unable to be used for the purposes of CDR authentication: • Data recipients MAY provide decoupled consent experiences that facilitate separation of the Consumption Device from the authorisation flow. • Data holders MAY provide decoupled authorisation experiences that facilitate separation of the Consumption Device from the Authentication Device. If implemented, data holders and data recipients MUST support decoupled authentication in accordance with any relevant consumer experience authentication and security profile standards. | 2AU0.00.04 | ||
05 | CX Standard | MUST NOT | Where a data holder implements Redirect to App, the authentication flow and method MUST NOT involve more steps than the consumer would reasonably encounter when logging in to the data holder’s app for non-CDR purposes, unless otherwise specified in the data standards. | Authentication Standards, Redirect to App, Authentication: Steps | 2AU0.00.05 | |
06 | Technical Standard | MUST | Data holders MUST support Redirect to App in accordance with the Authentication Schedule, and: • Data holders MUST use a single issuer identifier per app. • Data holders MUST only support Authorization Code Flow for Redirect to App authentication. • Data holders MUST support Claimed "https" Scheme URI redirection in accordance with section 7.2 and section 8 of [RFC8252]. • After authentication, the data holder MUST continue the authorisation flow within the data holder app. • Data holders SHOULD implement additional controls to minimise the risk of enumeration attacks via the redirect page. | Security Profile, Authentication Flows, Redirect to App, Data Holders | 2AU0.00.06 | |
07 | Technical Standard | MUST NOT | The following credential constraints apply such that Authenticators: • MUST NOT permit Memorised Secrets defined by [DigitalID-Accreditation] to achieve 'LoA 2' (as a single factor of authentication only). | Security Profile, Credential Requirements, Restricted Credentials | 2AU0.00.07 | |
08 | Technical Standard | MUST | A Single LoA value is carried in the acr claim which is described in section 2 of [OIDC].
• An LoA of 2 is represented by the URI: | Security Profile, Levels of Assurance (LoAs), Single Ordinal | 2AU0.00.08 | |
09 | CX Standard | MUST | When the authorisation flow is presented to the consumer in a data holder app, the data holder MUST provide consumers with the ability to switch or add user profiles based on the profiles supported by that app. | Authorisation Standards, Authorisation: Add or Switch Profiles | 2AU0.00.09 | |
10 | CX Standard | MAY | Data holders MAY add a 'profile selection' step or equivalent prior to the account selection step if a single identifier provides access to different customer accounts. For example, one customer ID may give access to business customer and individual customer accounts. The 'profile selection' step SHOULD only be considered if it is an existing customer experience, and SHOULD be as minimal as possible to avoid introducing unwarranted friction (having regard to CDR Rule 4.24). | 2AU0.00.10 | ||
11 | CX Standard | MUST | Data holders and data recipients MUST state in consumer-facing interactions and communications that third parties do not need consumer passwords to access CDR data. The exact phrasing of this is at the discretion of the data holder and data recipient. Note: In this context, 'third parties' refers to entities on the ADR-side and does not include any third parties that the data holder may engage. | Authentication Standards, Common Authentication Standards, Authentication: Passwords | 2AU0.00.11 | |
12 | Technical Standard | MUST | Data recipients MUST support Redirect to App in accordance with the Authentication Schedule, and: • Data recipients MUST register separate Redirect URIs where they provide both app-based and web-based redirection. • If data recipients initiate consent from an app, they MUST support Claimed "https" Scheme URI redirection in accordance with section 7.2 and section 8 of [RFC8252] for their app Redirect URI. | Security Profile, Authentication Flows, Redirect to App, Data Recipient | 2AU0.00.12 | |
13 | CX Standard | MUST NOT | Data holders MUST NOT introduce unwarranted friction into the authentication process. In line with CDR Rule 4.24 on restrictions when asking CDR consumers to authorise disclosure of CDR data, unwarranted friction for authentication flows and methods is considered to include, but is not limited to: • The addition of any requirements beyond normal data holder practices for authenticating the consumer, including, but not limited to, One Time Password (OTP) verification code delivery. • Providing or requesting additional information beyond normal data holder practices for authenticating the consumer including, but not limited to, OTP verification code delivery. • Offering additional or alternative services. • Referencing or including other documents. | Authentication Standards, Common Authentication Standards, Authentication: Friction | 2AU0.00.13 | |
14 | CX Standard | MAY | Data holders MAY invite consumers using ‘Redirect to Web’ flows to install the data holder app used for the purposes of CDR authentication. This invitation MUST NOT introduce unwarranted friction. | Authentication Standards, Common Authentication Standards, Authentication: App Install | 2AU0.00.14 | |
15 | CX Standard | MUST NOT | Data holders MUST NOT include forgotten details links in redirect screens. | Authentication Standards, Redirect to Web with OTP, Authentication: Password Link | 2AU0.00.15 | |
16 | Technical Standard | MUST | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • The data holder MUST request a user identifier in accordance with User Identifiers. • The data holder MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter into the redirected page. • The delivery mechanism for the OTP is at the discretion of the data holder, but MUST align to existing and preferred channels for the customer. • The data holder SHOULD implement additional controls to minimise the risk of interception of the OTP through the selected delivery mechanism. • The provided OTP MUST only be used for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions. • The provided OTP MUST be invalidated after a period of time at the discretion of the data holder. This expiry period SHOULD facilitate enough time for the customer to reasonably complete the authorisation process. • The provided OTP MUST be numeric digits and be between 4 and 6 digits in length. • The algorithm for the creation of the OTP is at the discretion of the data holder but SHOULD incorporate a level of pseudo-randomness appropriate for the use case. • The data holder SHOULD implement additional controls to minimise the risk of enumeration attacks via the redirect page. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU0.00.16 | |
17 | CX Standard | MUST | Data holders MUST communicate the expiry period of the OTP to the consumer in the authentication flow. | Authentication Standards, Redirect to Web with OTP, Authentication: OTP Expiry | 2AU0.00.17 | |
18 | CX Guideline | MAY | CDR Participants may choose to voluntarily implement Redirect to App before the future-dated obligation of 10 May 2027. If implemented prior to this date, they will also need to meet other relevant standards, including Fallback Authentication Flows, unless otherwise stated. | 2AU0.00.18 | ||
19 | CX Guideline | MAY | In line with existing practices, a data holder may provide functionality that allows a consumer to add, register, or switch profiles prior to, or after, authentication. | 2AU0.00.19 | ||
20 | CX Guideline | MAY | Where a consumer has not logged into the app before, or has been logged out, the data holder may require them to log in using a username and password as per their existing practices. Where this occurs, the data holder must still have regard for the standard that prohibits memorised secrets being relied upon as a single factor for the purposes of sharing CDR data. | Security Profile, Credential Requirements, Restricted Credentials | 2AU0.00.20 |