Add sender constraining mechanisms

[kburgin3]

Add mTLS and DPoP

[bc-pi]

A rough sketch of things that likely need to be accounted for or a least considered in this effort:

• checking the binding on inbound token of Token Exchange request. No standard defined here. Might not even be feasible or make sense depending on deployment (i.e. the RS acting as the client doesn't have access to the bound key)
• binding the token returned from Token Exchange. The request could be MTLS or have a DPoP header, which is kinda implied per standards. And the returned JWT could be bound with the respective cnf claim and method, which is maybe implied by standards but not explicitly written down anywhere (that I know of).
• checking the binding on inbound token/assertion of the Access Token Request. The request could be MTLS or have a DPoP header, which is kinda implied per standards but kinda leaves much to the imagination, and checked against the cnf claim of the JWT authz grant. The presence of the cnf claim might be sufficient to say the thing is bound and suggest/require checking it (implementations I know about would just ignore it, however). But maybe a new grant type would make sense to clearly convey the intent (also using urn:ietf:params:oauth:grant-type:jwt-bearer for a non-bearer thing is awkward).
• binding the resultant access token. The request could be MTLS or have a DPoP header and I think this is covered/implied by the existing specs to say that the issued access token should/could be bound a la DPoP Access Token Request and Mutual-TLS Client Certificate-Bound Access Tokens.

The Authorization server acting as client flips around nearly all of the pieces above to make them unworkable. I guess it'd need separate treatment with the definition of something like a proxied "trust me" this is the cnf I need in the final access token. IIRC Kelley had some prior work toward this end somewhere but I can't seem to find it at the moment. Or maybe sender constraining is just out of scope in the AS as client proxy case.