DataRight+ Security Profile: Baseline
draft-authors-datarightplus-infosec-baseline-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Stuart Low , Ben Kolera | ||
| Last updated | 2024-04-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-authors-datarightplus-infosec-baseline-00
datarightplus S. Low
Internet-Draft B. Kolera
Intended status: Experimental Biza.io
Expires: 3 October 2024 1 April 2024
DataRight+ Security Profile: Baseline
draft-authors-datarightplus-infosec-baseline-00
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.
Low & Kolera Expires 3 October 2024 [Page 1]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Provider . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Authorisation Server . . . . . . . . . . . . . . . . . . 3
3.1.1. Authorisation Flow . . . . . . . . . . . . . . . . . 4
3.1.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . 4
3.1.3. Claims . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 5
4. Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Authorisation Client . . . . . . . . . . . . . . . . . . 5
4.2. Resource Server . . . . . . . . . . . . . . . . . . . . . 6
5. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Implementation Considerations . . . . . . . . . . . . . . . . 6
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Scope
This document specifies methods for the following:
* method of obtaining OAuth2 tokens as originally described within
the [CDS] and;
* 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
* consider historical obligations which have expired
Low & Kolera Expires 3 October 2024 [Page 2]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
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;
Low & Kolera Expires 3 October 2024 [Page 3]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
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
Low & Kolera Expires 3 October 2024 [Page 4]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
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.
Low & Kolera Expires 3 October 2024 [Page 5]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
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:
* User Identifier;
* timestamp;
* IP;
* scopes;
* duration
Low & Kolera Expires 3 October 2024 [Page 6]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
7. Acknowledgement
The following people contributed to this document:
* Stuart Low (Biza.io) - Editor
* Ben Kolera (Biza.io)
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)", May 2015,
<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", 8 November 2014,
<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", 8
November 2014, <https://openid.net/specs/openid-connect-
discovery-1_0.html>.
Low & Kolera Expires 3 October 2024 [Page 7]
Internet-Draft DataRight+ Security Profile: Baseline April 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<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, June 2018,
<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, September 2021,
<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
Email: stuart@biza.io
Ben Kolera
Biza.io
Email: bkolera@biza.io
Low & Kolera Expires 3 October 2024 [Page 8]