CX Guidelines

Read first CX Checklist attributes ◦ Area refers to the stage in the consumer journey, such as Pre-consent, Consent, Authenticate, Authorise, or Consent Management. ◦ Focus area refers to a specific theme in each stage (e.g. 01. User Identifier). ◦ Checklist ref contains a unique reference number for the item. ▪ The first values refer to the Area (e.g. 0DL.xx.xx for data language; 2AU.xx.xx for authentication). ▪ The second set values refer to the Focus area (e.g. xxx.01.xx). ▪ The last values refer to the annotation number used on the wireframe, where available (e.g. xxx.xx.02; wireframes are linked to in the Example column). ◦ Type refers to the source of the statement: Rules, Standards and Guidelines. ◦ Participant refers to the relevant CDR Participant for the item. ◦ Requirement level refers to the level of obligation. For the data standards, the key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC2119. CX Guidelines provide optional examples and recommendations; as such, a MAY is used to denote a CX Guideline for the purposes of this checklist regardless of the language used in the guideline statement. ◦ Statement refers to the relevant requirement or recommendation as articulated in the rules, standards, or guidelines. ◦ References points to the requirement itself, or its location; typically a rule, standard, or research. ◦ Example links to the relevant artefact, such as the CX Guideline page, which includes wireframes of example implementations, or a table in the case of data language standards. ◦ Version introduced refers to the version of the data standards that was current when the item was introduced to the CX Guidelines, starting from version 1.4.0. Items noted as introduced in 1.4.0 or earlier are requirements that exist in v1.4.0 of the CX Guidelines (PDF). ◦ Date introduced refers to the specific date the item was introduced to the CX Checklist, using August 2020 as a starting point (when v1.4.0 was introduced). The date will typically be the date of the version release, but some new items may not constitute a standards change (e.g. a revised wireframe or rules change) and as such may not align with standards versioning. ◦ Date modified refers to when an existing CX Checklist entry was updated, which is not necessarily the date the corresponding requirement (Rule, Standard or Guideline) was changed. ◦ Status refers to whether the item is active or has been retired from the CX Guidelines. An 'active' item is applicable and current. A 'retired' item may be labelled as such because it no longer applies, has been merged with another item, or has been removed from the CX Guidelines. A 'retired' item may still be a requirement. These statuses are used in the live CX Checklist and CSV to highlight changes between versions of the CX Guidelines.

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	00. Authenticate - general
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	00. Authenticate - general
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	03. One Time Password
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	00. Authenticate - general
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	01. User identifier
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	03. One Time Password
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	03. One Time Password
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	03. One Time Password
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	03. One Time Password
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	03. One Time Password
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	03. One Time Password
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	03. One Time Password
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	03. One Time Password
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	01. User identifier
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	01. User identifier
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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: `urn:cds.au:cdr:2` • The authenticators used to attain this level MUST achieve Single Factor Authentication as defined in Authentication Schedule. • The authenticators used to attain this level MAY conform with the Authentication Level 'AL1' rules specified under the Digital ID Accreditation Data Standards [DigitalID-Accreditation] Authentication Levels (Chapter 2) requirements. NB: This is a subset of the Technical Standard referenced.	Security Profile, Levels of Assurance (LoAs), Single Ordinal	2AU.00.28	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general
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	00. Authenticate - general

Wireframe ref

Type

Requirement level

Statement

Reference

Checklist ref

Focus area

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