Wireframe ref | Type | Requirement level | Statement | Reference | Checklist ref | Focus area |
|---|---|---|---|---|---|---|
01 | CDR Rule | MUST | (8) For paragraph 56ED(7)(b) of the Act, the CDR entity must make its CDR policy readily available through each online service by means of which the CDR entity, or a CDR representative of the CDR entity, ordinarily deals with CDR consumers. | CDR Rule 7.2(8) | 2AU.00.01 | |
02 | 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 | CX Research 21 | 2AU.00.02 | |
05 | 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 | CX Research 12, 27 | 2AU.03.05 | |
06 | Technical Standard | SHOULD | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • The data holder SHOULD implement additional controls to minimise the risk of enumeration attacks via the redirect page. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.00.06 | |
07 | Technical Standard | MUST | If a data holder requests a user identifier for the purposes of identifying the customer during authentication, then the data holder: • MUST request a user identifier that can uniquely identify the customer. • MUST request a user identifier that is already known by the customer in the redirected page. | Security Profile, Credential Requirements, User Identifiers | 2AU.01.07 | |
08 | Technical Standard | MUST | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • 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. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | CX Research 12, 27 | 2AU.03.08 | |
10 | Technical Standard | MUST | Data Holders 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 | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.03.10 | |
11 | Technical Standard | SHOULD | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • 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. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.03.11 | |
12 | Technical Standard | MUST | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • The data holder SHOULD implement additional controls to minimise the risk of interception of the OTP through the selected delivery mechanism. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.03.12 | |
13 | Technical Standard | MUST | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • The provided OTP MUST be numeric digits and be between 4 and 6 digits in length. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.03.13 | |
14 | Technical Standard | SHOULD | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • 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. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.03.14 | |
15 | Technical Standard | MUST NOT | Where a data holder supports the ‘Redirect to Web with OTP’ flow: • 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. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | CDR Rule 4.24 | CX Research 12, 27 | 2AU.03.15 | |
16 | CX Guideline | MAY | Data holders should use the Brand Name of the data recipient wherever the data recipient is referenced in consumer-facing authentication processes, including cancellation screens and One Time Password (OTP) delivery. If the data recipient is not referenced in certain processes, such as the OTP message, data holders should not introduce the Brand Name for the purposes of this guideline. Data holders should not present the Software Product Name in relation to these processes. | 10 Usability Heuristics for User Interface Design: Match Between the System and the Real World (Nielsen) | 2AU.00.16 | |
17 | CX Guideline | MAY | Data holders should consider including their CDR policy in the authentication process as this will likely be the first online service the CDR consumer uses to interact with their data holder for the purposes of CDR. | 2AU.00.17 | ||
18 | CX Guideline | MAY | Data holders may choose to include relevant organisation credentials if it reflects existing authentication processes, such as their ABN. | 2AU.00.18 | ||
19 | CX Guideline | MAY | Data holders should include functionality that allows a consumer to request that a One Time Password be resent. | CX Workshop: Error handling | Decision Proposal 127 | 2AU.03.19 | |
20 | CX Guideline | MAY | Data holders should use a user identifier that is consistent and familiar with their existing digital channel experiences and use terminology that aligns with the intended sector. Some example user identifiers are email address, user name, mobile number and customer ID. | 2AU.01.20 | ||
21 | CX Guideline | MAY | User identifiers need to be unique to each single eligible CDR consumer. Data holders should aim to do this by using identifiers unique to each customer (e.g. Customer IDs for the banking sector) and/or verifying the consumer has primary access to their device/service (e.g. mobile number or email address). User identifiers need to be registered and verified external to the CDR authentication flow. If the consumer changes their primary access identifier (e.g. email address), data holders need to verify that the consumer is the intended user of that identifier before changing it (e.g. verifying email with an activation link). Data holders considering suitable user identifiers should exclude any identity attributes that are shared across two or more people or cannot be registered as a verified claim for only one person. | Security Profile: Authentication Flows | 2AU.01.21 | |
22 | CX Guideline | MAY | Data holders will need to determine appropriate authentication methods in accordance with the standards, including the appropriate identifiers and OTP delivery channels. As per Schedule 4 Rules 2.1 and 2.3(2) for the energy sector, some consumers may not have online access to an account. In such a scenario, an appropriate credential and/or OTP delivery channel may need to be determined by the data holder to successfully authenticate the consumer. To facilitate authentication in this scenario, a data holder may, for example, provide a support pathway to help such an offline consumer locate or register an appropriate credential. For OTP delivery, a data holder may note, in the authentication flow, that they do not possess the appropriate details to deliver the OTP, along with instructions for how to contact the data holder and register or provide these details, which should be external to the CDR flow. | 2AU.00.22 | ||
23 | CX Guideline | MAY | Support pathways should be provided to help consumers who may have forgotten their credentials or may not have the appropriate credentials and/or contact details. | 2AU.00.23 | ||
24 | CX Guideline | MAY | ‘Offline customers’ are eligible energy consumers without online access to their energy account(s). Data holders must take reasonable steps to support data sharing for offline customers and must not impose additional eligibility requirements, such as requiring online access prior to data sharing. | CDR Support Portal: Offline Customer Guidance | 2AU.00.24 | |
25 | CX Guideline | MAY | Data holders can offer online registration to an offline customer as part of their own processes, but this should be external to the authentication and authorisation flows. | CDR Support Portal: Offline Customer Guidance | 2AU.00.25 | |
26 | 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 | 2AU.00.26 | |
27 | 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 | 2AU.00.27 | |
28 | 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 | 2AU.00.28 | |
29 | 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 | 2AU.00.29 | |
30 | 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. NB: This is a subset of the Technical Standard referenced. | Security Profile, Credential Requirements, One Time Password Credential Requirements | 2AU.00.30 | |
31 | 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 | 2AU.00.31 | |
32 | 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 | 2AU.00.32 | |
33 | 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). | Authorisation Standards, Authorisation: Profile selection | 2AU.00.33 | |
34 | CX Guideline | MAY | Data holders may use alternative methods for authentication in accordance with the relevant standards for Consumer Experience Authentication and Security Profile. | 2AU.00.34 | ||
35 | CX Guideline | MAY | A user with valid credentials that is not authorised to share data should still be able to successfully authenticate. This may include a user that not a nominated representative, or is otherwise ineligible to share data. In this situation, the user should be able to successfully authenticate before seeing details in the authorisation flow outlining that they cannot share data, which may include a list of unavailable accounts and instructions on how to gain the ability to share data. A user that is ineligible or not a nominated representative should not fail at the point of authentication where they otherwise have valid credentials and meet the necessary criteria to successfully authenticate. | 2AU.00.35 | ||
36 | CX Guideline | MAY | When the ‘Redirect to Web with OTP’ flow is used, the ‘App Install’ CX Standard allows data holders to prompt users to install their app for the purposes of CDR authentication. This may be achieved via a banner, included in the footer, included in OTP delivery, or shared to a user's contact details following the completion of authentication, for example. The delivery channel and method for any additional invitations are at the discretion of the data holder. The exact wording of the message provided in the Redirect to Web flow is also at the data holder's discretion. However, data holders should avoid including links that could unnecessary friction or trigger phishing concerns. | 2AU.00.36 |