Collection Arrangement

Introduction

An accredited person or a CDR representative engage third party service providers under a CDR outsourcing arrangement in accordance with the outsourced service provider (OSP) provisions contained in the CDR Rules.

A CDR outsourcing arrangement is between a person (the OSP principal) and another person (the OSP or provider). A provider is engaged by an OSP principal to do one or both of the following:

1. collect CDR data from a CDR participant in accordance with the CDR Rules on behalf of the principal (for an OSP chain principal with unrestricted accreditation);
2. provide goods or services to the OSP principal using CDR data that it has collected on behalf of the principal or that has been disclosed to it by the OSP principal.

A provider is able to engage another provider in a further CDR outsourcing arrangement. These arrangements can occur repeatedly – that is, the second provider can subcontract to a third provider, forming a ‘chain’. Where there is a chain of CDR outsourcing arrangements, the first OSP principal in the chain is known as the OSP chain principal. In addition, in this scenario:

• the first provider is a direct OSP of the OSP chain principal
• the second provider and any subsequent providers are indirect OSPs of the OSP chain principal.

Purpose

The purpose of this guide is to provide technical commentary in relation to the OSP provisions in the CDR Rules. It should be read in conjunction with the CDR Rules and Explanatory statement to provide broader context on the impact to the CDR ecosystem, including the obligations and liabilities of the principal and the provider.

Details of how ADRs utilise outsourced service provider (OSP) models outside of a CDR outsourcing arrangement are not covered in this guide.

Collection Arrangement

The process of collecting consumer data involves a number of functions. Collection arrangements allow for the responsibilities of these to be assigned to either the provider or principal. The following tables suggest the way in which these can be logically separated based on whether the function is more closely related to the processes required to:

• collect CDR data from data holders within the ecosystem; or
• present data in a meaningful way to consumers.

Table 1: Services considered in this Guide

Service Category	Description
Certificate, JWKS and key management services	May include hosting endpoints, issuing and rotating keys and certificates, ensuring security infrastructure is implemented and supported as per best practice
Registration management services	May include storing records of issued client ids, updating registrations as required by the design or supporting new and decommissioning old use cases of the managed software products
Consumer data collection services	May occur periodically or on demand, ensuring that data is collected in accordance with the rules and standards.
Consent management services	May include storing consent records, expiring consents, synchronising consents with data holders, exposing consent management endpoints (Revocation, Arrangement Management), triggering data de-identification / deletion
Data holder change management services	Future changes to the rules may result in data holders supporting additional functionality or adopting changes as per the Consumer Data Standards and align to the associated versioning strategy. Providers may offer discovery services to detect changes in data holder support and offer services to help the principals manage this change
Data value add service including aggregation and insight services	Augment data with further information, offer aggregate information, apply machine learning (ML) models

Component Model

Figure 1 models the current build expectation of participants within the CDR ecosystem. Figure 2 models how the scope of responsibilities can be split between a principal and a provider collecting on the principal’s behalf. A subset of the principal’s responsibilities can therefore be handled by the provider, allowing them to:

1. specialise in the security and functional requirements of participating in the CDR; and
2. achieve economies of scale when becoming multi-tenanted and servicing multiple principals in the ecosystem.

Figure 1: Potential components and endpoints in a standard ADR to DH relationship without a provider

Source: https://cdr-register.github.io/register/#ecosystem-component-diagram

Figure 2: Potential components and endpoints in an ADR to DH relationship (Collection Arrangement) with a provider

Please refer to the CDR Register Design Ecosystem Component Diagram for a description of components and endpoints shown in Figure 1 and Figure 2.

 

Impact

Client Registration

Client Registration, as documented in the CDR Register Design, will not change to accommodate collection arrangements. Software products and their issued client ids will remain owned by the principal, however, providers may choose to offer registration management services.

Security Artefacts

JWKS endpoints and client certificates will remain owned by the principal however providers may choose to offer security artefact management services.

Accreditation Status Discovery within the Ecosystem

The status of a software product, managed within a collection arrangement, will be coupled to the accreditation status of both the principal and provider in this arrangement.

To achieve this, cascade rules for software product statuses, as currently defined in the CDR Register Design, will be updated as follows:

