Updated @February 22, 2024
This section shows examples of the Redirect with One Time Password flow, where the consumer inputs an identifier and a One Time Password (OTP) to authenticate with their data holder.
Overview
The Redirect with One Time Password authentication flow can be presented as two steps:
- User identifier
- One Time Password
At this step, the consumer will be able to enter their user identifier for verification with the data holder.
At this step, the consumer will be able to enter a One Time Password to authenticate and securely connect to the data holder.
Wireframes and guidelines
Note: The wireframes shown are examples of how to implement key rules, standards, and guidelines. Use the on-screen functions to adjust zoom level or expand the wireframes to be viewed at full screen.
The following wireframes also include guidance for ‘offline customers’, who are eligible energy consumers without online access to their energy account(s). For more information please refer to the Offline Customer Guidance on our CDR Support Portal.
‣
| 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. | 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. | 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.). | 2AU.03.04 | ||
05 | CX Standard | MUST | Data holders MUST communicate the expiry period of the OTP to the consumer in the authentication flow. | 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. | 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 |
‣
Note: Some interactions and screens have been omitted for simplicity.
Download open source asset
Open sources design assets are created in Figma for the purposes of assisting implementation. This Figma file contains annotated wireframes and working prototypes for Redirect with One Time Password.
Download design asset
| Item | File | Date released | Version introduced |
|---|---|---|---|
February 22, 2024 | 1.29.0 |
For past versions, refer to .Change log
‣
Open sources design assets are provided in the form of version-controlled Figma files. These assets contain the annotated wireframe and working prototype published on this page, and have been reviewed for accessibility compliance. Assets are partially conformant to Web Content Accessibility Guidelines (WCAG) 2.1 level AA. These assets do not tend to accessible code and instead focus on visual presentation and readability.
The assets use the GOLD Design System; component rationale, accessibility support, and code documentation is available in the GOLD Design System website.
For more details, see .Open Source Assets
References
These CX Guidelines were informed by consultations and research conducted in 2019 to 2023, including the following:
- Consultations
- DSB 2020, Decision Proposal 127 - CX Guidelines for Enhanced Error Handling and CX Workshop: Error handling
- DSB 2023, Noting Paper 296 - Offline Customer Authentication
- CX research
- Tobias 2019, Phase 2, Stream 3 report
- Other
Quick links to CX Guidelines:
The Consumer Data Standards Program is part of Treasury. Copyright © Commonwealth of Australia 2023.
The information provided on this website is licensed for re-distribution and re-use in accordance with Creative Commons Attribution 4.0 International (CC-BY 4.0) Licence.