]> Ping Identity

bcampbell@pingidentity.com

Palo Alto Networks

joe@salowey.net

Defakto Security

arndts.ietf@gmail.com

Independent

yaronf.ietf@gmail.com

Zscaler

yrosomakho@zscaler.com

Applications and Real-Time Workload Identity in Multi System Environments workload identity The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi-tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of-possession mechanism. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines credentials to facilitate authentication and authorization in the context of interaction between two workloads. This is the core component of the WIMSE architecture . This document focuses on the credentials that carry workload identity and bind the key material to the identity. The presentation of the proof of possession of the key material is part of other documents and out of scope for this one. In this document, two credentials are defined:

• The Workload Identity Token (WIT) is a JWT that represents the identity of a workload and binds a public key to that identity.
• The Workload Identity Certificate (WIC) is an X.509 certificate that represents the identity of a workload and binds a public key to that identity.

The Workload Identity Token is targeted for application-layer protocols. The Workload Identity Certificate is targeted for transport-layer protocols, primarily mutual TLS. Presenting a WIT over a TLS-protected channel, or binding an application-layer proof of possession to TLS session properties (see ), does not make the WIT a transport-layer credential: mutual TLS authentication uses the Workload Identity Certificate, not the WIT. This does not preclude the use of the WIC in application-layer protocols or the WIT in transport-layer protocols, but these are the primary intended uses. The various protocol bindings that use these credentials to authenticate workloads to each other are specified in separate documents and are out of scope for this document. Each such binding defines how a workload proves possession of the key material bound to its credential in order to authenticate to another workload. At the time of writing, three such protocol bindings are defined:

• Transport-layer authentication using mutual TLS with the Workload Identity Certificate, specified in .
• Application-layer authentication using the Workload Identity Token in conjunction with a JWT-based proof of possession, the Workload Proof Token (WPT), specified in .
• Application-layer authentication using the Workload Identity Token in conjunction with HTTP Message Signatures, specified in .

Deployment Architecture and Message Flow This architecture and message flow is part of the broader flow as described in Section 3.3 of the WIMSE architecture . Independent of the transport between the workloads, we assume that workloads hold credentials from the same trust domain and that following architecture applies:

Sequence of Operations | | | | | | | Workload A | (2) | Workload B | | |==============>| | | | | |--+ | | | | | (3) | | | |<-+ | | (4) | | | |<==============| | +------------+ +------------+ ]]>

The high-level message flow is as follows:

1. A transport connection is established using TLS server authentication for Workload B, optionally incorporating mutual TLS (mTLS) with Workload A's Workload Identity Certificate for client authentication.
2. Workload A prepares to call Workload B. This may include adding application-layer authentication information, such as the Workload Identity Token and proof of possession. Workload B authenticates Workload A.
3. Workload B authorizes Workload A and the call.
4. Workload B returns a response to Workload A, which may be either a success or an error response.

Depending on the protocol, the workload authentication may happen during step (1) at the transport-layer or at step (2) at the application-layer, or both.

Workload Identifiers and Authentication Granularity The Workload Identifier is a URI and its baseline syntax and processing requirements are defined in . While deployments define how they assign identifiers and what the path portion means, implementations are expected to conform to the URI requirements outlined in . To enable granular authentication between workloads, i.e., authenticate a peer as a specific workload, the following must be in place:

• Each workload must know its own identifier.
• A callee must be able to verify that a request is intended for it.
• A caller that authenticates the callee must know the identifier it expects the callee to present.

Once these conditions are met, the methods described in this document can be used for the caller and callee to authenticate one another. At the transport layer, the client validates the server certificate against that expected identifier as described in "Verifying Service Identity" of . At the application layer, the callee verifies the audience of the proof of possession ().

