Privacy Preserving Verifiable Geofencing with Residency Proofs for Sovereign Workloads

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

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.

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

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.

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.

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

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.

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

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.

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

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]: 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 1	[[I-D.mw-wimse-transitive-attestation]]	Bind workload to a local Workload Identity Agent (co-location / PoR).
Layer 2	This document	Verify Workload Host integrity for the Workload Identity Agent (platform evidence).
Layer 3	This document	Verify Workload Host residency within an approved boundary (location evidence).

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.

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

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.

Top-Level Structure

lah-bundle Fields

Field	Type	Required	Description
`tpm-ak`	string (Base64URL)	Yes	TPM Attestation Key public key (PEM-encoded). Hardware identity anchor. The TPM enforces that only this key can produce `tpm-quote-seal` — proving co-residency.
`geolocation-id-hash`	string (Base64URL)	Yes	`SHA-256(tpm-ak-bytes)`. Binds TPM identity to sensor identity - assumption is sensor integrity is handled by OOB host management plane
`geolocation-proof-hash`	string (Base64URL)	Yes	SHA-256 commitment over `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-technique`	string enum	Yes	`"none"` = raw lat/lon/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-payload`	object	Yes	Inner location data. Structure depends on `privacy-technique` (see Payload Variants below). Committed to by `geolocation-proof-hash` and optionally signed by `mno-endorsement.mno-sig`.
`nonce`	string (Base64URL)	Yes	N_fusion freshness nonce issued by the Workload Identity Management Plane. Chained: `HMAC(secret, n \\|\\| chain[n-1])`. Detects skipped/reordered attestations.
`timestamp`	integer (int64)	Yes	Unix epoch seconds. Set by the LAH agent at bundle construction time.
`tpm-quote-seal`	string (Base64URL)	Yes	`TPM2_Quote` produced by 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-identity-agent-image-digest`	string (hex SHA-256)	Yes	SHA-256 digest of the Workload Identity Agent (SPIRE agent) binary, measured at attestation time by the Host Identity Manager (Keylime). Detects agent binary compromise on every renewal cycle.

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

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 (URI)	Yes	URI to fetch full ZKP proof bytes from the proof depository. Verifier fetches bytes, computes `SHA-256(bytes)`, checks against `geolocation-proof-hash`.
`zkp-format`	string enum	Yes	ZKP proof system. Currently: `"plonky2"`.

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

mno-endorsement (Optional, Top-Level Sibling)

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

workload (Top-Level Sibling)

Field	Type	Required	Description
`workload-id`	string (SPIFFE ID)	Yes	The workload's SPIFFE identity URI (e.g., `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.

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)`

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

TPM Quote Verification Procedure

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

Example Instance (privacy-technique = "zkp")

Nonce Chain and Merkle Audit Log Where bundle[n] denotes the JCS-canonicalized lah-bundle object at attestation interval n:

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

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.

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.

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

Example Rotation Proof (Informative)

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

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

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.

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.

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

Operational Considerations

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.

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.

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

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.

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

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.

Appendix: Open Issues The following items are unresolved and are tracked for future revisions of this document.

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.

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.

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.

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

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

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.