| 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. The inclusion of such links is considered to increase the likelihood of phishing attacks. | Authentication Standards, Authentication: Password link | CX Research 21 | 2AU.00.02 | |
03 | CX Standard | MUST | Data holders and data recipients MUST state in consumer-facing interactions and communications that services utilising the CDR do not need access to consumer passwords for the purposes of sharing data. The exact phrasing of this is at the discretion of the data holder and data recipient. | Authentication Standards, Authentication: Passwords | CX Research 21 | 2AU.00.03 | |
04 | CX Standard | MUST | Data holders and data recipients MUST clearly refer to a “One Time Password” in consumer-facing interactions and communications. The use of the term “One Time Password” MAY be presented alongside an existing term used by a data holder (e.g. Netcode, one time pin etc.). | Authentication Standards, Authentication: ‘One Time Password’ (OTP) | CX Research 10 | 2AU.03.04 | |
05 | CX Standard | MUST | Data holders MUST communicate the expiry period of the OTP to the consumer in the authentication flow. | Authentication Standards, Authentication: OTP expiry | CX Research 12, 27 | 2AU.03.05 | |
06 | Technical Standard | SHOULD | Data holders SHOULD implement additional controls to minimise the risk of enumeration attacks via the redirect page. | 2AU.00.06 | ||
07 | Technical Standard | MUST | Data holders MUST request a user identifier that can uniquely identify the customer and that is already known by the customer in the redirected page. | 2AU.01.07 | ||
08 | Technical Standard | MUST | 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. | 2AU.03.08 | ||
09 | Technical Standard | MUST NOT | Data Holders MUST NOT request that the customer enter an existing password in the redirected page. | 2AU.03.09 | ||
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 | 2AU.03.10 | ||
11 | Technical Standard | SHOULD | Data Holders SHOULD implement additional controls to minimise the risk of interception of the OTP through the selected delivery mechanism. | 2AU.03.11 | ||
12 | Technical Standard | MUST | The provided OTP MUST be used only for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions. | 2AU.03.12 | ||
13 | Technical Standard | MUST | The provided OTP MUST be numeric digits and be between 4 and 6 digits in length. | 2AU.03.13 | ||
14 | Technical Standard | SHOULD | The algorithm for the creation of the OTP is at the discretion of the Data Holder but SHOULD incorporate a level of pseudorandomness appropriate for the use case. | 2AU.03.14 | ||
15 | Technical Standard | MUST NOT | The delivery mechanism for the One Time Password (OTP) is at the discretion of the data holder but MUST align to existing and preferred channels for the customer and 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 OTP delivery is considered to include: • the addition of any requirements beyond normal data holder practices for verification code delivery • providing or requesting additional information beyond normal data holder practices for verification code delivery • offering additional or alternative services • reference or inclusion of other documents | Security Profile: Authentication Flows | 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. | 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. | 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 | Convention CDS-DC-0016 | 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. | 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. | 2AU.00.25 |