Provider Status	Principal Status	Principal Software Product Status
Active	Active	Active
Suspended	Active	Inactive
Revoked	Active	Inactive
Surrendered	Active	Inactive
Any	Suspended	Inactive
Any	Revoked	Removed
Any	Surrendered	Removed

Requests for Consumer Data

Collection arrangements are predicated on both parties showing as active on the CDR Register. Establishing consent and making requests for consumer data should not occur if either party is inactive.

This accords with obligations of accredited persons and rule requirements.  Commercial arrangements between the provider and principal should properly reflect these obligations and requirements.  Principals may choose to leverage the software product status API to help ensure only valid requests are made.

Disclosure of Consumer Data

Data holders will be able to use the current design to ensure they are aware of the status that may apply to the provider, principal or any associated software product on the CDR Register.

Data holders currently check the status of software products to trigger their obligations as defined in Data Holder Responsibilities. This mechanism of relying on the status of the software product representing the combined statuses of provider, principal and software product will continue to be used. This ensures data holders only disclose consumer data or establish consent for consumers where a collection arrangement is in place when all parties are active on the CDR Register.

Data holder awareness of collection arrangement

There are no additional requirements on data holders to convey or be informed of the collection arrangement.

There will be no updates to the client registration process to disclose the collection arrangement to data holders or consumers via the data holder dashboard.

 

CDR Register

The CDR Register will undertake an incremental approach to support collection arrangements, improving functionality as the number of providers collecting on behalf of a principal increases, and the complexity of their models grow.

Incremental Release Schedule

Release 1: Early November 2020

The CDR Register will support collection arrangements however, it will NOT provide additional configuration functionality to principals and providers in the CDR Participant Portal.

Principals and providers are expected to work together to ensure the appropriate software product is configured, technical details captured and certificates issued to the appropriate party. This relationship will need to be maintained for any management tasks on the security artefacts, such as moving the location of JWKS_URI or rotation of client certificates.

JWKS public/private key management services could still be offered by the provider. This is left to the arrangement between the principal and provider.

NOTE: any software products owned by the principal which are not part of the collection arrangement, will need to belong to a separate brand, as illustrated in Figure 3. For help creating new Brands, refer to the section ‘Maintain Brand Details’ in the CDR Participant Portal User Guide (ref section 8.2 in version last updated in May 2020).

Figure 3: Principal in a collection arrangement with a separate Brand for a second software product

Release 2: Early 2021

The CDR Register will provide additional functionality to allow the ecosystem to accommodate more complex collection arrangement relationships.

Authentication with the CDR Register will be permitted at the software product level, using the software product ID as the client ID, as opposed to the current data recipient brand ID. This will allow software products to have independent authentication details (via the JWKS_URI being available at the software product level).

Providers will have the ability to manage software product technical details on behalf of a principal and can provide services to independently manage security artefacts at the software product level instead of brand, i.e. moving the location of the JWKS_URI or rotation of client certificates.

Release 2 functionality will remove restrictions on how software products are managed. Principals can choose to engage multiple providers for multiple software products, or manage a subset of their own software products, all under the same brand entity as illustrated in Figure 4.

Figure 4: Principal in a collection arrangement with multiple products for a single brand

 

Design Considerations: JWKS Key Management

JWKS key management is required to facilitate client authentication as described in the Consumer Data Standards. 

Control of the domain hosting the software product JWKS_URI needs to be well thought out prior to entering into a collection arrangement.

There is benefit in the principal maintaining control of the JWKS_URI domain while allowing the provider to manage its contents. This gives the principal flexibility to move ownership of the JWKS_URI management tasks away from the provider at a future date, if and as required.

If the provider maintains control over the domain, principals may lose the ability to authenticate with the data holder brand, introducing the following consequences in an anticipated sequence of events:

1. Provider controls JWKS_URI domain for the software product
2. Software product is registered with data holder brand by the provider, authenticating with keys controlled by the provider
3. Principal chooses to exit the collection arrangement and changes the JWKS_URI to a domain controlled by the principal
4. Principal attempts to update their software product registration with the data holder brand but does not have access to the equivalent keys to those hosted in the previous provider controlled JWKS_URI. Authentication therefore fails.
5. Principal no longer has control over their registration and will need to engage the data holder to re-establish trust