WIMSE Workload Attestation

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 9 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Workloads communicate with each other over HTTPS. Securing these workload-to-workload calls requires answering two questions: who is the caller, and can the caller be trusted?¶

The first question is addressed by the WIMSE architecture [I-D.ietf-wimse-arch]. The Workload Identity Token (WIT) [I-D.ietf-wimse-workload-creds] carries the workload's identity, issued and signed by an Identity Server [I-D.ietf-wimse-arch]. The WIT embeds the workload's public key, the Identity Server's assertion that this key belongs to this workload. The WIT alone, however, does not prove that the presenter holds the corresponding private key; any party that intercepts the WIT could replay it. The Workload Proof Token (WPT) [I-D.ietf-wimse-wpt] closes this gap: it is a short-lived token signed by the workload's private key, bound to a specific HTTPS request and target URL, proving possession of the private key corresponding to the public key in the WIT. Together, the WIT and WPT establish both who the caller is and that the caller is the legitimate holder of that identity. Both travel as HTTP header fields and survive TLS termination at proxies.¶

The second question, whether the caller's platform and key state can be trusted is not addressed by the WIT/WPT mechanism. A workload may have a valid identity and prove possession of its key, yet be running in a compromised environment, with a key that is not hardware-protected, or on a platform whose firmware or software does not meet the relying party's security policy.¶

The SEAT Working Group is developing protocols that add attestation to TLS. [I-D.fossati-seat-early-attestation] introduces new TLS extensions that carry attestation Evidence or Attestation Results intra-handshake. [I-D.fossati-seat-expat] provides post-handshake attestation using TLS Exported Authenticators. Both mechanisms are designed so that Evidence is cryptographically tied to a specific TLS connection.¶

However, this same property is their limitation when TLS does not extend end-to-end to the backend workload, as described in [I-D.ietf-wimse-arch]. The attestation binding does not reach the backend, and the backend workload receives no cryptographic evidence of the original caller's platform and key state.¶

Since the WIT and WPT already travel end-to-end as HTTP headers through TLS-terminating proxies, attestation information can travel alongside them in the same way. This document supports both the background check model and the passport model [RFC9334]. In both cases, the workload's public key is the binding element across the WIT, WPT, and the attestation information. This requires no changes to TLS, no changes to proxy infrastructure, and no modifications to the WIT or WPT specifications.¶

For the key binding verification to be cryptographically meaningful, the Evidence needs to contain a public-key confirmation claim corresponding to the workload's public key, and claims describing the protection properties of the associated private key. [RFC9711] illustrates how a key and key store may be represented in Evidence in Appendix A.1.4, but uses private-use claim labels and does not define standardised key-protection claims. One way to satisfy these requirements is the profile defined in [I-D.reddy-rats-key-binding].¶

2. Terminology

This document uses terms defined in the WIMSE Architecture [I-D.ietf-wimse-arch] and the RATS Architecture [RFC9334].¶

Workload Identity Token (WIT):

A JWT that represents the identity of a workload and binds a public key to that identity, as defined in [I-D.ietf-wimse-workload-creds].¶

Workload Proof Token (WPT):

A JWT that provides proof of possession of the private key associated with a WIT, as defined in [I-D.ietf-wimse-wpt].¶

TLS-terminating proxy:

An intermediary that terminates the caller's TLS connection and establishes a new, independent TLS connection to the backend workload.¶

Workload Evidence (WE):

Attestation Evidence generated by the workload's TEE, signed by the Attestation Key, and carried in the Workload-Evidence HTTP header field as defined in this document. Evidence freshness is provided by using the WPT jti claim [I-D.ietf-wimse-wpt] as the nonce during Evidence collection.¶

Workload EAR (WEAR):

An EAT Attestation Result (EAR) [I-D.ietf-rats-ear] generated by a Verifier following appraisal of the workload's Evidence, and carried in the Workload-Attestation-Result HTTP header field as defined in this document. Request binding is provided by using the WPT jti claim [I-D.ietf-wimse-wpt] as the nonce during Evidence collection, which the Verifier echoes in the eat_nonce claim of the EAR.¶

3. Scope

This document specifies mechanisms for conveying workload attestation information alongside WIMSE workload-to-workload HTTP requests, supporting both the background check model and the passport model [RFC9334].¶

4. The Workload-Evidence Header Field

The Workload-Evidence header field carries Evidence generated by the workload's TEE. The Evidence MUST be encapsulated in a CMW (Conceptual Message Wrapper) [I-D.ietf-rats-msg-wrap]. The CMW type field identifies the attestation technology and serialization format, providing interoperability at the envelope level without out-of-band negotiation.¶

The Evidence MUST contain:¶

• a public-key confirmation claim corresponding to the workload's public key, and¶

• claims describing the protection properties of the associated private key.¶

One way to satisfy these requirements is the profile defined in [I-D.reddy-rats-key-binding].¶

The three header fields form a coherent set, each independently signed by a different authority:¶

+----------------------------+------------------+---------------------------+
| Header field               | Signer           | Binds to                  |
+----------------------------+------------------+---------------------------+
| Workload-Identity-Token    | Identity Server  | Workload identity         |
| Workload-Proof-Token       | Workload         | Private key + Target URI  |
| Workload-Evidence          | TEE (AK)         | Platform + key            |
+----------------------------+------------------+---------------------------+

