Standard appears to redefine requirements for private_key_jwt authentication

[perlboy]

Description

As highlighted in Sandbox Issue 4 the Standards appear to have conflicting information in that they state that for private key client authentication:

Authorisation Servers MUST support the authentication of clients using the private_key_jwt Client Authentication method specified at section 9 of [OIDC].

But then indicate:

The aforementioned assertion MUST be sent to the Authorisation Server's Token endpoint with the POST method and MUST include the following REQUIRED parameters and MAY contain the following OPTIONAL parameters:
grant_type - REQUIRED. The grant type(s) supported by the Authorisation Server.
client_id - REQUIRED. The client ID of the bearer.

This appears to be in conflict with the underlying spec linked from OIDC, OAuth Assertions which includes:

client_id
OPTIONAL. The client identifier as described in Section 2.2 of
OAuth 2.0 [RFC6749]. The "client_id" is unnecessary for client
assertion authentication because the client is identified by the
subject of the assertion. If present, the value of the
"client_id" parameter MUST identify the same client as is
identified by the client assertion.

Essentially the Standards seem to add the client_id requirement over the top of the underlying spec?

Area Affected

Client Authentication

Change Proposed

The Standards seem to be restating client authentication and in doing so seem to be redefining it.

Suggest one of the following:

1. Remove references to assertions and parameters for private_key_jwt and simply defer to the upstream Standard (making client_id optional as a parameter in the process)
2. Remove references to OIDC Section 9 and therefore prescribe a "modified" client_credentials authentication mechanism

DSB Proposed Solution

The current DSB proposal for this issue is in this comment

[ACCC-DF]

Just to add some additional data to this issue, as mentioned in the CDR Maintenance Iteration call on the 05/10/2022, when using OIDF's Conformance Suite to test a Data Holder Auth Server's conformance to FAPI, the client_id parameter is not sent to the Auth Server's token endpoint by the FAPI clients. An example token request from the conformance suite is included below (trimmed with new lines for readability):

grant_type=authorization_code
&code=d0addfa6-529c-42aa...
&redirect_uri=https%3A%2F%2Fwww.certification.openid.net%2Ftest%2Fa%2Fcdr-auth-server%2Fcallback
&client_assertion=eyJraWQiOiI3RUZBODVDMThGR....
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&code_verifier=g3JZ0JatPK7Jm....

Therefore, if a Data Holder Auth Server follows the Consumer Data Standards and requires a client_id parameter in the token request, they would reject the token requests from the FAPI clients running in the FAPI conformance suite and would not be able to successfully complete FAPI Conformance Testing, unless they change their solution to workaround the restriction.

[markverstege]

This was discussed in the last MI call. No objections were raised with make the client_id optional. In doing so that would achieve successful FAPI conformance testing. It was noted that if the change is adopted that the obligation date for the change should be bundled with other uplift work such as FAPI 2.0.

[CDR-API-Stream]

Discussed in last week’s maintenance iteration call the primary driver to bring this change forward is to facilitate FAPI 1.0 certification testing.

The change being proposed is a relaxation of the REQUIRED statement to OPTIONAL. This defers to the upstream RFC7521 standard. The area affected is the Private Key JWT Client Authentication section of the data standards.

Considerations in regards to this change:

• This change will need to be facilitated through a future dated obligation imposed on data holders
• Relaxing this requirement would be a change for Data Holders but would not materially change ADR implementations because they can continue to send a client authentication assertion including the client_id.
• iss and sub claims must still be present and must still be the client ID of the bearer. Therefore, there is no security consideration raised with this change. See OIDC for private_key_jwt client authentication requirements.
• If present, the client_id claim must be verified in accordance with RFC7521.
  • It must represent the client ID of the bearer
  • It must be validated to be the same as the iss and sub claims
  • In other words, the Data Holder still has an obligation to verify, but must accept a client authentication assertion where the client_id is not presented

Future Dated Obligation

