Hi Emelia, I think this makes total sense and should be adopted. I would certainly implement this in our products immediately after standardization since we already have a proprietary mechanism that does the same thing.
Overall, I think the draft is well written and explains the relevant considerations in a good way. I have a few minor comments after reading the draft: 1. You write: "A requirement that a specific client always uses DPoP is instead expressed using the dpop_bound_access_tokens client metadata parameter (Section 5.2 of [RFC9449])." I think this wording is a bit strange since this is a different source of requirements, right? It is declared by the client, not the AS. This got me thinking about Nick's proposal from a while ago, which I think would make more sense for this kind of signaling: https://mailarchive.ietf.org/arch/msg/oauth/Z-uDsLi97benA3irxfCzotj7mnA/ 2. In the example metadata, you have EdDSA as one of the alg values, but that might not be the best example since EdDSA is marked deprecated in the registry. Might use e.g. ML-DSA-44 instead? 3. You write "a resource server that does not support DPoP will reject such requests." I'm not sure this is 100% true as written, since a poorly implemented RS might just ignore the DPoP header completely and allow unauthenticated access. I get what you mean though, and it is an important consideration to keep in mind when using this. On another note, maybe this text belongs in an implementation consideration section? Cheers, *Frederik Krogsdal Jacobsen* Staff Engineer, Identity Standards IDURA <https://idura.eu> On Mon, 2 Nov 2026 at 23:12, Emelia S. <emelia= [email protected]> wrote: > Hi all, > > Following a review / feedback on the CIMD draft from Max Gerber, we > realised that there was no way for an Authorization Server to signal to a > client that it always required DPoP bound access tokens. The only way to > currently indicate this was at a resource server level, not an > authorization server. > > As such I've written up a first draft of adding > `dpop_bound_access_tokens_required` to Authorization Server Metadata > (RFC8414) via the appropriate registry: > > > https://datatracker.ietf.org/doc/draft-emelia-oauth-as-metadata-dpop-required/ > > I think there may still be some changes required, but wanted to publish > now such that we can discuss briefly at IETF 127 since it relates to the > new version of CIMD. > > Yours, > Emelia Smith > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
