Dynamic Client Registration & JWKS endpoints

[ryderwj]

As part of dynamic registration, we will need to access the JWKS endpoint of the Data Recipient. I understand that the JWKS URI is first determined from information in the SSA. Are there any plans to hold base path information in the registry for data recipients in the same manner as for data holders should an organisation want to restrict outbound connections to just those predefined by the registry?

[perlboy]

@ryderwj The SSA results in non-repudiation of the Recipient from the Register containing JWKS details, expires quickly and is not reusable. Retrieving JWKS "out of band" without a matching assertion could represent security risk to a Holder.

Restricting outbound traffic to a list of JWKS endpoints will likely be ineffective as Recipients are probably quite likely to host them on a CDN with numerous and constantly rotating IPs.

Is there something wrong with the protections PS256 signing provides?

[ryderwj]

Hi @perlboy - this wasnt to perform out of band JWKS retrieval - this was more about needing to permit unrestricted outbound requests to enable the process.

[perlboy]

Hi @perlboy - this wasnt to perform out of band JWKS retrieval - this was more about needing to permit unrestricted outbound requests to enable the process.

@ryderwj Define "process". The call to /register assumes a call to the jwks_uri will be made which could be hosted literally anywhere by the Recipient.

[CDR-Register-Stream]

@ryderwj and @perlboy. Thanks for your query.

For Dynamic Client Registration to occur in real-time, DHs will need to be able to call external JWKS endpoints they have not encountered previously, in real-time. Without this ability, this becomes an asynchronous activity which the ADR will not be expecting.

Currently the Register stores the JWKS path in the Register but does not expose it on any API. @ryderwj I understand that you're querying whether the discovery APIs could be extended so you can get this information ahead of time. This functionality was not anticipated as a requirement for DCR and I'd like to understand the implications of having unrestricted outbound requests given the cryptographic assurances of the security profile.

[ryderwj]

Thanks @CDR-Register-Stream. Trusting the registry issued SSA is not the issue. This was more related to the standard security posture and supporting infrastructure applied organisationally which does not automatically allow access to locations that have not been previously whitelisted. If the location was supplied in advance it could be integrated with this process. It is solvable, but with a more complex solution.

[perlboy]

@ryderwj The challenge here is ("was", during design I initially thought we should whitelist too) what would be supplied in advance. JWKS endpoints can be (and are generally intended to be) distributed via a CDN which means IP allowances are next to useless. Hostname whitelisting is one other alternative but this would involve forcing Holder's into architectural decisions (TLS Proxy, DNS snooping/modification) while also not protecting against the tampering whitelisting is seeking to solve.

I understand the "standard security posture" response although my experience is this has been more emanating from border network administrators who want to solve all problems in layer2/3 rather than considering the layer 5-7 protections that dynamic registration methods use. Arguably if a banks employees have access to Google in the workplace they have already solved for this problem.

There are some other solutions notably including a JWKS checksum in the SSA but this has race conditions, increases implementation complexity and doesn't actually solve the problem at layer2/3 (so those netadmin's are still going to be upset).

As it stands:

• An SSA can only be downloaded from the Register by authorised clients (ie. Holders and ADRs)
• The SSA is signed by the Register and can be cryptographically verified
• The SSA contains a JWKS endpoint
• The Dynamic Client Registration request is signed by a Recipient using one of the keys available at this endpoint and this DCR is intended to be single use
• After registration the JWKS endpoint is registered with the Holder although the signing keys can be rotated so should be refreshed "regularly"
• After registration resource server access is constrained to an MTLS channel using the Register CA so, even if a "false" client registration was successful, accessing Consumer Data would also require the Recipients certificate as well

[CDR-Register-Stream]

Thank you @ryderwj and @perlboy for your contributions on this issue.

From my perspective, there are two considerations here:

1. The constraints of this standard security posture need to be elaborated on so they are fully understood and considered, both for current participants and those that are in development. Constraining this discussion to the Register repository is counter-productive and this should be discussed in the DSB standards-maintenance repository to ensure we have a wider (perhaps wiser) audience.

2. Understanding how widespread these concerns are is important. It is all well and good to raise a concern but we need to understand whether it is isolated or a common issue among participants. Any feedback which DHs and vendors can provide on their current / future implementations would be much appreciated.