Authentication mechanisms

[PieterKas]

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.

[gffletch]

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, private_secret_jwt, 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 access_token to the wrong server especially if the external access_token is a bearer token. Is this something we should just cover in the Security Considerations section?

[PieterKas]

I think you touch on a few things here:

1. 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?)
2. 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?
3. 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.

[gffletch]

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.

[gffletch]

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.

[gffletch]

I found the issue it's #95