



RATS                                                         R. Krishnan
Internet-Draft                                      JPMorgan Chase & Co.
Intended status: Informational                                  N. Smith
Expires: 2 September 2026                                          Intel
                                                                D. Lopez
                                                              Telefonica
                                                               A. Prasad
                                                                  Oracle
                                                            S. Addepalli
                                                                  Aryaka
                                                            1 March 2026


   Privacy Preserving Verifiable Geofencing with Residency Proofs for
                          Sovereign Workloads
               draft-lkspa-wimse-verifiable-geo-fence-04

Abstract

   Modern cloud and distributed computing rely heavily on software-only
   identities and bearer tokens that are easily stolen, replayed, or
   used from unauthorized locations.  Furthermore, traditional methods
   of location verification - such as IP-address-based geolocation - are
   easily spoofed via VPNs or proxies and significantly compromise
   infrastructure security and privacy for *Sovereign Workloads* and
   high-assurance environments.  This document defines a *High-Assurance
   Profile* designed to solve these challenges through hardware-rooted
   cryptographic verifiability.

   A host machine runs a workload identity agent for managing the
   workload identities on that platform.  This proposal replaces
   implicit trust and spoofable indicators with cryptographically
   verifiable hardware-rooted evidence of integrity and location for
   this agent.  Critically, this framework prioritizes *Location
   Privacy* by utilizing Zero-Knowledge Proofs (ZKP), allowing a
   workload to prove it is within a compliant "Sovereign Zone" without
   disclosing precise coordinates that could be used for tracking or
   exploitation.

   By binding software identities to persistent silicon identities and
   verified physical residency, this solution establishes a "Silicon-to-
   Workload" chain of trust.  It ensures that sensitive operations are
   only performed by authorized workloads running on untampered hardware
   in cryptographically verified, privacy-preserving geographic
   boundaries, fulfilling the high-assurance requirements of the *WIMSE
   Architecture* [[I-D.ietf-wimse-architecture]].





Krishnan, et al.        Expires 2 September 2026                [Page 1]

Internet-Draft                    V-GAP                       March 2026


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 2 September 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Server-centric Enforcement  . . . . . . . . . . . . . . .   6
     4.2.  User-centric Enforcement  . . . . . . . . . . . . . . . .   6
     4.3.  Compliance and Risk Reduction . . . . . . . . . . . . . .   7
   5.  Motivation and Gaps . . . . . . . . . . . . . . . . . . . . .   7
   6.  What This Profile Provides  . . . . . . . . . . . . . . . . .   7
   7.  Composition with Transitive Attestation and WIMSE . . . . . .   8
   8.  Operational Use: Gating Credentials on Verified Evidence  . .   9
   9.  High-Assurance Profile: Verifiable Geofencing Attestation
           Profile (V-GAP) . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  LAH-Bundle: Location Anchor Host Evidence Structure . . .   9



Krishnan, et al.        Expires 2 September 2026                [Page 2]

Internet-Draft                    V-GAP                       March 2026


       9.1.1.  Top-Level Structure . . . . . . . . . . . . . . . . .   9
       9.1.2.  lah-bundle Fields . . . . . . . . . . . . . . . . . .  10
       9.1.3.  geolocation-payload Variants  . . . . . . . . . . . .  12
       9.1.4.  mno-endorsement (Optional, Top-Level Sibling) . . . .  13
       9.1.5.  workload (Top-Level Sibling)  . . . . . . . . . . . .  13
       9.1.6.  Sensor Type Input Recipes (Opaque to Verifier)  . . .  14
       9.1.7.  TPM Quote Verification Procedure  . . . . . . . . . .  14
       9.1.8.  Example Instance (privacy-technique = "zkp")  . . . .  14
       9.1.9.  Nonce Chain and Merkle Audit Log  . . . . . . . . . .  15
     9.2.  Scalable Fleet Management . . . . . . . . . . . . . . . .  16
     9.3.  Key Registry and Synchronization  . . . . . . . . . . . .  16
     9.4.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  16
       9.4.1.  Example Rotation Proof (Informative)  . . . . . . . .  16
     9.5.  Credential Activation and Re-Verification . . . . . . . .  16
     9.6.  Revocation and Health Signals . . . . . . . . . . . . . .  17
     9.7.  Disconnected Operation (Leased Identity)  . . . . . . . .  17
     9.8.  Deployment Patterns (Informative) . . . . . . . . . . . .  17
   10. Operational Considerations  . . . . . . . . . . . . . . . . .  18
     10.1.  Distributed Identity Issuance and Scaling  . . . . . . .  18
     10.2.  Mobility and Sovereign Handover (Informative)  . . . . .  18
     10.3.  Location Anchor Hosts (Informative)  . . . . . . . . . .  19
   11. Policy Use (Informative)  . . . . . . . . . . . . . . . . . .  19
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   14. Appendix: Open Issues . . . . . . . . . . . . . . . . . . . .  20
     14.1.  IMA Restart Behavior . . . . . . . . . . . . . . . . . .  20
     14.2.  Location Privacy Options . . . . . . . . . . . . . . . .  21
     14.3.  Proximity Profiles . . . . . . . . . . . . . . . . . . .  21
     14.4.  Geotagging Textual Data  . . . . . . . . . . . . . . . .  21
     14.5.  Attesting Geotags  . . . . . . . . . . . . . . . . . . .  21
   15. Appendix: Public References for Strict Data Residency
           Rules . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   The *Workload Identity Agent* (e.g., SPIRE Agent) acts as the local-
   on-host intermediary responsible for managing and issuing identities
   to workloads.  It serves as a vetting mechanism, ensuring that a
   workload's execution environment meets required security and
   residency policies before granting it the cryptographic credentials
   necessary for network communication.  This High-Assurance Profile (a
   specialized RATS Profile) provides the technical mechanics to
   cryptographically bind this agent to the underlying hardware-verified
   platform and its privacy-preserving physical location.






