DataRight+ Security Profile: Baseline
Internet-Draft draft-authors-datarightplus-infosec-baseline-00
Stuart Low
Biza.io
stuart@biza.io
Ben Kolera
Biza.io
bkolera@biza.io
Internet
datarightplus
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].
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
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
Provider
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
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
Endpoints
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;
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
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
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;
Resource Server
The resource server provided by Providers: 1. SHALL support the provisions specified in clause 5.2.2 of [FAPI-1.0-Baseline];
Initiator
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.
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
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
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
Acknowledgement
The following people contributed to this document:
- Stuart Low (Biza.io) - Editor
- Ben Kolera (Biza.io)
Normative References
[CDS]

Consumer Data Standards (CDS)
Data Standards Body (Treasury)
[DATARIGHTPLUS-ROSETTA]

DataRight+ Rosetta Stone
Stuart Low
Biza.io
[FAPI-1.0-Advanced]

Financial-grade API Security Profile 1.0 - Part 2: Advanced
Nat Sakimura
Nat Consulting
John Bradley
Yubico
Illumila
Illumila
[FAPI-1.0-Baseline]

Financial-grade API Security Profile 1.0 - Part 1: Baseline
Nat Sakimura
Nat Consulting
John Bradley
Yubico
Illumila
Illumila
[JWT]

JSON Web Token (JWT)
M. Jones
Microsoft
John Bradley
Ping Identity
N. Sakimura
Nomura Research Institute
May 2015
[OIDC-Core]

OpenID Connect Core 1.0 incorporating errata set 1
Nat Sakimura
NRI
John Bradley
Ping Identity
Mike Jones
Microsoft
Breno de Medeiros
Google
Chuck Mortimore
Salesforce
8 Nov 2014
[OIDC-Discovery]

OpenID Connect Discovery 1.0 incorporating errata set 1
Nat Sakimura
NRI
John Bradley
Ping Identity
Mike Jones
Microsoft
E. Jay
Illumila
8 Nov 2014
[TDIF]

Trusted Digital Identity Framework ( TDIF)
Commonwealth of Australia (Digital Transformation Agency)
[RFC2119]
[RFC9126]
[RFC7662]
[RFC7009]
[RFC8414]