The workload's public key is the binding across all three: it is asserted by the Identity Server in the WIT, proven in possession by the WPT, and attested as hardware-protected by the Evidence.¶

5. The Workload-Attestation-Result Header Field

When the passport model is used, the Workload-Attestation-Result header field carries the EAT Attestation Result (EAR) generated by the Verifier [I-D.ietf-rats-ear].¶

The EAR MUST contain the ear_verified_attester_key claim. This claim provides the Relying Party with the verified public key of the attester. Because the ear_verified_attester_key claim is represented as a PEM-encoded SPKI or certificate, and the WIT carries the workload's public key as a JWK [I-D.ietf-wimse-workload-creds], implementations MUST convert between the two formats to perform the required cryptographic comparison.¶

The EAR MUST also contain the eat_nonce claim, set to the nonce value extracted from the appraised Evidence. Because the workload uses the WPT jti claim as the Evidence nonce, this value enables the Relying Party to verify that the EAR was produced from Evidence collected for this specific request.¶

+-----------------------------+------------------+---------------------------+
| Header field                | Signer           | Binds to                  |
+-----------------------------+------------------+---------------------------+
| Workload-Identity-Token     | Identity Server  | Workload identity         |
| Workload-Proof-Token        | Workload         | Private key + Target URI  |
| Workload-Attestation-Result | Verifier         | Appraised platform + key  |
+-----------------------------+------------------+---------------------------+

Similar to the background check model, the workload's public key acts as the binding element: it is asserted by the Identity Server in the WIT, proven in possession by the WPT, and verified by the Verifier in the EAR.¶

6. Protocol Flows

Caller (TEE Workload)                    Backend Workload
        |                                       |
        | [Startup]                             |
        | Generate key pair inside TEE          |
        | Obtain WIT from Identity Server       |
        |                                       |
        | [Per-request]                         |
        | Construct WPT, generate jti           |
        | Collect Evidence using jti as nonce   |
        | Sign WPT with private key             |
        |                                       |
        |------ HTTPS Request ----------------->|
        | Workload-Identity-Token: <WIT>        |
        | Workload-Proof-Token: <WPT>           |
        | Workload-Evidence: <CMW>              |
        |                                       |
        |                    Verify WIT         |
        |                    Verify WPT         |
        |                    Submit Evidence    |
        |                      + jti + WIT key  |
        |                      to Verifier      |
        |                    Evaluate policy    |
        |                                       |
        |<------ Response ----------------------|

Caller (TEE Workload)                  Verifier          Backend Workload
        |                                 |                     |
        | [Startup]                       |                     |
        | Generate key pair inside TEE    |                     |
        | Obtain WIT from Identity Server |                     |
        |                                 |                     |
        | [Per-request]                   |                     |
        | Construct WPT, generate jti     |                     |
        | Collect Evidence (jti as nonce) |                     |
        | Submit Evidence to Verifier --->|                     |
        |                                 | Verify Evidence     |
        |<----- Return EAR (w/ key) ------|                     |
        | Sign WPT with private key       |                     |
        |                                 |                     |
        |------ HTTPS Request --------------------------------->|
        | Workload-Identity-Token: <WIT>                        |
        | Workload-Proof-Token: <WPT>                           |
        | Workload-Attestation-Result: <EAR>                    |
        |                                                       |
        |                                     Verify WIT        |
        |                                     Verify WPT        |
        |                                     Verify EAR sig    |
        |                                     Verify key in     |
        |                                       EAR matches WIT |
        |                                     Evaluate policy   |
        |                                                       |
        |<------ Response --------------------------------------|

7. Applicability

The Workload-Evidence and Workload-Attestation-Result header fields defined in this document are applicable to both WIMSE application-level protection mechanisms: WPT [I-D.ietf-wimse-wpt] and HTTP Signatures [I-D.ietf-wimse-http-signature].¶

8. Proxy Behaviour

A TLS-terminating proxy MUST forward the Workload-Evidence and Workload-Attestation-Result header fields unchanged toward the backend workload. A proxy MUST NOT strip or modify the Workload-Evidence or Workload-Attestation-Result header fields.¶

9. Verification Algorithms

The backend workload acts as the Relying Party as defined in [RFC9334] and submits Evidence to a Verifier for appraisal.¶

The backend workload MUST first verify the WIT and WPT as defined in [I-D.ietf-wimse-wpt]. Following this, it MUST perform the steps for either the Background Check Model or the Passport Model, depending on which header is presented.¶

For both models, the request MUST NOT be processed further until all steps have completed successfully. If a backend workload requires attestation by policy, it MUST reject any request that does not include either a valid Workload-Evidence or Workload-Attestation-Result header field with a 403 Forbidden status code.¶

If a request contains both Workload-Evidence and Workload-Attestation-Result header fields, the backend MUST reject the request with 400 Bad Request.¶

10. Security Considerations

11. IANA Considerations

This document requests registration of the following HTTP header fields in the "HTTP Field Names" registry:¶

Field Name:

Workload-Evidence¶

Status:

permanent¶

Specification Document:

This document¶

Field Name:

Workload-Attestation-Result¶

Status:

permanent¶

Specification Document:

This document¶

12. References

Appendix A. Acknowledgements

The authors would like to thank Thomas Fossati and Ionut Mihalcea for the review and comments, and the SEAT Working Group participants for discussions that motivated this work.¶

Appendix B. Document History

Authors' Addresses