Independent Inventor

Balasore Odisha 756001 India info@sangamdas.com

Security location privacy data minimization egress execution finality 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.

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 and discussed for general AI interoperability in : 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 , and the attack discussed in ) is a specific instance of a broader problem: an agentic tool call that decides to forward local data to a foreign provider is itself a Candidate Act, whether the data is location or another protected value. The general binding of execution finality to tool-call dispatch — covering tool_use/computer-use style interfaces, function-calling interfaces, and MCP tool invocation — is specified separately in . 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.

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

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.

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 .

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 . European data-protection guidance treats the same idea as data minimisation and protection by default . 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 . 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.

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.

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.

W3C Geolocation and Permission Policy The W3C Geolocation API and related permission policy give a web origin a location reading after user permission . 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.

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.

Path-Level Privacy Controls Oblivious endpoints, MASQUE-based proxying, and private relay services can hide the client's network location from a destination . They do not bind the precision of application payload fields that already contain coordinates. Path privacy and payload-precision finality are complementary.

What This Profile Adds

• precision as an authorization dimension, not only as a provider configuration;
• 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.

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.

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.

Precision-Bounded Egress Profile

Precision Ladder Implementations SHOULD be able to distinguish at least the following authorized-precision classes:

• EXACT
• METER_10
• METER_100
• GRID
• GEOHASH
• 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.

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:

Class	Illustrative quantization
EXACT	Unrounded WGS84 latitude/longitude as measured, full available decimal precision.
METER_10	WGS84 latitude/longitude rounded to the grid cell implied by approximately 4 decimal places (~11 m at the equator), or an equivalent fixed-size local-tangent-plane grid.
METER_100	WGS84 latitude/longitude rounded to the grid cell implied by approximately 3 decimal places (~111 m at the equator); latitude-dependent longitude scale error MUST be accounted for above roughly 60 degrees latitude.
GRID	Snapped to a fixed-size equal-area or equal-angle cell (for example a 1 km reference grid); the released value is the cell identifier or cell centroid, not the original coordinate.
GEOHASH	A geohash string truncated to a fixed prefix length agreed by policy — for example a 5-character prefix (~4.9 km x 4.9 km cell) or a 7-character prefix (~153 m x 153 m cell); the sink MUST treat the released prefix length, not the underlying coordinate, as the authorized ceiling.
CITY	A locality name resolved from a fixed, versioned gazetteer reference, with no coordinate field present in the payload.
REGION	A first-level administrative division (state, province, or equivalent) from the same gazetteer reference, with no locality or coordinate field present.
COUNTRY	An ISO 3166-1 country code, with no finer administrative, locality, or coordinate field present.

Two implementation requirements follow regardless of which specific quantization a deployment adopts. First, the released payload MUST contain only the fields implied by the authorized class — a CITY release MUST NOT carry a latitude or longitude field alongside the city name, and a GEOHASH release MUST NOT carry a longer prefix than the authorized length. Second, the quantization boundary itself SHOULD be deterministic and independent of the exact input value's position within a cell, so that repeated exact fixes within the same cell do not leak finer information through boundary-crossing timing; this document does not specify a boundary-crossing mitigation and treats it as a documented residual risk consistent with .

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.

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.

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.

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.

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.

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.

LocationReleaseCandidate Object

Precision Decision Object

EgressFinalityAuthority Object

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.

Precision-Mismatch Denial

Complete Exact-to-Coarse Transaction

Cumulative Disclosure Extension

Protocol Operation

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.

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:

• 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 . This document does not claim that any implementation, including the reference implementation in , currently closes every vector listed above; see and for the corresponding limitations and attacks.

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.

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.

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.

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

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 .

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.

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 .

Measured Performance A 5,000-iteration benchmark of the Ed25519 configuration on the environment described in produced the following combined PED-plus-sink local processing latency: 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 , is a stronger consideration than microbenchmark speed alone. For a local, bounded, already-policy-resolved, short-lived, hot-path egress decision as described in , 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 . 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.

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 ;
• 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 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 as claims broader than what was actually measured.

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 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 — execution finality for AI-native 5G/6G and O-RAN control
• draft-das-6g-query-scoped-communication-handles — query-scoped communication authority for 6G signaling
• draft-das-map-discovery-communication-finality — execution finality applied to discovery/MAP-layer communication
• draft-das-rats-attestation-bnd-execution-finality — attestation-bound execution finality under RATS
• 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: Why We Should Treat Our GPS Coordinates More than Our Personal Data for Privacy and Security (EU AI Alliance Futurium)

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 , and explicit non-goals, is given in .