Conventions and Definitions All terminology in this document follows . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Establishing Trust Anchors Trust anchors used to validate Workload Identity Certificates and Workload Identity Tokens are associated with a trust domain, as discussed in . They are provisioned to consumers together with trust domain metadata for that domain. Trust anchors can be represented in different ways depending on the deployment; for example, as a set of public keys (such as a JWKS), as an X.509 certification authority used to validate certificate chains, or as other deployment-specific material. This document does not define a mechanism for discovering trust anchor information. Consumers MUST associate each trust domain with a known, preconfigured issuer (or set of issuers) and with the corresponding trust anchors. That mapping MUST be distributed via a secure out-of-band mechanism. A credential MUST be validated only against the anchors bound to the trust domain named in its Workload Identifier. To validate a WIT, the receiving workload verifies the JWS signature using key material from the trust anchors configured for the trust domain in the sub claim. Trust anchor material for WIT validation MAY include more than one public key so that operators can rotate signing keys. In practice, the alg header parameter would identify an algorithm that the validator accepts for that trust domain, and the signature would be checked under a key drawn from the configured trust anchors. If the JWS header contains a kid parameter, the validator would use the key in the trust anchor material with the same kid value. If kid is absent, deployment policy would need to provide unambiguous key selection (for example, when only a single key is configured for that trust domain). Recipient processing of a presented WIT is specified in . For Workload Identity Certificates, validators use the trust anchors for the peer's trust domain to validate the X.509 chain and the Workload Identifier in the certificate, as described in and in companion specifications such as .

One Workload Identity per Credential Each WIMSE credential carries exactly one Workload Identifier () that is used for authentication and authorization. Requiring a single identifier per credential keeps authorization and auditing unambiguous and aligns with common practice for workload X.509 certificates (for example, a single URI in an X.509-SVID). For a Workload Identity Token, that identifier is the value of the sub claim. For a Workload Identity Certificate, that identifier is carried in the single URI SubjectAltName described in . Multiple credentials of the same Workload Identifier may be differentiated using other fields such as the optional jti claim.

Application-Layer Credentials In many deployments communication between workloads cannot use end-to-end transport security such as TLS. For these deployment styles, this document proposes a credential that can be used at the application-layer.

The Workload Identity Token The Workload Identity Token (WIT) is a JWS signed JWT that represents the identity of a workload. It is issued by the Identity Server and binds a public key to the workload identity. See for security considerations. A WIT MUST contain the following content, except where noted:

• in the JOSE header:
  • alg: An identifier for a JWS asymmetric digital signature algorithm (registered algorithm identifiers are listed in the IANA JOSE Algorithms registry ). The value none MUST NOT be used.
  • typ: the WIT is explicitly typed, as recommended in , using the wit+jwt media type.
• in the JWT claims:
  • iss: The issuer of the token, which is the Identity Server, represented by a URI. The iss claim is RECOMMENDED but optional; See for details.
  • sub: The subject is the Workload Identifier as defined in , constrained to exactly one per credential ().
  • exp: The expiration time of the token (as defined in ). WITs should be refreshed regularly, e.g., on the order of hours.
  • jti: A unique identifier for the token (as defined in ). This claim is OPTIONAL. The jti claim is useful for auditing the issuance of individual WITs, and it is needed to identify individual tokens in deployments that operate an optional token status or deny-list mechanism (). Some token generation environments do not support it.
  • cnf: A confirmation claim referencing the public key of the workload.
    • jwk: Within the cnf claim, a jwk key MUST be present that contains the public key of the workload as defined in . The workload MUST prove possession of the corresponding private key when presenting the WIT to another party. As such, it MUST NOT be used as a bearer token and is not intended for use in the Authorization header.
      • alg: Within the jwk object, an alg field MUST be present. Allowed values are listed in the IANA "JSON Web Signature and Encryption Algorithms" registry established by . The presented proof MUST be produced with the algorithm specified in this field. The value none MUST NOT be used. Algorithms used in combination with symmetric keys MUST NOT be used. Also encryption algorithms MUST NOT be used as this would require additional key distribution outside of the WIT. To promote interoperability, the ES256 signing algorithm MUST be supported by general purpose implementations of this document.

