Internet-Draft DataRight+: Australian CDR Profile April 2024
Low Expires 5 October 2024 [Page]
Workgroup:
datarightplus
Internet-Draft:
draft-authors-datarightplus-cdr-profile-latest
Published:
Intended Status:
Experimental
Expires:
Author:
S. Low
Biza.io

DataRight+: Australian CDR Profile

Abstract

This is the ecosystem profile for the Australian CDR describing the composite components to form the technical infrastructure operating to form the Australian Consumer Data Right. This specification is intended to result in a [CDS] compatible implementation.

Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 October 2024.

▲

Table of Contents

1. Scope

The scope of this document is intended to be the combinatorial outcome of a variety of specifications to achieve a compliant outcome within the Australian Consumer Data Right. Because this document relates to a specific ecosystem deployment it contains static configuration information.

This document does not seek to navigate the complexities of [CDR-RULES] but rather to establish a technical baseline to consider these in each implementors context.

2. Terminology

This specification utilises the various terms outlined within [DATARIGHTPLUS-ROSETTA].

Banking Sector
Relates to the Holders, designated under the [CDR-RULES] in the Banking industry
Energy Sector
Relates to the Designated Holders, designated under the [CDR-RULES] in the Energy industry
Designated Holders
Designated Holders are organisations which belong to a designated sector, according to the [CDR-RULES] and meet certain eligibility requirements to be required to deliver CDR services within their sector.

3. Providers

Providers are required to deliver authorisation and resource requirements. They are also required to integrate with the Ecosystem Authority in the prescribed way.

3.1. Information Security

Providers MUST:

  1. comply with the Provider provisions described in [DATARIGHTPLUS-INFOSEC-BASELINE-00];
  2. comply with the provisions outlined in [DATARIGHTPLUS-ADMISSION-CONTROL-00];
  3. comply with the provisions outlined in [DATARIGHTPLUS-SHARING-ARRANGEMENT-V1-00];

  4. support the following acr claim and validate the Consumer with the following values:

    1. urn:cds.au:cdr:2 where the authentication achieved matches the Credential Level CL1 from [TDIF] or;
    2. urn:cds.au:cdr:3 where the authentication achieved matches the Credential Level CL2 from [TDIF]

  5. incorporate One-Time Passwords as part of the requirement to achieve the minimum acceptable value for the acr claim and:

    1. MUST be delivered using existing and preferred channels
    2. MUST be numeric digits and be between 4 and 6 digits in length
    3. MUST only be valid for the purposes of establishing authorisations between Provider and Initiators
    4. MUST be invalidated after a reasonable period of time
  6. MUST authenticate a confidential client using private_key_jwt as described in section 9 of [OIDC-Core] with a client identifier of cdr-register
  7. MUST supply a scope value of admin:metrics.basic:read for all successful authentications of the cdr-register client identifier

Note: The CDR currently mandates, essentially exclusively, the use of One-Time Passwords while restricting the introduction of additional "friction" via other factors. It is understood this is currently being reconsidered.

3.2. Resource Server

Providers operating within the Banking Sector MUST comply with the provisions outlined in [DATARIGHTPLUS-RESOURCE-SET-COMMON-00] and [DATARIGHTPLUS-RESOURCE-SET-BANKING-00].

Providers operating within the Energy Sector MUST comply with the provisions outlined in [DATARIGHTPLUS-RESOURCE-SET-COMMON-00] and [DATARIGHTPLUS-RESOURCE-SET-ENERGY-00].

3.2.1. Metrics

In addition to the aforementioned requirements Providers MUST deliver protected resource(s), in accordance with [DATARIGHTPLUS-REDOCLY-ID1], as follows:

Table 1
Resource Server Endpoint Required Scope Valid x-v
GET /admin/metrics admin:metrics.basic:read 5

3.2.2. Forced Metadata Refresh

In addition to the aforementioned requirements Providers MUST deliver protected resource(s), in accordance with [DATARIGHTPLUS-REDOCLY-ID1], as follows:

Table 2
Resource Server Endpoint Required Scope Valid x-v
GET /admin/metrics admin:metadata:update 1

On requesting this endpoint the Provider MUST trigger a refresh of the information obtained from the Ecosystem Directory.

4. Initiators

Initiators are required to comply with Ecosystem Authority requirements and integrate with Providers in prescribed ways.

Within the Australian CDR Initiators are commonly referred to as Software Products.

4.1. Information Security

Initiators MUST:

  1. comply with the Initiator provisions described in [DATARIGHTPLUS-INFOSEC-BASELINE-00];
  2. comply with the provisions outlined in [DATARIGHTPLUS-ADMISSION-CONTROL-00];
  3. comply with the provisions outlined in [DATARIGHTPLUS-SHARING-ARRANGEMENT-V1-00];

5. Ecosystem Authority

The Ecosystem Authority MUST comply with the requirements outlined within [DATARIGHTPLUS-ADMISSION-CONTROL-00].

