Internet-Draft DR+ Security Profile: Baseline August 2023
Low & Kolera Expires 2 February 2024 [Page]
Workgroup:
datarightplus-parity
Internet-Draft:
draft-authors-datarightplus-infosec-baseline-latest
Published:
Intended Status:
Experimental
Expires:
Authors:
S. Low
Biza.io
B. Kolera
Biza.io

DR+ Security Profile: Baseline

Abstract

The DR+ Security Profile: Baseline is intended to be a compatible profile of the [CDS] presented as a profile of [FAPI-1.0-Advanced]. This profile focuses primarily on the obligations between OP and RP with respect to authorisation requests and does so as an overlay on the underlying FAPI profile combined with the inclusion of permitted arrangement types within the CDR (currently one, the CDR Sharing Arrangement V1). It does not attempt to provide elaboration on registration protocols, certificate profiles, federation or other components specified within the Data Standards: Security Profile.

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 2 February 2024.

▲

Table of Contents

1. Scope

This document specifies methods for the following: - method of obtaining OAuth2 tokens in th designated manner under the CDR Rules and [CDS]; - requirements related to participants for initiating authorisations and obtaining ongoing authorisation credentials

This document does not seek to: - specify correlation elements between technical and the legal obligations contained within documents such as the CDR Rules; - restate unchanged requirements from upstream specifications - incorporate components which are headed towards retirement, notably at the time of drafting, the inclusion of Hybrid authorisation flow

2. Terminology

This specification uses the term "JSON Web Token (JWT)" as defined by [JWT].

The specification also defines the following terms:

CDR Rules
Refers to the Competition and Consumer (Consumer Data Right) Rules 2020
Consumer
A Consumer is a business or individual who authorises the sharing of data stored by a Data Holder on their behalf to a Software Product with their permission. Beyond having access an individual to their own data a User may also have access to zero or more non-individual Consumer's, for instance businesses that they have permission to make sharing decisions for.
Data Holder
A Data Holder is a party that holds consumer data for which sharing is to be conducted and for which their customer, the Consumer, participates in the authorisation process initiated by a Data Recipient. Please refer to the expanded description of Data Holder within this document.
Data Recipient
A Data Recipient is a party that receives consumer data from a Data Holder. This occurs by way of a Software Product.
Ecosystem Authority
The Ecosystem Authority represents the designated arbiter of trust between Data Holders, Data Recipients and the Consumer. Within the Australian Consumer Data Right this is the Australian Competition and Consumer Commission. Further elaboration on the Ecosystem Authority is provided within [CDRPLUS-ADMISSION-CONTROL].
Personally Identifiable Information (PII)
Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates.
Pairwise Pseudonymous Identifier (PPID)
Identifier that identifies the Consumer to a Data Recipient that cannot be correlated with the Consumer's PPID at another Data Recipient.
Software Product
A Software Product represents the technology infrastructure, ostensibly a client registration with an authorisation server, operated by a Data Recipient for the purposes of receiving consumer data.
User
A User is a human who provides an identifier unique to the individual and for which correlates to one or more Consumer relationships.
User Identifier
A User Identifier is a unique piece of information, typically a username, which identifies the User

3. Data Holder

For the purposes of this specification a Data Holder is described as the party who is offering or has offered services to the Consumer and/or holds relevant data related to those services on behalf of the Consumer.

The types and format of that data is outside the scope of this particular specification but traditionally includes: - specific customer information such as name, addresses and phone numbers; - information related to services such as account numbers, pricing information and balances; - transaction/ledger information pertaining to services provided

Within the CDR ecosystem the mandated Data Holders are ostensible Banking and Energy providers. Additional sectors can be designated by way of a legally binding Designation Instrument coupled with changes to the CDR Rules.

A Software Product assumes the role of an [OIDC-Core] OpenID Provider.

3.1. Authorisation Server

The authorisation server MUST support the provisions specified in clause 5.2.2 of [FAPI-1.0-Advanced] with the following sections replaced as follows: 1. Section 5.2.2-1: SHALL accept only PAR issued request object passed by reference using the request_uri parameter 1. Section 5.2.2-2: SHALL require the response_type value code in conjunction with the response_mode value jwt; 1. Section 5.2.2-11: MUST support the pushed authorization request endpoint as described in PAR; 1. Section 5.2.2-14: SHALL authenticate the confidential client using private_key_jwt specified in section 9 of [OIDC-Core]

