WIMSE Workload-to-Workload Authentication with HTTP Signatures

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.¶

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 inherit the requirement that ES256 MUST be supported from that document. 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.¶

This document defines the wimse-aud signature metadata parameter for requests. It is a String parameter. 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 be able to verify that the audience refers to it, using trusted configuration rather than untrusted request fields such as Host. See "Workload Identifiers and Authentication Granularity" in [I-D.ietf-wimse-workload-creds].¶

3.3. The wimse-sign-response Signature Parameter

This document defines the wimse-sign-response signature metadata parameter for requests. It is a Boolean parameter. When present with the value true, the client requires the server to sign the HTTP response to this request as specified in Section 3.5. 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

This document defines the wimse-req-nonce signature metadata parameter for signed responses. It is a String parameter. 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.¶

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.¶

3.6. Error Conditions

Errors may occur during the processing of the message signature. If the signature verification fails for any reason, such as an invalid signature, an expired validity time window, or a malformed data structure, an error is returned. Typically, this will be in response to an API call. An HTTP status code such as 400 (Bad Request) is appropriate. The response could include more details as per [RFC9457], such as an indicator that the wrong key material or algorithm was used. The use of HTTP status code 401 is NOT RECOMMENDED for this purpose because it requires a WWW-Authenticate with acceptable HTTP auth mechanisms in the error response and an associated Authorization header in the subsequent request. The use of these headers for the WIT is not compatible with this specification.¶

If the client required a signed response via wimse-sign-response and the server cannot sign the response, the server SHOULD return 400 (Bad Request) or 501 (Not Implemented), optionally with a [RFC9457] problem details body indicating that a signed response cannot be provided.¶

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.¶

{
  "alg": "Ed25519",
  "crv": "Ed25519",
  "d": "fNVx2xkvU-jbsowg3cHMGLPzODvkM8Rd1UClQxv_VP0",
  "kid": "svc-a-key",
  "kty": "OKP",
  "x": "QDYLWc32T8hljQoolDi0ukqXtvNB1h-qNbpfuwZkZDg"
}

=============== 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

{
  "alg": "Ed25519",
  "crv": "Ed25519",
  "d": "uJf73cksN9k54kJtgrc0nBc3_WzkcJovRXWjEIYyESE",
  "kid": "svc-b-key",
  "kty": "OKP",
  "x": "WUZzabuwlwS9xlhndvLRMWQdkyjdOqVySiwqqd6brLM"
}

=============== 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.

{
  "alg": "ES256",
  "crv": "P-256",
  "d": "RuJQPzrHlQrRllszMFQQw3e8bSdArcYeXjhnXRXclHs",
  "kid": "svc-c-key",
  "kty": "EC",
  "x": "dquxM0LHBbWlYCDxcNRHe9kb41lrnL0h_9ntNXKxzxw",
  "y": "HPqRls-EZoPrHY9gNRcZGq5pkypeovfnzLSfsYP2L6o"
}

=============== 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}

=============== 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"}

4.1. Cofide

• Organization: Cofide¶

• Implementation: https://github.com/cofide/wimse-s2s-httpsig-poc¶

• Maturity:¶

  • WIT + HTTP Message Signatures: proof-of-concept¶

• Coverage: WIT, HTTP Message Signatures¶

• License: Apache 2.0¶

• Contact: jason@cofide.io¶

• Last updated: 13-Nov-2025¶

4.2. wimsey

• Organization: independent¶

• Implementation: 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¶

• Last updated: 08-Sep-2026¶

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. The WIT MUST NOT be used as a bearer token. While this helps reduce the sensitivity of the token it is still possible that a token and its PoP may be captured and replayed within the PoP's lifetime.¶

The 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 should be used:¶

• 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. In order to prevent this, the token and PoP MUST be sent over a secure, server authenticated TLS connection unless a secure channel is provided by some other mechanisms. Hostname validation according to Section 6.3 of [RFC9525] MUST be performed by the client.¶

• Limiting Signature Lifespan¶

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

• Replay Protection¶

A signed message includes the nonce signature parameter. This parameter SHOULD be used by the receiver to perform basic replay protection: a nonce that has already been seen SHOULD cause the message to be rejected. 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 MAY 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 MUST 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.¶

5.3. Privacy Considerations

WITs and the signatures may contain private information such as user names or other identities. Care must be taken to prevent disclosure of this information. The use of TLS helps protect the privacy of WITs and PoPs.¶

WITs are typically associated with a workload and not a specific user, however in some deployments the workload may be associated directly to a user. In those cases a deployment should evaluate if the disclosure of WITs or signatures can be used to track a user.¶

6.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.¶

6.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.¶

6.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.¶

6.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 SHOULD attempt to detect replays where feasible. We note that since most of the message is signed, replay attacks are only possible in a context where the request would be accepted as valid, and this mitigates the risk to some extent.¶

• When 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).¶

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.¶

8.1. Normative References

[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-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>.

[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>.

[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>.

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

[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>.

A.1. 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.¶

A.2. draft-ietf-wimse-http-signature-06

• Add wimse-sign-response request signature parameter so clients can mandate a signed response; regenerate examples (#277).¶

A.3. 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).¶

A.4. 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).¶

A.5. 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).¶

A.6. draft-ietf-wimse-http-signature-02

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

A.7. draft-ietf-wimse-http-signature-01

• Clarified response signing.¶

• Clarified signature vs. token lifetime.¶

• Added security goals.¶

• Added an Implementation Status section.¶

A.8. draft-ietf-wimse-http-signature-00

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

A.9. 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.¶

A.10. 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.¶

A.11. 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.¶

A.12. 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.¶

A.13. 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.¶

A.14. 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.¶

A.15. 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.¶

A.16. draft-ietf-wimse-s2s-protocol-00

• Initial WG draft, an exact copy of draft-sheffer-wimse-s2s-protocol-00¶

• Added this document history section¶