In the client authentication method using WIT-SVID defined in draft 01 of the OAuth SPIFFE Client Authentication specification (hereafter referred to as spiffe_wit), applying the concepts of OAuth 2.0 Attestation-Based Client Authentication (hereafter ABCA) is reasonable. However, having it encroach upon the ABCA specification raises the following issues.
- According to the WIMSE Workload Credentials specification, the
sub claim of a Workload Identity Token (hereafter WIT) must be an identifier of the workload. On the other hand, in ABCA, the sub claim of a Client Attestation must be an identifier of the OAuth client. Since a workload and an OAuth client are not necessarily in a one-to-one relationship, using a WIT as a Client Attestation leads to a conflict in the requirements for the sub claim.
- In addition, there is an attempt to make ABCA implementations accept
wit+jwt as a value of the typ of a Client Attestation JWT, in addition to oauth-client-attestation+jwt.
These issues can be avoided by modifying the specification as follows:
- Use the
Workload-Identity-Token HTTP header instead of the OAuth-Client-Attestation HTTP header. This header is defined in the WIMSE Workload Credentials specification.
- Introduce and use a new
Workload-Identity-Token-PoP HTTP header instead of the OAuth-Client-Attestation-PoP HTTP header. (This new header would likely be better defined in the WIMSE Workload Credentials specification rather than in the OAuth SPIFFE Client Authentication specification.)
Since a WIT does not contain information identifying the OAuth client, when using the revised spiffe_wit client authentication, a separate client_id request parameter would be required. The server implementation would then, similar to the case of spiffe_jwt client authentication, verify that the value of the spiffe_id client metadata parameter of the OAuth client identified by the client_id request parameter matches the value of the sub claim in the WIT.
In the client authentication method using WIT-SVID defined in draft 01 of the OAuth SPIFFE Client Authentication specification (hereafter referred to as
spiffe_wit), applying the concepts of OAuth 2.0 Attestation-Based Client Authentication (hereafter ABCA) is reasonable. However, having it encroach upon the ABCA specification raises the following issues.subclaim of a Workload Identity Token (hereafter WIT) must be an identifier of the workload. On the other hand, in ABCA, thesubclaim of a Client Attestation must be an identifier of the OAuth client. Since a workload and an OAuth client are not necessarily in a one-to-one relationship, using a WIT as a Client Attestation leads to a conflict in the requirements for thesubclaim.wit+jwtas a value of thetypof a Client Attestation JWT, in addition tooauth-client-attestation+jwt.These issues can be avoided by modifying the specification as follows:
Workload-Identity-TokenHTTP header instead of theOAuth-Client-AttestationHTTP header. This header is defined in the WIMSE Workload Credentials specification.Workload-Identity-Token-PoPHTTP header instead of theOAuth-Client-Attestation-PoPHTTP header. (This new header would likely be better defined in the WIMSE Workload Credentials specification rather than in the OAuth SPIFFE Client Authentication specification.)Since a WIT does not contain information identifying the OAuth client, when using the revised
spiffe_witclient authentication, a separateclient_idrequest parameter would be required. The server implementation would then, similar to the case ofspiffe_jwtclient authentication, verify that the value of thespiffe_idclient metadata parameter of the OAuth client identified by theclient_idrequest parameter matches the value of thesubclaim in the WIT.