Determine whether key binding can be extended to CIBA, PAR, Token Exchange and other grant types

Split out of #20, which is now closed by #26.

#26 states that this specification defines key binding for the Authorization Code Flow and the Device Authorization Flow, that the Implicit Flow MUST NOT be used to obtain a key-bound ID Token, and that other flows are out of scope. That resolves the first half of #20.

This issue tracks the second half, as @fkj put it:

Work on determining whether anything is blocking people from potentially extending the spec to also support CIBA, PAR, etc.

Flows raised so far:

• CIBA
• Pushed Authorization Requests (RFC 9126)
• Token Exchange (RFC 8693) — previously discussed in #12, where the authorization code and device code flows were chosen instead
• Identity Assertion JWT Authorization Grant

The specific question for each is whether a value equivalent to c_s256 exists to bind the DPoP proof to the authentication session, since that is what the Authorization Code Flow and Device Authorization Flow rely on to prevent public key substitution.

Raised by @adeinega in #20 and on the list: https://lists.openid.net/pipermail/openid-specs-ab/2026-June/011355.html

Start by reading the key-binding conclusions in #26, the original discussion in #20, and the prior Token Exchange discussion in #12. Compare CIBA, RFC 9126, RFC 8693, and the Identity Assertion JWT Authorization Grant with the existing c_s256 and DPoP binding approach. Done means documenting whether an equivalent value exists for each flow and identifying any blockers to extending the specification.