| Internet-Draft | Access-Not-Egress | September 2026 |
| Das | Expires 12 March 2027 | [Page] |
A device may legitimately possess exact location while an application, SDK, AI agent, analytics library, or foreign endpoint is entitled only to a coarser representation, a delayed or randomized representation, or no location at all. Operating system permission to read a fix does not answer whether that fix may leave the device at the requested precision.¶
This document defines a precision-bounded egress profile: a data-minimization mechanism applied at the point of external disclosure, on top of an execution-finality architecture, applicable equally to conventional applications and to autonomous AI agents acting on a user's behalf. The gap this closes is concrete: an application that legitimately reads exact GPS for one on-device purpose commonly shares its process with an embedded SDK, agent tool, or cloud sync path that can forward the same exact coordinate to a destination that never needed it, without the user seeing that forwarding as a separate disclosure.¶
A proposed release is a Location-Release Candidate Act and remains non-effective while a Protected Enforcement Domain evaluates purpose, requester, component, recipient, destination, jurisdiction, required precision, policy and revocation state, cumulative disclosure state, and intended egress sink. The Protected Enforcement Domain issues scoped, non-bearer, cryptographically bound finality authority for a specific precision ceiling, expressed using the JSON interoperability objects defined in this document. An independent egress Finality Sink verifies that authority against the actual outbound payload immediately before release, so the bound ceiling, rather than the requester's declared precision, determines what may leave the device.¶
The permitted result may be exact data, a reduced representation, or denial. Data access is not data-export authority. Precise GPS access is not precise GPS-release authority.¶
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 12 March 2027.¶
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.¶
Consider an assistant asked to find nearby pharmacies, or a weather application asked for a local forecast. The device already has a high-accuracy coordinate. The external service does not need that coordinate. City or region is sufficient. Under ordinary permission models the application that may read exact GPS is also, in practice, the component that may transmit it — including through an SDK, agent tool call, telemetry path, or cloud sync that the user never saw as a separate disclosure.¶
This document treats the outbound release as the consequence that must be authorized. Local access may remain. Exact coordinates remain non-effective for external disclosure until purpose, recipient, destination, jurisdiction, precision ceiling, policy epoch, and sink binding have been verified. If exact precision is unnecessary, the Protected Enforcement Domain issues authority only for a coarser representation. If the application later places exact latitude and longitude on the wire, the egress Finality Sink detects a precision mismatch and the release stays non-effective.¶
The profile uses the two-boundary execution-finality chain defined for AI-native network control in [I-D.das-6g-finality] and discussed for general AI interoperability in [I-D.das-ef-interop]: Candidate Act, Non-Effective State, Protected Enforcement Domain, protected validation evidence, scoped non-bearer finality authority, and independent Finality Sink verification. This document specifies only the location- and data-egress predicates, the precision ladder, cumulative-disclosure handling, and the JSON objects for that profile.¶
The AI-agent case in this document (component type
AI_AGENT in Section 8, and the
attack discussed in Section 12.4) is a specific
instance of a broader problem: an agentic tool call that decides
to forward local data to a foreign provider is itself a
Candidate Act, whether the data is location or another
protected value. The general binding of execution finality to
tool-call dispatch — covering tool_use/computer-use
style interfaces, function-calling interfaces, and MCP tool
invocation — is specified separately in
[I-D.das-agentic-tool-binding]. This document
does not depend on that draft and can be implemented for
location alone; the two are complementary where an
implementation's egress sink also needs to gate agentic tool
calls in general.¶
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.¶
Failure to establish current finality authority MUST NOT be converted into permission to release protected location or other sensitive data.¶
Candidate Act, Non-Effective State, Protected Enforcement Domain (PED), Protected Validation Evidence, scoped non-bearer finality authority, and Finality Sink are used as in [I-D.das-6g-finality].¶
Mobile operating systems commonly frame location as an application permission: may application A read the user's location. The release question is narrower and later. May application A, or one of its SDKs, agents, analytics components, tools, or external processors, emit this precision to recipient B, for purpose C, in jurisdiction D, at time E, given prior releases F.¶
Those questions are not equivalent. An application can have a legitimate local need for a precise fix — navigation, E911, on-device geofencing — while no external weather, advertising, or model-inference endpoint has a corresponding need. ENISA mobile-privacy guidance already states that an application should not store an exact location point where a generic area is sufficient [ENISA-MOBILE]. European data-protection guidance treats the same idea as data minimisation and protection by default [GDPR-MIN].¶
Aggregation changes the risk further. Individually ordinary coordinates, timestamps, and routes can reveal workplaces, routines, relationships, or activity around sensitive sites once correlated at machine scale. Publicly reported fitness-tracking heatmaps around military installations illustrated that user permission for a benign purpose did not eliminate the downstream intelligence consequence [NATO-STRATCOM]. This document does not treat that class of harm as a reason to ban location. It treats it as a reason not to make the finest available representation the default egress object.¶
AI changes the economics, not the geometry, of that inference. Clustering, mobility analysis, and multisource fusion that once required specialist effort can run continuously over large datasets. The security significance of a disclosure therefore depends on what the value enables a downstream machine to infer, not only on whether a single record looks sensitive in isolation.¶
A Location-Release Candidate Act MUST NOT become externally effective merely because location permission was granted, the coordinate was already computed, an AI component selected a tool, or an upstream policy engine returned ALLOW.¶
The act MUST remain in a Non-Effective State until the PED validates act-specific predicates, protected validation evidence is committed, scoped non-bearer finality authority is released, the egress Finality Sink independently verifies that authority against the outbound payload, and the authority is consumed or otherwise made unsuitable for unauthorized replay.¶
local exact location remains inside protected domain
|
v
LOCATION-RELEASE CANDIDATE ACT
|
v
Non-Effective State
|
v
Protected Enforcement Domain
purpose, requester, component
recipient, destination, jurisdiction
required precision, user authorization
policy/revocation epochs
cumulative disclosure, sink identity
|
v
protected evidence + scoped authority
|
v
Egress Finality Sink
|
+-- exact representation permitted
+-- transformed representation permitted
`-- release denied
PED approval alone MUST NOT release data. The sink MUST prevent effectuation on verification failure. A warning or audit record is not sufficient.¶
Implementations SHOULD be able to distinguish at least the following authorized-precision classes:¶
The applicable class MUST be determined by declared purpose and current authorization state, not by the mere fact that the requester asked for the finest available value. Where a lower-precision representation is sufficient, the higher-precision representation SHOULD remain non-effective for egress.¶
The class names in the precision ladder are authorization labels, not self-defining measurements: a sink cannot decide whether an observed payload exceeds an authorized ceiling without a concrete quantization rule behind each name. This document does not mandate the following mapping as the sole conformant one, since coordinate reference system, datum, and rounding choices are properly a matter for working-group consensus rather than a single author's default. It is provided so that an implementer or reviewer has a concrete illustration to react to rather than an unquantified label, and SHOULD be treated as non-normative until a revision fixes a single mandatory-to-implement mapping:¶
| Class | Illustrative quantization |
|---|---|
| EXACT | Unrounded WGS84 latitude/longitude as measured, full available decimal precision. |
| METER_10 | WGS84 latitude/longitude rounded to the grid cell implied by approximately 4 decimal places (~11 m at the equator), or an equivalent fixed-size local-tangent-plane grid. |
| METER_100 | WGS84 latitude/longitude rounded to the grid cell implied by approximately 3 decimal places (~111 m at the equator); latitude-dependent longitude scale error MUST be accounted for above roughly 60 degrees latitude. |
| GRID | Snapped to a fixed-size equal-area or equal-angle cell (for example a 1 km reference grid); the released value is the cell identifier or cell centroid, not the original coordinate. |
| GEOHASH | A geohash string truncated to a fixed prefix length agreed by policy — for example a 5-character prefix (~4.9 km x 4.9 km cell) or a 7-character prefix (~153 m x 153 m cell); the sink MUST treat the released prefix length, not the underlying coordinate, as the authorized ceiling. |
| CITY | A locality name resolved from a fixed, versioned gazetteer reference, with no coordinate field present in the payload. |
| REGION | A first-level administrative division (state, province, or equivalent) from the same gazetteer reference, with no locality or coordinate field present. |
| COUNTRY | An ISO 3166-1 country code, with no finer administrative, locality, or coordinate field present. |
Two implementation requirements follow regardless of which specific quantization a deployment adopts. First, the released payload MUST contain only the fields implied by the authorized class — a CITY release MUST NOT carry a latitude or longitude field alongside the city name, and a GEOHASH release MUST NOT carry a longer prefix than the authorized length. Second, the quantization boundary itself SHOULD be deterministic and independent of the exact input value's position within a cell, so that repeated exact fixes within the same cell do not leak finer information through boundary-crossing timing; this document does not specify a boundary-crossing mitigation and treats it as a documented residual risk consistent with Section 10.6.¶
For a location-release act the PED SHOULD evaluate:¶
Possible PED decisions include ALLOW at the requested precision, ALLOW_WITH_TRANSFORMATION at a coarser precision, DELAY, RANDOMIZE, ESCALATE, or DENY. Exact GPS is not the default success path.¶
Purpose: nearby pharmacy discovery or local weather. Requested precision: exact GPS. Necessary precision: city or local area. Destination: external discovery or forecast service. Decision: exact GPS denied; coarse locality allowed. The external service receives "Balasore, Odisha" rather than a coordinate. The application can still perform the task. Utility did not require unrestricted data authority.¶
An implementation MAY incorporate cumulative disclosure state so that repeated individually acceptable releases do not automatically create an unauthorized movement history. This state is policy-dependent and can cause a later request to be downgraded, delayed, randomized, rate-limited, or denied.¶
Cumulative disclosure state is itself sensitive. Implementations SHOULD keep it device-local or inside the PED, SHOULD minimise retained identifiers, SHOULD bound retention to the policy window, and MUST NOT export the state as a movement history under authority issued for a single coarse release. A later revision may define a narrower privacy-preserving accumulator. This version only requires that if the state is used, it is treated as protected input to the PED, not as another egress object.¶
This architecture does not choose among national privacy rules. The PED consumes the policy applicable to the relevant jurisdiction and user or enterprise authorization state. United States, European, Indian, or other deployments MAY produce different authorized-precision decisions from the same Candidate Act. The protocol's role is to keep the selected policy technically binding at the point of release.¶
Possible sink locations include an OS location or data broker, a network-egress filter, a browser upload control, an API gateway, a cloud-sync agent, and enterprise wrapping of SDK traffic. If more than one path can emit the same protected representation — application upload, analytics SDK, advertising SDK, telemetry, clipboard, file export, agent tool call, background sync — each path capable of that consequence MUST be subject to the same precision ceiling or MUST be unable to emit the protected fields.¶
This document does not specify a single on-device enforcement point for every operating system. An implementation that leaves an equivalent path unverified does not satisfy the profile for that data class.¶
This section defines the semantic JSON contract for location-release acts. It does not require one transport. Objects MAY move over protected local IPC, OS broker APIs, HTTPS, or enterprise agents. A transport binding MUST preserve object integrity, sink identity, freshness, and non-bearer authority semantics.¶
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:ietf:params:json-schema:precision-egress:location-candidate:1",
"title": "LocationReleaseCandidate",
"type": "object",
"additionalProperties": false,
"required": [
"version", "object_type", "candidate_act_id", "act_type",
"created_at", "expires_at", "requester", "purpose",
"source_data", "requested_release", "destination",
"policy_state", "freshness", "finality_sink"
],
"properties": {
"version": { "type": "string", "const": "1.0" },
"object_type": {
"type": "string",
"const": "location_release_candidate"
},
"candidate_act_id": { "type": "string", "minLength": 16 },
"act_type": { "type": "string", "const": "LOCATION_RELEASE" },
"created_at": { "type": "string", "format": "date-time" },
"expires_at": { "type": "string", "format": "date-time" },
"requester": {
"type": "object",
"required": ["application_id"],
"properties": {
"application_id": { "type": "string" },
"component_id": { "type": "string" },
"component_type": {
"type": "string",
"enum": [
"APPLICATION", "SDK", "AI_AGENT", "ANALYTICS",
"ADVERTISING", "BROWSER", "CLOUD_SERVICE",
"SYSTEM_SERVICE", "OTHER"
]
}
}
},
"purpose": {
"type": "object",
"required": ["purpose_id", "declared_purpose"],
"properties": {
"purpose_id": { "type": "string" },
"declared_purpose": { "type": "string" },
"purpose_epoch": { "type": "integer", "minimum": 0 },
"user_intent_reference": { "type": "string" }
}
},
"source_data": {
"type": "object",
"required": ["data_class", "available_precision"],
"properties": {
"data_class": {
"type": "string",
"enum": [
"LOCATION", "MOBILITY_TRACE",
"PROXIMITY", "SENSOR_DERIVED_LOCATION"
]
},
"available_precision": {
"type": "string",
"enum": [
"EXACT", "METER_10", "METER_100", "GRID",
"GEOHASH", "CITY", "REGION", "COUNTRY"
]
},
"local_only": { "type": "boolean" },
"source_reference": { "type": "string" }
}
},
"requested_release": {
"type": "object",
"required": ["requested_precision", "fields"],
"properties": {
"requested_precision": {
"type": "string",
"enum": [
"EXACT", "METER_10", "METER_100", "GRID",
"GEOHASH", "CITY", "REGION", "COUNTRY", "NONE"
]
},
"fields": { "type": "array", "items": { "type": "string" } },
"retention_seconds": { "type": "integer", "minimum": 0 },
"continuous": { "type": "boolean" }
}
},
"destination": {
"type": "object",
"required": ["destination_id", "jurisdiction"],
"properties": {
"destination_id": { "type": "string" },
"endpoint": { "type": "string" },
"recipient_id": { "type": "string" },
"processor_type": {
"type": "string",
"enum": [
"FIRST_PARTY", "PROCESSOR", "SDK_VENDOR",
"AI_PROVIDER", "ANALYTICS", "AD_NETWORK",
"PUBLIC_AUTHORITY", "OTHER"
]
},
"jurisdiction": { "type": "string" },
"cloud_region": { "type": "string" }
}
},
"cumulative_disclosure": {
"type": "object",
"properties": {
"window_seconds": { "type": "integer", "minimum": 0 },
"prior_release_count": { "type": "integer", "minimum": 0 },
"prior_precision_max": { "type": "string" },
"movement_history_risk": {
"type": "string",
"enum": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
}
}
},
"policy_state": {
"type": "object",
"required": ["policy_epoch", "revocation_epoch"],
"properties": {
"policy_epoch": { "type": "integer", "minimum": 0 },
"authority_epoch": { "type": "integer", "minimum": 0 },
"revocation_epoch": { "type": "integer", "minimum": 0 },
"policy_profile_id": { "type": "string" },
"regulatory_profile_id": { "type": "string" }
}
},
"freshness": {
"type": "object",
"required": ["nonce"],
"properties": {
"nonce": { "type": "string", "minLength": 16 },
"sequence": { "type": "integer", "minimum": 0 },
"session_id": { "type": "string" }
}
},
"finality_sink": {
"type": "object",
"required": ["sink_id", "sink_type"],
"properties": {
"sink_id": { "type": "string" },
"sink_type": {
"type": "string",
"enum": [
"NETWORK_EGRESS", "OS_DATA_BROKER", "BROWSER_UPLOAD",
"API_GATEWAY", "CLOUD_SYNC", "TELEMETRY",
"ANALYTICS_SDK", "AD_SDK", "FILE_EXPORT",
"DATABASE_EXPORT", "OTHER"
]
}
}
}
}
}
¶
{
"version": "1.0",
"object_type": "precision_policy_decision",
"decision_id": "ppd-cf0c49",
"candidate_act_id": "loc-5c8238a4",
"decision": "ALLOW_WITH_TRANSFORMATION",
"requested_precision": "EXACT",
"authorized_precision": "CITY",
"transformation": {
"type": "PRECISION_REDUCTION",
"method": "CITY_LABEL",
"parameters": {
"country_code": "IN",
"region": "Odisha",
"city": "Balasore"
}
},
"validated_predicates": {
"application_valid": true,
"component_valid": true,
"purpose_valid": true,
"exact_precision_necessary": false,
"destination_valid": true,
"recipient_valid": true,
"jurisdiction_valid": true,
"user_authorization_valid": true,
"policy_epoch_valid": true,
"revocation_state_valid": true,
"cumulative_disclosure_acceptable": true,
"sink_binding_valid": true
},
"reason_codes": [
"MINIMIZATION_REQUIRED",
"EXACT_PRECISION_NOT_NECESSARY"
]
}
¶
{
"version": "1.0",
"object_type": "egress_finality_authority",
"authority_id": "efa-e71ad531",
"candidate_act_id": "loc-5c8238a4",
"decision_id": "ppd-cf0c49",
"evidence_id": "pve-location-332",
"scope": {
"data_class": "LOCATION",
"authorized_precision": "CITY",
"permitted_fields": ["city", "region", "country"],
"recipient_id": "weather-provider",
"destination_id": "weather.example",
"jurisdiction": "IN",
"retention_seconds_max": 3600
},
"binding": {
"candidate_act_digest": {
"algorithm": "SHA-256",
"value": "base64url-location-act-digest"
},
"nonce": "B21C9924FF77A183",
"policy_epoch": 42,
"authority_epoch": 11,
"revocation_epoch": 7,
"finality_sink_id": "egress-sink-01",
"protected_state_reference": "ped-location-state-91"
},
"lifetime": {
"issued_at": "2026-08-26T17:45:01Z",
"expires_at": "2026-08-26T17:45:10Z",
"single_use": true
},
"issuer": {
"ped_id": "ped-device-01",
"key_id": "ped-key-location-2",
"signature": "base64url-signature"
}
}
¶
The sink verifies the actual outbound payload immediately before release. Declared precision is not sufficient. The payload fields MUST be within the authorized ceiling.¶
{
"operation": "EgressSinkVerify",
"request_id": "egress-req-771",
"candidate_act_id": "loc-5c8238a4",
"authority_id": "efa-e71ad531",
"sink": {
"sink_id": "egress-sink-01",
"sink_type": "NETWORK_EGRESS"
},
"outbound_payload": {
"content_type": "application/json",
"data_class": "LOCATION",
"declared_precision": "CITY",
"fields": {
"city": "Balasore",
"region": "Odisha",
"country": "IN"
},
"payload_digest": {
"algorithm": "SHA-256",
"value": "base64url-payload-digest"
}
},
"destination": {
"destination_id": "weather.example",
"endpoint": "https://weather.example/forecast",
"recipient_id": "weather-provider",
"jurisdiction": "IN"
},
"freshness": { "nonce": "B21C9924FF77A183" }
}
¶
{
"operation": "EgressSinkVerify",
"request_id": "egress-req-771",
"decision": "ALLOW",
"verification": {
"authority_signature": "VALID",
"candidate_act_binding": "MATCH",
"data_class": "MATCH",
"payload_precision": "CITY_WITHIN_AUTHORIZED_CEILING",
"field_scope": "MATCH",
"recipient": "MATCH",
"destination": "MATCH",
"jurisdiction": "MATCH",
"policy_epoch": "CURRENT",
"revocation_epoch": "CURRENT",
"nonce": "FRESH",
"consumption_state": "UNUSED",
"sink_binding": "MATCH"
},
"consumption": {
"authority_id": "efa-e71ad531",
"status": "CONSUMED",
"consumed_at": "2026-08-26T17:45:02Z"
},
"release": {
"permitted": true,
"released_precision": "CITY",
"release_id": "release-881"
}
}
¶
{
"operation": "EgressSinkVerify",
"request_id": "egress-req-772",
"decision": "DENY",
"error": {
"code": "EF_PRECISION_MISMATCH",
"message": "Outbound payload exceeds authorized precision.",
"retryable": false
},
"verification": {
"authority_signature": "VALID",
"authorized_precision": "CITY",
"observed_payload_precision": "EXACT",
"destination": "MATCH",
"jurisdiction": "MATCH",
"sink_binding": "MATCH"
},
"release": { "permitted": false }
}
¶
{
"step_1_local_state": {
"available_location": {
"latitude": 21.494321,
"longitude": 86.932145,
"accuracy_meters": 4.2
},
"external_effect": "NONE"
},
"step_2_candidate_act": {
"candidate_act_id": "loc-5c8238a4",
"requester": {
"application_id": "weather-app",
"component_id": "forecast-module",
"component_type": "APPLICATION"
},
"purpose": {
"purpose_id": "local-weather",
"declared_purpose": "Provide weather for the user's area"
},
"requested_release": {
"requested_precision": "EXACT",
"fields": ["latitude", "longitude"]
},
"destination": {
"destination_id": "weather.example",
"recipient_id": "weather-provider",
"jurisdiction": "IN"
}
},
"step_3_ped_decision": {
"decision": "ALLOW_WITH_TRANSFORMATION",
"authorized_precision": "CITY",
"reason": "Exact coordinates are not necessary."
},
"step_4_authorized_payload": {
"city": "Balasore",
"region": "Odisha",
"country": "IN"
},
"step_5_sink_verification": {
"decision": "ALLOW",
"exact_coordinates_released": false,
"authority_consumed": true
}
}
¶
{
"cumulative_disclosure": {
"subject_scope": "device-local-pseudonymous-subject",
"window_seconds": 86400,
"prior_release_count": 144,
"prior_precision_max": "METER_100",
"distinct_destinations": 6,
"movement_history_risk": "HIGH",
"policy_action": "DOWNGRADE_TO_REGION"
}
}
¶
A Candidate Act SHOULD have a stable digest over load-bearing attributes including data class, requested and authorized precision, destination, recipient, jurisdiction, purpose, permitted fields, and sink identity. Changing exact GPS to city, recipient A to recipient B, or sink A to sink B MUST invalidate previously issued authority unless the changed operation is separately authorized.¶
Immediately before release the sink MUST verify authority integrity, act binding, sink identity, expiry and consumption state, nonce freshness, policy and revocation epochs, destination and jurisdiction, authorized field set, and that observed payload precision does not exceed the authorized ceiling. On success, single-use authority SHOULD be consumed atomically with release.¶
Implementations SHOULD define a canonicalization for payload inspection sufficient to detect exact coordinates presented under a city label, hidden in additional JSON fields, or duplicated on a parallel header. This version does not specify a complete media-type inspection algorithm. Absence of such inspection is a residual risk and MUST be documented by the implementation.¶
An implementation's canonicalization SHOULD explicitly account for the following evasion vectors, since a sink that checks only a payload's declared top-level fields in one expected encoding does not close them:¶
A sink MUST reject a release when its canonicalization cannot establish that the actual outbound representation, in whatever encoding it is transmitted, stays within the authorized precision ceiling and field set. Treating an unrecognized encoding as implicitly compliant is a fail-open behavior and is inconsistent with Section 11. This document does not claim that any implementation, including the reference implementation in Section 10, currently closes every vector listed above; see Section 10.6 and Section 12.4 for the corresponding limitations and attacks.¶
Repeated releases inside a previously validated envelope — same application, purpose, destination, jurisdiction, and precision ceiling — MAY use a hot path with local protected state and short-lived authority. The hot path MUST still perform sink verification. Cache miss, unknown destination, jurisdiction uncertainty, continuous-trace requests, exact precision, or elevated cumulative-disclosure risk SHOULD escalate. Timeout MUST NOT be treated as approval.¶
The following identifiers are design suggestions and are not IANA assignments. Location-egress implementations SHOULD be able to express at least:¶
A PRECISION_MISMATCH denial MAY include a remediation such as DOWNGRADE_TO_CITY. Other permitted actions include deny, delay, randomize, redact, quarantine, request fresh authority, or escalate.¶
A runnable reference implementation of this profile exists. It is provided to make the architecture inspectable and testable, not as a claim of production readiness. This section reports what the reference implementation is, what it measured, and what it does not establish. Where a claim below is environment-specific, it is stated as an observation on a single execution environment rather than as a general performance or security property of the protocol.¶
The reference implementation is written in Python (verified against 3.11 through 3.13, with final verification on 3.13.5). Python was chosen for readability, reproducibility, protocol experimentation, testability, and a direct mapping between the terminology in Section 3 and executable objects. It is not the implementation language expected for a production operating-system kernel, NIC, browser engine, or secure enclave; a production implementation is more likely to use Rust, C, C++, Swift, Kotlin/Android system services, eBPF, kernel modules, browser-engine code, TEE secure-world code, HSM applications, SmartNIC/DPU firmware, FPGA logic, or gateway/network-function code, depending on deployment target.¶
Primary dependencies were Pydantic (strict protocol
models, enum and field validation, schema generation, and
rejection of malformed input rather than silent acceptance),
the cryptography library (Ed25519 signing and
verification), and pytest (the automated test suite). The
environment used for the reported measurements was Linux on
x86_64 with approximately 5 visible logical CPUs and 5.8 GiB
of visible RAM; the host CPU model string reported 80 cores,
but only the visible logical CPUs were available to the
benchmark process. A formal peak-memory (RSS) measurement has
not yet been performed.¶
The reference implementation carries 98 automated tests, all passing at the time of this writing. The suite is weighted toward DENY and adversarial paths rather than success paths, because the invariant that matters is not "valid request produces ALLOW" but "a load-bearing mismatch leaves the protected release non-effective." The suite exercises, among other cases: valid coarse and exact release; exact-to-coarse transformation; hidden exact coordinates under a coarse label; replay of consumed authority; stale policy or revocation epochs; sink, destination, and recipient substitution; field-scope violations; cumulative-risk escalation; persistence of consumption state across an SQLite reopen; and concurrent attempts to consume the same single-use authority. Passing these tests demonstrates consistent enforcement of the modeled rules across the tested scenarios. It does not constitute a formal security proof; see Section 10.6.¶
The reference implementation signs finality authority using Ed25519 by default: the PED holds signing capability and the Finality Sink holds only verification capability, so the sink does not require the private key. An HMAC-SHA256 variation is also included to show that the execution-finality semantics defined in this document are not mathematically tied to Ed25519; HMAC requires shared secret material and therefore has a different trust model, and is not treated as an equivalent substitute for asymmetric trust separation.¶
Two persistence backends are demonstrated. An in-memory store is used for unit tests and deterministic short-lived experiments; state does not survive a process restart and is not rollback- or tamper-resistant. An SQLite store demonstrates durable evidence, activation state, consumption state, and replay state, and the suite confirms that consumed authority remains consumed after the database is reopened. SQLite is not a Protected Enforcement Domain: an attacker with sufficient privilege can modify the database file, delete state, restore an older copy, or otherwise roll back consumption state. A high-assurance production deployment is expected to require a secure enclave, TEE, HSM, TPM-backed state, hardware monotonic counters, kernel-protected storage, secure element, or DPU/SmartNIC protected state instead.¶
The Finality Sink in the reference implementation does not
trust a declared_precision label; it inspects the
actual structured outbound payload. A payload such as
{"declared_precision": "CITY", "city": "Balasore",
"latitude": 21.494321, "longitude": 86.932145} is
rejected because the observed payload exceeds the authorized
representation. The implementation also performs
meter-level coordinate-granularity checks so that a
latitude/longitude pair is not automatically treated as
coarse merely because the application labeled it
METER_100. This is a simplified reference check, not
a complete geospatial-precision or datum specification, and
not a general-purpose data-loss-prevention engine; see
Section 10.6.¶
A 5,000-iteration benchmark of the Ed25519 configuration on the environment described in Section 10.1 produced the following combined PED-plus-sink local processing latency:¶
Combined local finality path (Ed25519, n=5000): mean: 500.7 microseconds (~0.501 ms) p50: 457.7 microseconds (~0.458 ms) p95: 662.7 microseconds (~0.663 ms) p99: 882.0 microseconds (~0.882 ms)¶
An HMAC-SHA256 configuration produced a lower combined synthetic cost (mean approximately 297.7 microseconds, p99 approximately 652.3 microseconds), which is reported for comparison only and is not evidence that HMAC is the preferred production configuration; cryptographic trust separation, discussed in Section 10.3, is a stronger consideration than microbenchmark speed alone.¶
For a local, bounded, already-policy-resolved, short-lived, hot-path egress decision as described in Section 9, this document suggests an engineering target of p95 <= 1 millisecond, with a stronger experimental objective near p99 <= 1 millisecond. The measured Ed25519 run met both on this environment. This is an engineering target for the local hot path only, not a protocol requirement and not a production performance guarantee.¶
The target in this section applies only to a hot path that reuses a previously validated envelope: same requester, purpose, destination, jurisdiction, precision ceiling, current policy, current revocation state, short-lived authority, local evidence, and local sink. Exact-precision requests, continuous traces, a new destination, an unknown recipient, jurisdiction uncertainty, cross-border transfer, high cumulative-disclosure risk, fresh user approval, fresh remote attestation, complex enterprise policy, or human approval are expected to use a slower, escalated path instead, consistent with Section 9.¶
The measurement excludes GPS acquisition and GNSS processing, cellular or Wi-Fi transport, Internet latency, DNS resolution, TLS handshake, HTTP request time, cloud round trip, remote database lookup, browser IPC, Android Binder or iOS XPC overhead, TEE world switch, HSM request latency, remote attestation, remote policy service calls, external ledger interaction, VPN/proxy latency, full media inspection, encrypted-traffic decryption, and carrier network processing. The correct characterization of this result is that the Python reference implementation showed approximately 0.5 ms mean local PED-plus-sink processing in one synthetic execution environment. It is not a claim about total added latency to a real location request.¶
The reference implementation is runnable, testable, reproducible, vendor-neutral, and protocol-oriented research code. It is not a production Android or iOS privacy service, a carrier-certified gateway, a universal data-loss-prevention engine, a covert-channel prevention system, a privacy-law compliance certificate, a formally verified protocol, a hardware-rooted Protected Enforcement Domain, a production public-key infrastructure, a full differential-privacy implementation, or a complete location-anonymization system. In particular:¶
These limitations are listed so that a reviewer or implementer does not read the measurements in Section 10.5 as claims broader than what was actually measured.¶
The runnable reference implementation described in this section is published at:¶
https://github.com/sangmdas/Access-Is-Not-Egress-Precision-Bounded-Location-Release-Reference-Implementation¶
This document is part of a series of Internet-Drafts that apply the same execution-finality architecture — Candidate Act, Non-Effective State, Protected Enforcement Domain, protected validation evidence, scoped non-bearer finality authority, and independent Finality Sink verification — to different consequence classes. The following companion drafts are referenced for context and are tracked at the IETF Datatracker:¶
The policy motivation for treating precise location as data warranting its own protection, independent of the general personal-data category, is discussed in:¶
Why We Should Treat Our GPS Coordinates More than Our Personal Data for Privacy and Security (EU AI Alliance Futurium)¶
The objective is that protected location remains technically non-effective for egress unless current, act-specific, precision-bounded authority is verified at the sink.¶
Replay of a previously successful authority MUST be prevented by nonce, consumption, short lifetime, or equivalent state. Authority for city-level weather MUST NOT authorize exact GPS to the same host, a different host, or a different sink.¶
Ordinary application-layer software MAY be compromised or overly permissive. Security MUST NOT depend solely on the application, SDK, browser, or model returning ALLOW. A malicious SDK with valid in-process access SHOULD NOT be able to bypass a correctly placed egress sink.¶
If PED or sink integrity cannot be established, the implementation SHOULD NOT release exact or high-precision location. It MAY fail closed, downgrade, quarantine, or disable the protected consequence class.¶
A detailed threat model, including attacker classes, specific attacks against each binding defined in Section 9, and explicit non-goals, is given in Section 12.¶
This section states the security objective in attacker terms, identifies protected assets and trust boundaries, walks through the attacks each binding in Section 9 is intended to defeat, and lists explicit non-goals. It expands on Section 11 rather than replacing it.¶
Protected location or location-derived information MUST remain technically non-effective for external egress unless current, act-specific, precision-bounded authority is verified at the relevant egress Finality Sink. The system distinguishes local possession of location from authority to export it, and distinguishes declared precision from observed outbound precision. Neither equivalence MUST be assumed by an implementation.¶
Assets treated as security-sensitive include exact latitude/longitude, meter-level location, mobility traces, proximity information, sensor-derived location, destination identity, recipient identity, purpose, jurisdiction, policy state, revocation state, Finality Sink identity, Candidate Act descriptors, nonces and sequence state, protected evidence, finality authority, and cumulative-disclosure state. Cumulative-disclosure state is itself protected, because it can reveal a movement pattern even when every individual egress event was coarse; see Section 13.¶
A deployment is expected to identify at least the following trust boundary. The Egress Finality Sink is security-critical: if protected data can reach the network through a path that does not cross it, the architecture is not complete for that data class, and every path capable of emitting the same protected representation MUST be controlled or made unable to emit it, consistent with Section 7.¶
+--------------------------------------------------+
| Protected Environment |
| Exact Location |
| | |
| v |
| Candidate Act -> PED -> Protected Evidence |
| | |
| v |
| Scoped Finality Authority |
+--------|-------------------------------------------+
v
+--------------------------------------------------+
| Egress Finality Sink |
| verifies authority, payload, precision, fields, |
| destination, jurisdiction, replay state |
+--------|-------------------------------------------+
v
================ TRUST BOUNDARY ====================
v
External network / cloud / SDK / API / AI provider
¶
Trusted components are the PED, the Finality Sink, protected state, and the authority-verification key. Potentially untrusted components are the application, an embedded SDK, an AI agent, an analytics component, an advertising library, browser content, the cloud destination, and the network path.¶
An application has legitimate local access but may intentionally or accidentally attempt unauthorized egress — for example, a weather application that may read exact GPS but should transmit only CITY sends exact coordinates anyway. The Finality Sink observing EXACT against an authorized precision of CITY MUST deny the release. The same reasoning applies to an analytics, advertising, or telemetry SDK sharing the application's in-process access: security MUST NOT depend on the application or SDK behaving correctly, and the SDK's own egress path MUST also cross an appropriate sink.¶
An on-device AI agent may legitimately reason over exact local location while the external model provider needs only CITY, GRID, or coarse locality. If the agent attempts to send exact coordinates to the cloud model, the sink observing exact latitude/longitude against an authorized CITY/REGION ceiling MUST deny the release. A residual threat is not solved by this document: a model may encode location semantically, for example stating that the user is standing outside a named address, without emitting explicit coordinates. That is an explicit non-goal; see Section 12.5 and Section 13.¶
An attacker captures a previously valid authority and reuses it later. Nonce, sequence, short authority lifetime, single-use consumption state, policy epoch, and revocation epoch together MUST prevent reuse, consistent with Section 9.¶
An attacker changes a load-bearing attribute after
authority was issued for a different value — for example,
authority issued for CITY release to weather.example
is presented alongside an EXACT request to the same
destination, or the recipient or sink identity is swapped.
Because the Candidate Act digest is bound over precision,
destination, recipient, jurisdiction, purpose, permitted
fields, and sink identity, the substituted act MUST fail
verification. A stronger variant occurs after authorization:
the PED authorized {"city": "Balasore"} but the
application transmits {"city": "Balasore", "latitude":
21.494321, "longitude": 86.932145}. The sink inspecting
the actual payload, not the declared label, MUST detect the
mismatch and deny with EF_PRECISION_MISMATCH.¶
A payload may declare "declared_precision": "CITY"
while still carrying exact coordinates; the sink MUST NOT
trust the declared label and MUST derive or verify observed
precision independently. Exact information may also be
hidden in additional JSON fields, HTTP headers, metadata,
nested structures, duplicated fields, or query parameters.
Implementations SHOULD define payload canonicalization
sufficient to detect these cases, while this document does
not define a complete media-type inspection algorithm; see
Section 10.6.¶
Authority for weather.example MUST NOT
authorize ads.example, even over the same
transport or cloud provider. Destination and recipient are
not necessarily identical — a shared host such as
api.sharedcloud.example may serve multiple logical
processors — so authority binds both a
destination_id and a recipient_id.
Authority issued for one destination jurisdiction MUST NOT
be treated as valid if the actual route or endpoint resolves
to a different jurisdiction; a production system determines
jurisdiction from configured endpoint jurisdiction, cloud
region, processor metadata, enterprise policy, contractual
processor identity, or network location information, and
this document does not adjudicate which legal interpretation
is correct, only that the selected jurisdiction policy is
load-bearing.¶
An attacker restores authority issued under an older
policy_epoch or revocation_epoch after
current state has advanced. The sink comparing current
epoch state against the authority's bound epoch MUST reject
the stale authority.¶
A database-backed implementation may correctly persist
CONSUMED status, but an attacker with sufficient
privilege could restore an older filesystem or database
snapshot showing UNUSED. SQLite persistence alone,
as used in the reference implementation
(Section 10.3), does not solve this.
Higher-assurance deployments are expected to use a hardware
monotonic counter, sealed state, a TPM-backed counter,
TEE-protected state, an authenticated remote witness, or an
append-only protected log.¶
If the PED is compromised, it may authorize excessive precision, forge policy decisions, or issue malicious authority. The Finality Sink still independently checks candidate binding, payload precision, sink identity, current epochs, replay state, destination, and recipient, but cannot detect that a cryptographically valid PED decision was malicious if every sink-visible predicate is satisfied; production PEDs are expected to need TEE/HSM protection, attestation, key isolation, least privilege, policy separation, audit, and multi-party authorization for high-risk cases. Compromise of the Finality Sink itself is more severe: if the actual egress boundary permits release without finality verification, upstream PED validation cannot compensate, so security depends on placing the sink at a boundary that genuinely controls the consequence.¶
If an application has one path through a controlled API gateway and Finality Sink, and a second path through a raw socket directly to the network, and the second path can transmit protected information, finality protection is incomplete regardless of how well the first path is enforced. This is the principal limitation of any current implementation of this profile; see Section 10.6 and Section 7. Production approaches include an OS network broker, kernel enforcement, a mandatory enterprise proxy, sandboxed networking, a DLP layer, browser engine enforcement, restricted SDK network permissions, or an application capability model.¶
If an untrusted component encrypts exact coordinates before the sink, the sink sees only opaque ciphertext and cannot determine precision; the enforcement point MUST therefore sit before untrusted encryption, or the encryption operation itself MUST be inside the trusted finality boundary. Separately, an attacker may present the payload as base64, gzip, protobuf, CBOR, custom binary, nested JSON, URL-encoded, or multipart form data; a production implementation cannot assume plain JSON and needs media-type-aware canonicalization, which the reference implementation only partially demonstrates.¶
A malicious component may encode location indirectly through packet timing, packet size, request ordering, DNS labels, identifier selection, image pixels, custom metadata, or model output, none of which this architecture claims to eliminate. Separately, location may be inferred without exact coordinates from Wi-Fi access-point identifiers, Bluetooth beacons, cell identifiers, IP address, timezone, sensor data, camera images, landmarks, or movement vectors; precision-bounded GPS egress is therefore not equivalent to complete location privacy.¶
An attacker avoids sending exact location and instead requests repeated coarse releases — for example CITY-level location once per hour to different destinations — each of which individually satisfies policy but which together reconstruct a movement history. This is why cumulative disclosure is defined as protected state in Section 7 rather than left to per-release evaluation alone.¶
Fail-closed behavior trades against availability: an
attacker who can block policy lookup, block PED access,
corrupt sink state, or force a verification timeout can deny
legitimate releases if the system correctly fails closed.
Production deployments need bounded local policy cache,
high availability, replicated protected state, graceful
downgrade, emergency consequence classes, and controlled
escalation, without converting system unavailability into
ALLOW.¶
A time-of-check/time-of-use gap exists between Candidate Act authorization and actual release if destination resolution, routing, or endpoint state changes in between; a production sink SHOULD verify load-bearing information (for example resolved endpoint, TLS peer identity, destination service identity, and current policy state) as close as possible to actual release rather than relying solely on the earlier Candidate Act.¶
A confused-deputy attack manipulates a trusted host application into releasing data on behalf of an untrusted embedded SDK. The PED SHOULD distinguish application identity, component identity, and caller identity rather than treating an entire process as a single principal.¶
If the authority-signing key is compromised, the attacker can produce cryptographically valid authority at will; production systems need hardware-protected keys, key rotation, authority epoch, revocation, short validity, separated signing and transport keys, and audit. The reference implementation demonstrates signing semantics only, not full PKI lifecycle management. Separately, the same single-use authority sent simultaneously to two sinks MUST NOT be permitted to produce two successful releases; shared protected consumption state must ensure at most one effect succeeds, which the reference implementation tests for a single process but does not demonstrate at distributed, multi-sink scale.¶
This profile, and the reference implementation described in Section 10, do not claim to solve: all covert channels; all semantic exfiltration by a language model; all location inference from non-GPS signals; malicious kernel or hardware compromise; global traffic analysis; complete data-loss prevention; inspection of all encrypted data; formal privacy-loss accounting; legal jurisdiction determination; or general information-flow security. These are stated explicitly so that an implementer does not read conformance with this document as covering them.¶
Finality metadata can itself be sensitive: application identity, purpose, destination, jurisdiction, and precision class can reveal behavior even when coordinates are withheld. Implementations SHOULD minimise metadata exposed outside the PED and MAY use hashes, commitments, or sealed references rather than raw descriptors on untrusted paths.¶
Repeated coarse releases can still build a movement history. Authorized precision of CITY on each of 144 requests is not automatically harmless. Cumulative-disclosure evaluation exists for that reason and must not become a second exportable trace.¶
The cumulative-disclosure state defined in Section 7 is itself a weaponization risk, not only a mitigation. By construction it aggregates release timestamps, destinations, and precision history across a policy window for a subject scope; a state object built for that purpose is functionally a mobility log, and if it is exposed, exported, or made available to any party other than the PED that consumes it, it recreates the exact movement-history exposure that cumulative-disclosure evaluation exists to prevent, with the additional property that it is pre-aggregated and therefore cheaper to exploit than reconstructing history from individual releases. An implementation MUST NOT treat the cumulative-disclosure state as a general-purpose audit log, analytics source, or export object. Concretely:¶
An implementation SHOULD be able to state, as part of its own documentation, what cumulative-disclosure fields it retains, for how long, under what subject scope, and what happens to that state on user deletion or policy revocation. This document does not itself specify a formal privacy-loss accounting method for the state; see Section 10.6.¶
On-device models that reason over exact coordinates while egress is limited to city labels create an isolation requirement. This document does not specify how an implementation prevents the model or a tool-calling runtime from emitting the exact value through another channel. That channel, if it exists, is an egress path and is subject to Section 7.¶
Authority to access data inside one environment is not authority to transfer it to another jurisdiction, cloud region, unapproved processor, external analytics provider, unrelated AI provider, or advertising endpoint. A data-export Candidate Act SHOULD bind destination, recipient, jurisdiction, cloud region, purpose, data class, precision, policy and revocation epochs, and sink identity.¶
This document requests no IANA actions. The precision-class names and EF-xxx identifiers are illustrative. A later revision MAY propose registries for precision classes, consequence classes, or error codes.¶
Certain technical concepts described in this document are associated with pending patent applications in the DAS Protocols family, including PCT/IB2026/054453, PCT/IB2026/055615, PCT/IB2026/055760, PCT/IB2026/055870, PCT/IB2026/056058, and PCT/IB2026/053385. IETF IPR disclosure should follow BCP 79 [RFC8179]. This section is informational and does not define licensing terms.¶
A device or application may obtain exact location while an SDK, AI agent, analytics service, cloud processor, or external destination is entitled only to a less precise representation or to no location at all. This profile moves that distinction to the actual egress boundary. Precise GPS access is not precise GPS-release authority.¶
This appendix collects questions raised during early review of this and companion drafts in the same execution-finality series. It is non-normative and is included to shorten review cycles by answering predictable questions in one place.¶
A reviewer evaluating this document is expected to ask, at minimum: what exact interoperability problem requires standardization; which elements are protocol semantics versus implementation policy; the precise definition of "precision" and the canonical representation used for hashing; how a sink determines observed payload precision; how encrypted payloads are handled; how the architecture handles alternative egress paths; what "non-bearer authority" means operationally; which state must be protected versus cached; how keys are provisioned and rotated; how replay is prevented across multiple sinks; how single-use authority is consumed atomically; failure behavior during network partitions; latency, throughput, and object-size overhead; why existing OAuth, OS permission, or DLP mechanisms cannot carry the same information; what belongs at IETF versus W3C, 3GPP, O-RAN, a platform vendor, or enterprise DLP; and what minimum subset is actually required for interoperable deployment. This appendix and the sections it cross-references are intended to answer these precisely rather than by assertion.¶
The position of this document is not that existing location permissions are insecure and must be replaced. It is that existing permission, consent, transformation, relay, authorization, and privacy mechanisms remain in place as policy inputs, and that this profile adds a later consequence-control step in which a proposed outbound disclosure remains non-effective until act-specific precision authority is bound to recipient, destination, jurisdiction, policy state, and sink identity, and the actual outbound representation is independently checked immediately before release. This framing is intended to make the architecture complementary to existing standards rather than competitive with them.¶