WIMSE Workload-to-Workload with Workload Proof Tokens

Status of This Memo

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 27 March 2026.¶

Copyright Notice

Copyright (c) 2025 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

This document specifies a JWT-based proof of possession authentication profile for workload-to-workload communication as part of the WIMSE architecture defined in [I-D.ietf-wimse-arch]. This profile is inspired by the OAuth 2.0 Demonstration of Proof of Possession (DPoP) specification [RFC9449] and provides a JWT-centric approach to workload authentication.¶

In modern distributed systems, workloads often need to authenticate to each other in environments where end-to-end TLS is not available due to the presence of load balancers, API gateways, service meshes, and other middleboxes that terminate TLS connections. In such environments, traditional bearer tokens are insufficient due to security concerns around token theft and replay attacks, while the complexity of HTTP Message Signatures may not be warranted for all deployment scenarios. This profile addresses these needs by providing a proof of possession mechanism that builds upon familiar JWT technologies while ensuring that workload identities cannot be replayed or misused, even when passing through untrusted intermediaries.¶

This profile builds upon the base WIMSE workload-to-workload protocol and specifies the use of Workload Proof Tokens (WPTs) as the proof of possession mechanism. The approach combines:¶

1. The Workload Identity Token (WIT) - a JWT that establishes the workload's identity and binds it to a cryptographic key¶

2. The Workload Proof Token (WPT) - a short-lived JWT signed by the workload's private key that proves possession of that key¶

3. Request binding - the WPT includes claims that bind it to the specific request and associated tokens¶

The WPT includes hashes of the WIT and any other relevant tokens present in the request (such as OAuth access tokens or transaction tokens), ensuring that the proof of possession is bound to the complete request context. This prevents token substitution attacks and provides assurance that all tokens in the request are being used by their legitimate holder.¶

While this profile provides protection against token replay and ensures workload authentication in the presence of middleboxes, it does not provide the same level of message integrity protection as HTTP Message Signatures. Middleboxes can still modify unprotected portions of HTTP requests and responses. Deployments should carefully evaluate whether this level of protection is sufficient for their threat model, or whether the stronger integrity guarantees of HTTP Message Signatures are required.¶

This profile is particularly suitable for environments that already use JWT-based technologies and prefer to maintain consistency with OAuth 2.0 patterns. It provides a simpler alternative to HTTP Message Signatures while still offering strong authentication guarantees and protection against token replay attacks.¶

The profile defines the structure and validation requirements for WPTs, including mandatory claims, signature parameters, and the specific binding mechanisms that tie the proof to the request context. Like other WIMSE profiles, it is designed to be interoperable, allowing different authentication methods to be used by different workload pairs within the same distributed system as appropriate for their specific requirements and constraints.¶

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. DPoP-Inspired Authentication

This option, inspired by the OAuth DPoP specification [RFC9449], uses a DPoP-like mechanism to authenticate the calling workload in the context of the request. The Workload Identity Token (WIT) as defined in Section 3.1 "The Workload Identity Token" of [I-D.ietf-wimse-s2s-protocol] is sent in the request as described in Section 3.1.1 "The WIT HTTP Header" of [I-D.ietf-wimse-s2s-protocol]. An additional JWT, the Workload Proof Token (WPT), is signed by the private key corresponding to the public key in the WIT. The WPT is sent in the Workload-Proof-Token header field of the request. The ABNF syntax of the Workload-Proof-Token header field is:¶

WPT =  JWT

where the JWT projection is defined in Section 3.1.1 "The WIT HTTP Header" of [I-D.ietf-wimse-s2s-protocol].¶

A WPT MUST contain the following:¶

• in the JOSE header:¶

  • alg: An identifier for an appropriate JWS asymmetric digital signature algorithm corresponding to the confirmation key in the associated WIT. The value MUST match the alg value of the jwk in the cnf claim of the WIT. See Section 3.1 "The Workload Identity Token" of [I-D.ietf-wimse-s2s-protocol] for valid values and restrictions.¶

  • typ: the WPT is explicitly typed, as recommended in Section 3.11 of [RFC8725], using the application/wpt+jwt media type.¶

