]> SPIRL

arndts.ietf@gmail.com

Applications and Real-Time Workload Identity in Multi System Environments workload identity This document defines a DPoP-inspired JWT-based profile for workload-to-workload authentication within the WIMSE (Workload Identity in Multi System Environments) architecture. This profile uses the Workload Identity Token (WIT) combined with a Workload Proof Token (WPT) to provide cryptographic proof of possession. The WPT is a signed JWT that demonstrates the sender's possession of the private key bound to the WIT, while also binding the authentication to the specific request context. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies a JWT-based proof of possession authentication profile for workload-to-workload communication as part of the WIMSE architecture defined in . This profile is inspired by the OAuth 2.0 Demonstration of Proof of Possession (DPoP) specification 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.

Conventions and Definitions All terminology in this document follows . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

DPoP-Inspired Authentication This option, inspired by the OAuth DPoP specification , 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 is sent in the request as described in Section 3.1.1 "The WIT HTTP Header" of . 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:

Workload-Proof-Token Header Field ABNF

where the JWT projection is defined in Section 3.1.1 "The WIT HTTP Header" of . 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 for valid values and restrictions.
  • typ: the WPT is explicitly typed, as recommended in , using the application/wpt+jwt media type.
• in the JWT claims:
  • aud: The audience SHOULD contain the HTTP target URI () 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 for more details.
  • exp: The expiration time of the WPT (as defined in ). 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 . 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 , 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 , 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 ) 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 . An example WPT might look like the following:

Example Workload Proof Token (WPT)

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

Example WPT JOSE Header

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

Example WPT Claims

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

Example HTTP Request with WIT and WPT

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

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

Coexistence with JWT Bearer Tokens The WIT and WPT define new HTTP headers. They can therefore be presented along with existing headers used for JWT bearer tokens. This property allows for transition from mechanisms using identity tokens based on bearer JWTs to proof of possession based WITs. A workload may implement a policy that accepts both bearer tokens and WITs during a transition period. This policy may be configurable per-caller to allow the workload to reject bearer tokens from callers that support WITs. Once a deployment fully supports WITs, then the use of bearer tokens for identity can be disabled through policy. Implementations should be careful when implementing such a transition strategy, since the decision which token to prefer is made when the caller's identity has still not been authenticated, and needs to be revalidated following the authentication step. The WIT can also coexist with tokens used to establish security context, such as transaction tokens . In this case a workload's authorization policy may take into account both the sending workload's identity and the information in the context token. For example, the identity in the WIT may be used to establish which API calls can be made and information in the context token may be used to determine which specific resources can be accessed.

Client Authorization Using the Workload Identity The server application retrieves the workload identifier from the client certificate subjectAltName, which in turn is obtained from the TLS layer. The identifier is used in authorization, accounting and auditing. For example, the full workload identifier may be matched against ACLs to authorize actions requested by the peer and the identifier may be included in log messages to associate actions to the client workload for audit purposes. A deployment may specify other authorization policies based on the specific details of how the workload identifier is constructed. The path portion of the workload identifier MUST always be considered in the scope of the trust domain. See Section 2.3 "Workload Identifiers and Authentication Granularity" of on additional security implications of workload identifiers.

Security Considerations

Workload Identity Token and Proof of Possession The Workload Identity Token (WIT) is bound to a secret cryptographic key and is always presented with a proof of possession as described in Section 3.1 "The Workload Identity Token" of . 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-level options, and both are not used in MTLS. The WIT MUST NOT be used as a bearer token. While this helps reduce the sensitivity of the token it is still possible that a token and its proof of possession may be captured and replayed within the PoP's lifetime. The following are some mitigations for the capture and reuse of the proof of possession (PoP):

• Preventing Eavesdropping and Interception with TLS

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

• Limiting Proof of Possession Lifespan

The proof of possession MUST be time limited. A PoP should only be valid over the time necessary for it to be successfully used for the purpose it is needed. This will typically be on the order of minutes. PoPs received outside their validity time MUST be rejected.

