Client Authentication Mechanisms

[PieterKas]

WGLC Feedback from @bc-pi

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.1-6 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-mutual-authentication-of-th
I know there's some desire to use OAuth 2.0 Token Exchange [RFC8693] without necessarily pulling in all the other features/baggage of being an full blown authorization server but I find it hard to reconcile that a requesting workload is required to authenticate, the exact client authentication mechanism is out of scope, there are quite a few exact normative requirements about client authentication mechanisms (including a MUST on pre-configured sets?!), and there's no mention or acknowledgement of the existing standardized mechanisms for client authentication to an authorization server. Self-signed subject tokens and actor tokens seem potentially topically relevant as well.

Also

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-client-authentication
The first sentence is redundant with OAuth 2.0 Token Exchange itself. Sometimes restating things is worthwhile but I don't think that's the case here.
The second sentence with "the actor_token MUST authenticate the identity of the requesting workload" seems overly restrictive. What if the authentication has happened via other means and the actor_token is there to convey some other notion of delegation or something?
There's a lot more to "Client Authentication", the section name, than these two sentences. Consider something different. Or something.

[PieterKas]

Agreed on the need for consistency here.

I think want to:

1. Strongly encourage client authentication (hence the MUST - but perhaps it should be a SHOULD).
2. Strongly discourage client secrets (secret sprawl is a huge mess)
3. Encourage public key based methods, signed JWTs or WIMSE based authentication mechanisms (which are also public key based mechanisms).
4. Give guidance on deployment choices etc.
5. Avoid inventing anything new

@bc-pi - any concerns with those as goals?

I will work on text throughout the document to have a bit more consistency here (with a goal to say less and point to existing mechanisms wherever possible).

[PieterKas]

See PR #239 as an attempt to simplify and clarify. Feedback on ways to further improve it most welcome.