The Ecosystem Authority for the Australian CDR is the Australian Competition and Consumer Commission (ACCC).

5.1. Accreditation

The Ecosystem Authority performs external validation of participant capabilities, particularly of the Initiator Entity.

This occurs by way of a combination of Ecosystem Authority verification, external technology audit standards (notably ASAE3150) and legal assertions by a Initiator Entity carrying higher accreditation as to the suitability of new subordinate Initiator Entities.

As a result of this validation Initiator Entities are granted an accreditation status which in turn influences the authorisation scopes that are made available to thee relevant Initiator. Further detail on this process in the context of the CDR can be found within the [CDR-RULES] and within guidelines published on the CDR website.

The subject of accreditation is not intended to be covered by this specification. As a consequence this document focuses primarily on the relationship between Provider and Initiator with the Ecosystem Authority providing third party assurance with respect to technical admission control.

6. Electricity Authority

The Electricity Authority MUST comply with the relevant provisions outlined within [DATARIGHTPLUS-RESOURCE-SET-ENERGY-00].

The Electricity Authority for the Australian CDR is the Australian Energy Market Operator (AEMO).

7. Electricity Plan Website

The Electricity Plan Website MUST comply with the relevant provisions outlined within [DATARIGHTPLUS-RESOURCE-SET-ENERGY-00].

The Electricity Plan Website for the Australian CDR is Energy Made Easy operated by the Australian Energy Regulator.

8. Current Ecosystem Configuration

The following outlines the currently understood endpoint configuration for the Australian CDR ecosystem:

9. Implementation Considerations

Where One-Time Password OTP are in use the generation method SHOULD incorporate controls, such as retry limits, to minimise the risk of enumeration attacks.

10. Acknowledgement

The following people contributed to this document:

We acknowledge the contribution to the [CDS] of the following individuals:

11. Normative References

[CDR-RULES]
Department of the Treasury, "Competition and Consumer (Consumer Data Right) Rules 2020", <https://www.legislation.gov.au/F2020L00094/2023-07-22/text>.
[CDS]
Data Standards Body (Treasury), "Consumer Data Standards (CDS)", <https://consumerdatastandardsaustralia.github.io/standards>.
[DATARIGHTPLUS-ADMISSION-CONTROL-00]
Low, S. and B. Kolera, "DataRight+: Admission Control Baseline", <https://datarightplus.github.io/datarightplus-admission-control-baseline/draft-authors-datarightplus-admission-control-00/draft-authors-datarightplus-admission-control.html>.
[DATARIGHTPLUS-INFOSEC-BASELINE-00]
Low, S. and B. Kolera, "DataRight+ Security Profile: Baseline", <https://datarightplus.github.io/datarightplus-infosec-baseline/draft-authors-datarightplus-infosec-baseline-00/draft-authors-datarightplus-infosec-baseline.html>.
[DATARIGHTPLUS-REDOCLY-ID1]
Low, S., Kolera, B., and W. Cai, "DataRight+: Redocly (ID1)", <https://datarightplus.github.io/datarightplus-redocly/?v=ID1>.
[DATARIGHTPLUS-RESOURCE-SET-BANKING-00]
Low, S., "DataRight+: Banking Resource Set", <https://datarightplus.github.io/datarightplus-resource-set-banking/draft-authors-datarightplus-resource-set-banking-00/draft-authors-datarightplus-resource-set-banking.html>.
[DATARIGHTPLUS-RESOURCE-SET-COMMON-00]
Low, S., "DataRight+: Common Resource Set", <https://datarightplus.github.io/datarightplus-resource-set-common/draft-authors-datarightplus-resource-set-common-00/draft-authors-datarightplus-resource-set-common.html>.
[DATARIGHTPLUS-RESOURCE-SET-ENERGY-00]
Low, S., "DataRight+: Energy Resource Set", <https://datarightplus.github.io/datarightplus-resource-set-energy/draft-authors-datarightplus-resource-set-energy-00/draft-authors-datarightplus-resource-set-energy.html>.
[DATARIGHTPLUS-ROSETTA]
Low, S., "DataRight+ Rosetta Stone", <https://datarightplus.github.io/datarightplus-rosetta/draft-authors-datarightplus-rosetta.html>.
[DATARIGHTPLUS-SHARING-ARRANGEMENT-V1-00]
Low, S. and B. Kolera, "DataRight+: Sharing Arrangement V1", <https://datarightplus.github.io/datarightplus-sharing-arrangement-v1/draft-authors-datarightplus-sharing-arrangement-v1-00/draft-authors-datarightplus-sharing-arrangement-v1.html>.
[OIDC-Core]
Sakimura, N., "OpenID Connect Core 1.0 incorporating errata set 1", <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[TDIF]
Commonwealth of Australia (Digital Transformation Agency), "Trusted Digital Identity Framework ( TDIF)", <https://www.digitalidentity.gov.au>.

Author's Address

Stuart Low
Biza.io