Internet-Draft | DR+ Security Profile: Baseline | August 2023 |
Low & Kolera | Expires 2 February 2024 | [Page] |
The DR+ 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 OP and RP with respect to authorisation requests and does so as an overlay on the underlying FAPI profile combined with the inclusion of permitted arrangement types within the CDR (currently one, the CDR Sharing Arrangement V1). It does not attempt to provide elaboration on registration protocols, certificate profiles, federation or other components specified within the Data Standards: Security Profile.¶
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
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 2 February 2024.¶
Copyright (c) 2023 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies methods for the following: - method of obtaining OAuth2 tokens in th designated manner under the CDR Rules and [CDS]; - 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 - incorporate components which are headed towards retirement, notably at the time of drafting, the inclusion of Hybrid authorisation flow¶
This specification uses the term "JSON Web Token (JWT)" as defined by [JWT].¶
The specification also defines the following terms:¶
For the purposes of this specification a Data Holder is described as the party who is offering or has offered services to the Consumer and/or holds relevant data related to those services on behalf of the Consumer.¶
The types and format of that data is outside the scope of this particular specification but traditionally includes: - specific customer information such as name, addresses and phone numbers; - information related to services such as account numbers, pricing information and balances; - transaction/ledger information pertaining to services provided¶
Within the CDR ecosystem the mandated Data Holders are ostensible Banking and Energy providers. Additional sectors can be designated by way of a legally binding Designation Instrument coupled with changes to the CDR Rules.¶
A Software Product assumes the role of an [OIDC-Core] OpenID Provider.¶
The resource server provided by Data Holders: 1. SHALL support the provisions specified in clause 5.2.2 of [FAPI-1.0-Baseline];¶
For the purposes of this specification, a Software Product is a piece of technology infrastructure managed by a Data Recipient for a specific value proposition. That valuate proposition, following the request of consent from the Consumer, initiates authorisation requests to Data Holders and processes these responses for the purposes of obtaining access credentials (tokens) to utilise at various resource server endpoints.¶
Within a legal context there are a variety of Data Recipient engagement approaches however this specification seeks to avoid a variety of ambiguity and instead focus on the Software Product itself.¶
A Software Product assumes the role of an [OIDC-Core] Relying Party (Client).¶
Data Holders and Software Products MUST support the following:¶
Section 8.5 of [FAPI-1.0-Advanced] SHALL apply.¶
In addition:¶
Claims available via the profile scope will only return the details of the User which may be different to the Consumer.¶
Data Holders SHOULD explicitly capture Claims requested by the Data Recipient. If the data cluster or [OIDC] profile scope changes meaning in future this ensures the Data Holder only returns what the Consumer initially authorised to disclose.¶
Software Products SHOULD record the following information each time an authorisation flow is executed: username (consumer’s ID at the Data Recipient Software Product), timestamp, IP, consent scopes and duration.¶
Data Holders SHOULD implement additional controls to minimise the risk of interception of the OTP through the selected delivery mechanism.¶
The following people contributed to this document:¶