]> Palo Alto Networks

joe@salowey.net

Intuit

yaronf.ietf@gmail.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 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). 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 authentication and authorization in the context of interaction between two workloads. This is the core component of the WIMSE architecture . This document focuses on HTTP-based services, and the workload-to-workload call consists of a single HTTP request and its response. One option to protect such traffic is through Mutual TLS, and this usage is defined in . Many deployments prefer application-layer approaches, whether for lack of CA infrastructure or because inter-service communication consists of multiple separate TLS hops. This document defines one of the two WIMSE approaches for application-layer protection. We define a profile of the HTTP Signatures protocol to protect the service traffic. Service authentication uses the Workload Identity Token (WIT) defined in , and the signature uses the private key associated with the WIT and thus proves possession of that key. As noted, the WIMSE working group is specifying two alternatives for application-layer protection, both using the newly introduced Workload Identity Token . The first alternative is inspired by the OAuth DPoP specification. The second is based on the HTTP Message Signatures RFC, and this is the one defined in this document. includes a comparison of the two alternatives.

Deployment Architecture and Message Flow Refer to Sec. 1.2 of for the deployment architecture which is common to all three protection options, including the one described here.

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.

The Protocol: Authentication Based on HTTP Message Signatures This protocol uses the Workload Identity Token and the private key associated with its public key, to sign the request and optionally, the response. Formally, this is a profile of the Message Signatures specification . The request is signed as per . The following derived components MUST be signed:

• @method
• @request-target

In addition, the following request headers MUST be signed when they exist:

• Content-Type
• Content-Digest
• Authorization
• Txn-Token
• Workload-Identity-Token

If the response is signed, the following components MUST be signed:

• @status
• @method;req
• @request-target;req
• Content-Type if it exists
• Content-Digest if it exists
• Workload-Identity-Token

To ensure the message is fully integrity-protected, if the request or response includes a message body, the sender MUST include (and the receiver MUST verify) a Content-Digest header. For both requests and responses, the following signature parameters MUST be included:

• created
• expires - expiration MUST be short, e.g. on the order of minutes. The WIMSE architecture will provide separate mechanisms in support of long-lived compute processes.
• nonce
• tag - the value for implementations of this specification is wimse-workload-to-workload

For requests only, the following signature parameter MUST also be included:

• wimse-aud ()

For responses only, when response signing is enabled, the following signature parameter MUST also be included:

• wimse-req-nonce ()

The following signature parameters in the Signature-Input header MUST NOT be used:

• keyid - The signing key is sent along with the message in the WIT. Additionally specifying the key identity would add confusion.
• alg - The signature algorithm is specified in the jwk section of the cnf claim in the WIT. See and Sec. 3.3.7 of for details.

It is RECOMMENDED to include only one signature with the HTTP message. If multiple ones are included, then the signature label included in both the Signature-Input and Signature headers SHOULD be wimse. A sender MUST ensure that each nonce it generates is unique, at least among messages sent to the same recipient. To detect message replays, a recipient SHOULD reject a message (request or response) if a nonce generated by a certain peer is seen more than once. For clarity: the signature's lifetime (the expires signature parameter) is different and typically much shorter than the WIT's lifetime, denoted by its exp claim. Implementors need to be aware that the WIT is extracted from the message before the message signature is validated. Recipients of signed HTTP messages MUST validate the signature and content of the WIT before validating the HTTP message signature. They MUST ensure that the message is not processed further before it has been fully validated.

The wimse-aud Signature Parameter defines signature parameters for HTTP message signatures: metadata carried in the Signature-Input field alongside the covered components. That metadata is covered by the signature as the @signature-params component value (Section 2.3 of ), which is always the last line of the signature base. This document defines the wimse-aud signature metadata parameter for requests. Using a signature parameter carries the audience explicitly in Signature-Input. The default value for wimse-aud is the request's HTTP target URI (), without query or fragment components. Senders, recipients, and intermediaries do not always derive the same string for that URI: normalization and rewriting differ by implementation and hop, so the audience that verification should use is a deployment-specific choice. When the default string is not suitable for verification at the recipient, senders SHOULD set wimse-aud to an explicit audience value as appropriate for that deployment. The recipient MUST be able to verify that the audience refers to it. See "Workload Identifiers and Authentication Granularity" in for more detail.

The wimse-req-nonce Signature Parameter When response signing is enabled, this document defines the wimse-req-nonce signature metadata parameter for responses. This parameter binds requests to responses and prevents a malicious proxy from replaying responses to the wrong client. The server MUST set wimse-req-nonce to the value of the nonce signature parameter from the Signature-Input of the request that triggered the response.