As noted in , a Workload Identifier is a URI that includes a trust domain in the authority component. The runtime environment often determines which URI scheme is used, e.g., if SPIFFE is used to authenticate workloads, it mandates spiffe URIs. For deployments that do not use an environment-specific scheme, the wimse URI scheme can be used; it is defined in . An example WIT might look like this:

An example Workload Identity Token (WIT)

The decoded JOSE header of the WIT from the example above is shown here:

Example WIT JOSE Header

The decoded JWT claims of the WIT from the example above are shown here:

Example WIT claims, including an `iat` claim, demonstrating WIT's extensibility

The example omits the recommended iss claim; see and . The claims indicate that the example WIT:

• is valid until Thu Apr 24 2025 16:35:10 GMT (represented as NumericDate value 1745512510).
• identifies the workload to which the token was issued as wimse://example.com/specific-workload.
• has a unique identifier of x-_1CTL2cca3CSE4cwb_l.
• binds the public key represented by the jwk confirmation method to the workload wimse://example.com/specific-workload.
• requires the proof to be produced with the Ed25519 signature algorithm.

For elucidative purposes only, the workload's key, including the private part, is shown below in JWK format:

Example Workload's Key

The example WIT is signed with one of the Identity Server's signing keys; the JOSE header kid identifies which key was used. Validators use the Identity Server's public keys from the trust anchors configured for that trust domain to verify the signature (see ). The Identity Server's public key from this example is shown below in JWK format:

Example Identity Server Key

The WIT HTTP Header A WIT is conveyed in an HTTP header field named Workload-Identity-Token. ABNF for the value of Workload-Identity-Token header field is provided in :

Workload-Identity-Token Header Field ABNF

The following shows the WIT from in an example of a Workload-Identity-Token header field:

An example Workload Identity Token HTTP Header Field

Note that per , header field names are case insensitive; thus, Workload-Identity-Token, workload-identity-token, WORKLOAD-IDENTITY-TOKEN, etc., are all valid and equivalent header field names. However, case is significant in the header field value.

Including Additional Claims The WIT contains JSON structures and therefore can be trivially extended by adding more claims beyond those defined in the current document. This, however, could result in interoperability issues, which the following rules are addressing.

• To ensure interoperability in WIMSE environments, the use of Private claim names (Section 4.3 of ) is NOT RECOMMENDED.
• In closed environments, deployers MAY freely add claims to the WIT. Such claims SHOULD be collision-resistant, such as example.com/myclaim.
• A recipient that does not understand such claims MUST ignore them, as per Section 4 of .
• Outside of closed environments, new claims MUST be registered with IANA before they can be used.

It is RECOMMENDED that the WIT carries an iss claim for the auditing and operational uses described above. Validators are not required to use iss when validating the WIT or establishing the workload identity: the trust domain and workload identity are carried in the mandatory sub claim ().

Validating the WIT Verification of a WIT follows and the JWT best practices in , with the WIMSE-specific requirements below. To validate a WIT, the recipient MUST ensure the following:

• The token is a single well-formed JWT using JWS compact serialization (, ).
• The sub claim is present and is a single Workload Identifier (, ). The recipient uses the trust domain of that identifier to select the configured trust anchors ().
• The typ JOSE header parameter conveys a media type of wit+jwt.
• The JWS signature is valid under those trust anchors, as described in .
• The cnf claim is present and contains a jwk object with an alg member as specified in .
• Additional claims that are not understood are ignored, as specified in .

See for WIT lifetime considerations.

Audience of Application-Layer Proofs The Workload Identifier in a WIT identifies the sender. The audience of the proof of possession that accompanies the WIT identifies the intended recipient. A recipient MUST verify that the audience refers to it, using trusted configuration rather than request fields such as Host, because intermediaries may rewrite the request URI. Each proof-of-possession mechanism defines how the audience is set and validated; see "Audience validation" in and "The wimse-aud Signature Parameter" in .