In addition, the authorisation server:

  1. MUST support the [OIDC-Core] scopes openid and profile;
  2. SHALL support signed ID Tokens and MAY support signed and encrypted ID Tokens;
  3. SHALL issue access tokens with an expiry time of between 2 and 10 minutes;
  4. SHALL NOT accept authorisation request object passed by value
  5. SHALL provide the lifetime of an access token as an attribute named expires_in within the token endpoint response;
  6. MUST generate the sub as a PPID as described in Section 8 of [OIDC-Core];
  7. SHALL issue request_uri values which are one-time use and expire between 10 seconds and 90 seconds (this overrides [RFC9126] clause 4);
  8. MUST NOT specify duplicate kid parameters within the endpoint advertised at jwks_uri;
  9. MUST support a Token End Point as specified in Section 3.1.3 of [OIDC-Core];
  10. MUST support a UserInfo Endpoint as specified in Section 5.3 of [OIDC-Core];
  11. MUST utilise a different Issuer as specified in Section 1.2 of [OIDC-Core] for each marketable brand of the Data Holder;
  12. SHALL support discovery, as defined in OpenID Connect Discovery 1.0 [OIDC-Discovery];
  13. SHALL support an introspection endpoint, as defined in [RFC7662];
  14. SHALL support a revocation endpoint, as defined in [RFC7009]
  15. SHALL not use refresh token rotation unless, in the case a response with a new refresh token is not received and stored by the client, retrying the request (with the previous refresh token) will succeed

3.1.1. Authorisation Flow

During the authorisation flow, the authorisation server:

  1. MUST request a User Identifier that can identify the relationship between the user and the Consumer;
  2. MUST request a User Identifier already known by the User;
  3. MUST use a one-time password (OTP) provided to the Consumer through an existing channel or mechanism;
  4. MUST NOT request the User to provide a known password;
  5. MUST NOT introduce friction designed to make the authorisation process more difficult than it needs to be
3.1.1.1. One-Time Password (OTP)

The One-Time Password (OTP):

  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 Data Holder and Software Products
  4. MUST be invalidated after a reasonable period of time
  5. SHOULD incorporate a level of pseudo-randomness appropriate for the use case
  6. SHOULD incorporate controls, such as retry limits, to minimise the risk of enumeration attacks during the authorisation process

3.1.2. Endpoints

3.1.2.1. Discovery Document

The discovery document from the authorisation server:

  1. MUST support the require_pushed_authorization_requests parameter as described in [RFC9126] at the OpenID Connect Discovery 1.0 [OIDC-Discovery] endpoint;
  2. SHOULD support the require_pushed_authorization_requests parameter as described in [RFC9126] at the [RFC8414] endpoint;
3.1.2.2. Introspection Endpoint

The introspection endpoint:

  1. MUST NOT support introspection of Access Tokens
  2. MUST include the sub, exp and scope attributes
  3. MUST NOT include the username attribute
3.1.2.3. Revocation Endpoint

The revocation endpoint:

  1. MUST support revocation of Refresh Tokens
  2. MUST support revocation of Access Tokens

3.1.3. Claims

The authorisation server:

  1. MUST support the [OIDC-Core] claims of sub, auth_time, name, given_name family_name and last_updated;
  2. SHOULD support the [OIDC-Core] acr claim;
  3. MAY support the [OIDC-Core] claims of email, email_verified, phone_number and phone_number_verified;
  4. MUST NOT support any other claims outlined in [OIDC-Core];

3.1.4. Authentication Context Class References (ACR)

If the acr claim is supported, the authorisation server SHALL support the following ACR values:

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

Additionally, the authorisation server MUST ensure all operations meet the requirements of urn:cds.au:cdr:2 ACR value.

3.2. Resource Server

The resource server provided by Data Holders: 1. SHALL support the provisions specified in clause 5.2.2 of [FAPI-1.0-Baseline];

4. Software Product

For the purposes of this specification, a Software Product is a piece of technology infrastructure managed by a Data Recipient for a specific value proposition. That valuate proposition, following the request of consent from the Consumer, initiates authorisation requests to Data Holders and processes these responses for the purposes of obtaining access credentials (tokens) to utilise at various resource server endpoints.

Within a legal context there are a variety of Data Recipient engagement approaches however this specification seeks to avoid a variety of ambiguity and instead focus on the Software Product itself.

A Software Product assumes the role of an [OIDC-Core] Relying Party (Client).