Feedback is requested for adoption of a future obligation date. Given the maintenance iteration is mid-way through, it is proposed that 13/11/2023 be set for the obligation date (Y23 #5 obligation milestone).

[CDR-API-Stream]

As discussed in the maintenance iteration call, both Data Holders and the CDR Register require clients to authenticate using the Private Key JWT method under certain scenarios. The original proposal focused on the Data Holder changes, however there is also the consideration of changing the CDR Register.

Client Authentication Flow	Client / RP	OpenID Provider
ADR authenticating to Data Holder	ADR	Data Holder oAuth Token endpoint CDR Arrangement Revocation Endpoint
CDR Register authenticating to Data Holder	CDR Register	Data Holder Endpoints: oAuth Token endpoint Admin → Get Metrics Admin → Metadata Update
ADR authenticating to CDR Register	ADR	CDR Register Endpoints: oAuth Token endpoint Get Data Holder Brands Get Software Statement Assertion (SSA)

The driver for this change is to allow Data Holders to pass FAPI testing certification. There is less of a driver for the CDR Register to make this change because ADRs are already integrated. There may be a benefit to ADRs calling the CDR Register if the commonly used client libraries offer limited support for including the client_id in the assertion. However it is also likely this issue has already been dealt with given the number of ADRs already in the ecosystem.

The other benefit for the CDR Register following suit is consistency. That said, the ACCC would need to weigh these potential benefits against their existing implementation cost and the cost to change.

Change Impact

Given that ADRs are currently required to send the client_id when authenticating with the CDR Register, either option for the CDR Register would still permit both ADRs and Data Holders to continue sending client authentication requests without change. Changing the requirement on the CDR Register would seem to be less of a critical need compared to permitting Data Holders to stop mandatorily requiring the client_id. By relaxing this requirement on the CDR Register it would enable the CDR Register to also defer to upstream standardards although it is anticipated that the build cost associated with this requirement has already been realised.

Client Authentication Flow	Client / RP	OpenID Provider	Existing Client impacts	New Client impacts	OP impacts
ADR authenticating to Data Holder	ADR	Data Holder	None. ADRs can continue to send client_id	New ADRs need to ship the client_id if they go live before the Nov 13 2023 obligation date	DHs must allow client assertions that don't provide the client_id. When present, DHs must continue to validate the client_id is the same as the iss and sub claims
CDR Register authenticating to Data Holder	CDR Register	Data Holder	None. The CDR Register can continue to send client_id	N/A	DHs must allow client assertions that don't provide the client_id. When present, DHs must continue to validate the client_id is the same as the iss and sub claims
ADR authenticating to CDR Register	ADR	CDR Register	None. The ADR can continue to send client_id	New ADRs need to ship the client_id if they go live before the Nov 13 2023 obligation date	CDR Register must allow client assertions that don't provider the client_id. When present, the CDR Register must continue to validate the client_id is the same as the iss and sub claims

Phasing in

During the MI call, an option was presented to phase in Data Holder supportability. The suggestion was to vary the REQUIRED condition to RECOMMENDED before setting it to OPTIONAL to permit Data Holders to progressively migrate.

// Now
client_id - REQUIRED. The client ID of the bearer.

// Next
client_id - RECOMMENDED. The client ID of the bearer.

// Final
client_id - OPTIONAL. The client ID of the bearer.

In doing so, any ADR that does not send the client_id may be rejected by the individual Data Holder because they are enforcing the required condition until such time as the obligation for the optional condition is due. Up until that time, Data Holders wishing to defer to the upstream specification can do so immediately. In this situation, the Data Holder can accept client assertions that do not have the client_id provided they are verifying the client assertion is valid (and both the iss and sub match the known client). Data Holders that defer to the upstream specification must continue to verify the correctness of the client_id when presented.

During the transtion time it would be expected that ADRs would continue to send the client_id to avoid any rejected client authentication requests. Equally there is still no impetus for ADRs to remove the client_id after the client_id is made optional because their software will continue to work unaffected.

Similarly, the same logic can be applied to the CDR Register (and clients calling the CDR ) if it seeks to align to the upstream normative standards.

It would be expected that CTS would continue to test clients are presenting the client_id during the intervening transition period.

Given ADRs (and the CDR Register when calling the Data Holder) are currently required to provide the client_id it isn't necessary to phase out client functionality because it is a lowering of their current requirement.

Transition period

If the assumptions above hold correct, then the proposal is that the "RECOMMENDED" requirement be introduced without a future dated obligation whilst the "OPTIONAL" requirement be introduced with a 13/11/2023 obligation date Y23 #5 obligation milestone.

Wording of proposed changes

Until November 13th 2023
client_id - RECOMMENDED. The client ID of the bearer.

From November 13th 2023
client_id - OPTIONAL. The client ID of the bearer.

Whilst RFC6749 states that client_id is optional, it requires that the client_id be validated agains the client assertion's sub claim. Is it worth reiterating the statement in RFC6749 or including a statement to the effect of "in accordance with [RFC6749]" to the description?

E.g.,

From November 13th 2023
client_id - OPTIONAL. The client ID of the bearer in accordance with [RFC6749].

Further, the introductory statement be modified from:

The aforementioned assertion MUST be sent to the Authorisation Server's Token endpoint with the POST method and MUST include the following REQUIRED parameters and MAY contain the following OPTIONAL parameters:

to:

The aforementioned assertion MUST be sent to the Authorisation Server's Token endpoint with the POST method and MUST include the following REQUIRED parameters, SHOULD include the following RECOMMENDED parameters and MAY contain the following OPTIONAL parameters:

[ACCC-CDR]

The ACCC supports making the client_id optional to align to upstream RFC7521 standard and support FAPI certification by participants as proposed in the comment Standard appears to redefine requirements for private_key_jwt authentication · Issue #535 · ConsumerDataStandardsAustralia/standards-maintenance.

The ACCC confirms that the Register changes required to support this standards change are achievable by 13/11/2023 provided the relevant changes are published in the Consumer Data Standards by the 12th of May.

[nils-work]

Changes for this issue were staged here and incorporated into Standards version 1.24.0.