Error Conditions Errors may occur during the processing of the WIT. If the WIT validation fails for any reason, such as an invalid signature, an expired validity time window, or a malformed data structure, an error is returned. Typically, this will be in response to an API call, so an HTTP status code such as 400 (Bad Request) is appropriate. This response could include more details as per , such as an indicator that the wrong key material or algorithm was used. Using the HTTP status code 401 is only recommended for this purpose when an acceptable HTTP authentication mechanism exists that can be returned with the WWW-Authenticate HTTP header.

Coexistence with JWT Bearer Tokens The WIT defines new HTTP headers. It can therefore be presented along with existing headers used for JWT bearer tokens. This property allows for transition from mechanisms using identity tokens based on bearer JWTs to proof-of-possession-based WITs. A workload may implement a policy that accepts both bearer tokens and WITs during a transition period. This policy may be configurable per-caller to allow the workload to reject bearer tokens from callers that support WITs. Once a deployment fully supports WITs, then the use of bearer tokens for identity can be disabled through policy. Implementations should be careful when implementing such a transition strategy, since the decision which token to prefer is made when the caller's identity has still not been authenticated, and needs to be revalidated following the authentication step. The WIT can also coexist with tokens used to establish security context, such as transaction tokens . In this case a workload's authorization policy may take into account both the sending workload's identity and the information in the context token. For example, the identity in the WIT may be used to establish which API calls can be made and information in the context token may be used to determine which specific resources can be accessed.

Transport-Layer Credentials As noted in the introduction, for many deployments, transport-layer protection of application traffic is ideal.

The Workload Identity Certificate The Workload Identity Certificate is an X.509 certificate. The Workload Identifier used for WIMSE authentication and authorization MUST appear in exactly one SubjectAltName extension of type URI, as required by . The certificate MUST NOT contain more than one URI SAN that carries a Workload Identifier. When the certificate is also used for TLS server authentication, it is RECOMMENDED to include SubjectAltName extensions of type DNSName with the appropriate DNS names for clients that validate the server by host name rather than by workload identity. The certificate MAY contain SubjectAltName extensions of other types for PKIX or local policy, but only the URI SAN above is the WIMSE workload identity.

Client Authorization Using the Workload Identity The receiving application uses the authenticated peer's Workload Identifier in authorization, accounting, and auditing. For example, the full Workload Identifier may be matched against ACLs to authorize actions requested by the peer and the identifier may be included in log messages to associate actions to the client workload for audit purposes. A deployment may specify other authorization policies based on the specific details of how the Workload Identifier is constructed. The path portion of the Workload Identifier MUST always be considered in the scope of the trust domain. See on additional security implications of Workload Identifiers. How the receiving application obtains the Workload Identifier depends on the credential used to authenticate the peer:

• Application-layer: After successfully validating the WIT, the receiving application retrieves the Workload Identifier from the sub claim.
• Transport-layer: When the client is authenticated with a Workload Identity Certificate, the receiving application retrieves the Workload Identifier from the client certificate's SubjectAltName extension of type URI.

A workload MAY use other standard and deployment specific fields in the workload credential for accounting or authorization purposes.

Implementation Status Note to RFC Editor: please remove this section, as well as the reference to RFC 7942, before publication. This section records the status of known implementations of the protocol defined by this document at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". SPIFFE (Standard)

• Organization: CNCF
• Maturity:
  • Workload Identity Certificate: fully compatible with the X509-SVID and widely used.
  • Workload Identity Token: beta
• Coverage: Workload Identity Certificate, WIT
• Contact: SPIFFE sig-spec community

Defakto Security

• Organization: Defakto Security (prior SPIRL)
• Maturity:
  • Workload Identity Certificate: production
  • Workload Identity Token: alpha
