This spec should support an Option that builds on secure Workload Transport-layer authentication. Well-established protocols exist for Workload-to-Workload communication over mutually authenticated TLS 1.3.

I would like to propose an Option 3: Transport-layer Proof-of-possession, with a reference to the TLS credential used in the cnf claim of the WIT, based on https://datatracker.ietf.org/doc/html/rfc8705#section-3.1.

1. In the section The Workload Identity Token {#to-wit}, change the description of cnf to the following:

• cnf : A confirmation claim containing either the public key of the workload OR a cryptographically strong hash of the X.509 certificate conveyed during Transport layer security.
  • The public key cnf contains the jwk member as defined in {{Section 3.2 of RFC7800}}. The workload MUST prove possession of the corresponding private key when presenting the WIT to another party, which can be accomplished by using it in conjunction with one of the methods in {{dpop-esque-auth}} or {{http-sig-auth}}. As such, it MUST NOT be used as a bearer token and is not intended for use in the Authorization header.
  • The X.509 certificate hash cnf contains the x5t#S256 hash as described in Section 3.1 of [RFC8705]. When this value is provided, Proof-of-possession is delegated to the Transport-layer. The receiving Workload MUST verify that the x5t#S256 claim matches the hash of the Client's X.509 Certificate presented at the Transport-layer.

2. Add the following sub-section after Option 2: Authentication Based on HTTP Message Signatures {#http-sig-auth}:

Option 3: Transport-layer Proof-of-possession

In the case where Workload-to-Workload communication is secured by Mutually-authenticated Transport Layer Security 1.3, Proof-of-possession is conveyed via each Workload's CertificateVerify message. In this case, the Transport-layer guarantees that each Workload has already validated its Peer's Proof-of-possession of the Private Key. Proof-of-possession is conveyed during the TLS 1.3 handshake protocol using each peer's Certificate and CertificateVerify messages, along with other protocol messages transmitted. The Transport-layer must cache the SHA-256 hash of the validated Client Certificate and the first Subject Alternative Name (SAN) URI entry for use at the Application-layer. When the Destination Workload receives a WIT at the Application-layer with cnf claim with x5t#S256 property, it MUST establish Proof-of-possession as follows:

• Validate that the Certificate-bound WIT's cnf claim's x5t#S256 property matches the cached SHA-256 hash of the validated Client Certificate.
• Validate that the WIT's sub claim matches the first Subject Alternative Name (SAN) URI entry.

The first step proves that the WIT was issued to the holder of the PrivateKey for the X.509 Certificate presented by the client, and that Private Key was used to establish the mTLS session over which the WIT was transmitted. The second step validates that both the X.509 Certificate and the WIT were issued to the same Workload.