RP Authenticating→Consuming Component proof-of-possession is out of scope, with no minimum security properties defined

Summary: §9.2 requires that an RP Consuming Component "MUST NOT trust an ID Token with a cnf claim without a corresponding proof of possession from the RP Authenticating Component." §7 declares the mechanism for that proof entirely out of scope. No minimum properties — proof of possession of the specific key, replay-resistance, binding to the specific request — are defined anywhere, so two conformant implementations can satisfy "proof of possession" very differently, including weakly.

Evidence: §7: "The mechanism for how an RP Authenticating Component proves to an RP Consuming Component that it possesses the private keys associated with the cnf claim in the ID Token is out of scope of this document." Appendix A's use cases informally reach for "a DPoP proof over that request" as an example, but the appendix itself disclaims this as non-normative: "The mechanism by which an RP Authenticating Component proves possession of the private key to an RP Consuming Component is out of scope of this specification." No normative minimum bar exists elsewhere in the document.

Impact: As written, a literal reading of the MUST is satisfied by any assertion the Consuming Component chooses to call "proof of possession" — including one with no cryptographic binding to the cnf key at all. That defeats the purpose of this entire specification: turning the ID Token from a bearer token into a genuine proof-of-possession token only holds if the internal RP-to-RP-component hop enforces the same property the OP-to-RP hop does.

Suggested fix: RECOMMEND (SHOULD) a DPoP proof per RFC 9449 §4 as the default mechanism for this hop, since the document already profiles DPoP throughout. Require that any mechanism used provide at minimum: proof of possession of the specific cnf.jwk private key, replay-resistance, and binding to the specific request or session.

Note to reviewers: Considered whether leaving this fully open is reasonable given that RP architectures vary (a native app calling a local service vs. a distributed backend may reasonably differ). That's an argument for not prescribing one mechanism — it isn't an argument for defining no minimum properties at all. A floor (possession + freshness + binding) is compatible with letting implementations choose their own transport/format. A separate, sharper objection is also worth naming: this hop is entirely internal to the RP, invisible to any external conformance test, so an editor could reasonably argue a MUST nobody outside the RP can ever verify doesn't belong in a normative interoperability spec at all — the right fix being to downgrade this to non-normative guidance rather than add an unenforceable floor. We think a stated minimum is still worth having (self-conformance MUSTs are common elsewhere in this family), but flag the downgrade-to-guidance path as a fallback resolution the editors might prefer.

Read §7 and §9.2 alongside Appendix A and RFC 9449 §4. Determine whether to define normative minimum properties for possession of the cnf.jwk key, replay-resistance, and request or session binding, or instead downgrade the internal hop to non-normative guidance. Done means the specification has a resolved, internally consistent treatment of this requirement.