



WIMSE                                                        R. Krishnan
Internet-Draft                                       JPMorgan Chase & Co
Intended status: Informational                                 A. Prasad
Expires: 29 August 2026                                           Oracle
                                                                D. Lopez
                                                              Telefonica
                                                            S. Addepalli
                                                                  Aryaka
                                                        25 February 2026


    Transitive Attestation for Sovereign Workloads: A WIMSE Profile
                draft-mw-wimse-transitive-attestation-00

Abstract

   This document defines a *WIMSE Profile* for Transitive Attestation
   within the Workload Identity in Multi-Service Environments (WIMSE)
   framework.  It addresses the critical problem of *Identity
   Portability*, where software credentials (e.g., bearer tokens or
   keys) can be misappropriated and used from unauthorized
   environments—a risk amplified by the emergence of autonomous *AI
   Agents* that may move across jurisdictions or be hijacked via *prompt
   injection attacks*. By providing a standardized *Identity Conveyance*
   mechanism, this profile cryptographically binds software workloads to
   their local execution environment ("Proof of Residency") through a
   transitive chain of trust.  This chain consumes *Evidence* from the
   underlying platform—supporting both *high-assurance* RATS-based
   profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for
   residency verification and *standard* Workload Identity Agents for
   basic co-location proofs—to ensure that an identity is only valid
   when used from a verified, integral, or geographically compliant
   host.  The integrity and hardware-rooted security of the Workload
   Identity Agent itself is considered out-of-scope for this document
   and is addressed in the *Verifiable Geofencing* profile [[!I-D.lkspa-
   wimse-verifiable-geo-fence]].

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





Krishnan, et al.         Expires 29 August 2026                 [Page 1]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   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 29 August 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Scope and Boundaries  . . . . . . . . . . . . . . . . . . . .   4
   4.  The Solution: Transitive Attestation for Proof of
           Residency . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  mTLS-based Transitive Attestation . . . . . . . . . . . .   5
       4.1.1.  mTLS PoR Protocol Flow  . . . . . . . . . . . . . . .   5
     4.2.  Demonstrating Proof of Residency (DPoR) . . . . . . . . .   6
       4.2.1.  DPoR Protocol Flow  . . . . . . . . . . . . . . . . .   6
     4.3.  Confidential Computing and Hardware-Rooted Binding  . . .   7
       4.3.1.  Logical Quoting Enclave . . . . . . . . . . . . . . .   7
       4.3.2.  Channel Binding via TLS Exporter  . . . . . . . . . .   8
       4.3.3.  Relying Party Verification Loop . . . . . . . . . . .   8
   5.  Relation to Other IETF Work . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document defines the *WIMSE Profile* for "Transitive
   Attestation", addressing a critical technical gap in the high-level
   *WIMSE Architecture* [[!I-D.ietf-wimse-arch]] regarding how platform-
   level trust is transitively extended to software workloads.




Krishnan, et al.         Expires 29 August 2026                 [Page 2]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   Currently, workload identities are often "context-agnostic"—once a
   credential (e.g., a bearer token) is issued, it can often be used
   from any environment.  This *Identity Portability* allows an attacker
   who steals a token in one jurisdiction to use it from another,
   representing a significant *Sovereignty Violation* for workloads
   legally required to operate within specific boundaries.  This is
   particularly critical for *AI Agents*, whose autonomous nature,
   susceptibility to hijacking via *prompt injection attacks*, and
   potential for rapid migration across cloud environments require
   strict, verifiable adherence to data residency and host integrity
   policies.

   By addressing the *North-South* security axis of a workload's
   relationship with its local hosting environment, this profile
   establishes a *"Silicon-to-SVID"* chain of accountability.  It
   ensures that the Workload Identity Agent (the local agent) is
   empowered to issue identities that are cryptographically bound to a
   verified execution context.  This mechanism is flexible across
   assurance levels: it supports *High Assurance* residency verification
   rooted in hardware evidence (e.g., TPM/TEE), as well as *Standard
   Assurance* local co-location proofs provided by conventional workload
   agents.

   This draft acts as the *Conveyance Layer* that integrates with the
   findings of a *RATS Profile* (such as *Verifiable Geofencing* [[!I-
   D.lkspa-wimse-verifiable-geo-fence]]) to establish two distinct
   levels of assurance:

   *  *Co-location Verification*: A logical binding that ensures the
      workload and its agent are currently co-located on the same host,
      typically enforced via operating system isolation and local
      communication channels (e.g., Unix Domain Sockets).
   *  *Residency Verification (High Assurance)*: A high-assurance
      binding where the Workload Identity Agent itself is proven to be
      integral and rooted in hardware.  This ensures the identity is
      functionally "sticky" to the verified residence via a *Fast Path*
      renewal which uses cached attestation results.

   A workload obtains a fresh signature or proof from a local Workload
   Identity Agent, typically utilizing a *Workload Fusion Nonce
   (N_fusion)* to prevent replay.  This ensures the identity—and the
   usage of its associated credentials—is sensitive to the physical or
   logical residence of the workload, complementing the "East-West"
   delegation models.  Re-attestation follows a *Tiered Schedule* (see
   [[!I-D.lkspa-wimse-verifiable-geo-fence]]), separating frequent
   identity renewal from heavyweight platform evidence collection.