• Coverage: Workload Identity Certificate, WIT
• Contact: arndt@defakto.security

Teleport - Machine & Workload Identity

• Organization: Teleport
• Maturity:
  • Workload Identity Certificate: production
  • Workload Identity Token: research
• Coverage: Workload Identity Certificate
• Contact: noah@goteleport.com

wimsey

• Organization: independent
• Implementation: https://github.com/kanywst/wimsey
• Maturity:
  • Workload Identity Token: alpha
  • Workload Identity Certificate: alpha
• Coverage: WIT, Workload Identity Certificate
• Contact: kanywst on GitHub

Security Considerations

Workload Identity Workload Identifiers () are scoped to a trust domain (the URI authority component) and MUST be interpreted in that trust domain context. Using a Workload Identifier without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain. Similarly, a validator that obtains key material from the credential itself, for example by resolving the iss claim of a WIT to a key set, would accept credentials from any entity able to operate an issuer. The pre-configured binding of trust domains to authorized issuers and trust anchors described in prevents both attacks.

Trust Domain Membership and Peer Authentication Validating a peer's credential against the trust anchors for a trust domain establishes that the peer belongs to that trust domain, but does not by itself establish which workload the peer represents. The additional identity comparison described in is required to make that distinction. This affects both sides of a call, workloads acting as clients and workloads acting as servers. Proof of possession does not mitigate this vulnerability. It shows that the peer holds the private key for the credential it presented (), but it does not prove the identity itself. The same consideration applies when a Workload Identity Certificate is used at the transport layer. Deprovisioning a workload instance or stopping credential issuance does not invalidate its existing WITs or WICs. If the corresponding private key remains usable, these credentials can still support authentication until expiry, including any permitted clock skew, unless relying parties reject them earlier, for example through revocation. Credential lifetimes therefore affect the residual exposure after deprovisioning or detection of compromise. If multiple instances use the same Workload Identifier, the identifier alone cannot distinguish them for authorization or auditing.

Workload Identity Token and Proof of Possession The Workload Identity Token (WIT) is bound to a secret cryptographic key and is always presented with a proof of possession (PoP) as described in . The WIT is a general purpose token that can be presented in multiple contexts. The WIT and its PoP are used for application-layer authentication; they are not used as the client or server credential for mutual TLS, which uses the Workload Identity Certificate (). The WIT MUST NOT be used as a bearer token. While this helps reduce the sensitivity of the token it is still possible that a token and its PoP may be captured and replayed within the PoP's lifetime. The following are some mitigations for the capture and reuse of the WIT and its PoP:

Limiting Workload Identity Token Lifespan The WIT MUST have a limited lifetime expressed through the exp claim. If both a WIT and its corresponding private key are compromised, an attacker can impersonate the workload until the WIT expires. Because JWT-based credentials such as the WIT are not revocable on demand, a short expiration is the primary mitigation against continued use of a compromised WIT and key. WITs SHOULD therefore be short-lived, typically on the order of hours, with the chosen lifetime balancing the operational cost of frequent refresh against the window of exposure if a credential is compromised. This document does not define a revocation mechanism for WITs and does not rely on one; validators are not required to consult any token status service. Deployments MAY nevertheless operate such a mechanism as a defense in depth measure, for example a Token Status List or a deny-list of jti values. A deployment that does so MUST include the jti claim () in every WIT, because a WIT without a jti cannot be identified individually. Such mechanisms are subject to a propagation delay during which a revoked WIT may still be accepted, and their use does not relax the requirement for short WIT lifetimes.

Limiting Proof of Possession Lifespan The PoP MUST be time limited. A PoP should only be valid over the time necessary for it to be successfully used for the purpose it is needed. This will typically be on the order of minutes. PoPs received outside their validity time MUST be rejected.

