Code change:
In response to Updated section on: Mutual Authentication Security Considerations for Client Authentication Added security considerations for protecting the workload configuration NAME NAME
I wonder if we can clarify the guidance in Section 7.4 a bit: From: It SHOULD rely on mechanisms, such as Spiffe or some other means of performing MTLS [RFC8446], to securely authenticate the requester. To: It SHOULD rely on JWT or X.509 credentials, which may be provisioned using SPIFFE or other mechanisms, to securely authenticate the requester. The final sentence in section 7 probably also needs a bit of clarification: It SHOULD rely on mechanisms, such as [Spiffe], to securely authenticate the Transaction Token Service before making a Txn-Token Request. I think the requirement here should be that the Transaction Server should be authenticated to the workload using a JWT or X.509 certificate, which may be provisioned using SPIFFE or another mechanism and used with a secure protocol like MTLS or using the WIMSE service-to-service authentication mechanisms.
I think clarifying this would be good (Section 7.6:) For me the key is that any workload invoking the TTS must use some form of strong client authentication. That could be SPIFFE, privatesecretjwt, mTLS, ??? The normative requirement should be "strong client authentication" and the others can be examples of such. I'm not sure how the workload can "pre-authenticate" the TTS. I like the pre-defined endpoint (or maybe "pre-configured" endpoint) concept. Basically, the TTS should be at a well known location. I guess there is a security issue if the workload sends an accesstoken to the wrong server especially if the external accesstoken is a bearer token. Is this something we should just cover in the Security Considerations section?
I think you touch on a few things here: We don't address discoverability of transaction token servers. Should we add something (e.g. define a well known endpoint, include discovery metadata in the authorization server metadata etc?) Can you say more about "pre-authenticate"? Do you mean some mechanism whereby the workload can trust the TTS or the location of the TTS? Agreed on the security considerations for ensuring that the access token is not sent to an incorrect endpoint (I can imagine an adversary getting into a build server, modifying the TTS location for a workload, and then have the TTS send tokens to it. I can also imagine this happening by accident, especially if there are multiple TTS's in a deployment.
Regarding the second point: Yes, should there be a way for the workload to determine it can trust the TTS before sending it an external token? This isn't something that is common in OAuth specs. It is assumed that the client knows whether to send the request or not.
Regarding 1: I think we wanted to talk about it at the last IETF and ran out of time. I seem to remember a few conversations around "discovery" but nothing concrete was decided.
I found the issue it's

Related discussion:
text: and failed transactions.  It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the "txn" value. <ins> 9.8. A workload may be configured to access more than one instance of a Transaction Token Service to ensure redundency or reduce latency for transaction token requests.  The workload configuration should be protected against unauthorized addition or removal of Transaction Token Service instances.  An attacker may perform a denial of service attack or degrade the performance of a system by removing an instance of a Transaction Token Service from the workload configuration. 9.9. A workload may accidently send a transaction token request to a service that is not a Transaction Token Service, or an attacker may attempt to impersonate a Transaction Token Service in order to gain access to transaction token requests which includes senstive information like access tokens.  To minimise the risk of leaking sensitive information like access tokens that are included in the transacation token request, the workload must ensure that it authenticates the Transaction Token Service and only contact instances of the Transaction Token Service that is authorized to issue transaction tokens. </ins> 10. 10.1.