Token Request validation never checks the DPoP proof's key against the dpop_jkt declared at the Authentication Request

Summary: The client MUST declare dpop_jkt (JWK Thumbprint of the intended key) at the Authentication Request, but the Token Request checklist only runs RFC 9449 §5 verification and checks c_s256 — it never confirms the DPoP proof's key matches the declared dpop_jkt. dpop_jkt appears exactly twice in this document, both at the Authentication Request, never again.

Evidence: RFC 9449 §10 defines exactly this check: "the authorization server computes the JWK Thumbprint of the proof-of-possession public key in the DPoP proof and verifies that it matches the dpop_jkt parameter value... If they do not match, it MUST reject the request." This profile cites only §5, never §10. Its own c_s256 mechanism proves the proof belongs to this authorization code, not that its key is the one declared — different questions, not substitutes.

Impact: Anyone redeeming the authorization code with any keypair of their choosing gets a valid cnf claim bound to the End-User's identity, with no OP-side check that it's the key originally declared and consented to. PKCE doesn't cover this gap — it authenticates the party, not the key.

Suggested fix: Add a MUST to the Token Request checklist (both flows): the OP MUST verify the DPoP proof's key thumbprint matches dpop_jkt, per RFC 9449 §10.

Note to reviewers: Considered whether citing §5 implicitly carries §10 — unlikely, since the profile's explicit itemized checklist (with its own c_s256 mechanism) argues against silent inheritance. Also worth noting: if the declared dpop_jkt is never checked back at redemption, there's no security reason for it to be a pre-declared Authentication Request parameter at all — a bare DPoP proof taken fresh at the token endpoint, with no prior declaration, would be equivalent under the current checklist. That asymmetry (declare early, never verify) reads more like an oversight than a deliberate scoping choice.

Review the Token Request checklist for both flows and compare its cited RFC 9449 §5 checks with the proof-key check defined in §10. Confirm that the existing c_s256 check is distinct from dpop_jkt matching; done means both Token Request paths explicitly require matching and reject mismatches.