Limiting Proof of Possession Scope In order to reduce the risk of theft and replay the PoP should have a limited scope. For example, a PoP may be targeted for use with a specific workload and even a specific transaction to reduce the impact of a stolen PoP. In some cases a workload may wish to reuse a PoP for a period of time or have it accepted by multiple target workloads. A careful analysis is warranted to understand the impacts to the system if a PoP is disclosed allowing it to be presented by an attacker along with a captured WIT.

Replay Protection PoP mechanisms should include replay protection to prevent reuse of a captured PoP. Without it an attacker can replay a captured PoP within its validity period.

Binding to TLS Endpoint The PoP MAY be bound to a transport layer sender such as the client identity of a TLS session or TLS channel binding parameters. The mechanisms for binding are outside the scope of this document.

Workload Identity Certificate The Workload Identity Certificate carries the Workload Identifier in a single URI SubjectAltName (). As with the WIT, the identifier is meaningful only within its trust domain. A relying party MUST validate the certificate against the trust anchors configured for the peer's trust domain () and MUST reject the certificate if the Workload Identifier is not within that trust domain and the trust anchor used. Evaluating the path or other components of the identifier without also considering the trust domain and the trust anchor can allow one trust domain to impersonate workloads in another. Protocol-specific certificate validation requirements are defined in .

Limiting Workload Identity Certificate Lifespan Workload Identity Certificates are frequently issued to dynamic and/or short-lived workloads. Deployments SHOULD use certificate lifetimes appropriate to the workload environment, typically on a similar scale to WITs (). Long-lived certificates increase the impact of private-key compromise. As with WITs, short certificate lifetimes are the primary mitigation against continued use of a compromised key; this document does not rely on certificate revocation lists (CRLs) or Online Certificate Status Protocol (OCSP) for WICs, although deployments MAY use them as a defense in depth measure. The lifetime of Workload Identity Certificates is bounded by the lifetime and rotation cadence of the trust anchors of the trust domain (). Compromise of a trust anchor permits issuance of certificates for the trust domain for as long as that anchor remains trusted. Deployments should therefore consider leaf and trust-anchor lifetimes together rather than the leaf lifetime in isolation.

Workload Identity Key Management Both the Workload Identity Token and the Workload Identity Certificate carry a public key. The corresponding private key:

• MUST be kept private
• MUST be bound to a single Workload Identifier ()
• MUST NOT be used once the credential is expired
• SHOULD be regenerated for each new Workload Identity Token or Certificate, unless the key is sufficiently protected, e.g., non-exportable and hardware-bound.

For purposes of this section, keeping the private key private means that the private key is not intentionally disclosed outside the workload instance or an authorized signing component, is not placed in credentials, logs, images, configuration artifacts, or bearer tokens, and is not made available to intermediaries except as part of an explicitly trusted signing service. Compromise or disclosure of the private key invalidates the security assumptions of the associated WIT or WIC. This document does not require a particular key-protection mechanism; deployments that require stronger properties such as non-exportability, hardware-backed protection, or binding to a measured runtime need additional deployment-specific evidence or profile requirements. Verifiers must not infer such stronger properties from the WIT or WIC alone.

Transport Security An attacker observing or intercepting the communication channel can view the Workload Identity Token and its PoP and attempt to replay them to gain an advantage. To prevent this, the WIT and its PoP MUST be sent over a secure, server-authenticated TLS connection unless a secure channel is provided by some other mechanism. In some deployments the Workload Identity Token and PoP may pass through multiple systems. Communication between systems is over TLS, but the token and PoP are available in the clear at each intermediary. While an intermediary cannot modify the token or the information within the PoP, it can attempt to capture and replay the token or modify data not protected by the PoP. Mitigations listed in can reduce this risk. Deployments should analyze their situation to determine whether it is appropriate to trust and allow traffic to pass through a middlebox.

