Clarify jwks vs jwks_uri support

[yissellokta]

The Problem
Section 4.1 pulls in jwks via the DCR registry, but Section 6.3 only discusses rotation/updates for jwks_uri. This leaves the expected behavior for embedded jwks unclear.

The Proposal
I suggest we only support jwks_uri for CIMD and disallow embedded jwks.

Reasons:

• Reduced Complexity: For Dynamic CIMD, the Authorization Server (AS) shouldn't have to re-parse the entire metadata document just to find a key change.
• Clean Invalidation: Invalidation is much cleaner when the cryptographic identity is hosted at a separate jwks_uri rather than inside the metadata.
• Existing Patterns: Current implementations already focus on jwks_uri for dynamic rotation.

Question
Does the group see a hard requirement for keeping jwks embedded, or can we move to a jwks_uri only model to simplify implementation?

[aaronpk]

I would be in favor of this suggestion to remove jwks as an option from the metadata for the reasons described here.

[ThisIsMissEm]

I am aware of in the wild usage of jwks in CIMDs, however, it's not something I'd encourage; using a separate document for JWKS is probably best practice here anyway.

I'd be in favour of deprecation of jwks in CIMDs, and a technical note for why that is the way it is.

[ThisIsMissEm]

@aaronpk I think we'd have to make jwks embedded in a CIMD a SHOULD NOT instead of a MUST NOT, due to the in-the-wild usage currently present. Happy to do up a small pull request for this, that says it's a SHOULD NOT and then explains why that's the case, and why you should use jwks_uri instead.

[btiernay]

I am aware of in the wild usage of jwks in CIMD

@ThisIsMissEm curious, do you have any public examples you can share?

[ThisIsMissEm]

@btiernay smokesignal.events uses it: https://smokesignal.events/oauth-client-metadata.json

I'm sure I've seen other such examples too.

[panva]

I tried approaching this question from many different angles and came to the conclusion that there's little if any reason for a SHOULD NOT/MUST NOT here.

A regular client key rotation during which the client first publishes its new keys but doesn't use them can happen in both jwks and jwks_uri. In both cases the client controls the max-age of the particular http response and in doing so the time it knows to wait before starting to use a new key.

The only reason to push for jwks_uri is the 5kb recommendation on CIMD document size and public key sizes, but who's to say that limit doesn't exist on client's jwks_uri...

I think each client should be able to choose whichever scheme works for its deployment and looking at an AS implementation myself, I have no reason to prefer one over the other. Rotation via jwks_uri is an established pattern. Rotation via natural expiry and regular re-fetching of CIMD document comes out of the box with CIMD

[aaronpk]

My main interest in this is reducing optionality to make things simpler for implementers.