Signing the Response Protecting the response by signing it with the server's WIT is RECOMMENDED but optional. In particular, if the response may be exceptionally large or is expected to be streamed, signing it may not be practical. In practice, we expect response signing to be enabled by local policy. If response signing is enabled for a deployment, the client (recipient of the response) MUST check that the signature exists and validate it. The response MUST be rejected if a signature is absent or fails to validate. The client MUST verify that wimse-req-nonce matches the nonce it included in its request's Signature-Input. This binds the signed response to the specific request that triggered it. As described in , either client or server MAY send an Accept-Signature header, but is not required to do so. The Accept-Signature header indicates a preference for signed messages but does not mandate that responses be signed. When a client sends Accept-Signature in a request, it SHOULD list the response components it wishes to have signed (including at least those specified above for signed responses). When a server sends Accept-Signature in a response, it SHOULD list the request components it wishes to have signed in subsequent requests (minimally those specified above for signed requests).

Error Conditions Errors may occur during the processing of the message signature. If the signature verification 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. An HTTP status code such as 400 (Bad Request) is appropriate. The response could include more details as per , such as an indicator that the wrong key material or algorithm was used. The use of HTTP status code 401 is NOT RECOMMENDED for this purpose because it requires a WWW-Authenticate with acceptable HTTP auth mechanisms in the error response and an associated Authorization header in the subsequent request. The use of these headers for the WIT is not compatible with this specification.

Example Requests and Responses Following is a non-normative example of a signed request and a signed response. The caller uses this keypair:

Caller Private Key

The caller uses its keypair and generates the following HTTP request:

Signed Request

Assuming that the workload being called has the following keypair:

Callee Private Key

A signed response would be:

Signed Response

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 specification 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".

Cofide

• Organization: Cofide
• Implementation: https://github.com/cofide/wimse-s2s-httpsig-poc
• Maturity:
  • WIT + HTTP Message Signatures: proof-of-concept
• Coverage: WIT, HTTP Message Signatures
• License: Apache 2.0
• Contact: jason@cofide.io
• Last updated: 13-Nov-2025

Security Considerations This section includes security considerations that are specific to the HTTP Signature protocol defined here. Refer to for more generic security considerations associated with the workload identity and its WIT representation.

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 as described in . The WIT is a general purpose token that can be presented in multiple contexts. The WIT and its PoP are only used in the application-layer options, and neither is used in MTLS. 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 proof of possession may be captured and replayed within the PoP's lifetime. The HTTP Signature profile presented here binds the proof of possession to the critical parts of the HTTP request (and potentially response), including the Request URI and the message body. This eliminates most of the risk associated with active attackers on a middlebox. In addition, the following mitigations should be used:

• Preventing Eavesdropping and Interception with TLS

An attacker observing or intercepting the communication channel can view the token and its proof of possession and attempt to replay it to gain an advantage. In order to prevent this, the token and proof of possession MUST be sent over a secure, server authenticated TLS connection unless a secure channel is provided by some other mechanisms. Hostname validation according to Section 6.3 of MUST be performed by the client.

• Limiting Signature Lifespan

The signature lifespan MUST be limited by using a tight expires value, taking into account potential clock skew and processing latency, but usually within minutes of the message sending time. Signatures received outside their validity time MUST be rejected.

• Replay Protection

A signed message includes the nonce signature parameter that MUST uniquely identify it, within the scope of a particular sender. This parameter SHOULD be used by the receiver to perform basic replay protection against messages it has already seen. Depending upon the design of the system it may be difficult to synchronize the replay cache across all message validators. If an attacker can somehow influence the identity of the validator (e.g. which cluster member receives the message) then replay protection would not be effective.

Middle Boxes In some deployments the Workload Identity Token and proof of possession (signature) may pass through multiple systems. The communication between the systems is over TLS, but the WIT and signature are available in the clear at each intermediary. While the intermediary cannot modify the token or the information within the signature they can attempt to capture and replay the message or modify unsigned information, such as proprietary HTTP headers that may remain unsigned. Mitigations listed in the protocol provide a reasonable level of security in these situations, in particular if responses are signed in addition to requests.

Privacy Considerations WITs and the signatures may contain private information such as user names or other identities. Care must be taken to prevent disclosure of this information. The use of TLS helps protect the privacy of WITs and proofs of possession. WITs 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 signatures can be used to track a user.

Security Goals This section defines semiformal security goals for this protocol, when used in conjunction with the WIT credential. Our aim is to inform developers and for these goals to eventually evolve into formal verification of the protocol.

Prerequisites The following are out of scope of the protocol and their security is assumed.

• There exists a WIT Issuer which is trusted to issue credentials honestly.
• Workloads have a way to authenticate themselves to the Issuer and be provisioned with a valid WIT, associated with their WIMSE identity.
• All workloads are provisioned with trust anchors that allow them to validate incoming WITs.
• The entire authorization subsystem is out of scope and trusted. This can potentially include provisioning and enforcement of an authorization policy, issuance of transaction tokens and workload attestation.
• All workload-to-workload traffic is TLS-protected. However TLS may be terminated on one or more middleboxes and the TLS endpoint identity (or identities) is not associated with a WIMSE identity.
• As a result, all workload-to-workload traffic is confidential and (assuming honest participants) is only available to sender, receiver, and any TLS-terminating middleboxes that process the traffic.

Authentication