Threat Model This section states the security objective in attacker terms, identifies protected assets and trust boundaries, walks through the attacks each binding in is intended to defeat, and lists explicit non-goals. It expands on rather than replacing it.

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 be assumed by an implementation.

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 .

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 . PED -> Protected Evidence | | | | | v | | Scoped Finality Authority | +--------|-------------------------------------------+ v +--------------------------------------------------+ | Egress Finality Sink | | verifies authority, payload, precision, fields, | | destination, jurisdiction, replay state | +--------|-------------------------------------------+ v ================ TRUST BOUNDARY ==================== v External network / cloud / SDK / API / AI provider ]]> Trusted components are the PED, the Finality Sink, protected state, and the authority-verification key. Potentially untrusted components are the application, an embedded SDK, an AI agent, an analytics component, an advertising library, browser content, the cloud destination, and the network path.

Attacker Classes and Attacks

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.

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

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 .

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

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 .

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.

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.

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 (), does not solve this. Higher-assurance deployments are expected to use a hardware monotonic counter, sealed state, a TPM-backed counter, TEE-protected state, an authenticated remote witness, or an append-only protected log.

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.

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

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.

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.

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 rather than left to per-release evaluation alone.

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.

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.

Non-Goals This profile, and the reference implementation described in , 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.

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 is itself a weaponization risk, not only a mitigation. By construction it aggregates release timestamps, destinations, and precision history across a policy window for a subject scope; a state object built for that purpose is functionally a mobility log, and if it is exposed, exported, or made available to any party other than the PED that consumes it, it recreates the exact movement-history exposure that cumulative-disclosure evaluation exists to prevent, with the additional property that it is pre-aggregated and therefore cheaper to exploit than reconstructing history from individual releases. An implementation MUST NOT treat the cumulative-disclosure state as a general-purpose audit log, analytics source, or export object. Concretely:

• 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 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 ), the persistence mechanism is subject to the same rollback and tamper concerns as consumption state, discussed in , 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 . 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 .

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.

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.

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 . This section is informational and does not define licensing terms.

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.

Normative References Informative References 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. W3C ENISA European Commission Policy context only. This document does not specify EU law. NATO Strategic Communications Centre of Excellence

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 .

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 .

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 . This profile instead forces a precision ceiling that is cryptographically bound to a non-bearer authority token issued for that specific Candidate Act (, ): 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 — Candidate Act, Non-Effective State, protected validation, protected evidence, scoped 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 . 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 .

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 . 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 ; this profile does not require replacing it.

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 .

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 .

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 .

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

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 .

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.

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 .

Doesn't fail-closed create denial-of-service risk?

Yes; that is a fundamental tradeoff discussed in . 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 .

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 .

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 , demonstrates that.

Why not COSE/CBOR instead of JSON?

A reasonable future optimization. JSON keeps the reference implementation and the objects in 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 compact encodings, and measure releases per second, multi-core scaling, concurrent sessions, and persistent-state overhead; see . 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 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 , 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.

Does this require an IANA registry?

This document currently requests no IANA action; see . 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 .

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

A reviewer evaluating this document is expected to ask, at minimum: what exact interoperability problem requires standardization; which elements are protocol semantics versus implementation policy; the precise definition of "precision" and the canonical representation used for hashing; how a sink determines observed payload precision; how encrypted payloads are handled; how the architecture handles alternative egress paths; what "non-bearer authority" means operationally; which state must be protected versus cached; how keys are provisioned and rotated; how replay is prevented across multiple sinks; how single-use authority is consumed atomically; failure behavior during network partitions; latency, throughput, and object-size overhead; why existing OAuth, OS permission, or DLP mechanisms cannot carry the same information; what belongs at IETF versus W3C, 3GPP, O-RAN, a platform vendor, or enterprise DLP; and what minimum subset is actually required for interoperable deployment. This appendix and the sections it cross-references are intended to answer these precisely rather than by assertion. The position of this document is not that existing location permissions are insecure and must be replaced. It is that existing permission, consent, transformation, relay, authorization, and privacy mechanisms remain in place as policy inputs, and that this profile adds a later consequence-control step in which a proposed outbound disclosure remains non-effective until act-specific precision authority is bound to recipient, destination, jurisdiction, policy state, and sink identity, and the actual outbound representation is independently checked immediately before release. This framing is intended to make the architecture complementary to existing standards rather than competitive with them.