Krishnan, et al.        Expires 2 September 2026                [Page 3]

Internet-Draft                    V-GAP                       March 2026


   The architecture follows the RATS Architecture [[RFC9334]], defining
   the interactions between Provers, Verifiers, and Relying Parties to
   generate and validate high-confidence evidence regarding the Workload
   Identity Agent's status.  It provides the hardware-rooted evidence
   layer required by the WIMSE Architecture [[I-D.ietf-wimse-
   architecture]], establishing a "Silicon-to-Workload" chain of trust
   that ensures sensitive data is only processed by authorized workloads
   in approved, measured environments.

   To maintain location privacy while providing cryptographic
   verifiability, this profile leverages Transparent Zero-Knowledge
   Proofs (ZKPs).  Unlike traditional ZKP systems, transparent ZKPs
   require no trusted third party or complex trusted setup phase.  They
   achieve mathematical transparency through non-interactive, hash-based
   protocols, allowing a platform to prove it is resident within an
   approved geographic boundary without disclosing the exact coordinates
   of the underlying hardware.

2.  Conventions and Definitions

   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.

2.1.  Abbreviations

   *  *AK*: Attestation Key
   *  *BMC*: Baseboard Management Controller
   *  *DAA*: Direct Anonymous Attestation
   *  *EAT*: Entity Attestation Token
   *  *EK*: Endorsement Key
   *  *GNSS*: Global Navigation Satellite System
   *  *IMA*: Integrity Measurement Architecture
   *  *IMEI*: International Mobile Equipment Identity
   *  *IMSI*: International Mobile Subscriber Identity
   *  *LAH*: Location Anchor Host
   *  *OOB*: Out-of-Band
   *  *PCR*: Platform Configuration Register
   *  *PoR*: Proof of Residency
   *  *SPDM*: Security Protocol and Data Model
   *  *STARK*: Scalable Transparent ARgument of Knowledge
   *  *SVID*: SPIFFE Verifiable Identity Document
   *  *TEE*: Trusted Execution Environment
   *  *TPM*: Trusted Platform Module
   *  *V-GAP*: Verifiable Geofencing Attestation Profile
   *  *ZKP*: Zero-Knowledge Proof



Krishnan, et al.        Expires 2 September 2026                [Page 4]

Internet-Draft                    V-GAP                       March 2026


3.  Key Terms

   Data Residency:  Requirement that data processing and storage remain
      within an approved geographic boundary.
   Geofencing:  Enforcement that workloads execute only on approved
      hosts within an approved geographic boundary.
   Workload Identity Agent:  On-host component that issues workload
      identities (for example, SVIDs) to local workloads, subject to
      verifier-approved evidence.
   Location Anchor Host (LAH):  Trusted host or device that produces
      location evidence used to establish residency within a geofence.
   Workload Host:  Physical or virtual machine running the Workload
      Identity Agent and workloads; produces platform evidence.  Unless
      otherwise stated, this document assumes the unified deployment
      model in which the Workload Host and the Location Anchor Host
      (LAH) are the same machine.
   Composite Geolocation:  Location estimate fused from multiple sources
      and accompanied by a quality indicator.
   Proof of Residency (PoR) / Co-location:  Evidence that binds a
      workload (or Workload Host) to an approved local environment and
      geofence for a specific attestation interval.
   Silicon Root of Trust:  Hardware trust anchor that supports measured
      boot and protects attestation keys.
   Transparent Zero-Knowledge Proof:  ZKP that does not require a
      trusted setup; used to prove "inside an approved zone" without
      revealing precise coordinates.
   Workload Identity Management Plane:  Issues and validates workload
      identities and trust bundles based on verifier results and policy.
   Host Identity Management Plane:  Verifies platform integrity and
      residency evidence, and manages attestation key registration and
      platform health state (often via OOB paths).
   V-GAP (Verifiable Geofencing Attestation Profile):  Nested evidence
      format defined in this document for binding identity to verified
      platform integrity and verified residency.
   N_fusion (Workload Fusion Nonce):  Fresh nonce used to bind identity
      issuance to a specific attestation interval, delivered by the
      Workload Identity Management Plane.  Corresponds to the nonce
      field in the lah-bundle.

4.  Use Cases

   This profile supports attested data residency and geofencing for
   workloads and (optionally) users.  Common use cases fall into:
   server-centric enforcement, user-centric enforcement, and compliance
   and risk reduction.






Krishnan, et al.        Expires 2 September 2026                [Page 5]

Internet-Draft                    V-GAP                       March 2026