Krishnan, et al.         Expires 29 August 2026                 [Page 3]

Internet-Draft               WIMSE-TRANS-POR               February 2026


2.  Terminology

   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 document leverages the terminology defined in the RATS
   Architecture [[RFC9334]] and the WIMSE Architecture [[!I-D.ietf-
   wimse-arch]].

   Workload Identity Agent (Workload Identity Agent):  A local entity
      that acts as an *Attester* or *Attestation Intermediate* in the
      RATS framework.  It is responsible for providing Evidence or
      Attestation Results to a workload.
   Proof of Residency (PoR) / Co-location:  A cryptographic proof that
      binds a workload's current execution session to a specific,
      verified local environment or host.
   N_fusion (Workload Fusion Nonce):  A nonce provided by the Relying
      Party specifically for the workload-to-agent fusion flow.  It
      ensures the freshness of the residency proof and cryptographically
      binds the workload's request to the local agent's attestation.

   Workload identities are often represented by bearer tokens or keys
   that, once compromised, can be used by an attacker from any
   environment.  This "portability" allows an attacker who achieves RCE
   on a workload (e.g., in Region A) or hijacks an AI agent's logic via
   *prompt injection* to use the stolen keys or intercepted tokens from
   an attacking machine (e.g., in Region B).

   In the context of *Sovereign Workloads*, this portability is more
   than a technical vulnerability; it is a *Sovereignty Violation*. If a
   workload is legally or logically required to operate within a
   specific jurisdiction, any identity that can be successfully verified
   from outside that jurisdiction represents a failure of the sovereign
   boundary.  Relying Parties currently lack a standardized way to
   ensure that a presented identity is being used from the same verified
   host that was originally authorized.

3.  Scope and Boundaries

   This document focuses on the *Identity Conveyance* and *Session
   Binding* mechanisms required for Transitive Attestation.  It
   standardizes how a workload proves its co-location with a local agent
   and how that proof is bound to application sessions (e.g., mTLS or
   DPoP).




Krishnan, et al.         Expires 29 August 2026                 [Page 4]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   The following areas are explicitly *OUT OF SCOPE* for this profile:

   *  *Agent Identity and Integrity*: The mechanism by which a Workload
      Identity Agent (e.g., SPIRE Agent) proves its own identity and
      code integrity to a remote verifier.
   *  *Platform Attestation*: The collection and verification of
      hardware-level evidence (TPM quotes, TEE measurements) for the
      host platform.
   *  *Workload Identity Manager Interactions*: The specific protocols
      and APIs for obtaining nonces or credentials from a *Workload
      Identity Manager (WIM Manager)* during the issuance phase (e.g.,
      SVID CSRs).

   These security guarantees are provided by the underlying *RATS
   Profile* for *Verifiable Geofencing* [[!I-D.lkspa-wimse-verifiable-
   geo-fence]].  This WIMSE profile assumes that the Workload Identity
   Agent is operating in a verified, integral state as established by
   the Geofencing layer.

4.  The Solution: Transitive Attestation for Proof of Residency

   "Transitive Attestation" establishes a chain of trust from a hardware
   root through a local agent to the workload.  The Workload Identity
   Agent provides the workload with a "live" proof that it is currently
   resident on the verified host.  This local peer-to-peer connection is
   typically enforced through a *Unix Domain Socket (UDS)*, providing a
   kernel-level guarantee that the workload is co-located with the
   hardware-rooted agent.

4.1.  mTLS-based Transitive Attestation

   In an mTLS environment, the Proof of Residency (PoR) is bound to the
   mutually authenticated session and the local execution context via a
   transitive chain of trust.