Privacy Considerations WITs and PoPs may contain private information such as user names or other identities. Care should be taken to prevent the disclosure of this information. The use of TLS helps protect the privacy of WITs and PoPs in transit. Workload Identity Certificates likewise expose the Workload Identifier, and any attributes carried in the certificate, to the peer, to any TLS-terminating intermediary, and to logs; in particular, client-certificate authentication discloses the client's workload identity to the server during the TLS handshake. WITs and certificates with Workload Identifiers are typically associated with a workload and not a specific user, however in some deployments the workload may be associated directly to a user. While these are exceptional cases a deployment should evaluate if the disclosure of WITs or certificates can be used to track a user.

IANA Considerations

Media Type Registration IANA is requested to register the following entries to the "Media Types" registry :

• application/wit+jwt, per .

application/wit+jwt Type name: application Subtype name: wit+jwt Required parameters: N/A Optional parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the application/jwt media type. See . Security considerations: See the Security Considerations section of RFC XXX. Interoperability considerations: N/A Published specification: RFC XXX, . Applications that use this media type: Identity Servers that issue Workload Identity Tokens, and workloads that use these tokens to authenticate to each other. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): N/A Person & email address to contact for further information: See the Authors' Addresses section of RFC XXX. Intended usage: COMMON Restrictions on usage: N/A Author: See the Authors' Addresses section of RFC XXX. Change controller: Internet Engineering Task Force (iesg@ietf.org).

Hypertext Transfer Protocol (HTTP) Field Name Registration IANA is requested to register the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" :

• Workload-Identity-Token, per .

Workload-Identity-Token

• Field Name: Workload-Identity-Token
• Status: permanent
• Structured Type: N/A
• Specification Document: RFC XXX,
• Comments: see reference above for an ABNF syntax of this field

References Normative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. Independent Self-Issued Consulting JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore obsoletes RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Palo Alto Networks Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles workload authentication based on X.509 Workload Identity Certificates using mutual TLS (mTLS). Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Informative References IANA IANA IANA IANA This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. Palo Alto Networks Independent The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. MATTR Bundesdruckerei SPRIND This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053.

Document History RFC Editor: please remove before publication.

draft-ietf-wimse-workload-creds-03