• in the JWT claims:¶

  • aud: The audience SHOULD contain the HTTP target URI (Section 7.1 of [RFC9110]) of the request to which the WPT is attached, without query or fragment parts. However, there may be some normalization, rewriting or other process that requires the audience to be set to a deployment-specific value. See also Section 2.3 "Workload Identifiers and Authentication Granularity" of [I-D.ietf-wimse-s2s-protocol] for more details.¶

  • exp: The expiration time of the WPT (as defined in Section 4.1.4 of [RFC7519]). WPT lifetimes MUST be short, e.g., on the order of minutes or seconds.¶

  • jti: An identifier for the token. The value MUST be unique, at least within the scope of the sender.¶

  • wth: Hash of the Workload Identity Token, defined in Section 3.1 "The Workload Identity Token" of [I-D.ietf-wimse-s2s-protocol]. The value is the base64url encoding of the SHA-256 hash of the ASCII encoding of the WIT's value.¶

  • ath: Hash of the OAuth access token, if present in the request, which might convey end-user identity and/or authorization context of the request. The value, as per Section 4.1 of [RFC9449], is the base64url encoding of the SHA-256 hash of the ASCII encoding of the access token's value.¶

  • tth: Hash of the Txn-Token [I-D.ietf-oauth-transaction-tokens], if present in the request, which might convey end-user identity and/or authorization context of the request. The value MUST be the result of a base64url encoding (as defined in Section 2 of [RFC7515]) of the SHA-256 hash of the ASCII encoding of the associated token's value.¶

  • oth: Hash(es) of other token(s) in the request that convey end-user identity and/or authorization context of the request. The value is a JSON object with a key-value pair for each such token. For each, in the absence of an application profile specifying details, the key corresponds to the header field name containing the token, and the value is the base64url encoding of the SHA-256 hash of the ASCII bytes of the header field value with any leading or trailing spaces removed. The header field name MUST be normalized by converting it to all lower case. Header fields occurring multiple times in the request are not supported by default. An application profile may specify different behavior for a key, such as using a different hash algorithm or means of locating the token in the request.¶

To clarify: the ath, tth and oth claims are each mandatory if the respective tokens are included in the request.¶

The rules for using non-standard claims in WPTs are similar to the rules for WITs, as described in Section 3.1.2 "Including Additional Claims" of [I-D.ietf-wimse-s2s-protocol].¶

An example WPT might look like the following:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

eyJhbGciOiJFZERTQSIsInR5cCI6IndwdCtqd3QifQ.eyJhdGgiOiJDTDR3amZwUm1OZ\
i1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd3pDMGpJIiwiYXVkIjoiaHR0cHM6Ly93b\
3JrbG9hZC5leGFtcGxlLmNvbS9wYXRoIiwiZXhwIjoxNzQ1NTEwMDE2LCJqdGkiOiJfX\
2J3YzRFU0MzYWNjMkxUQzEtX3giLCJ3dGgiOiJBYVlVZkMzNEQxZGkyRnhRTHBpSUpKN\
1NnOFZaNm84T0Nkd1NmOUlUb0xnIn0.PI7d9AcYhLoEgPgbJvcM132lkBKnM1NXU-5hZ\
UzVTIyj2dRJaTLFs6e5NYv5gg6AqcV7NvkYCwfgMgWasWQzCA

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

{
  "alg": "EdDSA",
  "typ": "wpt+jwt"
}

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

{
  "ath": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI",
  "aud": "https://workload.example.com/path",
  "exp": 1740755048,
  "jti": "0c740386ca1dcad37de1b5f9de1b0705",
  "wth": "aA0W_oFJK7qV7zYhcmzR1KOXVCHjd2x6c4sOQLvE90Y"
}

An example of an HTTP request with both the WIT and WPT from prior examples is shown below:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

