WIMSE Workload Credentials (draft-ietf-wimse-workload-creds-03)

In one line: the draft defines the Workload Identity Token (a JWT) and the Workload Identity Certificate (an X.509 certificate) that bind a public key to exactly one Workload Identifier, and revision 03 adds a WIT validation procedure, a rule on the audience of proofs of possession, and stricter binding of trust domains to preconfigured trust anchors.

What this is

• Workloads that call each other need a credential that says who they are and which key they hold. This draft defines two such credentials and nothing about how possession of the key is proven; that is left to companion documents (Section 1).
• The Workload Identity Token (WIT) is a JWS-signed JWT issued by an Identity Server. Its sub claim carries one Workload Identifier and its cnf.jwk claim carries the workload's public key, including an alg member that fixes the algorithm of the later proof (Section 5.1).
• The Workload Identity Certificate (WIC) is an X.509 certificate that carries the Workload Identifier in exactly one URI SubjectAltName (Section 6.1). The WIT is meant for application-layer protocols and the WIC primarily for mutual TLS (Section 1).
• Trust is anchored per trust domain. Consumers must hold a preconfigured, out-of-band mapping from each trust domain to its issuers and trust anchors, and must validate a credential only against the anchors of the trust domain named in its Workload Identifier (Section 3).
• Revision 03 reorganises the document and adds a WIT validation checklist (Section 5.1.3), a section on the audience of application-layer proofs (Section 5.2) and a security section on the difference between trust domain membership and workload identity (Section 9.2).

How it works

sequenceDiagram
    participant A as Workload A (caller)
    participant B as Workload B (callee)
    A->>B: TLS connection, server authentication of B, optional mTLS with A's WIC
    A->>B: Request with Workload-Identity-Token header (WIT) and proof of possession
    B->>B: Validate WIT against preconfigured trust anchors, verify PoP audience
    B->>B: Authorize A and the call
    B-->>A: Success response or error response

1. A transport connection is established with TLS server authentication of Workload B. Mutual TLS using Workload A's WIC is optional (Section 1.1, step 1).
2. Workload A may add application-layer authentication: the WIT in the Workload-Identity-Token header field plus a proof of possession. The proof mechanisms are in [I-D.ietf-wimse-wpt] and [I-D.ietf-wimse-http-signature], not in this draft (Sections 1, 5.1.1).
3. Workload B selects trust anchors by the trust domain in the WIT sub claim and runs the checks of Section 5.1.3. It also verifies that the audience of the proof refers to itself, using trusted configuration and not request fields such as Host (Section 5.2).
4. Workload B authorizes the call using the Workload Identifier, matched in the scope of its trust domain (Section 7), and returns a response. Validation failures are reported as errors, typically HTTP 400 (Section 5.3).

Use cases

• A service mesh or platform issues short-lived WICs to workloads, and services authenticate each other with mutual TLS. The client checks the server certificate against the identifier it expects (Sections 1.2, 6.1).
• Traffic passes through intermediaries that terminate TLS, so end-to-end transport security is unavailable. The caller sends a WIT with a proof of possession at the application layer (Section 5).
• A deployment migrates from bearer JWTs to proof-of-possession WITs and accepts both for a transition period, with per-caller policy (Section 5.4).
• A deployment combines the WIT with a transaction token: the WIT decides which API calls are allowed and the context token decides which resources (Section 5.4).
• An operator that wants revocation as defence in depth runs a token status list or a jti deny-list next to short WIT lifetimes (Section 9.3.1).

Why This Matters Now

