| Internet-Draft | WIMSE Workload-to-Workload HTTP-Sig | October 2026 |
| Salowey & Sheffer | Expires 23 April 2027 | [Page] |
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).¶
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 (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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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¶
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:¶
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.¶
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].¶
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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
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).¶
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.¶
Following is a signed request and a signed response using Ed25519.¶
The caller (svcA) uses this keypair:¶
{
"alg": "Ed25519",
"crv": "Ed25519",
"d": "fNVx2xkvU-jbsowg3cHMGLPzODvkM8Rd1UClQxv_VP0",
"kid": "svc-a-key",
"kty": "OKP",
"x": "QDYLWc32T8hljQoolDi0ukqXtvNB1h-qNbpfuwZkZDg"
}
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
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"
}
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.
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"
}
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}
A signed response from svcC:¶
=============== 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"}
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.¶
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".¶
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.¶
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¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
IANA is requested to register the following entries in the "HTTP Problem Types" registry of [RFC9457].¶
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¶
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¶
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.¶
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.¶
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.¶
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.¶
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.¶
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).¶
RFC Editor: please remove before publication.¶
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.¶
Add wimse-sign-response request signature parameter so clients can mandate a signed response; regenerate examples (#277).¶
Regenerate non-normative request/response examples so the signed response includes wimse-req-nonce matching the request nonce (#274).¶
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).¶
Add new Wimse-Audience HTTP header (superseded by wimse-aud in -03).¶
Initial version, extracted from the -07 draft with minimal edits.¶
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.¶
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.¶
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.¶
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.¶