• Replace the access-path-to-identifier mapping API with conditions for caller and callee, and add a short subsection on the audience of application-layer proofs (#173, #175).
• Added a section to describe the security considerations of granular authentication.
• Use the fully-specified Ed25519 algorithm identifier in the examples instead of the deprecated EdDSA ().
• Add a WIT validation procedure for recipients (#290, #294).
• Clarify that WIT/PoP are application-layer credentials and are not used for mutual TLS; TLS binding does not change that (#256).
• Simplify the one-Workload-Identifier-per-credential section (#395).
• State the WIC revocation stance: short lifetimes like WITs; no CRL reliance (#270).
• State the WIT revocation stance and resolve the conflicting jti description: the document does not rely on revocation, but deployments may operate a token status list or jti deny-list, in which case jti is required in every WIT (#269).
• Editorial: consistent use of "proof of possession"/"PoP", with the abbreviation expanded on first use, and consistent capitalization of the defined term "Workload Identifier".
• Remove superfluous 'Use In Other Protocols' subsection that basically just said what amounts to "other specs can reference this"
• Retitle Application-Layer and Transport-Layer Workload-to-Workload Authentication to Application-Layer and Transport-Layer Credentials to clarify that these are credentials, not authentication protocols.
• say what it means to keep the private key private and that reuse of a key is probably okay when it's non-exportable and hardware-protected
• Reduce some normative and definitional duplication
• Point to draft-ietf-wimse-arch's "Trust Domain" from "Establishing Trust Anchors"
• Define sub a little more cleanly
• fix various editorial nits
• Try to clarify always server and sometimes client authentication in the transport bullet of the Message Flow breakdown
• Attempt some clarification of the Authentication Granularity section and reference RFC9525 for server certificate name validation
• Allow HTTP 401 for WIT errors when a WWW-Authenticate mechanism exists (#402).
• Validate credentials only against their trust domain's anchors (#370).
• Simplify iss text; remove iss-based key distribution (#411).
• Add exposure window after deprovisioning or compromise (#393).
• Remove Identity Server, PEP and PDP from the architecture diagram (#303).

draft-ietf-wimse-workload-creds-02

• Add a section requiring exactly one Workload Identifier per credential (the sub claim for a WIT, a single URI SubjectAltName for a WIC).
• Add a Trust Anchors section and clarify WIT validation, key selection, and key rotation.
• Rework the Security Considerations, including WIT lifetime, WIC validation and lifetime, and privacy of the workload identifier.
• Generalize client authorization to cover both the WIT and the WIC.
• Reference the protocol binding documents (mutual TLS, WPT, and HTTP Message Signatures).
• Rename "level" to "layer" throughout.

draft-ietf-wimse-workload-creds-01

• Clarify that the iss claim is RECOMMENDED in part for auditing and operations, and that validation of workload identity uses sub, not iss.
• Remove the wimse URI scheme definition and IANA registration from this document; both are specified in .

draft-ietf-wimse-workload-creds-00

• Remove WPT, HTTP-Sig and mutual TLS sections, which are going to be covered by individual documents. This includes re-phrasing of various sections to focus on the credentials only.

draft-ietf-wimse-s2s-protocol-07

• Rework the WPT's oth claim.
• update the media types.
• Discuss extensibility of WIT and WPT.
• Clarify error handling, specifically why not HTTP 401.
• Correct the code examples.
• Add registration request content for a wimse URI scheme.
• New section on key management.
• Use of the Accept-Signature header.

draft-ietf-wimse-s2s-protocol-06

• Explicit definition of the Workload Identity Certificate.
• Definition of the validation of workload identifiers as part of workload authentication. Still work in progress.

draft-ietf-wimse-s2s-protocol-05

• Removed the entire Workload Identity section which is now covered in the Architecture document.
• Content-Digest is mandatory with HTTP-Sig.
• Some wording on extending the protocol beyond HTTP.
• IANA considerations.

draft-ietf-wimse-s2s-protocol-04

• Require cnf.jwk.alg in WIT which restricts signature algorithm of WPT or HTTP-Sig.
• Replay protection as a SHOULD for both WPT and HTTP-Sig.
• Consolidate terminology with the Architecture draft.

draft-ietf-wimse-s2s-protocol-03

• Consistently use "workload".
• Implement comments from the SPIFFE community.
• Make iss claim in WIT optional and add wording about its relation to key distribution.
• Remove iss claim from WPT.
• Make jti claim in WIT optional.
• Error handling for the application-level methods.

draft-ietf-wimse-s2s-protocol-02

• Coexistence with bearer tokens.
• Improve the architecture diagram.
• Some more ABNF.
• Clarified identifiers and URIs.
• Moved an author to acknowledgments.

draft-ietf-wimse-s2s-protocol-01

• Addressed multiple comments from Pieter.
• Clarified WIMSE identity concepts, specifically "trust domain" and "workload identifier".
• Much more detail around mTLS, including some normative language.
• WIT (the identity token) is now included in the WPT proof of possession.
• Added a section comparing the DPoP-inspired app-level security option to the Message Signature-based alternative.

draft-ietf-wimse-s2s-protocol-00

• Initial WG draft, an exact copy of draft-sheffer-wimse-s2s-protocol-00
• Added this document history section

Acknowledgments The authors would like to thank Pieter Kasselman for his detailed comments. We thank Daniel Feldman for his contributions to earlier versions of this document. Additional thanks to the WIMSE working group for the feedback and discussions that helped shape this specification, including, but not limited to, Andrii Deinega, Flemming Andreasen, Jean-François "Jeff" Lombardo, Karthik Rampalli, and Songbo Bu.