datarightplus S. Low Internet-Draft B. Kolera Intended status: Experimental Biza.io Expires: 25 March 2025 21 September 2024 DataRight+ Security Profile: Baseline draft-authors-datarightplus-infosec-baseline-latest 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 25 March 2025. 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. Terminology 3. Provider 3.1. Authorisation Server 3.1.1. Authorisation Flow 3.1.2. Endpoints 3.1.3. Claims 3.2. Resource Server 4. Initiator 4.1. Authorisation Client 4.2. Resource Server 5. TLS Considerations 6. Implementation Considerations 7. Acknowledgement 8. Normative References Authors' Addresses 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 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 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: * User Identifier; * timestamp; * IP; * scopes; * duration 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)", . [DATARIGHTPLUS-ROSETTA] Low, S., "DataRight+ Rosetta Stone", . [FAPI-1.0-Advanced] Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 2: Advanced", . [FAPI-1.0-Baseline] Sakimura, N., Bradley, J., and E. Jay, "Financial-grade API Security Profile 1.0 - Part 1: Baseline", . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", May 2015, . [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, . [OIDC-Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", 8 November 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", September 2021, . [TDIF] Commonwealth of Australia (Digital Transformation Agency), "Trusted Digital Identity Framework ( TDIF)", . Authors' Addresses Stuart Low Biza.io Email: stuart@biza.io Ben Kolera Biza.io Email: bkolera@biza.io