4.1.1.  mTLS PoR Protocol Flow

   The mTLS-based flow integrates residency verification into the
   session establishment and validation phase:

   1.  *Certificate Extensions*: The client (workload) supplies an X.509
       certificate during the mTLS handshake containing a custom
       extension.  This extension includes the public key or SVID
       details of the local Workload Identity Agent (Attester).
   2.  *Post-Handshake Nonce*: After the mTLS handshake is successfully
       completed, the client requests a residency-specific nonce from
       the *Verifier* (e.g., Relying Party) to ensure anti-replay.




Krishnan, et al.         Expires 29 August 2026                 [Page 5]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   3.  *Local Attestation Binding*: The client constructs a PoR
       assertion payload containing:
       *  A cryptographic hash of the TLS Exporter value [[RFC5705]].
       *  The residency nonce provided by the server.
       *  A timestamp representing the current time of assertion
          creation.

   |  [!NOTE] By binding to the TLS Exporter instead of the application
   |  traffic keys, the Proof of Residency remains valid across TLS 1.3
   |  KeyUpdate operations.  Standard key rotation refreshes traffic
   |  keys but does not change the exporter master secret, thus avoiding
   |  unnecessary re-attestation cycles while maintaining strong
   |  cryptographic binding to the session.

   4.  *Agent Signature*: The client sends this payload to the local
       Workload Identity Agent (typically via a Unix Domain Socket).
       The Workload Identity Agent verifies the local peer environment
       and signs the payload with its private key.
   5.  *PoR Submission*: The client sends this attested response to the
       resource server for verification.
   6.  *Server Verification*: The *Verifier* performs a joint
       verification of identity and residency:
       *  *Identity*: Verifies the client certificate as part of
          standard mTLS.
       *  *Residency*: Verifies the PoR assertion signature against the
          Workload Identity Agent public key found in the client's
          certificate extension.
       *  *Binding and Freshness*: Ensures that the TLS Exporter hash,
          the nonce, and the timestamp match the current active session
          and are within an acceptable freshness window.

   Upon successful verification, the resource server has proof that the
   client identity (presented via mTLS) is currently resident in the
   same authorized environment as the verified Workload Identity Agent.

4.2.  Demonstrating Proof of Residency (DPoR)

   "Demonstrating Proof of Residency" (DPoR) is an enhancement to the
   Demonstrating Proof-of-Possession (DPoP) mechanism defined in
   [[RFC9449]].  While DPoP ensures _possession_ of a private key held
   by the client, DPoR ensures the physical or logical _residency_ of
   the workload using that key by binding the request to a local
   attestation.

4.2.1.  DPoR Protocol Flow

   The DPoR flow integrates residency verification into the per-request
   application-level authorization:



Krishnan, et al.         Expires 29 August 2026                 [Page 6]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   1.  *Nonced Request*: The *Verifier* SHOULD provide a residency-
       specific nonce (e.g., via a DPoR-Nonce header) to the client to
       ensure anti-replay of the residency proof.
   2.  *Local Attestation Binding*: The client constructs a DPoR
       assertion payload containing:
       *  The hash of the DPoP public key used for the request (e.g.,
          the jkt thumbprint).
       *  The residency nonce provided by the server.
       *  A timestamp representing the current time of assertion
          creation.
   3.  *Agent Signature*: The client sends this payload to the local
       Workload Identity Agent (typically via a Unix Domain Socket).
       The Workload Identity Agent (acting as an Attester) verifies the
       local execution context and signs the payload with its private
       key.
   4.  *DPoR Assertion Submission*: The client includes the resulting
       signature in a DPoR header or as an extension to the DPoP JWT.
   5.  *Server Verification*: The *Verifier* performs a joint
       verification of possession and residency:
       *  *Possession*: Verifies the DPoP proof as per [[RFC9449]].
       *  *Residency*: Verifies the DPoR assertion signature against the
          Workload Identity Agent public key.
       *  *Binding and Freshness*: Ensures that the jkt (DPoP key
          thumbprint), the nonce, and the timestamp in the residency
          proof match the current request and are within an acceptable
          freshness window.

   This binding ensures that a DPoP key cannot be "exported" and used
   from a different machine, as the resource server would detect the
   lack of a valid, hardware-rooted residency proof for that specific
   key from the new environment.

4.3.  Confidential Computing and Hardware-Rooted Binding

   In Confidential Computing (CC) environments, the Relationship between
   high-level workload identities and hardware-rooted evidence is
   formalized through specific architectural patterns.  This section
   details how Transitive Attestation bridges the gap between hardware
   quotes and application-layer identities.

