]> Biza.io

stuart@biza.io

Biza.io

bkolera@biza.io

Internet datarightplus The DataRight+ Security Profile: Baseline is intended to be a compatible profile of the presented as a profile of . 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 . Further terminology used is deliberately jurisdiction agnostic, please refer to 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 .

Scope This document specifies methods for the following:

• method of obtaining OAuth2 tokens as originally described within the 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 and the terms "Consumer", "Ecosystem Authority", "Initiator", "Personally Identifiable Information (PII)", "Provider", "User" as defined by . 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 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

In addition, the authorisation server:

1. SHALL support the 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 ;
6. SHALL issue request_uri values which are one-time use and expire between 10 seconds and 90 seconds (this overrides 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 ;
9. SHALL support a UserInfo Endpoint as specified in Section 5.3 of ;
10. SHALL for each Provider, utilise a different issuer as specified in Section 1.2 of ;
11. SHALL support discovery, as defined in OpenID Connect Discovery 1.0 ;
12. SHALL support an introspection endpoint, as defined in ;
13. SHALL support a revocation endpoint, as defined in ;
14. SHALL ensure all operations meet at at least the requirements of Credential Level CL1 rules of ;
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 at the OpenID Connect Discovery 1.0 endpoint;
2. SHALL support the require_pushed_authorization_requests parameter as described in at the 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 claims of sub, auth_time, name, given_name family_name and last_updated;
2. SHALL ignored and not authorise any other claims outlined in ;
3. SHOULD support the acr claim;
4. MAY support the 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 ;

Initiator

Authorisation Client The Initiators authorisation client:

1. SHALL support the provisions specified in clause 5.2.3 and 5.2.4 of ;
2. SHALL support pushed authorisation requests as described in ;
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 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 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 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 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 Data Standards Body (Treasury) Biza.io Nat Consulting Yubico Illumila Nat Consulting Yubico Illumila Microsoft Ping Identity Nomura Research Institute NRI Ping Identity Microsoft Google Salesforce NRI Ping Identity Microsoft Illumila Commonwealth of Australia (Digital Transformation Agency)