Potential key substitution risk due to missing session-key commitment ?

I would like to ask for clarification upon a potential gap between the authorization session and the final holder key. Currently, there is no cryptographic term linking the End-User's authentication at the AS to the holder key presented later at the Credential Endpoint. This gap persists even when sender-constraining mechanisms like DPoP are strictly utilized. DPoP ensures the token presenter holds the DPoP key (K_{DPoP}), but it does not prove that the End-User authorized the specific credential binding key (K_H). For example, in a split-architecture wallet scenario (Section 13.4), a compromised backend holding a valid DPoP-bound token could unilaterally substitute its own holder key into the proofs parameter. The Issuer would then issue a valid credential bound to the attacker's key, completely unable to verify if this K_H belongs to the original authorized session. A way to prevent this substitution risk may be anchoring the intended holder key to the initial Authorization Request, similar to how the dpop_jkt parameter works in RFC 9449, creating an end-to-end commitment. Or do I miss some other details within the spec? Thank you in advance.

Start with Section 13.4 and trace the Authorization Request, the authorization session, the proofs parameter, and the later Credential Endpoint exchange. Compare the proposed holder-key commitment with DPoP’s dpop_jkt mechanism in RFC 9449. Done should be a decided specification resolution explaining whether the substitution risk exists and, if so, how the end-to-end binding is defined.