4.3.1.  Logical Quoting Enclave

   In a Transitive Attestation model, trust is passed through a chain of
   components.

   *  *Hardware Layer*: A Confidential Computing environment (e.g.,
      Intel TDX or SGX) provides a "Hardware Root of Trust."




Krishnan, et al.         Expires 29 August 2026                 [Page 7]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   *  *Intermediate Layer (Workload Identity Agent)*: In this profile,
      the Workload Identity Agent (e.g., a SPIRE Agent) is treated as
      the trusted software component that "vouches" for the workloads.
   *  *Logical Equivalent*: By running the Workload Identity Agent
      inside a TEE (Trusted Execution Environment), the hardware can
      attest to the integrity of the agent.  This allows the agent to
      act as a "Compliance Bridge" as defined in [[!I-D.lkspa-wimse-
      verifiable-geo-fence]].  Just as a hardware *Quoting Enclave (QE)*
      signs a local report to turn it into a globally verifiable
      "Quote," the Workload Identity Agent (running in a TEE) signs
      Workload Identity Documents (SVIDs/WITs).  Effectively, the agent
      becomes a _logical_ quoting enclave that bridges hardware-rooted
      trust to software-level workload identities.

4.3.2.  Channel Binding via TLS Exporter

   To prevent man-in-the-middle (MITM) and replay attacks, the hardware
   evidence must be cryptographically bound to the communication
   channel.  This is achieved using the *TLS Exporter* [[RFC5705]].

   *  *The Mechanism*: RFC 5705 allows both sides of a TLS session to
      derive a unique, secret value (the Exporter) that is bound to that
      specific handshake.
   *  *The Binding*: The workload places a hash of this TLS Exporter
      value into the *User Defined Data* field of the CC quote (e.g.,
      ReportData in SGX or RTMR in TDX).
   *  *Security Property*: This cryptographically binds the hardware
      evidence to that specific TLS session.  If an attacker attempts to
      reuse the same quote on a different TLS session, the Exporter
      values will not match, and the verification will fail.

4.3.3.  Relying Party Verification Loop

   The Relying Party (Verifier) completes the trust loop by performing
   the following steps:

   |  [!NOTE] The Relying Party (which may be the Resource Server or an
   |  API Gateway/Proxy acting on its behalf) extracts the TLS Exporter
   |  value.

   1.  *Hardware Verification*: Receives the CC Quote and verifies the
       hardware signature (proving the code is running in a real TEE).
   2.  *Extractor*: Extracts the TLS Exporter value (or its hash) from
       the quote's metadata (User Defined Data).
   3.  *Comparison*: Compares this value to its own locally computed TLS
       Exporter value for the current active connection.





Krishnan, et al.         Expires 29 August 2026                 [Page 8]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   4.  *Enforcement*: If they match, the Relying Party is certain that
       the entity it is talking to via TLS is the _exact same entity_
       that generated the hardware attestation.

   This architecture ensures that identity is not just a bearer token,
   but is cryptographically tied to the verified runtime environment and
   the specific communication channel.

5.  Relation to Other IETF Work

    +==============+==============+=========+=========================+
    | Layer        | Component    | WG      | Core Responsibility     |
    +==============+==============+=========+=========================+
    | *Layer 1*    | *Transitive  | *WIMSE* | *Conveyance*: Binds     |
    |              | Attestation* |         | identity to the local   |
    |              |              |         | agent (Co-location/     |
    |              |              |         | Residency).             |
    +--------------+--------------+---------+-------------------------+
    | *Layer 2*    | *Verifiable  | *RATS*  | *Platform Evidence*:    |
    |              | Geofencing*  |         | Verifies host integrity |
    |              |              |         | and Workload Identity   |
    |              |              |         | Agent hardware          |
    |              |              |         | residency (TPM).        |
    +--------------+--------------+---------+-------------------------+
    | *Layer 3*    | *Verifiable  | *RATS*  | *Location Evidence*:    |
    |              | Geofencing*  |         | Verifies physical       |
    |              |              |         | geography (GNSS/ZKP).   |
    +--------------+--------------+---------+-------------------------+
    | *Delegation* | *Actor       | *SPICE* | Provides *East-West*    |
    |              | Chain*       |         | identity delegation     |
    |              |              |         | proof [[!I-D.draft-mw-  |
    |              |              |         | spice-actor-chain]].    |
    +--------------+--------------+---------+-------------------------+
    | *Shield*     | *SPICE*      | *SPICE* | Employs Selective       |
    |              |              |         | Disclosure (SD-CWT) to  |
    |              |              |         | protect residency/      |
    |              |              |         | geographic privacy.     |
    +--------------+--------------+---------+-------------------------+

                                  Table 1

   1.  *Transitive Attestation (WIMSE) - Layer 1 (Conveyance)*: This
       document act as the technical integrator profile for WIMSE.  It
       standardizes how local context results are transitively extended
       to workloads.  It reflects its status as the *Consumer* of
       attestation results to address the *North-South* identity
       portability problem.




