Open standards are central to our work at Cofide. We firmly believe that building best-in-class products in workload identity requires adopting and contributing to both established and emergent industry best practices. In a series of blog posts, we’ll explain recent developments, and demonstrate their relevance in securing modern enterprise architectures.
To kick off, we will present a new and experimental token from the IETF - the Workload Identity Token (WIT) - and how it can be used in conjunction with an existing standard - HTTP Message Signatures - to secure workload-to-workload communications when integrity protections of Transport Layer Security (TLS) are not available, ensuring that zero-trust identity architectures can be deployed across complex trust boundaries.
Organisations such as the Internet Engineering Task Force (IETF) codify consensus technical knowledge into protocols and standards, helping direct the secure and interoperable use of networking technologies. Standards under the governance of the IETF include TLS, HTTP, QUIC, and WebRTC. The IETF is broadly organised into multiple working groups, each with their own remit and area of interest.
While SPIFFE is perhaps synonymous with machine and workload identity at this stage, it is not the only standard in this area. The Workload Identity in Multi-System Environments (WIMSE) working group has multiple draft candidate proposals of increasing maturity, all of which seek to address the myriad challenges associated with securing workloads in diverse and complex environments.
Among these is Workload-to-Workload Authentication Internet Draft (I-D) which, in its own words:
…defines authentication and authorization in the context of interaction between two workloads… define[s] the credentials that both workloads should possess and how they are used to protect the HTTP exchange.
End-to-end transport security via mTLS represents the gold standard for workload-to-workload communication, but this is often not possible in heterogeneous cloud environments. Accordingly, the I-D outlines application-level alternatives and looks to standardise the credentials enabling authentication in these contexts. One such credential is the newly proposed Workload Identity Token (WIT).
At present, the SPIFFE standard supports JWT-SVIDs for application-level workload authentication. Issuing a JWT with custom claims is allowed by SPIFFE, and provides some flexibility for both authentication and authorization purposes. JWT-SVIDs are typically easier to integrate with systems (including legacy) than the corresponding X.509-SVID for transport layer mTLS, especially where TLS might be terminated at some intermediate stage (e.g., with a load balancer or some kind of proxy).
An example JWT for use in a JWT-SVID might look like:
{
...
"typ": "JWT"
}.{
"iss": "spiffe://example.org",
"sub": "spiffe://example.org/...",
"aud": ["spiffe://example.org/..."],
"exp": 1730725200,
"iat": 1730721600,
// Arbitrary claims supported in JWT-SVID
"foo": "bar"
}
Despite its flexibility and interoperable nature, the JWT-SVID does have a few drawbacks which may disqualify it from use in certain use cases (mainly due to its nature as a bearer token):
With these in mind, the Workload Identity Token (WIT) and its upcoming WIT-SVID implementation improve on JWT-SVIDs. The WIT is a signed JSON Web Token (JWT) which represents the identity of the workload it is issued to. This is minted and provided by an identity server (e.g. a SPIFFE Workload API implementation) in the same manner as the JWT-SVID, but its signing process binds the workload’s public key to the WIT-SVID. This makes the WIT a specialised example of the existing JWT credential supported in SPIFFE, providing the ability to perform a PoP evaluation otherwise not possible with the JWT-SVID.
An example WIT is provided here:
{
...
- "typ": "JWT"
+ "typ": "wit+jwt" // Explicit new WIT type
}.{
+ "cnf": { // Confirmation claim, referencing the public key of the workload
+ "jwk": {
+ "alg": "ES256",
+ "k": "MFkw...",
+ "kty": "oct",
+ "use": "sig"
+ }
+ },
- "iss": "spiffe://example.org",
+ "iss": "wimse://example.org", // Issuer of the token, which is the Identity Server
- "sub": "spiffe://example.org/...",
+ "sub": "wimse://example.org/..." // Subject of the token, which is the identity of the workload
- "aud": ["spiffe://example.org/..."], // No longer required
"exp": 1730725200,
"iat": 1730721600,
// Arbitrary claims supported in WIT-SVID
"foo": "bar"
}
As WIT is not a bearer token, the holder must prove possession of the corresponding private key with the public key contents provided in the WIT’s cnf claim. This mitigates against the aforementioned drawbacks seen with the JWT-SVIDs, while maintaining the inherent JWT extensibility (with custom claims). The WIMSE standard proposes two methods for performing this proof process.
One of these methods utilises the established HTTP Message Signatures (RFC 9421) standard to ensure message integrity while demonstrating the caller has the corresponding private key. HTTP Message Signatures provide guarantees about the inbound message by requiring the caller to sign (with a local private key) parts or all of the message before it is sent. This creates a digital signature, which is incorporated in the sent HTTP message headers and then examined by the recipient with the caller’s public key for validation.
As described in the previous section, the WIMSE WIT specification requires the public key of the workload (used in the RFC9421 signing process) to be included in the WIT itself (as the cnf claim), making verification on the recipient side straightforward as the recipient needs only to continue trusting the token issuer.
This is a particularly useful approach when the caller might have to pass through an intermediate (“middlebox” in the draft standard) before reaching the server, and the recipient needs guarantees the request content has not been altered in transit. It also works well even in the case mutating processes do need to alter some aspects of the message on the path from the caller to the recipient: these headers can remain unsigned, and not impact the integrity evaluation of the other relevant message attributes.
Common use cases (which often require TLS termination partway through the full end-to-end) where this could be a consideration include:
Incorporating the WIT and HTTP Message Signatures provides a cryptographically verifiable means to secure workload-to-workload communications when transport layer security is not possible, ensuring that zero trust identity architectures can be deployed across complex trust and organisational boundaries. An existing implementation of RFC9421 (yaronf/httpsign) is used by this demonstration.
The team at Cofide have put together a proof-of-concept implementation of the WIMSE application-level authentication with HTTP Message Signatures methodology for anyone interested in becoming familiar with the standard and the technologies involved. This makes use of our experimental test identity server minispire which issues a developmental version of the proposed WIT-SVID credential to each workload.
An example of the WIMSE-enabled HTTP client making a call (some implementation omitted for brevity):
func (c *Client) getHttp(req *http.Request) (*httpsign.Client, error) {
// Obtain WIT-SVID from identity server. This consists of the WIT
// (WitSvid) and a private key for signing (WitSvidKey)
svid, err := c.GetWITSVID()
...
// Instantiate signer for outgoing messages, using the WitSvidKey
// private key provided by the identity server
signer, err := shared.GetWITHTTPSigner(
svid.WitSvidKey,
signedHeaders,
shared.WithNonce(getNonce(req)),
shared.WithClaims(&claims),
)
...
// Set WIT in message header
req.Header.Set("Workload-Identity-Token", svid.WitSvid)
// Return client with HTTP Message Signatures enabled
return httpsign.NewDefaultClient(httpsign.NewClientConfig()
.SetSignatureName("wimse").SetSigner(signer)), nil
}
When running the proof-of-concept implementation, you’ll be presented with the WIT itself plus the messages on both the client- and server-side.
WIT header and payload:
{
"alg": "ES256",
"kid": "kid",
"typ": "wit+jwt"
}{
"aud": "",
"cnf": {
"jwk": {
"alg": "ES256",
"k": "MFk...",
"kty": "oct",
"use": "sig"
}
},
"exp": 1761818361,
"iat": 1761818061,
"iss": "wimse://example.com",
"jti": "69055e02f3172df4efcf9fbd4ffa1080a7c1ef63d7c9776beaef0a3ed2950658",
"sub": "spiffe://example.com/bin/wimse-9421-client/gid/1000/pid/38898/uid/1000"
}
Request:
GET / HTTP/1.1
Workload-Identity-Token: eyJhbGciO...
Signature: wimse=:uYOTjb4eKf2cBn4Tye...:
Signature-Input: wimse=("@method" "@request-target" "workload-identity-token");created=1761818061;expires=1761818361;nonce="ce5ce6ca2cf748677c5198ffa72f2906a1e3f3eaaf9a8487eea551f2ca469ef0";alg="ecdsa-p256-sha256";tag="wimse-service-to-service"
Response:
HTTP/1.1 200 OK
Workload-Identity-Token: eyJhbGciOiJFUz...
Content-Digest: sha-256=:7JVJmgim6dP1haght1LWmS2hCitii6JgPiDrVLqTclw=:
Content-Length: 23
Content-Type: text/plain; charset=utf-8
Date: Thu, 30 Oct 2025 09:54:21 GMT
Signature: wimse=:YKMb/G/k0t9aTe...:
Signature-Input: wimse=("@status" "date" "workload-identity-token" "content-digest" "content-type" "content-length");created=1761818061;alg="ecdsa-p256-sha256";tag="wimse-service-to-service"
You are very WIMSEcal!
This is an early implementation of an emerging draft standard that remains in active development, and should be considered a demonstrator system. The team at Cofide welcome any contributions or feedback on the project. We look forward to further contribution to WIMSE and sharing more about the emerging standards in future blog posts - stay tuned!
Talk to us for a demo and join our early access programme.
