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 | 2AU1.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. | 2AU1.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. | 2AU1.00.03 | ||
04 | 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 | 2AU1.00.04 | |
05 | 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 | 2AU1.00.05 | |
06 | 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 | 2AU1.00.06 | |
07 | 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 | 2AU1.00.07 | |
08 | 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 | 2AU1.00.08 | |
09 | 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). | 2AU1.00.09 | ||
10 | 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 | 2AU1.00.10 | |
11 | 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 | 2AU1.00.11 | |
12 | 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. | 2AU1.00.12 | ||
13 | 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. | 2AU1.00.13 | ||
14 | CX Guideline | MAY | Data holders may use alternative methods for authentication in accordance with the relevant standards for Consumer Experience Authentication and Security Profile. | 2AU1.00.14 | ||
15 | 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 | 2AU1.00.15 | |
16 | CX Guideline | MAY | In the instance a user installs a data holder app, or is logged out after a session, data holders are permitted to require users to log in with their user ID and password. This guideline should be considered in conjunction with the CX Standards for Common Authentication Standards. | 2AU1.00.16 | ||
17 | CX Guideline | MAY | Data holders should display the name of the brand receiving the consumer data request. This should match the specified brandName value on the register. | 2AU1.00.17 |