• Trigger: revision 03 of a core WIMSE working group draft (Datatracker states: Active, I-D Exists, WG Document) reorganised its structure, tightened trust-anchor binding, added a proof-audience section and removed the standalone paragraph on several identifiers per runtime. The working group chair asked the list to flag any substantive change that needs more discussion.
• Source evidence: Appendix A.1 of the draft lists the changes with issue numbers (#173, #175, #256, #269, #270, #290, #294, #303, #370, #393, #395, #402, #411). The mail archive shows the author announcement and the chair's request for review (30 October 2026, 18:29 UTC; both linked under Sources). As of 1 November 2026 the list had no replies to either.
• Expected impact: implementers of the companion documents (mutual TLS, WPT, HTTP signatures) and of identity servers get a concrete recipient checklist and clearer rules on revocation, audience and key handling. Anyone who cited the old section numbers, or built the access-path-to-identifier mapping API that revision 02 required, has to re-check against 03.

What Changed

• Spec/document change summary:
  • Section 3: a credential MUST be validated only against the anchors bound to the trust domain in its Workload Identifier. The explicit prohibition on using iss to fetch a JWKS from the token is gone; Section 9.1 now explains that a validator taking keys from the credential would accept any issuer, and Appendix A.1 says "remove iss-based key distribution (#411)". Section 5.1.3 of revision 02, which covered iss and jwks_uri use, was replaced by "Validating the WIT".
  • Section 5.1.3 (new): the recipient MUST check a single well-formed JWS compact JWT, a single Workload Identifier in sub used to pick trust anchors, typ of wit+jwt, a valid signature, cnf with a jwk that has alg, and ignore unknown claims.
  • Section 5.2 (new): the audience of the proof of possession identifies the intended recipient, and the recipient MUST verify it refers to itself. Mechanism details are left to [I-D.ietf-wimse-wpt] and [I-D.ietf-wimse-http-signature].
  • Section 1.2: the revision 02 requirement that implementations MUST allow a mapping from access path to workload identifier is replaced by three conditions (a workload knows its own identifier, a callee can verify a request is meant for it, a caller knows the identifier it expects) and a pointer to [RFC9525] for server certificates.
  • Section 4: the paragraph on deployments with several labels for one runtime is removed. It put the identity used for the access decision in the one credential and forbade a second workload identifier for correlation. The rule of exactly one Workload Identifier per credential stays in the first paragraph of Section 4, in sub, and in Section 6.1; multiple credentials with the same identifier may be told apart by jti and similar fields.
  • Section 9.3.1 and Section 9.4.1: the draft does not rely on WIT or WIC revocation. Deployments MAY run a token status list or jti deny-list, and then MUST include jti in every WIT. CRL and OCSP are not relied on for WICs.
  • Section 9.2 (new): validating against a trust domain's anchors proves membership of the domain, not which workload the peer is. Proof of possession does not fix that. Existing credentials stay usable after deprovisioning until expiry.
  • Section 9.5: private keys SHOULD be regenerated for each new credential unless sufficiently protected, for example non-exportable and hardware-bound; "keeping the key private" is defined, and verifiers must not infer stronger key protection from the credential alone.
  • Section 5.3: HTTP 401 is allowed for WIT errors only when an acceptable HTTP authentication mechanism can be returned in WWW-Authenticate. Revision 02 said 401 was NOT RECOMMENDED.
  • Section 1 and 9.3: a WIT sent over TLS, or a proof bound to TLS properties, does not make the WIT a transport-layer credential; mutual TLS uses the WIC.
  • Examples and references: cnf.jwk.alg in the examples is now Ed25519 instead of EdDSA ([RFC9864]); the WIT example was re-signed. [RFC8725] is replaced by [I-D.ietf-oauth-rfc8725bis] and [RFC8414] is dropped. New references are [RFC9525], [RFC6960], [RFC9864] and [I-D.ietf-oauth-status-list]. An implementation status entry for wimsey was added. Section 1.1 of the old document ("Use In Other Protocols") was removed and the Identity Server, PEP and PDP were dropped from the architecture figure.
• Compatibility or migration concerns:
  • Section numbers moved (for example former Section 1.3 is now 1.2, former Section 9.2 is now 9.3), so external references by number need updating. One is already wrong: draft-ietf-wimse-http-signature-08 (Sections 3 and 3.6) tells recipients to validate the WIT "as specified in Section 5.1.4" of this draft, but neither -02 nor -03 has a Section 5.1.4. WIT validation is Section 5.1.3 in -03.
  • EdDSA is not forbidden. The alg rule in Section 5.1 still allows any signature algorithm in the IANA JOSE registry except none, symmetric-key and encryption algorithms. [RFC9864] marks EdDSA as Deprecated in that registry, and the examples moved to the fully specified Ed25519. Verifiers that accept only the new identifier will reject older EdDSA keys.
  • Deployments that relied on iss-driven key discovery must move to preconfigured trust anchors.
  • Implementations that exposed the revision 02 access-path mapping hook get no normative guidance on how the expected callee identifier is supplied now.

Technical Analysis

• Threat model implications:
  • Cross-domain spoofing: identifiers are meaningful only inside their trust domain, and ignoring the trust domain lets one domain impersonate another (Sections 9.1, 9.4).
  • Rogue issuer: key material taken from the credential itself would be accepted from anyone running an issuer; preconfigured binding prevents it (Sections 3, 9.1).
  • Membership versus identity: a valid credential from the right domain does not tell a client or server which workload it faces, and proof of possession does not close that gap. The identifier comparison of Section 1.2 is what does (Section 9.2).
  • Capture and replay of a WIT with its PoP within the PoP lifetime. Mitigations are short PoP lifetime, narrow audience or scope, replay protection and optional TLS binding (Sections 9.3.2 to 9.3.5).
  • Compromise and deprovisioning: JWT and certificate credentials are not revocable on demand, so lifetime is the main control. Stopping issuance does not invalidate existing credentials (Sections 9.2, 9.3.1, 9.4.1).
  • Trust anchor compromise bounds certificate safety, so leaf and anchor lifetimes should be considered together (Section 9.4.1).
  • Intermediaries see the WIT and PoP in clear text and can replay them or alter data the PoP does not cover (Section 9.6).
• Protocol flow implications:
  • The draft is credential-only. Possession proof, audience encoding and replay rules live in other drafts, so the checks of Section 5.1.3 are necessary but not sufficient for authentication.
  • The caller side now needs an expected callee identifier, and the callee side needs trusted configuration for its own audience (Sections 1.2, 5.2).
  • The WIT is carried in the Workload-Identity-Token header, defined by an ABNF of three base64url parts, and is not for the Authorization header (Sections 5.1, 5.1.1).
• Interop concerns:
  • typ must be wit+jwt, cnf.jwk.alg is mandatory and must be the algorithm of the proof, and ES256 MUST be supported by general purpose implementations (Section 5.1).
  • Unknown claims must be ignored, and private claim names are NOT RECOMMENDED, so extensions should use collision-resistant or IANA-registered names (Section 5.1.2).
  • The WIC must have exactly one URI SAN carrying the identifier. DNSName SANs are RECOMMENDED when clients validate by host name (Section 6.1).
  • Normative dependencies include several Internet-Drafts ([I-D.ietf-oauth-rfc8725bis], [WIMSE-ID], [I-D.ietf-wimse-mutual-tls]), which affects how quickly this draft can progress (Section 12.1).

Open Questions

• Section 5.1.3 does not list the exp check, an algorithm allowlist, or an iss check when iss is present. It refers to [RFC7515] and the JWT best practices, and Section 9.3.1 only says to see lifetime considerations. Is that enough for interoperable validators?
• Section 5.1 says iss is RECOMMENDED but optional and points to Section 5.1.2 for details. Section 5.1.2 refers to "the auditing and operational uses described above", which the revised Section 5.1 text no longer spells out.
• Section 3 requires a known, preconfigured issuer per trust domain, but the draft does not say whether a recipient must compare a present iss with that issuer.
• Section 4 keeps exactly one identifier per credential but drops the guidance on stable service identity versus instance identity. Section 9.2 warns that instances sharing an identifier cannot be told apart. Whether the shorter text is enough is a question the chair's request for substantive-change review could cover.
• Section 1.2 and Section 5.2 require the callee to verify the audience and the caller to know the expected callee identifier, but give no mechanism to learn either value. The companion drafts carry the audience as the WPT aud claim, which SHOULD be the HTTP target URI (draft-ietf-wimse-wpt-02 Sections 2 and 3.1.7), and as the mandatory wimse-aud signature parameter (draft-ietf-wimse-http-signature-08 Section 3.2). What happens with proof mechanisms that carry no audience is not stated.
• Section 5.3 allows 401 with WWW-Authenticate "when an acceptable HTTP authentication mechanism exists". The draft does not name such a mechanism for WITs, and Section 5.1 says the WIT is not for the Authorization header.
• Section 9.3.1 makes jti mandatory for deployments that run a deny-list or token status list, while Section 5.1 keeps jti OPTIONAL. A validator cannot tell from the token whether the issuer operated such a mechanism.
• Section 9.5 allows key reuse across credentials when the key is hardware-bound and non-exportable, but says verifiers cannot infer this from the credential. How a verifier learns it is left to deployment profiles.
• As of 1 November 2026 the WIMSE list had only the announcement and the chair's call for review, with no replies. Which changes, if any, the working group considers substantive is not yet known.

Experiments

• Lab 1: build a WIT validator that implements the Section 5.1.3 checklist and feed it tokens with a wrong typ, a missing cnf.jwk.alg, two URIs in sub, an unknown claim, an expired exp, and a trust domain with no configured anchors. Record which cases the checklist alone rejects and which depend on JWT best-practice rules.
• Lab 2: sign a Figure 2 style WIT with an iss pointing at an attacker-controlled JWKS URL and confirm that a validator following Section 3 and Section 9.1 never fetches it and rejects the token when the trust domain has no matching preconfigured anchor.
• Lab 3: replay a captured WIT and proof to a second callee, with and without audience checking from trusted configuration (Section 5.2), and with a proxy that rewrites Host, to see where audience validation fails.

Sources

• draft-ietf-wimse-workload-creds-03 on the Datatracker
• Diff between revisions 02 and 03
• WIMSE list: I-D Action announcement for revision 03
• WIMSE list: new version notification and chair's request for review
• draft-ietf-wimse-workload-creds-02 text
• draft-ietf-wimse-wpt-02 text
• draft-ietf-wimse-http-signature-08 text
• RFC 9864
• wimsey, the implementation listed in Section 8

Trigger

The subject was picked as "Diff active WG draft: draft-ietf-wimse-workload-creds-03". The note recorded with it says: reorganised structure, stricter trust-anchor binding, new proof-audience section and dropped single-identifier rule, all in a core WG draft. Datatracker states are Active, I-D Exists and WG Document. One correction to that note: the draft still requires exactly one Workload Identifier per credential (Section 4, Section 5.1 sub, Section 6.1). What was dropped is the paragraph that told deployments how to handle several labels for the same runtime.

Why This Matters

The draft is the credential layer for the WIMSE companion documents on mutual TLS, the Workload Proof Token and HTTP message signatures (Section 1). Changes to how a recipient validates a WIT (Section 5.1.3), how trust anchors are bound to a trust domain (Section 3) and how audience is checked (Section 5.2) apply to every protocol that reuses these credentials. The working group chair asked the list on 30 October 2026 to flag anything substantive that needs more discussion, because it is a core document.

Open Questions

• Does Section 5.1.3 give enough for interoperable validators without an explicit exp, algorithm or iss check?
• Is the shorter Section 4 enough once the guidance on stable versus instance identities is gone?
• How do callers and callees learn the expected callee identifier and their own audience value (Sections 1.2, 5.2)?
• Which changes does the working group regard as substantive? As of 1 November 2026 the chair's request had no replies.

References

Normative references listed in Section 12.1:

• [I-D.ietf-oauth-rfc8725bis] JSON Web Token Best Current Practices (draft revision 10), new in 03 and replacing RFC 8725.
• [I-D.ietf-wimse-mutual-tls] Workload Authentication Using Mutual TLS (draft revision 03).
• [WIMSE-ID] Workload Identifier (draft-ietf-wimse-identifier revision 04).
• RFC 2119, RFC 8174, RFC 5234, RFC 7515, RFC 7517, RFC 7518, RFC 7519, RFC 7800, RFC 7942, RFC 9110.
• RFC 9525 (Service Identity in TLS), new in 03.

Informative references listed in Section 12.2:

• [I-D.ietf-wimse-arch] (revision 08), [I-D.ietf-wimse-wpt] (revision 02), [I-D.ietf-wimse-http-signature] (revision 08), [I-D.ietf-oauth-transaction-tokens] (revision 11).
• [I-D.ietf-oauth-status-list] (revision 21), RFC 6960 (OCSP) and RFC 9864 (fully-specified algorithms), all new in 03.
• RFC 9457, and the IANA registries for HTTP fields, JOSE algorithms, JWT claims and media types.
• RFC 8414 was removed from the references.

Key Changes

• Structure: the section "Use In Other Protocols" is removed, Sections 5 and 6 are retitled "Application-Layer Credentials" and "Transport-Layer Credentials", a Section 5.2 on audience and a Section 5.1.3 on WIT validation are added, and the Security Considerations are renumbered (new Section 9.2).
• Section 1.2: the mapping API requirement is replaced by caller and callee conditions and a reference to RFC 9525 for server identity.
• Section 3: validation only against anchors bound to the trust domain in the Workload Identifier; the issuer must be known and preconfigured; the explicit prohibition on iss-based key lookup is removed in favour of Section 9.1 and the removal of iss-based key distribution.
• Section 4: the paragraph on deployments with several labels for one runtime (a stable service identity and an instance, say) is removed. It put the identity used for the access decision in the one credential and forbade encoding a second identifier for correlation. Exactly one identifier per credential is kept.
• Section 5.1: sub and jti definitions reworded, jti tied to deny-list or status list deployments, typ guidance now cites the RFC 8725 successor draft.
• Section 5.3: HTTP 401 allowed when a WWW-Authenticate mechanism exists.
• Section 9: revocation stance for WIT and WIC, exposure after deprovisioning, key-protection wording, and the clarification that WIT and PoP are not used for mutual TLS.
• Examples use Ed25519 in cnf.jwk.alg; the example WIT was re-signed. The implementation status gains a wimsey entry.

Impact Analysis

• Upstream: depends on the WIMSE architecture draft for terminology and trust domains, on the WIMSE Workload Identifier draft for identifier syntax and the wimse URI scheme, and on the JWT best-practices successor draft. A change in any of these drafts can affect this one, because three normative references are still Internet-Drafts.
• Downstream: the mutual TLS, WPT and HTTP signature drafts supply the proof of possession and must define audience handling that satisfies Section 5.2. Section numbers they cite from this draft may have moved. Identity server and SPIFFE-style implementations that issue WITs and WICs are the main implementers.
• Compatibility: a WIT with typ of wit+jwt, sub and cnf.jwk.alg should still validate. Behaviour that changes is iss-driven key lookup (no longer supported), the algorithm name in examples (Ed25519), the 401 guidance and the removed mapping requirement. EdDSA is still allowed by the Section 5.1 alg rule; [RFC9864] marks it Deprecated and only the examples moved to Ed25519.

• Reject a WIT whose typ header is not wit+jwt, and reject one with alg set to none (Section 5.1.3 for typ, Section 5.1 for alg).
• Reject a WIT that is not a single JWS compact serialization JWT, for example a JSON serialization or a token with extra segments (Section 5.1.3).
• Reject a WIT with no sub, or with a sub that is not exactly one Workload Identifier (Section 4, Section 5.1.3).
• Select trust anchors from the trust domain in sub, and confirm a WIT signed by the correct key of a different trust domain is rejected (Section 3, Section 9.1).
• Confirm the validator never fetches key material from a URL in iss, and still accepts a WIT with no iss (Section 3, Section 5.1.2, Section 9.1).
• If iss is present, check what your implementation does when it differs from the issuer configured for the trust domain; the draft does not specify this.
• Verify signature key selection with and without kid, including a trust domain with several keys during rotation (Section 3).
• Reject a WIT with no cnf, no cnf.jwk, or no cnf.jwk.alg; reject alg values that are none, symmetric or encryption algorithms (Section 5.1.3 for presence, Section 5.1 for the allowed algorithms).
• Check the algorithm of the presented proof equals cnf.jwk.alg, and test ES256 support in a general purpose implementation (Section 5.1).
• Test cnf.jwk.alg of Ed25519 and of EdDSA against your verifier and the companion drafts. Both are allowed by the Section 5.1 alg rule; EdDSA is Deprecated by [RFC9864] and the examples now use Ed25519 (Appendix A.1).
• Reject an expired WIT and apply the clock skew policy on purpose, since Section 5.1.3 does not list exp and refers to Section 9.3.1 (Section 5.1.3, Section 9.3.1).
• Ignore unknown claims in a WIT and do not fail on private claim names; use collision-resistant names for your own claims (Section 5.1.2).
• Send the WIT in the Workload-Identity-Token header, match the ABNF of three base64url parts, treat the header name as case insensitive and the value as case sensitive, and never put it in Authorization (Section 5.1, Section 5.1.1).
• Verify that the audience of the proof of possession names the recipient, taken from trusted configuration, and test a request whose Host header was rewritten by an intermediary (Section 5.2).
• Test a proof of possession whose audience names another workload, and a replay of a captured WIT and proof to a second callee (Section 5.2, Section 9.3.3, Section 9.3.4).
• Reject a proof of possession outside its validity time and check that its lifetime is on the order of minutes (Section 9.3.2).
• If you operate a jti deny-list or token status list, check every issued WIT carries jti; confirm validators still work with a WIT that has no jti when no such mechanism is used (Section 5.1, Section 9.3.1).
• Check that a WIC has exactly one URI SubjectAltName carrying the Workload Identifier, and that a certificate with two such URIs is rejected (Section 4, Section 6.1).
• For a server WIC, include DNSName SANs for clients that validate by host name, and test a client that compares the server certificate to the expected Workload Identifier per RFC 9525 (Section 1.2, Section 6.1).
• Validate a WIC chain only against the trust anchors of the trust domain in its URI SAN, and reject a certificate whose identifier is outside that domain and anchor (Section 3, Section 9.4).
• Match authorization policy on the full Workload Identifier in the scope of its trust domain, not on the path alone (Section 7, Section 9.4).
• Confirm a WIT presented over TLS is not treated as the mutual TLS client credential, and that mutual TLS authentication uses the WIC (Section 1, Section 9.3).
• Return 400 for WIT validation errors and use 401 only when a WWW-Authenticate mechanism can be offered (Section 5.3).
• During a bearer-to-WIT transition, revalidate the caller identity after the authentication step when both token types are accepted (Section 5.4).
• Check WIT and WIC lifetimes are short (WITs on the order of hours, Sections 5.1 and 9.3.1) and that existing credentials are rejected after expiry even when issuance has stopped (Section 9.2; WIC lifetime in Section 9.4.1).
• Check that keys are not reused after credential expiry and are regenerated for each credential unless they are non-exportable and hardware-bound, and that verifiers do not infer key protection from the credential (Section 9.5).
• Check references to this draft from other documents for old section numbers, for example former Section 1.3 (now 1.2), former Section 5.1.3 (the iss note, removed) and former Sections 9.2.1 to 9.2.5 (now 9.3.1 to 9.3.5).

Environment

• Runtime:
• Tooling:
• Versions:

Steps

Results

Failure Modes

Next Actions