• A workload receiving a request can validate that it is signed correctly, and can identify the sender.
• A workload receiving a response can similarly authenticate its sender, provided that optional response signing has been activated and likewise, the recipient validates this signature.
• The above implies that a stolen WIT cannot be used by an entity other than its owner.

Integrity

• No requests can be modified without detection by the recipient. Integrity of all present HTTP headers specified in this document is protected, as well as the derived components listed in , the signature parameters (including wimse-aud on requests and wimse-req-nonce on responses) as covered by @signature-params in , and the message body (when present).
• No responses can be modified without detection, provided that optional response signing has been activated and that the recipient validates incoming responses.
• Note: Headers not specified in this document may remain unsigned and could potentially be modified or deleted by intermediaries without detection.

Replay and Deletion

• Replay protection is not strictly mandated because of implementation considerations (e.g., distributed system challenges with synchronizing replay caches across validators). Therefore it is not claimed as a goal, though implementations SHOULD attempt to detect replays where feasible. We note that since most of the message is signed, replay attacks are only possible in a context where the request would be accepted as valid, and this mitigates the risk to some extent.
• When response signing is enabled, validating wimse-req-nonce mitigates replay of a signed response to a client other than the one that sent the triggering request.
• Unless response signing is mandated by local policy, complete deletion of a request/response pair is possible without detection.

IANA Considerations

HTTP Signature Metadata Parameters Registration IANA is requested to register the following entries in the "HTTP Signature Metadata Parameters" registry , per the registration template in Section 6.3.1 of :

• wimse-aud, per .
• wimse-req-nonce, per .

wimse-aud

• Name: wimse-aud
• Description: the WIMSE message audience. Request signatures only; binds the HTTP message signature to the intended recipient.
• Reference: RFC XXX, .

wimse-req-nonce

• Name: wimse-req-nonce
• Description: on response signatures, the nonce value from the triggering request's Signature-Input; binds the response to that request.
• Reference: RFC XXX, .

References Normative References This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Ping Identity CyberArk Defakto Security Intuit Zscaler 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. 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. 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. 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. 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. Informative References n.d. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg 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. CyberArk 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 a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). 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-level 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. 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. 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.

Document History RFC Editor: please remove before publication.

draft-ietf-wimse-http-signature-04

• On signed responses, require wimse-req-nonce (request binding); register with IANA. Non-normative response example not updated accordingly; the Signature value was not regenerated (see issue tracker).

draft-ietf-wimse-http-signature-03

• Replace Wimse-Audience HTTP header with the wimse-aud signature metadata parameter (); register with IANA (HTTP Signature Metadata Parameters). Non-normative request example updated accordingly; the Signature value was not regenerated (see issue tracker).

draft-ietf-wimse-http-signature-02

• Add new Wimse-Audience HTTP header (superseded by wimse-aud in -03).

draft-ietf-wimse-http-signature-01

• Clarified response signing.
• Clarified signature vs. token lifetime.
• Added security goals.
• Added an Implementation Status section.

draft-ietf-wimse-http-signature-00

• Initial version, extracted from the -07 draft with minimal edits.

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

Comparing the DPoP Inspired Option with Message Signatures The two workload protection options have different strengths and weaknesses regarding implementation complexity, extensibility, and security. Here is a summary of the main differences between and .

• The DPoP-inspired solution is less HTTP-specific, making it easier to adapt for other protocols beyond HTTP. This flexibility is particularly valuable for asynchronous communication scenarios, such as event-driven systems.
• Message Signatures, on the other hand, benefit from an existing HTTP-specific RFC with some established implementations. This existing groundwork means that this option could be simpler to deploy, to the extent such implementations are available and easily integrated.
• Given that the WIT (Workload Identity Token) is a type of JWT, the DPoP-inspired approach that also uses JWT is less complex and technology-intensive than Message Signatures. In contrast, Message Signatures introduce an additional layer of technology, potentially increasing the complexity of the overall system.
• Message Signatures offer superior integrity protection, particularly by mitigating message modification by middleboxes. See also .
• A key advantage of Message Signatures is that they support response signing. This opens up the possibility for future decisions about whether to make response signing mandatory, allowing for flexibility in the specification and/or in specific deployment scenarios.
• In general, Message Signatures provide greater flexibility compared to the DPoP-inspired approach. Future versions of this draft (and subsequent implementations) can decide whether specific aspects of message signing, such as coverage of particular fields, should be mandatory or optional. Covering more fields will constrain the proof so it cannot be easily reused in another context, which is often a security improvement. The DPoP inspired approach could be designed to include extensibility to sign other fields, but this would make it closer to trying to reinvent Message Signatures.

Acknowledgments The authors would like to thank Pieter Kasselman for his detailed comments, as well as Jason Costello, Maartje Eyskens and Radosław Piliszek for implementing this draft and sharing their learnings. We thank Daniel Feldman for his contributions to earlier versions of this document. We also thank Arndt Schwenkschuster and Brian Campbell who coauthored the grand unified WIMSE Workload to Workload protocol draft.