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: 7.6. <ins> A workload and Transaction Token Service MUST perform mutual authentication. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so: <del> It MUST name a limited, pre-configured set of workloads that MAY request Txn-Tokens </del> <ins> It MUST maintain a limited, pre-configured set of authorized workloads that MAY request Txn-Tokens. It MUST authenticate the requesting workload and confirm that it is included in the list of workloads authorized to request a transaction token. </ins> <del> It MUST individually authenticate the requester as being one of the named requesters </del> <ins> It SHOULD accept workload credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as SPIFFE or other provisioning protocols. </ins> <del> It SHOULD rely on mechanisms, such as SPIFFE used in conjunction with MTLS RFC8446, or some other means of performing MTLS, to securely authenticate the requester </del> <ins> It SHOULD use X.509 credentials in conjunction with MTLS RFC8446, or a JWT protected by TLS at the transport layer, to securely authenticate the requesting workload. </ins> It SHOULD NOT rely on insecure mechanisms, such as long-lived <del> shared secrets to authenticate the requesters </del> <ins> shared secrets to authenticate the requesting workloads. The requesting workload MUST ensure that it authenticates the Transaction Token Service.  In order to do so: It MUST have a pre-configured location for the Transaction Token Service. </ins> <del> The requesting workload MUST have a pre-configured location for the Transaction Token Service.  It SHOULD rely on mechanisms, such as SPIFFE, to securely authenticate the Transaction Token Service before making a Txn-Token Request. </del> <ins> It SHOULD accept Transaction Token Service credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as SPIFFE or other provisioning protocols. It SHOULD use X.509 credentials in conjunction with MTLS RFC8446, or a JWT protected by TLS at the transport layer, to securely authenticate the Transaction Token Service. It SHOULD NOT rely on insecure mechanisms, such as long-lived shared secrets to authenticate the Transaction Token Service. </ins> 8.