Internet-Draft DataRight+ Security Profile: Baseline April 2024
Low & Kolera Expires 3 October 2024 [Page]
Workgroup:
datarightplus
Internet-Draft:
draft-authors-datarightplus-infosec-baseline-00
Published:
Intended Status:
Experimental
Expires:
Authors:
S. Low
Biza.io
B. Kolera
Biza.io

DataRight+ Security Profile: Baseline

Abstract

The DataRight+ 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 Provider and Initiator with respect to authorisation requests and does so as an overlay on the underlying FAPI profile combined with the inclusion of specified authorisation types.

This profile does not attempt to provide elaboration on registration protocols, certificate profiles, federation or other components specified within the [CDS]. Further terminology used is deliberately jurisdiction agnostic, please refer to [DATARIGHTPLUS-ROSETTA] for specific ecosystem mappings.

Notational Conventions

The keywords "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 3 October 2024.

▲

Table of Contents

1. Scope

This document specifies methods for the following:

This document does not seek to:

2. Terminology

This specification uses the term "JSON Web Token (JWT)" as defined by [JWT] and the terms "Consumer", "Ecosystem Authority", "Initiator", "Personally Identifiable Information (PII)", "Provider", "User" as defined by [DATARIGHTPLUS-ROSETTA].

The specification also defines the following terms:

Pairwise Pseudonymous Identifier (PPID)
Identifier that identifies the Consumer to a Initiator that cannot be correlated with the Consumer's PPID at another Initiator.
User Identifier
A User Identifier is a unique piece of information, typically a username, which identifies the User

3. Provider

3.1. Authorisation Server

The authorisation server SHALL support the provisions specified in clause 5.2.2 of [FAPI-1.0-Advanced] with the following sections replaced:

  1. Section 5.2.2-1: SHALL accept only PAR issued request object passed by reference using the request_uri parameter;
  2. Section 5.2.2-2: SHALL require the response_type value code in conjunction with the response_mode value jwt;
  3. Section 5.2.2-11: SHALL support the pushed authorization request endpoint as described in PAR;
  4. 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. SHALL 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 provide the lifetime remaining of an access token as an attribute named expires_in within the token endpoint response;
  5. SHALL generate the sub as a PPID as described in Section 8 of [OIDC-Core];
  6. SHALL issue request_uri values which are one-time use and expire between 10 seconds and 90 seconds (this overrides [RFC9126] clause 4);
  7. SHALL NOT specify duplicate kid parameters within the endpoint advertised at jwks_uri;
  8. SHALL support a Token End Point as specified in Section 3.1.3 of [OIDC-Core];
  9. SHALL support a UserInfo Endpoint as specified in Section 5.3 of [OIDC-Core];
  10. SHALL for each Provider, utilise a different issuer as specified in Section 1.2 of [OIDC-Core];
  11. SHALL support discovery, as defined in OpenID Connect Discovery 1.0 [OIDC-Discovery];
  12. SHALL support an introspection endpoint, as defined in [RFC7662];
  13. SHALL support a revocation endpoint, as defined in [RFC7009];
  14. SHALL ensure all operations meet at at least the requirements of Credential Level CL1 rules of [TDIF];
  15. SHALL NOT utilise refresh token rotation

3.1.1. Authorisation Flow

During the authorisation flow, the authorisation server:

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

3.1.2. Endpoints

3.1.2.1. Discovery Document

The discovery document from the authorisation server:

  1. SHALL support the require_pushed_authorization_requests parameter as described in [RFC9126] at the OpenID Connect Discovery 1.0 [OIDC-Discovery] endpoint;
  2. SHALL 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. SHALL NOT support introspection of access tokens
  2. SHALL include the sub, exp and scope attributes
  3. SHALL NOT include the username attribute
3.1.2.3. Revocation Endpoint

The revocation endpoint:

  1. SHALL support revocation of refresh tokens
  2. SHALL support revocation of access tokens
  3. MAY support revocation of ID tokens

3.1.3. Claims

The authorisation server:

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

3.2. Resource Server

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

4. Initiator

4.1. Authorisation Client

The Initiators 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 Provider;
  4. SHALL submit authorisation requests containing a exp claim, in accordance with [JWT] Section 4.1.4;
  5. SHALL submit authorisation requests containing a exp claim that is less than or equal to 3600;
  6. SHALL 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.

4.2. Resource Server

The resource server SHALL support the provisions specified in clause 6.2.2 of [FAPI-1.0-Baseline] with the following sections replaced:

  1. Section 6.2.2-3: SHALL send the last time the customer logged into the client in the x-fapi-auth-date header where the value is supplied as a HTTP-date as in Section 7.1.1.1 of RFC7231, e.g., x-fapi-auth-date: Tue, 11 Sep 2012 19:43:31 GMT;
  2. Section 6.2.2-4: SHALL send the customer’s IP address if this data is available in the x-fapi-customer-ip-address header, e.g., x-fapi-customer-ip-address: 2001:DB8::1893:25c8:1946 or x-fapi-customer-ip-address: 198.51.100.119; and

5. 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 except where required for Discovery or Consumer browser access (ie. Authorisation endpoint);
  2. All parties SHALL apply the certificate management policy requirements of the relevant Ecosystem Authority

6. Implementation Considerations

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

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

Initiators SHOULD record the following information each time an authorisation flow is executed:

7. Acknowledgement

The following people contributed to this document:

8. Normative References

[CDS]
Data Standards Body (Treasury), "Consumer Data Standards (CDS)", <https://consumerdatastandardsaustralia.github.io/standards>.
[DATARIGHTPLUS-ROSETTA]
Low, S., "DataRight+ Rosetta Stone", <https://datarightplus.github.io/datarightplus-rosetta/draft-authors-datarightplus-rosetta.html>.
[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", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7009]
Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, , <https://www.rfc-editor.org/info/rfc7009>.
[RFC7662]
Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , <https://www.rfc-editor.org/info/rfc7662>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , <https://www.rfc-editor.org/info/rfc8414>.
[RFC9126]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, , <https://www.rfc-editor.org/info/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