4.1.  Server-centric Enforcement

   Enterprises need cryptographic proof that workloads run only on
   approved hosts within an approved geographic boundary, and that data
   flows only between approved boundaries.

   *  *Workload-to-workload (general):* Relying parties accept workload
      identities only when the issuing host attests platform integrity
      and "in-zone" residency, preventing credentials from being used
      outside the approved boundary.

   *  *Agentic AI workloads:* An AI agent may access sensitive data or
      perform sensitive actions only when its Workload Identity Agent
      presents hardware-rooted integrity evidence and a verifiable "in-
      zone" proof (optionally privacy-preserving), binding identity to
      both platform state and residency.

   *  *Federated / edge AI (key or model release):* High-value artifacts
      (e.g., decryption keys or model weights in federated learning) are
      released only when the partner/edge host attests it is integral
      and resident within the required boundary.  This is useful for
      intermittently connected sites.

   *  *User-to-server:* Clients validate that the server endpoint is
      operating within an approved boundary (e.g., by policy tied to the
      server's attested identity and residency evidence).

4.2.  User-centric Enforcement

   Enterprises may also need trustworthy location signals for user-
   facing access decisions.

   *  *Geofenced access control:* User access is permitted only when the
      user (or user device) proves it is within an allowed boundary,
      ideally without requiring precise location disclosure.

   *  *On-premises boundaries:* Customer-premises equipment can define
      an enterprise boundary, with a network or enterprise
      infrastructure providing supporting evidence for policy
      enforcement.

   *  *Restricted support geographies:* Administrative or support
      actions can be allowed only when the operator proves presence
      within allowed geographies, reducing policy and insider-risk
      exposure.






Krishnan, et al.        Expires 2 September 2026                [Page 6]

Internet-Draft                    V-GAP                       March 2026


4.3.  Compliance and Risk Reduction

   Geofence attestation provides audit-ready evidence to support data
   residency and sovereignty controls, and it can also reduce non-
   compliance risk from misconfiguration or spoofable signals.  Even
   when not mandated, "in-zone" proofs help address: configuration
   drift, edge relocation/proxying, contractual residency requirements,
   and location-privacy minimization (proving "inside the zone" without
   storing coordinates).

5.  Motivation and Gaps

   Operators need to enforce _where_ sensitive workloads run without
   relying on signals that are easy to spoof (IP geolocation, region
   labels) or credentials that are easy to steal (bearer tokens).  In
   many systems today, platform integrity and residency are inferred
   from configuration and control-plane metadata rather than verified
   with cryptographic evidence.

   Key gaps include:

   *  *Unverifiable location metadata (data-at-rest / data-generation):*
      Location tags for arbitrary data objects are not standardized and
      are typically unsigned, making provenance and integrity difficult
      to validate.
   *  *Token theft and replay (data-in-use):* Bearer tokens can be
      copied and replayed from unauthorized hosts or locations; stronger
      mechanisms exist but are not consistently deployed and can add
      operational overhead.
   *  *Implicit trust in “region” and transit:* A relying party often
      cannot cryptographically verify a server’s physical residency, and
      requests may traverse intermediaries (e.g., proxies) that expand
      the effective trust boundary.

6.  What This Profile Provides

   This document defines a High-Assurance Profile (a specialized RATS
   profile) that makes *platform integrity* and *geofence residency*
   verifiable inputs to authorization and credential issuance, while
   supporting privacy-preserving “in-zone” proofs where available.

   At a high level, the profile enables a relying party (or identity
   issuer) to require evidence that: 1. the Workload Identity Agent is
   running on an approved, measured platform; and 2. that platform is
   resident within an approved geographic boundary (optionally without
   revealing coordinates).





Krishnan, et al.        Expires 2 September 2026                [Page 7]

Internet-Draft                    V-GAP                       March 2026


7.  Composition with Transitive Attestation and WIMSE

   This profile is designed to compose with [[I-D.mw-wimse-transitive-
   attestation]] and the *WIMSE Architecture* [[I-D.ietf-wimse-
   architecture]].

   *  *[I-D.mw-wimse-transitive-attestation] (Layer 1):* Binds a
      workload to a _local_ Workload Identity Agent (co-location / PoR),
      treating the agent as a trust anchor.
   *  *This document (Layers 2 and 3):* Defines how that Workload
      Identity Agent is itself verified:
      -  *Layer 2 — Platform integrity:* Hardware-rooted evidence of the
         host state (e.g., TPM-based attestation).
      -  *Layer 3 — Residency:* Cryptographically verifiable proof the
         attested host is inside an approved boundary (optionally
         privacy-preserving).

   +======+=========================================+==================+
   |Layer | Document                                | Responsibility   |
   +======+=========================================+==================+
   |*Layer| [[I-D.mw-wimse-transitive-attestation]] | Bind workload    |
   |1*    |                                         | to a local       |
   |      |                                         | Workload         |
   |      |                                         | Identity Agent   |
   |      |                                         | (co-location /   |
   |      |                                         | PoR).            |
   +------+-----------------------------------------+------------------+
   |*Layer| This document                           | Verify Workload  |
   |2*    |                                         | Host integrity   |
   |      |                                         | for the          |
   |      |                                         | Workload         |
   |      |                                         | Identity Agent   |
   |      |                                         | (platform        |
   |      |                                         | evidence).       |
   +------+-----------------------------------------+------------------+
   |*Layer| This document                           | Verify Workload  |
   |3*    |                                         | Host residency   |
   |      |                                         | within an        |
   |      |                                         | approved         |
   |      |                                         | boundary         |
   |      |                                         | (location        |
   |      |                                         | evidence).       |
   +------+-----------------------------------------+------------------+

                                  Table 1






Krishnan, et al.        Expires 2 September 2026                [Page 8]

Internet-Draft                    V-GAP                       March 2026


8.  Operational Use: Gating Credentials on Verified Evidence

   This profile assumes two cooperating control planes:

   *  *Host Identity Management Plane:* Verifies platform integrity and
      residency evidence and produces an attestation result.
   *  *Workload Identity Management Plane:* Issues or renews workload
      identities (e.g., SVIDs) only when the attestation result
      satisfies policy.

   To prevent mix-and-match and replay, attestation results SHOULD be
   fresh and SHOULD be bound to the identity issuance event (e.g., by
   cryptographically binding freshness values used for platform quotes
   and workload credential issuance within the verifier result).

   Where policy requires it, the verifier can additionally require that
   an agent software measurement (e.g., image digest) is covered by
   validated platform evidence, reducing the risk that a modified or
   unauthorized agent obtains credentials.

   In intermittently connected edge deployments, local operation can
   continue during outages, while centralized policy can be enforced on
   renewal and on release of high-value secrets once connectivity is
   available.

9.  High-Assurance Profile: Verifiable Geofencing Attestation Profile
    (V-GAP)

   V-GAP is a RATS/WIMSE attestation profile that binds a *Workload
   Identity Agent* to (1) hardware-rooted host integrity and (2)
   verified residency within a configured geofence.  It does this with
   an evidence bundle from a *Location Anchor Host (LAH)*.

9.1.  LAH-Bundle: Location Anchor Host Evidence Structure

   The lah-bundle is a hardware-sealed evidence structure embedded as an
   X.509 extension (OID 1.3.6.1.4.1.55744.1.1) in a SPIRE SVID.  It
   binds a workload identity to physically verifiable claims — TPM
   hardware identity, privacy-preserving geolocation, and agent binary
   integrity — without exposing PII.

9.1.1.  Top-Level Structure

   {
     "lah-bundle": { },
     "mno-endorsement": { },
     "workload": { }
   }



Krishnan, et al.        Expires 2 September 2026                [Page 9]

Internet-Draft                    V-GAP                       March 2026


9.1.2.  lah-bundle Fields

    +==============+=============+==========+=========================+
    | Field        | Type        | Required | Description             |
    +==============+=============+==========+=========================+
    | tpm-ak       | string      |   Yes    | TPM Attestation Key     |
    |              | (Base64URL) |          | public key (PEM-        |
    |              |             |          | encoded).  Hardware     |
    |              |             |          | identity anchor.  The   |
    |              |             |          | TPM enforces that only  |
    |              |             |          | this key can produce    |
    |              |             |          | tpm-quote-seal —        |
    |              |             |          | proving co-residency.   |
    +--------------+-------------+----------+-------------------------+
    | geolocation- | string      |   Yes    | SHA-256(tpm-ak-bytes).  |
    | id-hash      | (Base64URL) |          | Binds TPM identity to   |
    |              |             |          | sensor identity -       |
    |              |             |          | assumption is sensor    |
    |              |             |          | integrity is handled by |
    |              |             |          | OOB host management     |
    |              |             |          | plane                   |
    +--------------+-------------+----------+-------------------------+
    | geolocation- | string      |   Yes    | SHA-256 commitment over |
    | proof-hash   | (Base64URL) |          | geolocation-payload.    |
    |              |             |          | Required in both        |
    |              |             |          | privacy modes.  When    |
    |              |             |          | privacy-technique=zkp:  |
    |              |             |          | SHA-256(zkp-proof-      |
    |              |             |          | bytes).  When privacy-  |
    |              |             |          | technique=none: SHA-    |
    |              |             |          | 256(JCS({lat, lon,      |
    |              |             |          | accuracy})).            |
    +--------------+-------------+----------+-------------------------+
    | privacy-     | string enum |   Yes    | "none" = raw lat/lon/   |
    | technique    |             |          | accuracy in payload.    |
    |              |             |          | "zkp" = zero-knowledge  |
    |              |             |          | proof URI in payload.   |
    |              |             |          | Controls location       |
    |              |             |          | privacy only; device    |
    |              |             |          | identity privacy is     |
    |              |             |          | always protected via    |
    |              |             |          | geolocation-id-hash.    |
    +--------------+-------------+----------+-------------------------+
    | geolocation- | object      |   Yes    | Inner location data.    |
    | payload      |             |          | Structure depends on    |
    |              |             |          | privacy-technique (see  |
    |              |             |          | Payload Variants        |
    |              |             |          | below).  Committed to   |



Krishnan, et al.        Expires 2 September 2026               [Page 10]

Internet-Draft                    V-GAP                       March 2026


    |              |             |          | by geolocation-proof-   |
    |              |             |          | hash and optionally     |
    |              |             |          | signed by mno-          |
    |              |             |          | endorsement.mno-sig.    |
    +--------------+-------------+----------+-------------------------+
    | nonce        | string      |   Yes    | N_fusion freshness      |
    |              | (Base64URL) |          | nonce issued by the     |
    |              |             |          | Workload Identity       |
    |              |             |          | Management Plane.       |
    |              |             |          | Chained: HMAC(secret, n |
    |              |             |          | \|\| chain[n-1]).       |
    |              |             |          | Detects skipped/        |
    |              |             |          | reordered attestations. |
    +--------------+-------------+----------+-------------------------+
    | timestamp    | integer     |   Yes    | Unix epoch seconds.     |
    |              | (int64)     |          | Set by the LAH agent at |
    |              |             |          | bundle construction     |
    |              |             |          | time.                   |
    +--------------+-------------+----------+-------------------------+
    | tpm-quote-   | string      |   Yes    | TPM2_Quote produced by  |
    | seal         | (Base64URL) |          | the AK in tpm-ak.       |
    |              |             |          | Qualifying data = SHA-  |
    |              |             |          | 256(JCS({tpm-ak,        |
    |              |             |          | geolocation-id-hash,    |
    |              |             |          | geolocation-proof-hash, |
    |              |             |          | privacy-technique,      |
    |              |             |          | nonce, timestamp,       |
    |              |             |          | workload-identity-      |
    |              |             |          | agent-image-digest})).  |
    |              |             |          | Binds all fields into a |
    |              |             |          | single hardware-sealed  |
    |              |             |          | statement.              |
    +--------------+-------------+----------+-------------------------+
    | workload-    | string (hex |   Yes    | SHA-256 digest of the   |
    | identity-    | SHA-256)    |          | Workload Identity Agent |
    | agent-image- |             |          | (SPIRE agent) binary,   |
    | digest       |             |          | measured at attestation |
    |              |             |          | time by the Host        |
    |              |             |          | Identity Manager        |
    |              |             |          | (Keylime).  Detects     |
    |              |             |          | agent binary compromise |
    |              |             |          | on every renewal cycle. |
    +--------------+-------------+----------+-------------------------+

                                  Table 2






Krishnan, et al.        Expires 2 September 2026               [Page 11]

Internet-Draft                    V-GAP                       March 2026


9.1.3.  geolocation-payload Variants

   *When privacy-technique = "none" (raw coordinates):*

      +==========+==================+==========+===================+
      | Field    | Type             | Required | Description       |
      +==========+==================+==========+===================+
      | lat      | number (float64) |   Yes    | Latitude, WGS-84  |
      |          |                  |          | decimal degrees   |
      +----------+------------------+----------+-------------------+
      | lon      | number (float64) |   Yes    | Longitude, WGS-84 |
      |          |                  |          | decimal degrees   |
      +----------+------------------+----------+-------------------+
      | accuracy | number (float64) |   Yes    | Accuracy radius   |
      |          |                  |          | in meters         |
      +----------+------------------+----------+-------------------+

                                 Table 3

   geolocation-proof-hash = Base64URL(SHA-256(JCS({lat, lon,
   accuracy})))

   *When privacy-technique = "zkp" (zero-knowledge proof):*

   +===============+========+==========+==============================+
   | Field         | Type   | Required | Description                  |
   +===============+========+==========+==============================+
   | zkp-proof-uri | string |   Yes    | URI to fetch full ZKP proof  |
   |               | (URI)  |          | bytes from the proof         |
   |               |        |          | depository.  Verifier        |
   |               |        |          | fetches bytes, computes SHA- |
   |               |        |          | 256(bytes), checks against   |
   |               |        |          | geolocation-proof-hash.      |
   +---------------+--------+----------+------------------------------+
   | zkp-format    | string |   Yes    | ZKP proof system.            |
   |               | enum   |          | Currently: "plonky2".        |
   +---------------+--------+----------+------------------------------+

                                 Table 4

   geolocation-proof-hash = Base64URL(SHA-256(zkp-proof-bytes))










Krishnan, et al.        Expires 2 September 2026               [Page 12]

Internet-Draft                    V-GAP                       March 2026


9.1.4.  mno-endorsement (Optional, Top-Level Sibling)

   +==============+=============+==========+==========================+
   | Field        | Type        | Required | Description              |
   +==============+=============+==========+==========================+
   | mno-key-cert | string      |   Yes    | MNO signing certificate. |
   |              | (Base64URL  |          | Verifiers SHOULD         |
   |              | DER)        |          | validate this            |
   |              |             |          | certificate chains to a  |
   |              |             |          | known MNO root before    |
   |              |             |          | accepting the            |
   |              |             |          | endorsement.             |
   +--------------+-------------+----------+--------------------------+
   | mno-sig      | string      |   Yes    | ECDSA/EdDSA signature    |
   |              | (Base64URL) |          | over JCS(geolocation-    |
   |              |             |          | payload) only.  The MNO  |
   |              |             |          | attests location within  |
   |              |             |          | carrier visibility —     |
   |              |             |          | does not sign host       |
   |              |             |          | fields (tpm-ak, nonce,   |
   |              |             |          | tpm-quote-seal).         |
   +--------------+-------------+----------+--------------------------+

                                 Table 5

9.1.5.  workload (Top-Level Sibling)

    +=============+=========+==========+==============================+
    | Field       | Type    | Required | Description                  |
    +=============+=========+==========+==============================+
    | workload-id | string  |   Yes    | The workload's SPIFFE        |
    |             | (SPIFFE |          | identity URI (e.g.,          |
    |             | ID)     |          | spiffe://example.org/python- |
    |             |         |          | app).                        |
    +-------------+---------+----------+------------------------------+
    | key-source  | string  |   Yes    | Origin of the workload's key |
    |             |         |          | material (e.g., "tpm-app-    |
    |             |         |          | key").  The value is         |
    |             |         |          | implementer-defined;         |
    |             |         |          | verifiers SHOULD treat       |
    |             |         |          | unrecognized values as       |
    |             |         |          | opaque strings unless policy |
    |             |         |          | requires specific values.    |
    +-------------+---------+----------+------------------------------+

                                  Table 6





Krishnan, et al.        Expires 2 September 2026               [Page 13]

Internet-Draft                    V-GAP                       March 2026


9.1.6.  Sensor Type Input Recipes (Opaque to Verifier)

      +=================+==========================================+
      | Sensor Type     | geolocation-id-hash Input                |
      +=================+==========================================+
      | Mobile (CAMARA) | SHA-256(tpm-ak-bytes \|\| IMEI-bytes     |
      |                 | \|\| IMSI-bytes)                         |
      +-----------------+------------------------------------------+
      | GNSS receiver   | SHA-256(tpm-ak-bytes \|\| sensor-serial- |
      |                 | bytes \|\| sensor-class-id-bytes)        |
      +-----------------+------------------------------------------+

                                 Table 7

   The verifier sees only the opaque hash — never the raw identifiers.

9.1.7.  TPM Quote Verification Procedure

   1.  Decode tpm-quote-seal (Base64URL → bytes)
   2.  Parse TPMS_ATTEST structure
   3.  Assert TPMS_ATTEST.type == TPM_ST_ATTEST_QUOTE
   4.  Compute expected_qd = SHA-256(JCS({tpm-ak, geolocation-id-hash,
       geolocation-proof-hash, privacy-technique, nonce, timestamp,
       workload-identity-agent-image-digest}))
   5.  Assert TPMS_ATTEST.qualifyingData == expected_qd
   6.  Verify signature over TPMS_ATTEST bytes using tpm-ak public key
       (RSASSA-PKCS1-v1_5 or ECDSA)

9.1.8.  Example Instance (privacy-technique = "zkp")






















Krishnan, et al.        Expires 2 September 2026               [Page 14]

Internet-Draft                    V-GAP                       March 2026


   {
     "lah-bundle": {
       "tpm-ak": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG...\n-----END PUBLIC KEY-----",
       "geolocation-id-hash": "7f4a2c1b9e3d8f0a6b5c4d2e1f0a9b8c...",
       "geolocation-proof-hash": "c8bc2ed62a7a650d99e0884197cdf345...",
       "privacy-technique": "zkp",
       "geolocation-payload": {
         "zkp-proof-uri": "https://verifier.example/v1/proof/c8bc2ed6...",
         "zkp-format": "plonky2"
       },
       "nonce": "ZmUyZjdmMzlmZGVlZWQxOTM1YjY0Mjk0...",
       "timestamp": 1740693456,
       "tpm-quote-seal": "ARoAAQALAAUACwEA...",
       "workload-identity-agent-image-digest": "a1b2c3d4e5f6...64-char-hex-sha256"
     },
     "mno-endorsement": {
       "mno-key-cert": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...",
       "mno-sig": "MEYCIQDx9z2k..."
     },
     "workload": {
       "workload-id": "spiffe://example.org/python-app",
       "key-source": "tpm-app-key"
     }
   }

9.1.9.  Nonce Chain and Merkle Audit Log

   Where bundle[n] denotes the JCS-canonicalized lah-bundle object at
   attestation interval n:

   chain[n] = SHA-256(chain[n-1] || SHA-256(JCS(bundle[n])))
   nonce[n]  = HMAC(secret, n || chain[n-1])

    +===========+=====================================================+
    | Mechanism | Role                                                |
    +===========+=====================================================+
    | Chained   | Input control — agent cannot submit without         |
    | nonce     | responding to the management plane's current state. |
    +-----------+-----------------------------------------------------+
    | Merkle    | Audit output — proves inclusion of past bundles,    |
    | chain     | detects gaps, and enables regulatory audit.         |
    +-----------+-----------------------------------------------------+

                                  Table 8







Krishnan, et al.        Expires 2 September 2026               [Page 15]

Internet-Draft                    V-GAP                       March 2026


9.2.  Scalable Fleet Management

   Large deployments need lifecycle management for the attestation keys
   referenced by V-GAP (for example, tpm-ak) and for the policies that
   authorize them.

9.3.  Key Registry and Synchronization

   *  A Cloud (central) Host Identity Management Plane maintains a
      registry of accepted AK public keys and associated metadata (e.g.,
      EK certificate chain, hardware identity, and status).
   *  An Edge Host Identity Management Plane MAY maintain a local
      registry to support disconnected operation and periodically
      synchronizes updates to the central registry.

9.4.  Key Rotation

   To prevent rogue key injection during rotation:

   *  The central registry MUST accept a new AK only if the edge plane
      provides a rotation proof that chains the new AK to previously
      accepted state.
   *  A rotation proof MUST be a JCS-canonicalized object signed by the
      previously accepted AK (or, if available, validated by a fresh
      hardware-rooted OOB quote).

9.4.1.  Example Rotation Proof (Informative)

   {
    "new-ak-pub": "Base64URL_Encoded_Public_Key",
    "serial-number": "AK_Serial_XYZ",
    "timestamp": 1708845600,
    "hardware-uuid": "Host_Hardware_UUID",
    "signature": "Base64URL_Signature_from_Previous_AK"
   }

9.5.  Credential Activation and Re-Verification

   Credential activation (e.g., TPM2_MakeCredential) is expensive to run
   on every request.  Verifiers SHOULD perform it on events such as:

   *  Initial onboarding
   *  Reboot / reset detection (e.g., TPM clock/reset counters)
   *  Policy violations or drift signals (e.g., firmware or inventory
      changes)
   *  Failure of location evidence checks
   *  Explicit elevation to higher assurance policy




Krishnan, et al.        Expires 2 September 2026               [Page 16]

Internet-Draft                    V-GAP                       March 2026


   Between full activations, verifiers MAY accept fresh quotes from
   registered AKs as proof of continued compliance, subject to policy.

9.6.  Revocation and Health Signals

   *  The edge plane SHOULD maintain a per-node health signal (e.g.,
      tamper, firmware policy violations).
   *  On severe health signals, the verifier MUST revoke the relevant
      AK(s) and reject identities derived from them according to policy.

9.7.  Disconnected Operation (Leased Identity)

   For intermittent connectivity, the verifier MAY issue identities with
   extended validity (a lease) under policy.  If a lease is used:

   *  The edge plane MUST revoke or refuse renewal locally on tamper/
      drift signals.
   *  The workload MUST re-attest and satisfy current policy on
      reconnection before renewal or release of high-value secrets.

9.8.  Deployment Patterns (Informative)

   Implementations commonly fall into the following patterns, differing
   in how platform integrity evidence and the tpm-quote-seal are
   collected:

   *  *In-band host attestation*: Evidence collected by host software
      (for example, Keylime-style deployments).  In this pattern, the
      Workload Identity Management Plane (for example, SPIRE Server)
      generates N_fusion and shares it with the Host Identity Management
      Plane (for example, the Keylime Verifier) over a server-to-server
      channel.  The Keylime Verifier then delivers N_fusion to the
      Keylime Agent running on the host, which collects TPM and
      geolocation evidence, assembles the lah-bundle, and returns it via
      the host-side channel.  This pattern is well-suited to commodity
      servers and cloud VMs where a BMC path is not available or not
      required.














Krishnan, et al.        Expires 2 September 2026               [Page 17]

Internet-Draft                    V-GAP                       March 2026


   *  *Out-of-band management*: Evidence collected via a management
      controller / BMC path (for example, iLO-class OOB management such
      as HPE OneView).  In this pattern, the Workload Identity
      Management Plane (for example, SPIRE Server) generates N_fusion
      and shares it with the Host Identity Management Plane (for
      example, HPE OneView) over a server-to-server channel.  The Host
      Identity Management Plane then delivers N_fusion to the host via
      the BMC / OOB path — bypassing the host OS entirely.  The host TPM
      seals the lah-bundle with that nonce, and the sealed bundle is
      returned via the same OOB path.  This pattern is recommended for
      high-assurance environments where the host OS is part of the
      threat model.

   *  *Cloud-hosted attestation environments*: Provider mechanisms
      exposing measured boot and TPM-backed claims (for example, Nitro-
      class enclaves or shielded VM instances).  The cloud provider
      supplies a hardware-rooted quote that can serve as the tpm-quote-
      seal; the geolocation claim is typically derived from the
      provider's zone or region attestation.  Implementations SHOULD
      verify that the provider's attestation scope satisfies the
      geofence policy.

10.  Operational Considerations

10.1.  Distributed Identity Issuance and Scaling

   To support edge deployments and intermittent connectivity, identity
   issuance may be distributed within a sovereign boundary.

   *  *Edge issuance*: Workload identities (for example, SVIDs) MAY be
      issued by an issuer deployed within the same boundary as the
      workloads.
   *  *Scoping*: Issued identities SHOULD be scoped so they are not
      accepted outside the intended deployment boundary (for example,
      via trust bundle partitioning and policy).
   *  *Renewal gating*: Issuers SHOULD renew short-lived identities only
      when the verifier result for integrity and residency is valid for
      the requested freshness window.

10.2.  Mobility and Sovereign Handover (Informative)

   When a workload moves between anchors or boundaries, the Workload
   Identity Agent MUST obtain a new V-GAP bundle that reflects the new
   LAH and current residency.

   Verifiers SHOULD treat this as a normal re-attestation event: -
   platform integrity continuity can remain stable, but - residency
   checks MUST be re-evaluated for the new anchor/boundary.



Krishnan, et al.        Expires 2 September 2026               [Page 18]

Internet-Draft                    V-GAP                       March 2026


10.3.  Location Anchor Hosts (Informative)

   To scale location sensing, a deployment may use dedicated anchors:

   *  *End-user anchors*: A user device (for example, a phone) can serve
      as an LAH for a nearby client device.  The mechanism by which the
      anchor establishes its own location (and any proximity evidence it
      may provide) is out of scope for this document.
   *  *Data center anchors*: A small set of hosts can act as LAHs for a
      cluster.  Timing-based mechanisms (for example, PTP-derived) may
      assist in establishing relative location; protocol details are
      deferred to future profiling work (see [[I-D.ramki-ptp-hardware-
      rooted-attestation]]).

11.  Policy Use (Informative)

   Relying parties and identity issuers can use V-GAP results as inputs
   to authorization.

   *  *ABAC*: Residency and integrity can be mandatory claims for
      sensitive operations.
   *  *KMS gatekeeping*: Release of high-value assets (for example,
      decryption keys) SHOULD depend on a recent successful verification
      result.
   *  *Fail closed*: If V-GAP evidence is carried in an X.509 extension
      and marked CRITICAL, any implementation that does not understand
      the extension will reject the credential.

12.  Security Considerations

   V-GAP reduces reliance on spoofable location signals and stolen
   tokens by making integrity and residency cryptographically
   verifiable.  Implementers still need to address the following
   threats:

   *  *Replay and mix-and-match*: Use nonces and evidence stapling so
      that old location evidence cannot be combined with a fresh
      platform quote (or vice versa).
   *  *Location spoofing*: Treat sensor and network inputs as
      adversarial.  Prefer multiple, corroborating sources where
      feasible, and apply conservative policy when evidence quality
      degrades.
   *  *Relay and displacement*: When proximity mechanisms are introduced
      in future profiles, implementers should be aware that they are
      vulnerable to relay attacks and anchor displacement.  Mitigations
      (such as tight RTT-based acceptance windows and anchor health
      attestation) are deferred to those future profiles.




Krishnan, et al.        Expires 2 September 2026               [Page 19]

Internet-Draft                    V-GAP                       March 2026


   *  *Management plane compromise*: OOB paths reduce dependence on the
      host OS but introduce dependence on the management controller and
      its network.  Protect this plane with secure boot, authenticated
      updates, strong access controls, network segmentation, and audit
      logging.
   *  *Time and freshness*: Verifiers MUST enforce bounded freshness
      windows and MUST define recovery behavior (re-attestation,
      quarantine, or revocation) when clocks drift or evidence becomes
      stale.
   *  *Registry and allowlist integrity*: Protect key registries and
      policy stores against tampering; treat them as high-value
      privileged assets.
   *  *Privacy*: Avoid unnecessary collection or retention of precise
      location data.  Prefer "in-zone" proofs (ZKP) where policy
      permits.

13.  IANA Considerations

   IANA is requested to register the following Object Identifier (OID)
   in the "SMI Numbers" registry under the "SMI Private Enterprise
   Numbers" (1.3.6.1.4.1) branch, or as appropriate for the V-GAP
   profile.

   *Mandatory Criticality:* Implementations of this profile MUST mark
   the X.509 extension containing the V-GAP Evidence Bundle as
   *CRITICAL*. This ensures that non-compliant gateways fail closed
   rather than granting access to residency-constrained workloads.

   *  *OID*: 1.3.6.1.4.1.55744.1.1
   *  *Description*: Verifiable Geofencing Attestation Profile (V-GAP)
      Evidence Bundle
   *  *Reference*: This document.

14.  Appendix: Open Issues

   The following items are unresolved and are tracked for future
   revisions of this document.

14.1.  IMA Restart Behavior

   Define an interoperable way to detect and handle Workload Identity
   Agent restarts without requiring a full host reboot, while preserving
   measurement integrity.








Krishnan, et al.        Expires 2 September 2026               [Page 20]

Internet-Draft                    V-GAP                       March 2026


14.2.  Location Privacy Options

   Clarify the complete set of supported privacy techniques and define
   the policy logic for selecting between precise location disclosure,
   coarse location, and ZKP-based "in-zone" proofs.

14.3.  Proximity Profiles

   This document defers proximity proof mechanisms to future profiling
   work.  Open items include:

   *  Defining one or more proximity evidence profiles (for example,
      PTP-derived, BLE/UWB ranging, or network-RTT-based) as separate
      documents.
   *  Specifying how proximity evidence is represented and bound to the
      V-GAP bundle (for example, as an additional hash field).
   *  Addressing relay and displacement threats, including RTT-based
      acceptance windows, anchor health attestation, and disagreement
      policies for multi-anchor deployments.
   *  Profiling the use of CAMARA-style MNO location signals as a
      proximity corroboration mechanism.

14.4.  Geotagging Textual Data

   There is no widely deployed standard for geotagging arbitrary textual
   data objects.

14.5.  Attesting Geotags

   There is no widely deployed standard for cryptographically signing
   geotags to prevent manipulation.

15.  Appendix: Public References for Strict Data Residency Rules

   India -- Reserve Bank of India (RBI): Payment System Data
   Localization (2018): From RBI Circular RBI/2017-18/153 (April 6,
   2018): "All system providers shall ensure that the entire data
   relating to payment systems operated by them are stored in a system
   only in India.  This data should include the full end-to-end
   transaction details / information collected / carried / processed as
   part of the message / payment instruction."

   South Korea's Data Localization Regulations -- Geospatial Information
   Management Act (Spatial Data Act): Article 16, Paragraph 1: Prohibits
   the export of state-led survey data.

Authors' Addresses




Krishnan, et al.        Expires 2 September 2026               [Page 21]

Internet-Draft                    V-GAP                       March 2026


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


   Ned Smith
   Intel
   Email: ned.smith@intel.com


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


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


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




























Krishnan, et al.        Expires 2 September 2026               [Page 22]
