Access Is Not Egress: Precision-Bounded Location Release

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

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

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

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

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

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

local exact location remains inside protected domain
                    |
                    v
     LOCATION-RELEASE CANDIDATE ACT
                    |
                    v
            Non-Effective State
                    |
                    v
     Protected Enforcement Domain
        purpose, requester, component
        recipient, destination, jurisdiction
        required precision, user authorization
        policy/revocation epochs
        cumulative disclosure, sink identity
                    |
                    v
     protected evidence + scoped authority
                    |
                    v
           Egress Finality Sink
                    |
     +-- exact representation permitted
     +-- transformed representation permitted
     `-- release denied

PED approval alone MUST NOT release data. The sink MUST prevent effectuation on verification failure. A warning or audit record is not sufficient.¶

7. Precision-Bounded Egress Profile

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

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "urn:ietf:params:json-schema:precision-egress:location-candidate:1",
  "title": "LocationReleaseCandidate",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "version", "object_type", "candidate_act_id", "act_type",
    "created_at", "expires_at", "requester", "purpose",
    "source_data", "requested_release", "destination",
    "policy_state", "freshness", "finality_sink"
  ],
  "properties": {
    "version": { "type": "string", "const": "1.0" },
    "object_type": {
      "type": "string",
      "const": "location_release_candidate"
    },
    "candidate_act_id": { "type": "string", "minLength": 16 },
    "act_type": { "type": "string", "const": "LOCATION_RELEASE" },
    "created_at": { "type": "string", "format": "date-time" },
    "expires_at": { "type": "string", "format": "date-time" },
    "requester": {
      "type": "object",
      "required": ["application_id"],
      "properties": {
        "application_id": { "type": "string" },
        "component_id": { "type": "string" },
        "component_type": {
          "type": "string",
          "enum": [
            "APPLICATION", "SDK", "AI_AGENT", "ANALYTICS",
            "ADVERTISING", "BROWSER", "CLOUD_SERVICE",
            "SYSTEM_SERVICE", "OTHER"
          ]
        }
      }
    },
    "purpose": {
      "type": "object",
      "required": ["purpose_id", "declared_purpose"],
      "properties": {
        "purpose_id": { "type": "string" },
        "declared_purpose": { "type": "string" },
        "purpose_epoch": { "type": "integer", "minimum": 0 },
        "user_intent_reference": { "type": "string" }
      }
    },
    "source_data": {
      "type": "object",
      "required": ["data_class", "available_precision"],
      "properties": {
        "data_class": {
          "type": "string",
          "enum": [
            "LOCATION", "MOBILITY_TRACE",
            "PROXIMITY", "SENSOR_DERIVED_LOCATION"
          ]
        },
        "available_precision": {
          "type": "string",
          "enum": [
            "EXACT", "METER_10", "METER_100", "GRID",
            "GEOHASH", "CITY", "REGION", "COUNTRY"
          ]
        },
        "local_only": { "type": "boolean" },
        "source_reference": { "type": "string" }
      }
    },
    "requested_release": {
      "type": "object",
      "required": ["requested_precision", "fields"],
      "properties": {
        "requested_precision": {
          "type": "string",
          "enum": [
            "EXACT", "METER_10", "METER_100", "GRID",
            "GEOHASH", "CITY", "REGION", "COUNTRY", "NONE"
          ]
        },
        "fields": { "type": "array", "items": { "type": "string" } },
        "retention_seconds": { "type": "integer", "minimum": 0 },
        "continuous": { "type": "boolean" }
      }
    },
    "destination": {
      "type": "object",
      "required": ["destination_id", "jurisdiction"],
      "properties": {
        "destination_id": { "type": "string" },
        "endpoint": { "type": "string" },
        "recipient_id": { "type": "string" },
        "processor_type": {
          "type": "string",
          "enum": [
            "FIRST_PARTY", "PROCESSOR", "SDK_VENDOR",
            "AI_PROVIDER", "ANALYTICS", "AD_NETWORK",
            "PUBLIC_AUTHORITY", "OTHER"
          ]
        },
        "jurisdiction": { "type": "string" },
        "cloud_region": { "type": "string" }
      }
    },
    "cumulative_disclosure": {
      "type": "object",
      "properties": {
        "window_seconds": { "type": "integer", "minimum": 0 },
        "prior_release_count": { "type": "integer", "minimum": 0 },
        "prior_precision_max": { "type": "string" },
        "movement_history_risk": {
          "type": "string",
          "enum": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
        }
      }
    },
    "policy_state": {
      "type": "object",
      "required": ["policy_epoch", "revocation_epoch"],
      "properties": {
        "policy_epoch": { "type": "integer", "minimum": 0 },
        "authority_epoch": { "type": "integer", "minimum": 0 },
        "revocation_epoch": { "type": "integer", "minimum": 0 },
        "policy_profile_id": { "type": "string" },
        "regulatory_profile_id": { "type": "string" }
      }
    },
    "freshness": {
      "type": "object",
      "required": ["nonce"],
      "properties": {
        "nonce": { "type": "string", "minLength": 16 },
        "sequence": { "type": "integer", "minimum": 0 },
        "session_id": { "type": "string" }
      }
    },
    "finality_sink": {
      "type": "object",
      "required": ["sink_id", "sink_type"],
      "properties": {
        "sink_id": { "type": "string" },
        "sink_type": {
          "type": "string",
          "enum": [
            "NETWORK_EGRESS", "OS_DATA_BROKER", "BROWSER_UPLOAD",
            "API_GATEWAY", "CLOUD_SYNC", "TELEMETRY",
            "ANALYTICS_SDK", "AD_SDK", "FILE_EXPORT",
            "DATABASE_EXPORT", "OTHER"
          ]
        }
      }
    }
  }
}

{
  "version": "1.0",
  "object_type": "precision_policy_decision",
  "decision_id": "ppd-cf0c49",
  "candidate_act_id": "loc-5c8238a4",
  "decision": "ALLOW_WITH_TRANSFORMATION",
  "requested_precision": "EXACT",
  "authorized_precision": "CITY",
  "transformation": {
    "type": "PRECISION_REDUCTION",
    "method": "CITY_LABEL",
    "parameters": {
      "country_code": "IN",
      "region": "Odisha",
      "city": "Balasore"
    }
  },
  "validated_predicates": {
    "application_valid": true,
    "component_valid": true,
    "purpose_valid": true,
    "exact_precision_necessary": false,
    "destination_valid": true,
    "recipient_valid": true,
    "jurisdiction_valid": true,
    "user_authorization_valid": true,
    "policy_epoch_valid": true,
    "revocation_state_valid": true,
    "cumulative_disclosure_acceptable": true,
    "sink_binding_valid": true
  },
  "reason_codes": [
    "MINIMIZATION_REQUIRED",
    "EXACT_PRECISION_NOT_NECESSARY"
  ]
}

{
  "version": "1.0",
  "object_type": "egress_finality_authority",
  "authority_id": "efa-e71ad531",
  "candidate_act_id": "loc-5c8238a4",
  "decision_id": "ppd-cf0c49",
  "evidence_id": "pve-location-332",
  "scope": {
    "data_class": "LOCATION",
    "authorized_precision": "CITY",
    "permitted_fields": ["city", "region", "country"],
    "recipient_id": "weather-provider",
    "destination_id": "weather.example",
    "jurisdiction": "IN",
    "retention_seconds_max": 3600
  },
  "binding": {
    "candidate_act_digest": {
      "algorithm": "SHA-256",
      "value": "base64url-location-act-digest"
    },
    "nonce": "B21C9924FF77A183",
    "policy_epoch": 42,
    "authority_epoch": 11,
    "revocation_epoch": 7,
    "finality_sink_id": "egress-sink-01",
    "protected_state_reference": "ped-location-state-91"
  },
  "lifetime": {
    "issued_at": "2026-08-26T17:45:01Z",
    "expires_at": "2026-08-26T17:45:10Z",
    "single_use": true
  },
  "issuer": {
    "ped_id": "ped-device-01",
    "key_id": "ped-key-location-2",
    "signature": "base64url-signature"
  }
}

{
  "operation": "EgressSinkVerify",
  "request_id": "egress-req-771",
  "candidate_act_id": "loc-5c8238a4",
  "authority_id": "efa-e71ad531",
  "sink": {
    "sink_id": "egress-sink-01",
    "sink_type": "NETWORK_EGRESS"
  },
  "outbound_payload": {
    "content_type": "application/json",
    "data_class": "LOCATION",
    "declared_precision": "CITY",
    "fields": {
      "city": "Balasore",
      "region": "Odisha",
      "country": "IN"
    },
    "payload_digest": {
      "algorithm": "SHA-256",
      "value": "base64url-payload-digest"
    }
  },
  "destination": {
    "destination_id": "weather.example",
    "endpoint": "https://weather.example/forecast",
    "recipient_id": "weather-provider",
    "jurisdiction": "IN"
  },
  "freshness": { "nonce": "B21C9924FF77A183" }
}

{
  "operation": "EgressSinkVerify",
  "request_id": "egress-req-771",
  "decision": "ALLOW",
  "verification": {
    "authority_signature": "VALID",
    "candidate_act_binding": "MATCH",
    "data_class": "MATCH",
    "payload_precision": "CITY_WITHIN_AUTHORIZED_CEILING",
    "field_scope": "MATCH",
    "recipient": "MATCH",
    "destination": "MATCH",
    "jurisdiction": "MATCH",
    "policy_epoch": "CURRENT",
    "revocation_epoch": "CURRENT",
    "nonce": "FRESH",
    "consumption_state": "UNUSED",
    "sink_binding": "MATCH"
  },
  "consumption": {
    "authority_id": "efa-e71ad531",
    "status": "CONSUMED",
    "consumed_at": "2026-08-26T17:45:02Z"
  },
  "release": {
    "permitted": true,
    "released_precision": "CITY",
    "release_id": "release-881"
  }
}

{
  "operation": "EgressSinkVerify",
  "request_id": "egress-req-772",
  "decision": "DENY",
  "error": {
    "code": "EF_PRECISION_MISMATCH",
    "message": "Outbound payload exceeds authorized precision.",
    "retryable": false
  },
  "verification": {
    "authority_signature": "VALID",
    "authorized_precision": "CITY",
    "observed_payload_precision": "EXACT",
    "destination": "MATCH",
    "jurisdiction": "MATCH",
    "sink_binding": "MATCH"
  },
  "release": { "permitted": false }
}

{
  "step_1_local_state": {
    "available_location": {
      "latitude": 21.494321,
      "longitude": 86.932145,
      "accuracy_meters": 4.2
    },
    "external_effect": "NONE"
  },
  "step_2_candidate_act": {
    "candidate_act_id": "loc-5c8238a4",
    "requester": {
      "application_id": "weather-app",
      "component_id": "forecast-module",
      "component_type": "APPLICATION"
    },
    "purpose": {
      "purpose_id": "local-weather",
      "declared_purpose": "Provide weather for the user's area"
    },
    "requested_release": {
      "requested_precision": "EXACT",
      "fields": ["latitude", "longitude"]
    },
    "destination": {
      "destination_id": "weather.example",
      "recipient_id": "weather-provider",
      "jurisdiction": "IN"
    }
  },
  "step_3_ped_decision": {
    "decision": "ALLOW_WITH_TRANSFORMATION",
    "authorized_precision": "CITY",
    "reason": "Exact coordinates are not necessary."
  },
  "step_4_authorized_payload": {
    "city": "Balasore",
    "region": "Odisha",
    "country": "IN"
  },
  "step_5_sink_verification": {
    "decision": "ALLOW",
    "exact_coordinates_released": false,
    "authority_consumed": true
  }
}

{
  "cumulative_disclosure": {
    "subject_scope": "device-local-pseudonymous-subject",
    "window_seconds": 86400,
    "prior_release_count": 144,
    "prior_precision_max": "METER_100",
    "distinct_destinations": 6,
    "movement_history_risk": "HIGH",
    "policy_action": "DOWNGRADE_TO_REGION"
  }
}

9. Protocol Operation

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

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)

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

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

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

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

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

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?

There is overlap. The narrower contribution is the protocol-oriented sequence in Section 6: Candidate Act, Non-Effective State, protected validation, protected evidence, scoped authority, sink verification, and effect. 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.¶

Is this basically OAuth?

OAuth authorizes access to resources and APIs. Execution finality addresses a later step: the client already has access, a specific data release is generated, and the question is whether this exact release should be allowed to become effective. OAuth authorization can be one PED input; 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 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?

Yes, if the sink is placed too late, and that is a deployment failure. The enforcement point MUST be before untrusted encryption, or encryption MUST occur inside the trusted enforcement boundary; see Section 12.4.¶

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

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 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 or Apple problem?

A fair question. The potentially IETF-relevant part is interoperable semantics among 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. 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.¶

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