WIMSE Workload-to-Workload Authentication with HTTP Signatures
draft-ietf-wimse-http-signature-08
| Document | Type | Active Internet-Draft (wimse WG) | |
|---|---|---|---|
| Authors | Joseph A. Salowey , Yaron Sheffer | ||
| Last updated | 2026-10-20 | ||
| Replaces | draft-ietf-wimse-s2s-protocol | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Justin Richer | ||
| Shepherd write-up | Show Last changed 2026-10-24 | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | ietf@justin.richer.org |
draft-ietf-wimse-http-signature-08
Workload Identity in Multi System Environments J. Salowey
Internet-Draft Palo Alto Networks
Intended status: Standards Track Y. Sheffer
Expires: 23 April 2027 Independent
20 October 2026
WIMSE Workload-to-Workload Authentication with HTTP Signatures
draft-ietf-wimse-http-signature-08
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://ietf-wg-
wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-s2s-
protocol.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/.
Discussion of this document takes place on the Workload Identity in
Multi System Environments Working Group mailing list
(mailto:wimse@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at
https://www.ietf.org/mailman/listinfo/wimse/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-wimse/draft-ietf-wimse-s2s-protocol.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Salowey & Sheffer Expires 23 April 2027 [Page 1]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Deployment Architecture and Message Flow . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. The Protocol: Authentication Based on HTTP Message
Signatures . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 8
3.2. The wimse-aud Signature Parameter . . . . . . . . . . . . 8
3.3. The wimse-sign-response Signature Parameter . . . . . . . 9
3.4. The wimse-req-nonce Signature Parameter . . . . . . . . . 9
3.5. Signing the Response . . . . . . . . . . . . . . . . . . 9
3.6. Error Conditions . . . . . . . . . . . . . . . . . . . . 11
3.7. Example Requests and Responses . . . . . . . . . . . . . 11
3.7.1. Ed25519: svcA calling svcB . . . . . . . . . . . . . 11
3.7.2. ES256: svcB calling svcC . . . . . . . . . . . . . . 13
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
4.1. Cofide . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. wimsey . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Workload Identity Token and Proof of Possession . . . . . 17
5.2. Middle Boxes . . . . . . . . . . . . . . . . . . . . . . 18
Salowey & Sheffer Expires 23 April 2027 [Page 2]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. HTTP Signature Metadata Parameters Registration . . . . . 19
7.1.1. wimse-aud . . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. wimse-sign-response . . . . . . . . . . . . . . . . . 19
7.1.3. wimse-req-nonce . . . . . . . . . . . . . . . . . . . 19
7.2. HTTP Problem Types Registration . . . . . . . . . . . . . 19
7.2.1. wimse-signature-invalid . . . . . . . . . . . . . . . 20
7.2.2. wimse-signed-response-unsupported . . . . . . . . . . 20
7.2.3. wimse-signed-response-unavailable . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Security Goals . . . . . . . . . . . . . . . . . . . 23
A.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 23
A.2. Authentication . . . . . . . . . . . . . . . . . . . . . 24
A.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. Replay and Deletion . . . . . . . . . . . . . . . . . . . 24
Appendix B. Document History . . . . . . . . . . . . . . . . . . 25
B.1. draft-ietf-wimse-http-signature-08 . . . . . . . . . . . 25
B.2. draft-ietf-wimse-http-signature-07 . . . . . . . . . . . 25
B.3. draft-ietf-wimse-http-signature-06 . . . . . . . . . . . 26
B.4. draft-ietf-wimse-http-signature-05 . . . . . . . . . . . 26
B.5. draft-ietf-wimse-http-signature-04 . . . . . . . . . . . 26
B.6. draft-ietf-wimse-http-signature-03 . . . . . . . . . . . 26
B.7. draft-ietf-wimse-http-signature-02 . . . . . . . . . . . 26
B.8. draft-ietf-wimse-http-signature-01 . . . . . . . . . . . 26
B.9. draft-ietf-wimse-http-signature-00 . . . . . . . . . . . 26
B.10. draft-ietf-wimse-s2s-protocol-07 . . . . . . . . . . . . 27
B.11. draft-ietf-wimse-s2s-protocol-06 . . . . . . . . . . . . 27
B.12. draft-ietf-wimse-s2s-protocol-05 . . . . . . . . . . . . 27
B.13. draft-ietf-wimse-s2s-protocol-04 . . . . . . . . . . . . 27
B.14. draft-ietf-wimse-s2s-protocol-03 . . . . . . . . . . . . 28
B.15. draft-ietf-wimse-s2s-protocol-02 . . . . . . . . . . . . 28
B.16. draft-ietf-wimse-s2s-protocol-01 . . . . . . . . . . . . 28
B.17. draft-ietf-wimse-s2s-protocol-00 . . . . . . . . . . . . 28
Appendix C. Comparing the DPoP Inspired Option with Message
Signatures . . . . . . . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
This document defines authentication and authorization in the context
of interaction between two workloads. This is the core component of
the WIMSE architecture [I-D.ietf-wimse-arch]. This document focuses
on HTTP-based services, and the workload-to-workload call consists of
a single HTTP request and its response.
Salowey & Sheffer Expires 23 April 2027 [Page 3]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
One option to protect such traffic is through Mutual TLS (mTLS), and
this usage is defined in [I-D.ietf-wimse-mutual-tls]. Many
deployments prefer application-layer approaches, whether for lack of
Certification Authority (CA) infrastructure or because inter-service
communication consists of multiple TLS hops. This document defines
one such WIMSE approach for application-layer protection.
We define a profile of the HTTP Signatures protocol [RFC9421] to
protect the service traffic. Service authentication uses the
Workload Identity Token (WIT) defined in
[I-D.ietf-wimse-workload-creds], and the signature uses the private
key associated with the WIT and thus proves possession of that key.
WIMSE is specifying two approaches for application-layer protection,
both using the newly introduced Workload Identity Token
[I-D.ietf-wimse-workload-creds]. The first alternative
[I-D.ietf-wimse-wpt] is inspired by the OAuth DPoP specification
[RFC9449]. The second is based on the HTTP Message Signatures RFC
[RFC9421], and it is defined in this document. Appendix C includes a
comparison of the two approaches.
1.1. Deployment Architecture and Message Flow
Refer to Sec. 1.2 of [I-D.ietf-wimse-workload-creds] for the
deployment architecture which is common to both application-level
approaches, as well as the transport-level one.
2. Conventions and Definitions
All terminology in this document follows [I-D.ietf-wimse-arch].
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The Protocol: Authentication Based on HTTP Message Signatures
This protocol uses the Workload Identity Token
[I-D.ietf-wimse-workload-creds] and the private key associated with
its public key, to sign the HTTP request and optionally, the
response. Formally, this is a profile of the Message Signatures
specification [RFC9421].
The request is signed as per [RFC9421]. The following derived
components MUST be signed:
Salowey & Sheffer Expires 23 April 2027 [Page 4]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
* @method
* @path
* @query
This profile covers @path and @query separately rather than @request-
target, following Section 2.2.5 of [RFC9421]. @query is included even
when the request has no query component; in that case its value is ?
(Section 2.2.7 of [RFC9421]). The @authority derived component is
not included: TLS-terminating proxies and load balancers commonly
rewrite the authority (see [I-D.ietf-wimse-arch] and Section 5.2), so
signing it would break those deployments. Recipient binding is
carried instead by the mandatory wimse-aud signature parameter
(Section 3.2).
Exception for CONNECT (Section 9.3.6 of [RFC9110]): the request
target is in authority-form (host:port), so @path and @query are not
meaningful. For a CONNECT request, senders MUST cover @method and
@authority instead of @path and @query, and MUST NOT cover @path or
@query. The @authority value is the host and port of the CONNECT
target (Section 2.2.3 of [RFC9421]). This exception is specific to
CONNECT; this profile otherwise continues to omit @authority.
In addition, the following request headers MUST be signed when they
exist:
* Content-Type
* Content-Digest
* Authorization
* Txn-Token [I-D.ietf-oauth-transaction-tokens]
* Workload-Identity-Token
If the response is signed, the following components MUST be signed:
* @status
* @method;req
* @path;req
* @query;req
* Content-Type if it exists
Salowey & Sheffer Expires 23 April 2027 [Page 5]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
* Content-Digest if it exists
* Workload-Identity-Token
When the signed response corresponds to a CONNECT request, senders
MUST cover @method;req and @authority;req instead of @path;req and
@query;req, and MUST NOT cover @path;req or @query;req.
To protect the integrity of the message body, if the request or
response includes a body, the sender MUST include (and the receiver
MUST verify) a Content-Digest header as defined in [RFC9530]. This
implies the receiver MUST compute the Content-Digest value for the
message content received and compare it with the Content-Digest value
provided in the message.
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.
This profile is for individual request/response exchanges;
mechanisms for long-lived batch-style workloads are out of scope.
* 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 (Section 3.2)
For requests only, the following signature parameter MAY also be
included:
* wimse-sign-response (Section 3.3)
For responses only, the following signature parameter MUST also be
included:
* wimse-req-nonce (Section 3.4)
The following signature parameters in the Signature-Input header MUST
NOT be used:
Salowey & Sheffer Expires 23 April 2027 [Page 6]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
* 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 [I-D.ietf-wimse-workload-creds] and
Sec. 3.3.7 of [RFC9421] for details.
It is RECOMMENDED to include only one signature with the HTTP
message. The WIMSE signature is the one whose tag parameter is
wimse-workload-to-workload (Section 7.2.7 of [RFC9421]). If no
signature has that tag value, the message does not carry a WIMSE HTTP
signature. If more than one signature has that tag value, the
recipient MUST reject the message. When more than one signature is
present, recipients MUST use that tag to find the WIMSE signature;
they MUST NOT choose by label (Section 7.2.5 of [RFC9421]).
Senders MUST generate each nonce at random with sufficient length
that the probability of collision is negligible among all nonces a
recipient might observe within the lifetime of a signature. To that
end, senders MUST use a cryptographically secure random number
generator, and the nonce MUST contain at least 64 bits of entropy; 96
bits or more is RECOMMENDED. Members of a sender cluster therefore
need not coordinate nonce generation.
Recipients MAY maintain a replay cache and SHOULD reject a message
(request or response) whose nonce they have already seen. What
nonces are remembered, and for how long, is a local policy matter;
this document does not require replay caches to be shared across
validators. Without such sharing, replay to a different cluster
member can still succeed.
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. Recipients MUST reject
signatures that fall outside their validity time window.
Implementers 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 WIT as specified in
Section 5.1.4 of [I-D.ietf-wimse-workload-creds] before validating
the HTTP message signature. They MUST ensure that the message is not
processed further before it has been fully validated.
Salowey & Sheffer Expires 23 April 2027 [Page 7]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
The WIT and the HTTP message signature MUST be sent over a server-
authenticated TLS connection unless another channel provides
confidentiality and server authentication comparable to TLS. When
TLS is used, the client MUST perform hostname validation according to
Section 6.3 of [RFC9525], and TLS deployments SHOULD follow the
recommendations in [BCP195].
3.1. Signature Algorithms
The HTTP message signature algorithm is determined by the alg member
of the cnf.jwk object in the WIT ("The Workload Identity Token" in
[I-D.ietf-wimse-workload-creds]). This profile does not define a
separate algorithm baseline; general-purpose implementations follow
the algorithm requirements in that document, including support for
ES256. The alg signature parameter MUST NOT be used, as specified
above.
Recipients MUST verify the HTTP message signature using the algorithm
identified by cnf.jwk.alg and MUST reject the message if that
algorithm is not acceptable under local policy for the peer's trust
domain. See also Section 7.3.6 of [RFC9421] on key and algorithm
specification downgrades.
3.2. The wimse-aud Signature Parameter
[RFC9421] 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 [RFC9421]), which
is always the last line of the signature base.
The wimse-aud signature metadata parameter is a String parameter for
requests. Using a signature parameter carries the audience
explicitly in Signature-Input, so the value is protected by the
signature and is not affected by hop-by-hop rewriting of the request
URI.
The sender MUST set wimse-aud to an audience value that identifies
the intended recipient of the request. By default, the sender uses
the HTTP target URI (Section 7.1 of [RFC9110]) of the request,
without query or fragment components, as known to the sender. When
intermediaries rewrite the request URI, or when that string would not
match what the recipient expects, the sender uses a deployment-
specific audience value that the recipient can recognize. The
audience identifies the intended recipient of the proof; it is
distinct from the sender's Workload Identifier in the WIT sub claim.
Salowey & Sheffer Expires 23 April 2027 [Page 8]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
The recipient MUST verify that wimse-aud matches one of the audience
values in its trusted configuration using the Simple String
Comparison method of Section 6.2.1 of [RFC3986]. Strings that differ
only by URI normalization (for example, a trailing slash or an
explicit default port) do not match under that method; if such
variants are acceptable, each should be included in the
configuration. The recipient MUST NOT derive an acceptable audience
from untrusted request fields such as Host. A sender that relies on
the default target-URI value is responsible for producing a string
that matches one of the recipient's configured values under that
comparison. See "Workload Identifiers and Authentication
Granularity" in [I-D.ietf-wimse-workload-creds].
3.3. The wimse-sign-response Signature Parameter
The wimse-sign-response signature metadata parameter is a Boolean
parameter for requests. When present with the value true, the client
requires a signed HTTP response: the server MUST sign the response as
specified in Section 3.5, or return an error if it cannot
(Section 3.6). When the parameter is omitted, or present with the
value false, the client does not require a signed response via this
parameter.
If the client is configured to require a signed response, it MUST
include wimse-sign-response with the Boolean value true in the
request's Signature-Input.
This parameter is not mandatory. Moreover, the server MAY sign the
response even if this parameter is missing from the request or is
present with the value false.
3.4. The wimse-req-nonce Signature Parameter
The wimse-req-nonce signature metadata parameter is a String
parameter for signed responses. This parameter binds requests to
responses and prevents a malicious server-side component or middlebox
from replaying responses to the wrong client.
Every signed response MUST include wimse-req-nonce. The server MUST
set it to the value of the nonce signature parameter from the
Signature-Input of the request that triggered the response.
3.5. Signing the Response
Protecting the response by signing it with the server's WIT is
RECOMMENDED but not required. In particular, if the response may be
exceptionally large or is expected to be streamed, signing it may not
be practical.
Salowey & Sheffer Expires 23 April 2027 [Page 9]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
Response signing is required of the server for a given exchange when
either of the following is true:
* The request's Signature-Input includes wimse-sign-response with
the Boolean value true (Section 3.3).
* Local policy at the server requires response signing for that
exchange.
If the server is required to sign the response but cannot produce a
signed response (for example, because the response is streamed or
exceptionally large), it MUST NOT return a successful unsigned
response; it MUST return an error as described in Section 3.6.
The client MUST reject an unsigned response when the request's
Signature-Input included wimse-sign-response with the Boolean value
true.
If the client did not require a signed response via wimse-sign-
response, server-side local-policy signing is opportunistic from the
client's point of view: the client has no signal that a signature was
expected, so a middlebox that strips a signed response leaves an
ordinary unsigned response that the client MUST accept. The server
MAY still sign in that case. Whenever a signed response is present,
the client MUST validate it and reject it if validation fails.
When validating a signed response, the client MUST verify that wimse-
req-nonce is present and equals the nonce from the corresponding
request.
As described in Section 5 of [RFC9421], either client or server MAY
send an Accept-Signature header. That header indicates a preference
for signed messages; it does not mandate that a response be signed.
Only wimse-sign-response with the Boolean value true creates such a
mandate (Section 3.3, Section 3.5). When both are present, the
server MUST treat wimse-sign-response as authoritative for whether a
signed response is required. When a client sends Accept-Signature in
a request, it MUST 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
MUST list the request components it wishes to have signed in
subsequent requests, minimally those specified above for signed
requests. Accept-Signature MUST NOT be used to request coverage
weaker than this profile.
Salowey & Sheffer Expires 23 April 2027 [Page 10]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
3.6. Error Conditions
Errors may occur during the processing of the message signature.
This profile specifies the following HTTP status codes for API use.
The party generating the error SHOULD include a problem details body
([RFC9457]) with the corresponding registered problem type
(Section 7.2), unless it knows that the peer does not accept problem
details responses.
If authentication of a signed request fails — including WIT
validation (Section 5.1.4 of [I-D.ietf-wimse-workload-creds]) or
verification of the HTTP message signature — for any reason such as
an invalid signature, an expired validity time window, or a malformed
data structure, the server MUST return 400 (Bad Request). The
problem type for this error is https://iana.org/assignments/http-
problem-types#wimse-signature-invalid (Section 7.2.1). The server
MUST NOT distinguish in the response which check failed, so as not to
reveal whether the WIT or the HTTP message signature was
unacceptable. 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.
If response signing is required (Section 3.5) and the server cannot
sign the response, the server MUST NOT return a successful unsigned
response. If the server does not support response signing, it MUST
return 501 (Not Implemented); the problem type for this error is
https://iana.org/assignments/http-problem-types#wimse-signed-
response-unsupported (Section 7.2.2). If the server supports
response signing but cannot sign this particular response (for
example, because the response is streamed or exceptionally large), it
MUST return 400 (Bad Request); the problem type for this error is
https://iana.org/assignments/http-problem-types#wimse-signed-
response-unavailable (Section 7.2.3).
3.7. Example Requests and Responses
The following non-normative examples illustrate this profile with two
algorithms: Ed25519 ([RFC9864]) for svcA/svcB, and ES256 for svcC.
The first exchange is svcA calling svcB; the second is svcB calling
svcC.
3.7.1. Ed25519: svcA calling svcB
Following is a signed request and a signed response using Ed25519.
Salowey & Sheffer Expires 23 April 2027 [Page 11]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
The caller (svcA) uses this keypair:
{
"alg": "Ed25519",
"crv": "Ed25519",
"d": "fNVx2xkvU-jbsowg3cHMGLPzODvkM8Rd1UClQxv_VP0",
"kid": "svc-a-key",
"kty": "OKP",
"x": "QDYLWc32T8hljQoolDi0ukqXtvNB1h-qNbpfuwZkZDg"
}
Figure 1: svcA Private Key (Ed25519)
The caller uses its keypair and generates the following HTTP request:
=============== NOTE: '\' line wrapping per RFC 8792 ================
GET /gimme-ice-cream?flavor=vanilla HTTP/1.1
Host: svcb.example.com
Signature: sig1=:wfnk8T0ysp3a6bvqZAoeBoa2dFgRHooSel8jIAbKnbIP13cpy/O\
1J6xAYkziiUnVQ+NlMoR+ANDBHRwoB7ZIAA==:
Signature-Input: sig1=("@method" "@path" "@query" "workload-identity\
-token");created=1789405135;expires=1789405435;nonce="abcd1111";tag=\
"wimse-workload-to-workload";wimse-aud="https://svcb.example.com/gim\
me-ice-cream";wimse-sign-response
Workload-Identity-Token: eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiaXNzdWVyLWt\
leSIsInR5cCI6IndpdCtqd3QifQ.eyJjbmYiOnsiandrIjp7ImFsZyI6IkVkMjU1MTki\
LCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoic3ZjLWEta2V5Iiwia3R5IjoiT0tQIiwieCI6\
IlFEWUxXYzMyVDhobGpRb29sRGkwdWtxWHR2TkIxaC1xTmJwZnV3WmtaRGcifX0sImV4\
cCI6MTc4OTQwNTQzNSwiaWF0IjoxNzg5NDA1MTM1LCJpc3MiOiJodHRwczovL2V4YW1w\
bGUuY29tL2lzc3VlciIsImp0aSI6IndpdC0xNzg5NDA1MTM1OTUxMjQ5OTY1Iiwic3Vi\
Ijoid2ltc2U6Ly9leGFtcGxlLmNvbS9zdmNBIn0.XDaCtnf42Z4bYKqQxTkMGJ-Gtcg5\
iG7Z0QdBxj4J_d8Q4PVcoFwxfaeKnJD_iuTF8Nt_0eyZOiGYgngCk2omAg
Figure 2: Signed Request (svcA to svcB)
Assuming that the workload being called (svcB) has the following
keypair:
{
"alg": "Ed25519",
"crv": "Ed25519",
"d": "uJf73cksN9k54kJtgrc0nBc3_WzkcJovRXWjEIYyESE",
"kid": "svc-b-key",
"kty": "OKP",
"x": "WUZzabuwlwS9xlhndvLRMWQdkyjdOqVySiwqqd6brLM"
}
Salowey & Sheffer Expires 23 April 2027 [Page 12]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
Figure 3: svcB Private Key (Ed25519)
A signed response would be:
=============== NOTE: '\' line wrapping per RFC 8792 ================
HTTP/1.1 404 Not Found
Content-Length: 20
Content-Digest: sha-256=:uJC3qmCc7n6/6w4N2I0vAfj1cd/hTOAhxLEYXmPbNno\
=:
Content-Type: text/plain
Signature: sig1=:CUsdmPCDf6I587umdsSTKJvC00fMkj48Z7g1sWzYWAzhB2OZgZa\
ujchkP1Xw2dsJlTngAIbhyIq07diOYnHIBQ==:
Signature-Input: sig1=("@status" "workload-identity-token" "content-\
type" "content-digest" "@method";req "@path";req "@query";req);creat\
ed=1789405135;expires=1789405437;nonce="abcd2222";tag="wimse-workloa\
d-to-workload";wimse-req-nonce="abcd1111"
Workload-Identity-Token: eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiaXNzdWVyLWt\
leSIsInR5cCI6IndpdCtqd3QifQ.eyJjbmYiOnsiandrIjp7ImFsZyI6IkVkMjU1MTki\
LCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoic3ZjLWIta2V5Iiwia3R5IjoiT0tQIiwieCI6\
IldVWnphYnV3bHdTOXhsaG5kdkxSTVdRZGt5amRPcVZ5U2l3cXFkNmJyTE0ifX0sImV4\
cCI6MTc4OTQwNTQzNywiaWF0IjoxNzg5NDA1MTM3LCJpc3MiOiJodHRwczovL2V4YW1w\
bGUuY29tL2lzc3VlciIsImp0aSI6IndpdC0xNzg5NDA1MTM1OTUxNTEzODY2Iiwic3Vi\
Ijoid2ltc2U6Ly9leGFtcGxlLmNvbS9zdmNCIn0.T9hsSJX6aaMAbF5lnB47vHXj4k_c\
gOVRQtENfrdj0_Ut9vv5eEnGXcR_vqyfcm8mi-tQyg57sEvfFuoseRoCBA
No ice cream today.
Figure 4: Signed Response (svcB to svcA)
3.7.2. ES256: svcB calling svcC
The following exchange uses ES256 at the callee (svcC). The caller
is svcB, using the Ed25519 keypair above.
The callee (svcC) uses this keypair:
{
"alg": "ES256",
"crv": "P-256",
"d": "RuJQPzrHlQrRllszMFQQw3e8bSdArcYeXjhnXRXclHs",
"kid": "svc-c-key",
"kty": "EC",
"x": "dquxM0LHBbWlYCDxcNRHe9kb41lrnL0h_9ntNXKxzxw",
"y": "HPqRls-EZoPrHY9gNRcZGq5pkypeovfnzLSfsYP2L6o"
}
Figure 5: svcC Private Key (ES256)
Salowey & Sheffer Expires 23 April 2027 [Page 13]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
A signed request from svcB to svcC:
=============== NOTE: '\' line wrapping per RFC 8792 ================
POST /inventory/cones HTTP/1.1
Host: svcc.example.com
Content-Digest: sha-256=:TzKXT0tUEfiTFkjRzwE8nCFnQljMuX5xwJaJgJCp+1g\
=:
Content-Length: 31
Content-Type: application/json
Signature: sig1=:EzNtEBAW99awIJtUjPxMqtHXYh0Y6MpOwzeMePSMCx6oqU2gh68\
0rk5+B1zFD8Xv7TRRffiM6nCOd58u4bvGDg==:
Signature-Input: sig1=("@method" "@path" "@query" "workload-identity\
-token" "content-type" "content-digest");created=1789405135;expires=\
1789405437;nonce="abcd3333";tag="wimse-workload-to-workload";wimse-a\
ud="https://svcc.example.com/inventory/cones";wimse-sign-response
Workload-Identity-Token: eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiaXNzdWVyLWt\
leSIsInR5cCI6IndpdCtqd3QifQ.eyJjbmYiOnsiandrIjp7ImFsZyI6IkVkMjU1MTki\
LCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoic3ZjLWIta2V5Iiwia3R5IjoiT0tQIiwieCI6\
IldVWnphYnV3bHdTOXhsaG5kdkxSTVdRZGt5amRPcVZ5U2l3cXFkNmJyTE0ifX0sImV4\
cCI6MTc4OTQwNTQzNywiaWF0IjoxNzg5NDA1MTM3LCJpc3MiOiJodHRwczovL2V4YW1w\
bGUuY29tL2lzc3VlciIsImp0aSI6IndpdC0xNzg5NDA1MTM1OTUxNTEzODY2Iiwic3Vi\
Ijoid2ltc2U6Ly9leGFtcGxlLmNvbS9zdmNCIn0.T9hsSJX6aaMAbF5lnB47vHXj4k_c\
gOVRQtENfrdj0_Ut9vv5eEnGXcR_vqyfcm8mi-tQyg57sEvfFuoseRoCBA
{"flavor":"vanilla","amount":1}
Figure 6: Signed Request (svcB to svcC)
A signed response from svcC:
Salowey & Sheffer Expires 23 April 2027 [Page 14]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
=============== NOTE: '\' line wrapping per RFC 8792 ================
HTTP/1.1 409 Conflict
Content-Length: 43
Content-Digest: sha-256=:xKyvC1Ob10QItKe0NdnKhtZ/6R7/JkpTxdH20RccxFY\
=:
Content-Type: application/json
Signature: sig1=:opZnqGnxaozdrf8ecfV+pAQ2wH2aIOtM5+dS6NI/MozKaVF3OUf\
xFyAC34i2+KbMNZHYlTzJzCPqXRucMbgFlA==:
Signature-Input: sig1=("@status" "workload-identity-token" "content-\
type" "content-digest" "@method";req "@path";req "@query";req);creat\
ed=1789405135;expires=1789405439;nonce="abcd4444";tag="wimse-workloa\
d-to-workload";wimse-req-nonce="abcd3333"
Workload-Identity-Token: eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiaXNzdWVyLWt\
leSIsInR5cCI6IndpdCtqd3QifQ.eyJjbmYiOnsiandrIjp7ImFsZyI6IkVTMjU2Iiwi\
Y3J2IjoiUC0yNTYiLCJraWQiOiJzdmMtYy1rZXkiLCJrdHkiOiJFQyIsIngiOiJkcXV4\
TTBMSEJiV2xZQ0R4Y05SSGU5a2I0MWxybkwwaF85bnROWEt4enh3IiwieSI6IkhQcVJs\
cy1FWm9QckhZOWdOUmNaR3E1cGt5cGVvdmZuekxTZnNZUDJMNm8ifX0sImV4cCI6MTc4\
OTQwNTQzOSwiaWF0IjoxNzg5NDA1MTM5LCJpc3MiOiJodHRwczovL2V4YW1wbGUuY29t\
L2lzc3VlciIsImp0aSI6IndpdC0xNzg5NDA1MTM1OTUxNTcwODY2Iiwic3ViIjoid2lt\
c2U6Ly9leGFtcGxlLmNvbS9zdmNDIn0.kaMHAoW7nZ5NrkwOzHE1zGEm-S9Dk5rWICPj\
KQenhHuwksZqhW2EO1MV0vh_dcBQzvnMS710Do9KEZkcg4QyDQ
{"error":"out_of_stock","flavor":"vanilla"}
Figure 7: Signed Response (svcC to svcB)
4. 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 [RFC7942].
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.
Salowey & Sheffer Expires 23 April 2027 [Page 15]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
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".
4.1. Cofide
* Organization: Cofide
* Implementation: https://github.com/cofide/wimse-s2s-httpsig-poc
(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
4.2. wimsey
* Organization: independent
* Implementation: https://github.com/kanywst/wimsey
(https://github.com/kanywst/wimsey)
* Maturity:
- WIT + HTTP Message Signatures: alpha
* Coverage: WIT, HTTP Message Signatures, signed responses
* License: Apache 2.0
* Contact: kanywst on GitHub (https://github.com/kanywst)
* Last updated: 08-Sep-2026
Salowey & Sheffer Expires 23 April 2027 [Page 16]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
5. Security Considerations
This section includes security considerations that are specific to
the HTTP Signature protocol defined here. Refer to
[I-D.ietf-wimse-workload-creds] for more generic security
considerations associated with the workload identity and its WIT
representation.
5.1. 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 [I-D.ietf-wimse-workload-creds]. 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. As specified in that document, the WIT is
not 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 HTTP Signature profile presented here binds the PoP to the
critical parts of the HTTP request (and potentially response),
including the request method, path, query, the intended audience
(wimse-aud), and the message content. The audience is a signed
signature parameter rather than a re-derived URI component, so it
survives intermediaries that rewrite the authority. This profile
does not cover @authority for that reason (Section 3). This
eliminates most of the risk associated with active attackers on a
middlebox.
In addition, the following mitigations apply:
* Preventing Eavesdropping and Interception with TLS
An attacker observing or intercepting the communication channel can
view the token and its PoP and attempt to replay it to gain an
advantage. Sending the token and PoP on a server-authenticated TLS
connection (Section 3), with hostname validation, mitigates passive
capture on the path. TLS-terminating intermediaries still see the
cleartext WIT and signature; see Section 5.2.
* Limiting Signature Lifespan
A short expires value (Section 3) limits the window during which a
captured signature can be replayed. Rejecting signatures outside
their validity time is required by that section.
* Replay Protection
Salowey & Sheffer Expires 23 April 2027 [Page 17]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
The nonce signature parameter and optional replay caching (Section 3)
provide basic replay detection. 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.
5.2. Middle Boxes
In some deployments the Workload Identity Token and PoP (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 without detection, it
can attempt to capture and replay the message or modify unsigned
information, such as any HTTP headers that remain unsigned.
HTTP permits intermediaries to transform messages ([RFC9421]). This
profile is intended to remain verifiable across common TLS-
terminating proxies and load balancers: it does not cover @authority,
and it carries recipient binding in wimse-aud (Section 3). An
intermediary can add its own HTTP message signature to a message that
already carries a WIMSE signature. Recipients continue to identify
the WIMSE signature by its tag value wimse-workload-to-workload and
do not select by label (Section 3).
If an intermediary changes a component covered by the WIMSE
signature, verification of that signature fails. This document does
not define a profile for stripping the origin WIMSE signature and
replacing it with a new WIMSE signature at the intermediary. Such
resigning would authenticate the intermediary rather than the origin
workload and is left to deployment-specific policy outside this
specification.
Mitigations listed in the protocol provide a reasonable level of
security in these situations, in particular if responses are signed
in addition to requests. See also Section 3.5 for the distinction
between client-mandated and opportunistic response signing.
6. Privacy Considerations
Privacy considerations for the Workload Identity Token and its proof
of possession are discussed in [I-D.ietf-wimse-workload-creds]. This
profile does not introduce additional privacy concerns beyond those.
Salowey & Sheffer Expires 23 April 2027 [Page 18]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
7. IANA Considerations
7.1. HTTP Signature Metadata Parameters Registration
IANA is requested to register the following entries in the "HTTP
Signature Metadata Parameters" registry
[IANA.HTTP.MESSAGE.SIGNATURE], per the registration template in
Section 6.3.1 of [RFC9421]:
* wimse-aud, per Section 7.1.1.
* wimse-sign-response, per Section 7.1.2.
* wimse-req-nonce, per Section 7.1.3.
7.1.1. wimse-aud
* Name: wimse-aud
* Description: String; the WIMSE message audience. Request
signatures only; binds the HTTP message signature to the intended
recipient.
* Reference: RFC XXX, Section 3.2.
7.1.2. wimse-sign-response
* Name: wimse-sign-response
* Description: Boolean; when true on a request signature, the client
requires the server to sign the corresponding HTTP response.
* Reference: RFC XXX, Section 3.3.
7.1.3. wimse-req-nonce
* Name: wimse-req-nonce
* Description: String; on response signatures, the nonce value from
the triggering request's Signature-Input; binds the response to
that request.
* Reference: RFC XXX, Section 3.4.
7.2. HTTP Problem Types Registration
IANA is requested to register the following entries in the "HTTP
Problem Types" registry of [RFC9457].
Salowey & Sheffer Expires 23 April 2027 [Page 19]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
7.2.1. wimse-signature-invalid
* Type URI: https://iana.org/assignments/http-problem-types#wimse-
signature-invalid
* Title: WIMSE HTTP Signature Invalid
* Recommended HTTP status code: 400
* Reference: RFC XXX, Section 3.6
7.2.2. wimse-signed-response-unsupported
* Type URI: https://iana.org/assignments/http-problem-types#wimse-
signed-response-unsupported
* Title: WIMSE Signed Response Unsupported
* Recommended HTTP status code: 501
* Reference: RFC XXX, Section 3.6
7.2.3. wimse-signed-response-unavailable
* Type URI: https://iana.org/assignments/http-problem-types#wimse-
signed-response-unavailable
* Title: WIMSE Signed Response Unavailable
* Recommended HTTP status code: 400
* Reference: RFC XXX, Section 3.6
8. References
8.1. Normative References
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Salowey & Sheffer Expires 23 April 2027 [Page 20]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J. A., Schwenkschuster, A.,
Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
Credentials", Work in Progress, Internet-Draft, draft-
ietf-wimse-workload-creds-02, 2 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/rfc/rfc9457>.
Salowey & Sheffer Expires 23 April 2027 [Page 21]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
8.2. Informative References
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-11, 30 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-11>.
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[I-D.ietf-wimse-mutual-tls]
Salowey, J. A. and Y. Rosomakho, "Workload Authentication
Using Mutual TLS", Work in Progress, Internet-Draft,
draft-ietf-wimse-mutual-tls-02, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
mutual-tls-02>.
[I-D.ietf-wimse-wpt]
Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
Token", Work in Progress, Internet-Draft, draft-ietf-
wimse-wpt-02, 27 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-02>.
[IANA.HTTP.MESSAGE.SIGNATURE]
"HTTP Message Signature", n.d.,
<https://www.iana.org/assignments/http-message-signature/
http-message-signature.xhtml#signature-metadata-
parameters>.
Salowey & Sheffer Expires 23 April 2027 [Page 22]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
[RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
JSON Object Signing and Encryption (JOSE) and CBOR Object
Signing and Encryption (COSE)", RFC 9864,
DOI 10.17487/RFC9864, October 2025,
<https://www.rfc-editor.org/rfc/rfc9864>.
Appendix A. Security Goals
This appendix presents semiformal security goals for this protocol,
when used in conjunction with the WIT credential. The intent is to
inform developers and to support eventual formal verification of the
protocol; the goals are not normative requirements beyond those
stated in the body of this document.
A.1. 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.
Salowey & Sheffer Expires 23 April 2027 [Page 23]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
A.2. 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 validate the
signature and identify the sender when a signed response is
present.
* The above implies that a stolen WIT cannot be used by an entity
other than its owner.
A.3. Integrity
* Covered components of a request cannot 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 Section 3, the signature parameters
(including wimse-aud and wimse-sign-response on requests and
wimse-req-nonce on responses) as covered by @signature-params in
[RFC9421], and the message content (when present).
* Covered components of a signed response cannot be modified without
detection by the recipient.
* This profile is designed so that, for typical REST APIs, the
essential parts of the message are covered by the signature.
* Headers not specified in this document may remain unsigned and
could potentially be modified or deleted by intermediaries without
detection.
A.4. 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 are encouraged 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 a signed response is present, validating wimse-req-nonce
mitigates replay of that response to a client other than the one
that sent the triggering request.
Salowey & Sheffer Expires 23 April 2027 [Page 24]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
* Undetected deletion of a request/response pair is prevented only
when the client required a signed response via wimse-sign-response
with the Boolean value true and rejects an unsigned response.
Server local-policy signing alone does not provide that guarantee
(Section 3.5).
Appendix B. Document History
// RFC Editor: please remove before publication.
B.1. draft-ietf-wimse-http-signature-08
* Address Justin Richer's shepherd review (#385).
* Exception for CONNECT: cover @authority instead of @path/@query
(#368).
* Specify Simple String Comparison for wimse-aud verification
(#396).
B.2. draft-ietf-wimse-http-signature-07
* WGLC: replace @request-target with @path/@query; select the WIMSE
signature by tag (#297, #301).
* WGLC: tighten signed-response rules (wimse-sign-response, Accept-
Signature, opportunistic local-policy signing, deletion detection)
and require wimse-req-nonce on every signed response (#297, #301,
#305).
* WGLC: clarify wimse-aud (defaults, deployment-specific values) and
why @authority is not covered; nonce replay caching; algorithms
via WIT cnf.jwk.alg; middlebox/proxy considerations (#297, #305).
* Clarify parameter types, wimse-sign-response false vs omitted,
integrity goals, and short expires; make wimse-arch and RFC 9457
normative (#305).
* Regenerate examples for the profile changes; add an ES256 svcB-to-
svcC exchange alongside Ed25519 svcA/svcB (#312, [RFC9864]).
* Reference the WIT validation procedure in
[I-D.ietf-wimse-workload-creds] (#290); consistent "proof of
possession"/"PoP" wording.
Salowey & Sheffer Expires 23 April 2027 [Page 25]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
B.3. draft-ietf-wimse-http-signature-06
* Add wimse-sign-response request signature parameter so clients can
mandate a signed response; regenerate examples (#277).
B.4. draft-ietf-wimse-http-signature-05
* Regenerate non-normative request/response examples so the signed
response includes wimse-req-nonce matching the request nonce
(#274).
B.5. 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).
B.6. draft-ietf-wimse-http-signature-03
* Replace Wimse-Audience HTTP header with the wimse-aud signature
metadata parameter ([RFC9421]); register with IANA (HTTP Signature
Metadata Parameters). Non-normative request example updated
accordingly; the Signature value was not regenerated (see issue
tracker).
B.7. draft-ietf-wimse-http-signature-02
* Add new Wimse-Audience HTTP header (superseded by wimse-aud in
-03).
B.8. draft-ietf-wimse-http-signature-01
* Clarified response signing.
* Clarified signature vs. token lifetime.
* Added security goals.
* Added an Implementation Status section.
B.9. draft-ietf-wimse-http-signature-00
* Initial version, extracted from the -07 draft with minimal edits.
Salowey & Sheffer Expires 23 April 2027 [Page 26]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
B.10. 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.
B.11. 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.
B.12. 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.
B.13. 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.
Salowey & Sheffer Expires 23 April 2027 [Page 27]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
B.14. 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.
B.15. 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.
B.16. 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.
B.17. draft-ietf-wimse-s2s-protocol-00
* Initial WG draft, an exact copy of draft-sheffer-wimse-s2s-
protocol-00
* Added this document history section
Salowey & Sheffer Expires 23 April 2027 [Page 28]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
Appendix C. 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
[I-D.ietf-wimse-wpt] and Section 3.
* 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 Section 5.2.
* 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
specification (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.
Salowey & Sheffer Expires 23 April 2027 [Page 29]
Internet-Draft WIMSE Workload-to-Workload HTTP-Sig October 2026
Acknowledgments
The authors would like to thank Pieter Kasselman for his detailed
comments, Flemming Andreasen, Kieran Sweeney and Anton Sokolov for
their WGLC reviews, Justin Richer for his document shepherd review,
as well as Jason Costello, Maartje Eyskens, Radosław Piliszek and
kanywst 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.
Authors' Addresses
Joe Salowey
Palo Alto Networks
Email: joe@salowey.net
Yaron Sheffer
Independent
Email: yaronf.ietf@gmail.com
Salowey & Sheffer Expires 23 April 2027 [Page 30]