Access Is Not Egress: Precision-Bounded Location Release
draft-das-precision-bounded-egress-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Reference Implementation — Access Is Not Egress: Precision-Bounded Location Release
Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance — Apply AI Alliance, European Commission Futurium |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-precision-bounded-egress-03
Network Working Group S. Das
Internet-Draft Independent Inventor
Intended status: Informational 8 September 2026
Expires: 12 March 2027
Access Is Not Egress: Precision-Bounded Location Release
draft-das-precision-bounded-egress-03
Abstract
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.
Das Expires 12 March 2027 [Page 1]
Internet-Draft Access-Not-Egress September 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 12 March 2027.
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Relationship to Existing Mechanisms . . . . . . . . . . . . . 7
5.1. Operating-System Location Permissions . . . . . . . . . . 7
5.2. W3C Geolocation and Permission Policy . . . . . . . . . . 7
5.3. Coarsening, Fuzzing, and Differential Privacy . . . . . . 7
5.4. Path-Level Privacy Controls . . . . . . . . . . . . . . . 7
5.5. What This Profile Adds . . . . . . . . . . . . . . . . . 7
6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Precision-Bounded Egress Profile . . . . . . . . . . . . . . 9
7.1. Precision Ladder . . . . . . . . . . . . . . . . . . . . 9
7.2. Illustrative Precision-Class Quantization . . . . . . . . 10
7.3. PED Predicates . . . . . . . . . . . . . . . . . . . . . 12
Das Expires 12 March 2027 [Page 2]
Internet-Draft Access-Not-Egress September 2026
7.4. Worked Example . . . . . . . . . . . . . . . . . . . . . 12
7.5. Cumulative Disclosure . . . . . . . . . . . . . . . . . . 13
7.6. Jurisdiction-Neutral Policy Input . . . . . . . . . . . . 13
7.7. Sink Placement and Alternate Paths . . . . . . . . . . . 13
8. JSON Interoperability Profile . . . . . . . . . . . . . . . . 14
8.1. LocationReleaseCandidate Object . . . . . . . . . . . . . 14
8.2. Precision Decision Object . . . . . . . . . . . . . . . . 17
8.3. EgressFinalityAuthority Object . . . . . . . . . . . . . 18
8.4. EgressSinkVerify Request and Response . . . . . . . . . . 19
8.5. Precision-Mismatch Denial . . . . . . . . . . . . . . . . 21
8.6. Complete Exact-to-Coarse Transaction . . . . . . . . . . 22
8.7. Cumulative Disclosure Extension . . . . . . . . . . . . . 24
9. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 24
9.1. Digest and Substitution . . . . . . . . . . . . . . . . . 24
9.2. Sink Verification . . . . . . . . . . . . . . . . . . . . 24
9.3. Hot Path and Escalation . . . . . . . . . . . . . . . . . 25
9.4. Failure Codes . . . . . . . . . . . . . . . . . . . . . . 26
10. Reference Implementation . . . . . . . . . . . . . . . . . . 26
10.1. Implementation Environment . . . . . . . . . . . . . . . 27
10.2. Test Coverage . . . . . . . . . . . . . . . . . . . . . 27
10.3. Cryptographic and Persistence Variations . . . . . . . . 28
10.4. Payload Inspection . . . . . . . . . . . . . . . . . . . 28
10.5. Measured Performance . . . . . . . . . . . . . . . . . . 28
10.6. What the Reference Implementation Does Not Establish . . 30
10.7. Resources . . . . . . . . . . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Security Objective . . . . . . . . . . . . . . . . . . . 32
12.2. Protected Assets . . . . . . . . . . . . . . . . . . . . 33
12.3. Trust Boundaries . . . . . . . . . . . . . . . . . . . . 33
12.4. Attacker Classes and Attacks . . . . . . . . . . . . . . 34
12.4.1. Compromised Application or Embedded SDK . . . . . . 34
12.4.2. AI-Agent Semantic Exfiltration . . . . . . . . . . . 34
12.4.3. Replay . . . . . . . . . . . . . . . . . . . . . . . 34
12.4.4. Candidate-Act and Payload Substitution . . . . . . . 34
12.4.5. Precision-Label Forgery and Hidden Fields . . . . . 35
12.4.6. Destination, Recipient, and Jurisdiction
Substitution . . . . . . . . . . . . . . . . . . . . 35
12.4.7. Policy and Revocation Rollback . . . . . . . . . . . 35
12.4.8. Persistent-State Rollback . . . . . . . . . . . . . 35
12.4.9. PED and Finality Sink Compromise . . . . . . . . . . 36
12.4.10. Sink-Bypass and Alternate-Path Attacks . . . . . . . 36
12.4.11. Encrypted-Payload and Encoding Evasion . . . . . . . 36
12.4.12. Covert Channels and Derived Location . . . . . . . . 37
12.4.13. Cumulative-Disclosure Attack . . . . . . . . . . . . 37
12.4.14. Availability, TOCTOU, and Confused-Deputy Threats . 37
12.4.15. Key Compromise and Multi-Sink Races . . . . . . . . 38
12.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . 38
Das Expires 12 March 2027 [Page 3]
Internet-Draft Access-Not-Egress September 2026
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
14. Data-Sovereignty Considerations . . . . . . . . . . . . . . . 40
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
16. Intellectual Property Note . . . . . . . . . . . . . . . . . 40
17. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 40
18. Normative References . . . . . . . . . . . . . . . . . . . . 40
19. Informative References . . . . . . . . . . . . . . . . . . . 41
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
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,
Das Expires 12 March 2027 [Page 4]
Internet-Draft Access-Not-Egress September 2026
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.
2. Requirements Language
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.
3. Terminology
Location-Release Candidate Act
A Candidate Act whose intended consequence is external disclosure
of location or a location-derived signal, including exact
coordinates, a mobility trace, proximity, or sensor-derived
location.
Available precision
The finest representation the local environment currently holds.
Available precision MUST NOT by itself authorize release at that
precision.
Authorized precision
The coarsest-or-equal representation permitted to become
externally effective for a particular act. The Finality Sink MUST
treat authorized precision as a ceiling on the outbound payload.
Precision transformation
A PED-directed reduction of available data to the authorized
representation before or at the sink, for example city label, grid
cell, shortened geohash, delay, or randomization.
Egress Finality Sink
The first boundary at which the location representation would
leave the protected environment. Depending on deployment this MAY
be an OS data broker, network egress filter, browser upload
control, API gateway, enterprise agent, or equivalent. A
component is a sink only if the release is technically non-
completable without successful verification.
Das Expires 12 March 2027 [Page 5]
Internet-Draft Access-Not-Egress September 2026
Cumulative disclosure state
Protected state describing prior releases in a policy window, used
to decide whether another individually acceptable release would
create an unauthorized movement history or equivalent exposure.
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].
4. Problem Scope
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.
Das Expires 12 March 2027 [Page 6]
Internet-Draft Access-Not-Egress September 2026
5. Relationship to Existing Mechanisms
This profile is intended to consume decisions from existing
permission, consent, and policy systems. Those systems remain
inputs. They do not replace sink verification of the outbound
payload.
5.1. Operating-System Location Permissions
Current mobile platforms distinguish, to varying degrees, approximate
and precise location, one-time and continuous access, and foreground
versus background access. Those controls govern whether an
application process may read a provider. They typically do not bind
a particular outbound payload, recipient, jurisdiction, or precision
ceiling at the moment of network egress, and they often do not
distinguish the first-party application from an embedded SDK on the
same release path.
5.2. W3C Geolocation and Permission Policy
The W3C Geolocation API and related permission policy give a web
origin a location reading after user permission [W3C-GEO]. They do
not, by themselves, inspect a later fetch, beacon, or agent tool call
that forwards that reading at full precision to a third party.
5.3. Coarsening, Fuzzing, and Differential Privacy
Geohash prefixes, grid snapping, geo-fuzzing, delay, and
differential-privacy mechanisms are compatible with this profile.
They are candidate transformation methods. This document does not
select one transformation. It requires that whatever representation
is actually sent is the representation bound to the authority, and
that a finer representation MUST NOT pass the sink under that
authority.
5.4. Path-Level Privacy Controls
Oblivious endpoints, MASQUE-based proxying, and private relay
services can hide the client's network location from a destination
[RFC9298]. They do not bind the precision of application payload
fields that already contain coordinates. Path privacy and payload-
precision finality are complementary.
5.5. What This Profile Adds
* precision as an authorization dimension, not only as a provider
configuration;
Das Expires 12 March 2027 [Page 7]
Internet-Draft Access-Not-Egress September 2026
* component identity (application versus SDK, agent, analytics, or
advertising library) as a predicate;
* recipient, destination, and jurisdiction bindings on the release;
* optional cumulative-disclosure evaluation;
* sink-side comparison of authorized precision with the actual
outbound payload; and
* fail-closed denial or mandatory downgrade rather than advisory
minimisation.
6. Architecture
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.
Das Expires 12 March 2027 [Page 8]
Internet-Draft Access-Not-Egress September 2026
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
Figure 1: Precision-bounded egress chain
PED approval alone MUST NOT release data. The sink MUST prevent
effectuation on verification failure. A warning or audit record is
not sufficient.
7. Precision-Bounded Egress Profile
7.1. Precision Ladder
Implementations SHOULD be able to distinguish at least the following
authorized-precision classes:
* EXACT
* METER_10
* METER_100
* GRID
* GEOHASH
Das Expires 12 March 2027 [Page 9]
Internet-Draft Access-Not-Egress September 2026
* CITY
* REGION
* COUNTRY
* DELAYED or RANDOMIZED variants of the above
* NONE
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.
7.2. Illustrative Precision-Class Quantization
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:
Das Expires 12 March 2027 [Page 10]
Internet-Draft Access-Not-Egress September 2026
+===========+====================================================+
| 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. |
+-----------+----------------------------------------------------+
Table 1
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
Das Expires 12 March 2027 [Page 11]
Internet-Draft Access-Not-Egress September 2026
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.
7.3. PED Predicates
For a location-release act the PED SHOULD evaluate:
* requesting application and component identity and type;
* declared purpose and whether exact precision is necessary for that
purpose;
* recipient, destination, processor type, and jurisdiction;
* current user authorization and policy/revocation epochs;
* data class and requested fields;
* whether the release is one-shot or continuous; and
* cumulative disclosure state where the policy requires it;
* intended egress sink identity.
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.
7.4. Worked Example
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.
Das Expires 12 March 2027 [Page 12]
Internet-Draft Access-Not-Egress September 2026
7.5. Cumulative Disclosure
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.
7.6. Jurisdiction-Neutral Policy Input
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.
7.7. Sink Placement and Alternate Paths
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.
Das Expires 12 March 2027 [Page 13]
Internet-Draft Access-Not-Egress September 2026
8. JSON Interoperability Profile
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.
8.1. LocationReleaseCandidate Object
{
"$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"
]
}
}
},
Das Expires 12 March 2027 [Page 14]
Internet-Draft Access-Not-Egress September 2026
"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" }
}
},
Das Expires 12 March 2027 [Page 15]
Internet-Draft Access-Not-Egress September 2026
"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 },
Das Expires 12 March 2027 [Page 16]
Internet-Draft Access-Not-Egress September 2026
"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"
]
}
}
}
}
}
8.2. Precision Decision Object
Das Expires 12 March 2027 [Page 17]
Internet-Draft Access-Not-Egress September 2026
{
"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"
]
}
8.3. EgressFinalityAuthority Object
Das Expires 12 March 2027 [Page 18]
Internet-Draft Access-Not-Egress September 2026
{
"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"
}
}
8.4. EgressSinkVerify Request and Response
The sink verifies the actual outbound payload immediately before
release. Declared precision is not sufficient. The payload fields
MUST be within the authorized ceiling.
Das Expires 12 March 2027 [Page 19]
Internet-Draft Access-Not-Egress September 2026
{
"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" }
}
Das Expires 12 March 2027 [Page 20]
Internet-Draft Access-Not-Egress September 2026
{
"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"
}
}
8.5. Precision-Mismatch Denial
Das Expires 12 March 2027 [Page 21]
Internet-Draft Access-Not-Egress September 2026
{
"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 }
}
8.6. Complete Exact-to-Coarse Transaction
Das Expires 12 March 2027 [Page 22]
Internet-Draft Access-Not-Egress September 2026
{
"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
}
}
Das Expires 12 March 2027 [Page 23]
Internet-Draft Access-Not-Egress September 2026
8.7. Cumulative Disclosure Extension
{
"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"
}
}
9. Protocol Operation
9.1. Digest and Substitution
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.
9.2. Sink Verification
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:
Das Expires 12 March 2027 [Page 24]
Internet-Draft Access-Not-Egress September 2026
* coordinate values re-encoded in a nested or duplicated JSON field,
an HTTP header, a URL query parameter, a cookie, or request
metadata rather than the expected top-level field;
* coordinate values transported inside a non-JSON or binary-native
encoding — protobuf, CBOR, MessagePack, a custom binary stream, or
a compressed body (gzip, brotli, or similar) — that the sink's
JSON-oriented inspection would otherwise pass through uninspected;
* coordinate values split across multiple fields or messages such
that no single field individually exceeds the authorized precision
(for example separately transmitting a rounded value and a fine-
grained offset or delta);
* coordinate values embedded in a payload the sink does not parse as
structured data at all, such as image or audio metadata, a free-
text field, or a file attachment; and
* coordinate-derived values that are individually below the
precision ceiling but that, combined with other fields the sink
does treat as authorized (timestamp, device identifier, network
measurement), allow the recipient to reconstruct a finer position
than any single released field discloses.
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.
9.3. Hot Path and Escalation
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.
Das Expires 12 March 2027 [Page 25]
Internet-Draft Access-Not-Egress September 2026
9.4. Failure Codes
The following identifiers are design suggestions and are not IANA
assignments. Location-egress implementations SHOULD be able to
express at least:
* EF-002 NO_FINALITY_AUTHORITY
* EF-005 AUTHORITY_ALREADY_USED
* EF-006 REPLAY_DETECTED
* EF-012 SCOPE_MISMATCH
* EF-020 DESTINATION_MISMATCH
* EF-021 JURISDICTION_MISMATCH
* EF-023 PRECISION_MISMATCH
* EF-030 POLICY_EPOCH_MISMATCH
* EF-031 REVOCATION_STATE_MISMATCH
* EF-040 SINK_MISMATCH
* EF-070 ESCALATION_REQUIRED
* EF-080 FAIL_CLOSED
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.
10. Reference Implementation
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.
Das Expires 12 March 2027 [Page 26]
Internet-Draft Access-Not-Egress September 2026
10.1. Implementation Environment
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.
10.2. Test Coverage
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.
Das Expires 12 March 2027 [Page 27]
Internet-Draft Access-Not-Egress September 2026
10.3. Cryptographic and Persistence Variations
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.
10.4. Payload Inspection
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.
10.5. Measured Performance
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:
Das Expires 12 March 2027 [Page 28]
Internet-Draft Access-Not-Egress September 2026
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.
Das Expires 12 March 2027 [Page 29]
Internet-Draft Access-Not-Egress September 2026
10.6. What the Reference Implementation Does Not Establish
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:
* it does not prove that every alternate egress path on a real
device (telemetry, clipboard, file export, background sync, an
analytics or advertising SDK using a direct socket, agent tool
calls, shared memory, IPC, debug logs, crash reports, or a covert
channel) is closed, which is the central limitation discussed in
Section 12;
* its payload inspection covers selected structured JSON cases and
does not fully canonicalize XML, protobuf, CBOR, MessagePack,
multipart or compressed bodies, custom binary formats, or media
metadata;
* it cannot determine payload precision once an untrusted component
encrypts the value before the sink;
* its cumulative-disclosure accumulator demonstrates the principle
in Section 7 but is not a differential-privacy budget, a
trajectory-privacy or k-anonymity calculation, or a formal re-
identification estimate;
* its Protected Enforcement Domain and Finality Sink are ordinary
software processes, not hardware-rooted trust (ARM TrustZone,
Intel TDX, AMD SEV-SNP, Apple Secure Enclave, Android StrongBox,
TPM, HSM, confidential VM, SmartNIC, or DPU protected execution);
and
* its 98 passing tests demonstrate behavior for the tested cases and
are not a substitute for formal verification (for example with
TLA+, Tamarin, ProVerif, Coq, Lean, Isabelle, or Alloy), nor for a
measured production throughput, request-per-second, multi-core
scaling, or mobile battery-impact result, none of which has been
produced yet.
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.
Das Expires 12 March 2027 [Page 30]
Internet-Draft Access-Not-Egress September 2026
10.7. Resources
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
(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:
draft-das-ai-native-6g-execution-finality
(https://datatracker.ietf.org/doc/draft-das-ai-native-6g-
execution-finality/) — execution finality for AI-native 5G/6G and
O-RAN control
draft-das-6g-query-scoped-communication-handles
(https://datatracker.ietf.org/doc/draft-das-6g-query-scoped-
communication-handles/) — query-scoped communication authority for
6G signaling
draft-das-map-discovery-communication-finality
(https://datatracker.ietf.org/doc/draft-das-map-discovery-
communication-finality/) — execution finality applied to
discovery/MAP-layer communication
draft-das-rats-attestation-bnd-execution-finality
(https://datatracker.ietf.org/doc/draft-das-rats-attestation-bnd-
execution-finality/) — attestation-bound execution finality under
RATS
draft-das-child-safe-rendering-finality
(https://datatracker.ietf.org/doc/draft-das-child-safe-rendering-
finality/) — execution finality for preventing unauthorized
rendering of age-restricted content to minors
The policy motivation for treating precise location as data
warranting its own protection, independent of the general personal-
data category, is discussed in:
Das Expires 12 March 2027 [Page 31]
Internet-Draft Access-Not-Egress September 2026
Why We Should Treat Our GPS Coordinates More than Our Personal Data
for Privacy and Security (https://futurium.ec.europa.eu/en/apply-ai-
alliance/community-content/why-we-should-treat-our-gps-coordinates-
more-our-personal-data-privacy-and-security) (EU AI Alliance
Futurium)
11. Security Considerations
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.
12. Threat Model
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.
12.1. Security Objective
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
Das Expires 12 March 2027 [Page 32]
Internet-Draft Access-Not-Egress September 2026
be assumed by an implementation.
12.2. Protected Assets
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.
12.3. Trust Boundaries
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
Das Expires 12 March 2027 [Page 33]
Internet-Draft Access-Not-Egress September 2026
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.
12.4. Attacker Classes and Attacks
12.4.1. Compromised Application or Embedded SDK
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.
12.4.2. AI-Agent Semantic Exfiltration
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.
12.4.3. Replay
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.
12.4.4. Candidate-Act and Payload Substitution
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
Das Expires 12 March 2027 [Page 34]
Internet-Draft Access-Not-Egress September 2026
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.
12.4.5. Precision-Label Forgery and Hidden Fields
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.
12.4.6. Destination, Recipient, and Jurisdiction Substitution
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.
12.4.7. Policy and Revocation Rollback
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.
12.4.8. Persistent-State Rollback
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
Das Expires 12 March 2027 [Page 35]
Internet-Draft Access-Not-Egress September 2026
witness, or an append-only protected log.
12.4.9. PED and Finality Sink Compromise
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.
12.4.10. Sink-Bypass and Alternate-Path Attacks
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.
12.4.11. Encrypted-Payload and Encoding Evasion
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.
Das Expires 12 March 2027 [Page 36]
Internet-Draft Access-Not-Egress September 2026
12.4.12. Covert Channels and Derived Location
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.
12.4.13. Cumulative-Disclosure Attack
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.
12.4.14. Availability, TOCTOU, and Confused-Deputy Threats
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.
Das Expires 12 March 2027 [Page 37]
Internet-Draft Access-Not-Egress September 2026
12.4.15. Key Compromise and Multi-Sink Races
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.
12.5. Non-Goals
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.
13. Privacy Considerations
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
Das Expires 12 March 2027 [Page 38]
Internet-Draft Access-Not-Egress September 2026
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:
* the state MUST remain device-local or PED-internal and MUST NOT be
transmitted to a destination, recipient, or Finality Sink as part
of, or alongside, a location-release payload;
* the state SHOULD use a pseudonymous or rotating subject scope
rather than a stable cross-context user identifier, so that
compromise of the state does not directly yield an identified
movement history;
* retained fields SHOULD be the minimum needed for the policy
decision — release count, coarse precision history, and distinct-
destination count, for example — rather than raw timestamps, exact
prior payloads, or full destination identifiers, where the coarser
form is sufficient for the policy in force;
* retention MUST be bounded to the policy window in Section 7 and
expired entries MUST be deleted rather than retained indefinitely
for convenience; and
* where an implementation persists the state (for example in the
SQLite variation discussed in Section 10.3), the persistence
mechanism is subject to the same rollback and tamper concerns as
consumption state, discussed in Section 12.4, because an attacker
who can roll back cumulative-disclosure state can also roll back
the escalation it would otherwise trigger.
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.
Das Expires 12 March 2027 [Page 39]
Internet-Draft Access-Not-Egress September 2026
14. Data-Sovereignty Considerations
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.
15. IANA Considerations
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.
16. Intellectual Property Note
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.
17. Conclusion
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.
18. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
Das Expires 12 March 2027 [Page 40]
Internet-Draft Access-Not-Egress September 2026
19. Informative References
[ENISA-MOBILE]
ENISA, "Privacy and data protection in mobile
applications", 2017.
[GDPR-MIN] European Commission, "Principles of data protection,
including data minimisation and protection by default",
2018. Policy context only. This document does not
specify EU law.
[I-D.das-6g-finality]
Das, S., "Execution-Finality for AI-Native 5G/6G and
O-RAN", Work in Progress, Internet-Draft, draft-das-ai-
native-6g-execution-finality-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-das-ai-
native-6g-execution-finality-01>.
[I-D.das-agentic-tool-binding]
Das, S., "tool_use Is Not invoke(): Binding Execution-
Finality to Agentic Tool Calls", Work in Progress,
Internet-Draft, draft-das-agentic-tool-binding-02, August
2026, <https://datatracker.ietf.org/doc/html/draft-das-
agentic-tool-binding-02>. Applies the Agent Candidate Act
profile to tool_use/computer_use, function-calling, and
MCP tool invocation, requiring scoped authority
verification before a tool-call dispatch takes effect.
[I-D.das-ef-interop]
Das, S., "Execution-Finality for AI Interoperability",
Work in Progress, Internet-Draft, draft-das-execution-
finality-ai-interoperability-00, August 2026,
<https://datatracker.ietf.org/doc/html/draft-das-
execution-finality-ai-interoperability-00>.
[NATO-STRATCOM]
NATO Strategic Communications Centre of Excellence, "Work
on consumer geolocation, metadata, and operationally
significant inference from ordinary activity data", 2018.
[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>.
[W3C-GEO] W3C, "Geolocation", 2025,
<https://www.w3.org/TR/geolocation/>.
Das Expires 12 March 2027 [Page 41]
Internet-Draft Access-Not-Egress September 2026
Appendix A. Frequently Asked Questions
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.
Why is a new protocol concept needed? Isn't this just an OS
permission?
No. An OS permission answers whether application A may read
location. This profile answers a later question: may this exact
representation leave the protected environment, to this recipient,
for this purpose, at this precision, right now. Provider access
and outbound release authority are different questions; see
Section 4.
Isn't approximate-location permission already enough?
Approximate-location permissions reduce what the application
receives at all. This profile supports a different deployment:
the application legitimately receives exact location locally while
the external service receives only coarse location. That matters
for applications that genuinely need precise local computation but
have no need to disclose it externally.
Why not just transform the location before giving it to the
application?
That is a valid design for some cases, but it does not support an
application that needs exact local data for navigation, on-device
geofencing, emergency logic, local AI, or sensor fusion while the
external service needs only coarse information. This profile
separates local computational authority from external disclosure
authority; see Section 6.
Isn't this just Data Loss Prevention, or something an enterprise
firewall doing deep packet inspection already covers?
There is overlap, and enterprise DPI can catch some of the same
cases. The distinction is mechanism, not outcome. Conventional
DLP typically relies on pattern matching against the payload — a
regex for coordinate-shaped values, a signature for a known field
name — which is inherently heuristic and evadable by re-encoding,
as discussed in Section 12.4. This profile instead forces a
precision ceiling that is cryptographically bound to a non-bearer
authority token issued for that specific Candidate Act (Section 6,
Section 7): the sink is not guessing whether a value looks like a
coordinate, it is checking whether the observed payload stays
inside the ceiling that authority was actually issued for. The
protocol-oriented sequence in Section 6 — Candidate Act, Non-
Effective State, protected validation, protected evidence, scoped
Das Expires 12 March 2027 [Page 42]
Internet-Draft Access-Not-Egress September 2026
authority, sink verification, effect — is the narrower
contribution. Traditional DLP products may perform equivalent
checks; this profile is intended to be complementary to DLP, not a
claim that DLP cannot implement similar enforcement.
Isn't this information-flow control?
It has similarities, but this profile currently defines a narrower
consequence-control mechanism centered on a specific egress
Candidate Act, not a complete language-level or system-wide
information-flow type system.
Why isn't differential privacy enough?
Differential privacy, fuzzing, grid snapping, and geohashing are
transformation mechanisms; see Section 5. This profile asks a
separate question: which transformation is authorized for this
particular release, and did the actual payload obey that
authorization. Differential privacy and coarsening are treated as
compatible transformation mechanisms, not replacements for sink
verification.
Doesn't MASQUE or private relay already protect location?
Path privacy and payload privacy are different. A relay can hide
a client's network address while the application payload still
contains latitude and longitude. These are complementary
mechanisms; see Section 5.
Why call the authority "non-bearer"?
Because possession of the serialized authority is not by itself
sufficient for effectuation. The reference implementation
requires a valid signed authority together with matching sink-
local activation state, so a copied authority without its
protected state fails; see Section 10.3. This is one reference
realization of non-bearer semantics, not a requirement that every
implementation use the identical mechanism.
Isn't this basically OAuth, since OAuth already handles scoped
tokens?
OAuth authorizes access to a resource or an API — it answers
whether the client may call the endpoint at all. Execution
finality governs a later, different question: access has already
been granted, a specific data release has already been generated,
and the question is whether this exact release — this precision,
this destination, this payload — should be allowed to become
effective right now. A valid OAuth scope does not tell a sink
whether the payload behind it stayed inside an authorized
precision ceiling. OAuth authorization can be one PED input among
others listed in Section 7; this profile does not require
replacing it.
Das Expires 12 March 2027 [Page 43]
Internet-Draft Access-Not-Egress September 2026
Why must the sink verify independently instead of trusting the
PED?
Because state can change between validation and effectuation:
policy, revocation, destination, payload, or sink identity may all
change in that interval. Independent sink verification closes
that window; see Section 12.3.
Where exactly is the Finality Sink?
There is no single universal location. Possible deployments
include an OS data broker, network egress broker, browser upload
layer, API gateway, enterprise proxy, SDK wrapper, cloud-sync
boundary, file-export boundary, or database-export boundary. The
requirement is functional: the protected consequence must be
technically unable to complete without successful verification;
see Section 7.
What if there are multiple egress paths?
All of them are in scope. If network upload is protected but a
telemetry SDK or file export can release the same data, the
architecture is incomplete for that data class; see Section 12.4.
How does the sink know the payload's true precision?
This is a hard implementation problem. The reference
implementation handles selected structured JSON and meter-level
coordinate granularity; see Section 10.4. A production standard
would need clearer canonical precision rules for coordinates,
grids, geohashes, region labels, derived location, and structured
payloads generally, which this document deliberately leaves
unspecified for now.
What does METER_100 actually mean?
An approximate precision class in the current implementation. A
standards-grade definition would need to specify coordinate
reference system, quantization method, rounding, latitude-
dependent scale, boundary conditions, datum, and error tolerance,
none of which is fully specified by this draft.
CITY is not a consistent privacy level. How is that handled?
It is not handled by the precision class alone. CITY in a
metropolitan area and CITY in a small settlement do not provide
equal anonymity; the precision ladder is an authorization
abstraction, not a mathematical anonymity guarantee. Stronger
privacy guarantees would need contextual information such as
population, geographic area, sensitivity, or user context.
Can an application simply encrypt exact GPS before the sink,
breaking payload inspection or end-to-end encryption?
If the sink sits after untrusted encryption, it sees only opaque
Das Expires 12 March 2027 [Page 44]
Internet-Draft Access-Not-Egress September 2026
ciphertext and cannot determine precision — that is a deployment
failure, not a protocol failure. The Finality Sink MUST sit
inside the trusted runtime environment, immediately before the
untrusted encryption step occurs, or MUST be integrated directly
into the local OS data broker or equivalent trusted egress point,
so that inspection happens on plaintext the sink itself controls;
see Section 12.4. This does not require decrypting end-to-end
traffic in transit or placing a middlebox between two trusted
endpoints — the sink operates at the sender, on the payload as
constructed, before it is encrypted for the wire.
What about QUIC or TLS?
The architecture is transport-independent. TLS or QUIC protects
the transport after the Finality Sink has decided what payload may
leave: payload construction, then Finality Sink, then the approved
payload, then TLS/QUIC encryption, then the network.
Doesn't payload inspection break end-to-end encryption?
Not necessarily. The sink can operate at the sender before
encryption; the architecture does not require a middlebox to
decrypt end-to-end traffic.
How do you prevent a malicious model from leaking location in
text?
The current implementation does not fully solve this. A statement
such as naming the user's exact cross street can reveal precise
location without emitting coordinates. A future AI-specific
profile may need structured tool outputs, semantic filtering,
information-flow controls, restricted network tools, and model
sandboxing. This is a residual risk; see Section 13 and
Section 12.5.
Is cumulative disclosure mathematically defined?
Not fully. The current implementation demonstrates the stateful
principle that many individually acceptable disclosures may
collectively become unacceptable, without a formal privacy-loss
calculus. Stronger versions could incorporate differential-
privacy accounting, trajectory privacy, mobility uniqueness, or
formal exposure budgets; see Section 7.
Where is cumulative-disclosure state stored?
It needs protection because the state itself can become a movement
history. Deployment options include device-local protected
storage, a TEE, a secure database, or an enterprise policy engine.
The reference implementation uses memory and SQLite for
demonstration only; SQLite carries no hardware trust.
Das Expires 12 March 2027 [Page 45]
Internet-Draft Access-Not-Egress September 2026
What happens when the PED is unavailable?
No PED means no new authority means no protected release, unless
policy explicitly permits a previously established bounded
envelope. Timeout is never treated as approval; see Section 9.
Doesn't fail-closed create denial-of-service risk?
Yes; that is a fundamental tradeoff discussed in Section 12.4.
Production systems need high availability, a local policy cache,
replication, bounded fallback, safe downgrade, and emergency
modes, none of which may silently convert failure into
unrestricted disclosure.
How are emergency services handled?
As a distinct policy and consequence class — for example E911 or
an equivalent emergency response service may be authorized for
exact location while weather is limited to CITY. This document
does not prescribe emergency policy; it carries whatever policy
outcome exists into enforcement.
What happens if policy changes after authority issuance?
Authority carries policy and revocation epoch information, and the
sink verifies current state before release, so a stale authority
is rejected; see Section 12.4.
How are keys provisioned and rotated?
Not defined by this document. A production design could use a
device trust anchor, an enterprise CA, a hardware-backed signing
key, authority epoch, key rotation, and revocation, but this
requires a separate deployment profile; see Section 10.6.
Why Ed25519?
Widely implemented, easy to verify, asymmetric, and compact. The
architecture's semantics do not depend on Ed25519 specifically;
the reference implementation's HMAC-SHA256 variation, discussed in
Section 10.3, demonstrates that.
Why not COSE/CBOR instead of JSON?
A reasonable future optimization. JSON keeps the reference
implementation and the objects in Section 8 readable and easy to
inspect. A production profile could use CBOR, COSE, protobuf,
compact binary, or OS-native IPC structures; the core requirement
is deterministic binding and interoperable semantics, not JSON
specifically.
How large are the objects, and what is the throughput?
The reference implementation prioritizes readability over compact
wire size and has not measured production throughput. A
production profile would need to measure object sizes and evaluate
Das Expires 12 March 2027 [Page 46]
Internet-Draft Access-Not-Egress September 2026
compact encodings, and measure releases per second, multi-core
scaling, concurrent sessions, and persistent-state overhead; see
Section 10.6. No wire-size or throughput claim is made by this
document.
Can this scale to millions of mobile devices?
The architecture is distributable because PED and sink roles can
run locally on each device or endpoint, but the reference
implementation does not demonstrate millions of users, cloud-scale
policy distribution, large fleet key rotation, or large-scale
revocation. Those remain open deployment questions.
Why is this an IETF problem instead of an Android, Apple, or W3C
problem — isn't blocking an SDK from reading a host app's data
just local OS sandboxing, like Android runtime permissions or iOS
App Tracking Transparency?
A fair question, and local sandboxing is a real and useful
control, but it does not cover this profile's actual scope.
Sandboxing governs one boundary: whether a process may read a
provider. This profile governs a cross-boundary problem: the
application, the edge API gateway or enterprise proxy the payload
transits, and the cloud AI agent or service that ultimately
receives it are commonly operated by different vendors with no
shared sandboxing authority over one another. No single OS
vendor's local permission model can bind what an enterprise
firewall or a cloud-side proxy independently verifies about an
already-departed payload. What this document defines — a semantic
JSON contract in Section 8 for the Candidate Act, precision
authority, and sink verification — is what lets a gateway or proxy
under a different administrative authority than the device
confirm, on its own, whether a mobile device's outbound payload
matches the data-minimization ceiling it was actually authorized
for. That interoperable semantics layer, spanning application,
agent, OS, enterprise gateway, cloud service, API gateway, and
network service — Candidate Act representation, precision
authority, recipient and destination binding, evidence references,
replay semantics, sink identity, and failure semantics — is the
IETF-relevant part. Operating-system enforcement itself may
remain platform-specific.
Does this require a new transport protocol?
No. As stated in Section 8, the semantic objects may be
transported over existing protected mechanisms such as local IPC,
OS APIs, HTTPS, or enterprise agents. A future standard may
define bindings rather than a new transport.
Das Expires 12 March 2027 [Page 47]
Internet-Draft Access-Not-Egress September 2026
Does this require an IANA registry?
This document currently requests no IANA action; see Section 15.
The precision-class names and EF-xxx identifiers are illustrative.
A later revision could propose registries if interoperability
requires them.
How is this different from application consent?
Consent can be one policy input. This architecture addresses
technical enforcement after the consent or policy decision:
consent feeds policy input, which feeds the PED, which issues
finality authority, which the sink verifies. Consent alone does
not inspect the actual outbound payload.
How does this work with GDPR or other laws?
The protocol is jurisdiction-neutral and does not determine legal
requirements. A policy engine may produce different results under
EU, Indian, US, or enterprise policy; the protocol's role is to
make the selected result enforceable at the point of release; see
Section 14.
Isn't recipient jurisdiction difficult to determine?
Yes, and this is a real deployment challenge. Possible approaches
include authoritative service metadata, enterprise configuration,
cloud-region declarations, and verified processor identities.
This document does not define universal jurisdiction discovery.
What proves non-bypassability?
Not the reference implementation described in Section 10. Actual
non-bypassability requires system integration showing that every
consequence-bearing egress path is controlled — for example OS
broker enforcement, kernel networking restrictions, browser engine
enforcement, enterprise gateway enforcement, or TEE/DPU
integration. This is one of the most important production
validation requirements and remains open; see Section 10.6 and
Section 12.4.
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
Das Expires 12 March 2027 [Page 48]
Internet-Draft Access-Not-Egress September 2026
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.
Author's Address
Sangam Das
Independent Inventor
Balasore 756001
Odisha
India
Email: info@sangamdas.com
Das Expires 12 March 2027 [Page 49]