JSON Web Token (JWT)

Introduction

The following are notes on the use of JSON Web Tokens (JWTs) in the context of the Consumer Data Standards. Refer to the open standards documentation for full information on JWT and related standards.

See:

• RFC 7519

Certificate Requirements

Certificates issued by the CDR CA (Consumer Data Right Certificate Authority) are used only for mTLS (mutual Transport Layer Security).

Other keys, such as the JWKS for JWT signing and encryption, are created by the participant and the public side of the key pair published by their JWKS end point.  These keys are not issued by the Register.

As certificates are bound to domain, multiple certificates are issued only if multiple domains are used for base URIs. Certificates are not issued separately based on use or concern.

There is no need to use the certificates provided by the CA for signing or encryption.  The certificates and the JWKS are entirely independent.

The algorithm used for signing and encryption is communicated between the ADR (Accredited Data Recipient) and the DH (Data Holder) using the OpenID Discovery protocol, for DH capability, and via the information obtained via dynamic client registration, for ADR capability.

PAR client id

The client_id is required in the request syntax and the request object passed to the PAR (Pushed Authorization Request) and authorize endpoint. This is required by oAuth 2.0 and is covered in OIDC section 6.1. The client_id is not in the client_assertion itself but in the request syntax and request object JWT.

A valid OAuth 2.0 Authorization Requests MUST include values for the response_type and client_id in the OAuth 2.0 request syntax. The values for these parameters MUST match those in the Request Object, if present.

Client authentication and client_id

In CDS Client Authentication, the standards state the mTLS is not to be used for client authentication. Data Holders validate the client using Self-signed JWT Client Authentication, or private_key_jwt authentication using client_credentials authorisation grant flow according to Private Key JWT Client Authentication.

The JWT presentation of the client registration performs a proxy for client authentication before the client is registered and a client_id is issued by the DH. This binds the SSA (Software Statement Assertion) to the request made by the anonymous client seeking registration. The DH can then validate the outer registration JWT by checking it was signed using the key of the ADR listed via the ADR's jwks_uri endpoint which is provided in the SSA JWT signed by the Register. 

The DH can validate that the SSA was signed using the key of the Register, by verifying it against the associated JWK published at the CDR Register JWKS endpoint.

The client_id is sent to identify the confidential client when sending requests to the token endpoint, as part of authenticating its client credentials. See section 3.2.1 of RFC6749. The client_id is required for requests utilising mutual-TLS client authentication in RFC8705.
The requirements, for passing and validating the client_id or other required parameters defined in the Private Key JWT client authentication section, apply to any CDS endpoints that require Private Key JWT client authentication.

The client_id is the value the DH issues to the confidential client (ADR software product) as part of Dynamic Client Registration. The subject in this instance is the confidential client.

The client_id should be validated against the subject claim value in the client-assertion and rejected if the client_id in the request is different to the subject claim in the client-assertion.

CDR Register Client Authentication

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.

Admin API - Clarification regarding authentication

For the CDR  Register connecting to the Get Metrics endpoint, the issuer is the CDR Register and their signed JWT will be presented in the Authorisation header as a bearer token.

Note that the JWKS endpoint for the CDR Register is not publicly available - it is supplied to Data Holders as part of the onboarding process with the CDR Register.

Subsections