Krishnan, et al.         Expires 29 August 2026                 [Page 9]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   2.  *Verifiable Geofencing (RATS) - Layer 2 & 3 (Evidence)*: Defined
       in [[!I-D.lkspa-wimse-verifiable-geo-fence]].  This document acts
       as the *RATS Profile* that provides the hardware-rooted
       foundation (TPM, Silicon Root of Trust, GNSS) and the out-of-band
       monitoring required to verify the Workload Identity Agent itself.
       It generates the high-assurance evidence that Layer 1 consumes.
   3.  *Actor Chain - The Delegation*: Complements this draft by
       addressing the *East-West* axis of agent-to-agent communication
       [[!I-D.draft-mw-spice-actor-chain]].  While Transitive
       Attestation proves _where_ an actor is running (North-South), the
       Actor Chain proves _who_ called whom across the network (East-
       West).
   4.  *SPICE (Secure Patterns for Internet Credential Exchange) - The
       Shield*: Utilizes Selective Disclosure (SD-CWT) to protect
       sensitive location data.  It allows a workload to prove residency
       within a broad "Sovereign Zone" without revealing precise GPS
       coordinates, balancing security with privacy.

   Additional relationships include:

   *  *Verifiable Geofencing [[!I-D.lkspa-wimse-verifiable-geo-fence]]*:
      Provides the normative technical specification for Layer 2 and
      Layer 3 attestation.  This draft (Transitive Attestation) acts as
      the application-layer profile that implements these residency
      proofs within mTLS and DPoP flows, fulfilling the "Silicon-to-
      SVID" chain.
   *  *WIMSE Architecture [[!I-D.ietf-wimse-arch]]*: This draft provides
      the technical fulfillment for the secure agent requirements and
      thread model mitigations (e.g., token theft) defined in the
      architecture.

6.  Security Considerations

   Proof of Residency or Co-location specifically mitigates the "Stolen
   Credential Portability" threat, which encompasses both stolen private
   keys and stolen bearer/DPoP tokens.

   An attacker who steals a private key or intercepts an active token
   from a workload cannot use those credentials from an external
   environment.  Any attempt to use the stolen credential requires a
   corresponding PoR assertion that is:

   1.  *Locally Attested*: Linked to the local Workload Identity Agent's
       signing interface, typically protected by OS permissions or
       hardware roots.
   2.  *Context-Specific*: Bound to a fresh, server-provided nonce and a
       current timestamp.




Krishnan, et al.         Expires 29 August 2026                [Page 10]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   3.  *Protected*: Access to the Workload Identity Agent's signing
       capability is restricted by local Operating System permissions
       and logical isolation.

   Consequently, credentials become functionally "sticky" to the
   verified residence; an attacker cannot generate a valid proof without
   achieving a compromise of the identity agent itself.  While a
   software-based agent provides strong logical isolation, a hardware-
   rooted agent (see [[!I-D.lkspa-wimse-verifiable-geo-fence]]) provides
   the highest level of protection against agent cloning and export.

   The security of this model relies on the *Workload Identity Agent*
   correctly providing a fresh assertion bound to the current workload
   session.  While this document specifies the conveyance of N_fusion,
   the underlying platform-level freshness—including the binding to
   hardware-rooted platform nonces (N_platform)—is managed by the
   associated *RATS Profile* (see [[!I-D.lkspa-wimse-verifiable-geo-
   fence]]).  If a verifier accepts a residency proof that lacks a fresh
   agent signature, the "Silicon-to-SVID" chain of trust is compromised.

   TBD: Discussion on Workload Identity Agent compromise, nonce entropy
   requirements, and clock skew for timestamp verification.

7.  IANA Considerations

   This document has no IANA actions at this time.

Authors' Addresses

   Ram Krishnan
   JPMorgan Chase & Co
   Email: ramkri123@gmail.com


   A Prasad
   Oracle
   Email: a.prasad@oracle.com


   Diego R. Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com


   Srinivasa Addepalli
   Aryaka
   Email: srinivasa.addepalli@aryaka.com




Krishnan, et al.         Expires 29 August 2026                [Page 11]