• Limiting Proof of Possession Scope

In order to reduce the risk of theft and replay the PoP should have a limited scope. For example, a PoP may be targeted for use with a specific workload and even a specific transaction to reduce the impact of a stolen PoP. In some cases a workload may wish to reuse a PoP for a period of time or have it accepted by multiple target workloads. A careful analysis is warranted to understand the impacts to the system if a PoP is disclosed allowing it to be presented by an attacker along with a captured WIT.

• Replay Protection

A proof of possession includes the jti claim that MUST uniquely identify it, within the scope of a particular sender. This claim SHOULD be used by the receiver to perform basic replay protection against tokens it has already seen. Depending upon the design of the system it may be difficult to synchronize the replay cache across all token 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.

• Binding to TLS Endpoint

The POP MAY be bound to a transport layer sender such as the client identity of a TLS session or TLS channel binding parameters. The mechanisms for binding are outside the scope of this specification.

Middle Boxes In some deployments the Workload Identity Token and proof of possession may pass through multiple systems. The communication between the systems is over TLS, but the token and PoP are available in the clear at each intermediary. While the intermediary cannot modify the token or the information within the PoP they can attempt to capture and replay the token or modify the data not protected by the PoP. Mitigations listed in Section 3 "Application Level Workload-to-Workload Authentication" of can be used to provide some protection from middle boxes. However we note that the DPoP-inspired solution () does not protect major portions of the request and response and therefore does not provide protection from an actively malicious middle box. Deployments should perform analysis on their situation to determine if it is appropriate to trust and allow traffic to pass through a middle box. This profile provides authentication and limited integrity protection but does not protect the entire HTTP message. Deployments requiring stronger integrity guarantees should consider the HTTP Message Signatures profile defined in .

Privacy Considerations Privacy considerations for this specification are the same as those described in Section 4.4 "Privacy Considerations" of .

IANA Considerations

JSON Web Token Claims IANA is requested to add the following entries to the "JSON Web Token Claims" registry :

Claim Name	Claim Description	Change Controller	Reference
tth	Transaction Token hash	IETF	RFC XXX,
wth	Workload Identity Token hash	IETF	RFC XXX,
oth	Other Tokens hashes	IETF	RFC XXX,

Media Type Registration IANA is requested to register the following entries to the "Media Types" registry :

• application/wpt+jwt, per .

application/wpt+jwt Type name: application Subtype name: wpt+jwt Required parameters: N/A Optional parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the "application/jwt" media type. See . Security considerations: See the Security Considerations section of RFC XXX. Interoperability considerations: N/A Published specification: RFC XXX, . Applications that use this media type: Workloads that use these tokens to integrity-protect messages in the WIMSE workload-to-workload protocol. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): N/A Person & email address to contact for further information: See the Authors' Addresses section of RFC XXX. Intended usage: COMMON Restrictions on usage: N/A Author: See the Authors' Addresses section of RFC XXX. Change controller: Internet Engineering Task Force (iesg@ietf.org).

Hypertext Transfer Protocol (HTTP) Field Name Registration IANA is requested to register the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" :

• Workload-Proof-Token, per .

Workload-Proof-Token

• Field Name: Workload-Proof-Token
• Status: permanent
• Structured Type: N/A
• Specification Document: RFC XXX,
• Comments: see reference above for an ABNF syntax of this field

References Normative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IANA IANA IANA IANA IANA This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Ping Identity CyberArk SPIRL Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. SGNL Practical Identity LLC SPIRL Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity and authorization context across workloads within a trusted domain during the processing of external programmatic requests, such as API calls. They ensure that this context is preserved throughout the call chain, even when new transactions are initiated internally, thereby enhancing security and consistency in complex, multi-service architectures.

Document History RFC Editor: please remove before publication.

draft-schwenkschuster-s2s-jwt-pop-00 Initial clone from original draft-ietf-wimse-s2s-06 which contained both, Workload Proof Token and HTTP Message Signature proof of possession mechanisms.

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.