4.1. Authorisation Client

The authorisation client:

  1. SHALL support the provisions specified in clause 5.2.3 and 5.2.4 of [FAPI-1.0-Baseline];
  2. SHALL support pushed authorisation requests as described in [RFC9126];
  3. SHALL obtain the consent of the Consumer prior to commencing authorisation with the Data Holder;
  4. MUST submit authorisation requests containing a exp claim, in accordance with [JWT] Section 4.1.4;
  5. MUST submit authorisation requests containing a exp claim that is less than or equal to 3600;
  6. MUST submit authorisation requests containing a nbf claim in accordance with [JWT] Section 4.1.5

Note: The form and structure of the consent obtained by the authorisation client is outside the scope of this document.

5. Supported Arrangement Types

Data Holders and Software Products MUST support the following:

  1. CDR Sharing Arrangement V1 as described in [CDRPLUS-INFOSEC-SHARING-V1]

6. TLS Considerations

Section 8.5 of [FAPI-1.0-Advanced] SHALL apply.

In addition:

  1. Use of Mutual TLS is REQUIRED at all Authenticated Resource Server endpoints;
  2. Use of Mutual TLS is REQUIRED at all OAuth2 endpoints except where required for Discovery or Consumer browser access (ie. Authorisation endpoint);
  3. All parties SHALL utilise certificates issued by the Ecosystem Authority

7. Implementation Considerations

Claims available via the profile scope will only return the details of the User which may be different to the Consumer.

Data Holders SHOULD explicitly capture Claims requested by the Data Recipient. If the data cluster or [OIDC] profile scope changes meaning in future this ensures the Data Holder only returns what the Consumer initially authorised to disclose.

Software Products SHOULD record the following information each time an authorisation flow is executed: username (consumer’s ID at the Data Recipient Software Product), timestamp, IP, consent scopes and duration.

8. Security Considerations

Data Holders SHOULD implement additional controls to minimise the risk of interception of the OTP through the selected delivery mechanism.

9. Acknowledgement

The following people contributed to this document:

9.1. This document relies heavily upon the [CDS] and we therefore acknowledge the contribution of the following individuals:

  • James Bligh (Data Standards Body) - Lead Architect for the Consumer Data Right
  • Mark Verstege (Data Standards Body) - Lead Architect, Banking & Information Security for the Consumer Data Right
  • Ivan Hosgood (Data Standards Body & ACCC) - Solutions Architect

10. Normative References

[CDRPLUS-ADMISSION-CONTROL]
Low, S., "DataRight Plus: Admission Control", <https://datarightplus.github.io/datarightplus-admission-control/draft-authors-datarightplus-admission-control.html>.
[CDRPLUS-INFOSEC-SHARING-V1]
Low, S., "CDR: Sharing Arrangement V1", <https://datarightplus.github.io/datarightplus-specs/main/datarightplus-infosec-sharing-v1.html>.
[CDS]
Data Standards Body (Treasury), "Consumer Data Standards (CDS)", <https://consumerdatastandardsaustralia.github.io/standards>.
[FAPI-1.0-Advanced]
Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 2: Advanced", <https://openid.net/specs/openid-financial-api-part-2-1_0.html>.
[FAPI-1.0-Baseline]
Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 1: Baseline", <https://openid.net/specs/openid-financial-api-part-1-1_0.html>.
[JWT]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", , <https://datatracker.ietf.org/doc/html/rfc7519>.
[OIDC-Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", , <http://openid.net/specs/openid-connect-core-1_0.html>.
[OIDC-Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", , <https://openid.net/specs/openid-connect-discovery-1_0.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", <https://datatracker.ietf.org/doc/html/rfc2119>.
[RFC7009]
Ed., T. L. and M. Scurtescu, "OAuth 2.0 Token Revocation", <https://datatracker.ietf.org/doc/html/rfc7009>.
[RFC7662]
Ed., J. R., "OAuth 2.0 Token Introspection", , <https://datatracker.ietf.org/doc/html/rfc7662>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", , <https://datatracker.ietf.org/doc/html/rfc8414>.
[RFC9126]
Ed., T. L., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", , <https://datatracker.ietf.org/doc/html/rfc9126>.
[TDIF]
Commonwealth of Australia (Digital Transformation Agency), "Trusted Digital Identity Framework (TDIF)", <https://www.digitalidentity.gov.au>.

Authors' Addresses

Stuart Low
Biza.io
Ben Kolera
Biza.io