POST /path HTTP/1.1
Host: workload.example.com
Content-Type: application/json
Authorization: Bearer 16_mAd0GiwaZokU26_0902100
Workload-Identity-Token: eyJhbGciOiJFUzI1NiIsImtpZCI6Ikp1bmUgNSIsInR\
5cCI6IndpdCtqd3QifQ.eyJjbmYiOnsiandrIjp7ImFsZyI6IkVkRFNBIiwiY3J2Ijoi\
RWQyNTUxOSIsImt0eSI6Ik9LUCIsIngiOiIxQ1hYdmZsTl9MVlZzSXNZWHNVdkIwM0pt\
bEdXZUNIcVFWdW91Q0Y5MmJnIn19LCJleHAiOjE3NDU1MTI1MTAsImlhdCI6MTc0NTUw\
ODkxMCwianRpIjoieC1fMUNUTDJjY2EzQ1NFNGN3Yl9sIiwic3ViIjoid2ltc2U6Ly9l\
eGFtcGxlLmNvbS9zcGVjaWZpYy13b3JrbG9hZCJ9.6KraSQUxWdl9dxFQ3Fj6dPY0Vi8\
8OkwFwZpAIOhLeq6AbXAnLLQgOp8U9UDGcBuYF3KiNv6oKQD1ZWAzrMZOJw
Workload-Proof-Token: eyJhbGciOiJFZERTQSIsInR5cCI6IndwdCtqd3QifQ.eyJ\
hdGgiOiJDTDR3amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd3pDMGpJIiw\
iYXVkIjoiaHR0cHM6Ly93b3JrbG9hZC5leGFtcGxlLmNvbS9wYXRoIiwiZXhwIjoxNzQ\
1NTEwMDE2LCJqdGkiOiJfX2J3YzRFU0MzYWNjMkxUQzEtX3giLCJ3dGgiOiJBYVlVZkM\
zNEQxZGkyRnhRTHBpSUpKN1NnOFZaNm84T0Nkd1NmOUlUb0xnIn0.PI7d9AcYhLoEgPg\
bJvcM132lkBKnM1NXU-5hZUzVTIyj2dRJaTLFs6e5NYv5gg6AqcV7NvkYCwfgMgWasWQ\
zCA

{"do stuff":"please"}

To validate the WPT in the request, the recipient MUST ensure the following:¶

• There is exactly one Workload-Proof-Token header field in the request.¶

• The Workload-Proof-Token header field value is a single and well-formed JWT.¶

• The signature algorithm in the alg JOSE header string-equal matches the alg attribute of the jwk in the cnf claim of the WIT.¶

• The WPT signature is valid using the public key from the confirmation claim of the WIT.¶

• The typ JOSE header parameter of the WPT conveys a media type of wpt+jwt.¶

• The aud claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request in which the WPT was received, ignoring any query and fragment parts. See also Section 2.3 "Workload Identifiers and Authentication Granularity" of [I-D.ietf-wimse-s2s-protocol] for implementation advice on this verification check.¶

• The exp claim is present and conveys a time that has not passed. WPTs with an expiration time unreasonably far in the future SHOULD be rejected.¶

• The wth claim is present and matches the hash of the token value conveyed in the Workload-Identity-Token header.¶

• It is RECOMMENDED to check that the value of the jti claim has not been used before in the time window in which the respective WPT would be considered valid.¶

• If presented in conjunction with an OAuth access token, the value of the ath claim matches the hash of that token's value.¶

• If presented in conjunction with a Txn-Token, the value of the tth claim matches the hash of that token's value.¶

• If presented in conjunction with a token conveying end-user identity or authorization context, the value of the oth claim matches the hash of that token's value.¶

• If the oth claim is present, verify the hashes of all tokens listed in the oth claim per the default behavior defined in Section 3 or as specified by an application specific profile. If the oth claim contains entries that are not understood by the recipient, the WPT MUST be rejected. Conversely, additional tokens not covered by the oth claim MUST NOT be used by the recipient to make authorization decisions.¶

4. Security Considerations

5. IANA Considerations

6. References

Appendix A. Document History

RFC Editor: please remove before publication.¶

Acknowledgments

The authors would like to thank Pieter Kasselman for his detailed comments.¶

We thank Daniel Feldman for his contributions to earlier versions of this document.¶

Author's Address