CDR Register Client Authentication

Introduction

The Consumer Data Standards version 1.9.0 introduced private_key_jwt authentication and access token usage against the data holder admin endpoints, including GetMetrics.

Github #360 was used to track collaboration through the design process.

This issue resulted in the following updates to the client authentication section of the CDS security profile

Data Holders SHALL authenticate the CDR Register client using one of the following Client Authentication methods:

• • • Self-signed JWT client assertion authenticated by the protected request endpoint according to Self-signed JWT Client Authentication, or
    • private_key_jwt authentication using client_credentials authorisation grant flow according to Private Key JWT Client Authentication.

This functionality allows for data holders to choose which client authentication mechanism they use to protect these endpoints.

1. Self-signed JWT Client Authentication

The previous and current designs allowed for a self-signed token to be created by the CDR Register to authenticate against the admin endpoints.

2. private_key_jwt authentication using client_credentials

The addition of private_key_jwt authentication using the client_credentials grant to retrieve an access token to use against the admin endpoints allows for data holders to treat these endpoints consistently with their resource APIs.

The addition of the admin:* scopes allows the admin endpoints authorisation to be constrained to access tokens issued to the CDR Register.

Creating CDR Register Registration

Data holders choosing to adopt the private_key_jwt authentication mechanism at their admin endpoints must manually register the CDR Register as a client in their IDP. The associated client_id must then be persisted against the associated record (Data Holder Brand) in the CDR Participant Portal. The data holder technical contact has the appropriate role to set this record.

Example: CDR Register retrieving GetMetrics data

During metrics collection, the CDR Register checks whether a client_id is registered against the data holder brand being called. A registered client_id infers private_key_jwt client authentication is available to the CDR Register. The Register retrieves an access token from the data holder token endpoint using the client_credentials grant. The data holder authenticates the CDR Register using the private_key_jwt authentication mechanism and then issues an access token with the appropriate admin.* scopes.

This short-lived access token is then presented at the appropriate admin APIs and in this case, can be used to retrieve data holder metrics

Please refer to CDS and GitHub issue #360 to familiarise yourself with the collaborative input used to reach this outcome.