| Internet-Draft | Privacy-by-Design Map Reachability | September 2026 |
| Das | Expires 5 March 2027 | [Page] |
Map-based discovery systems can help a person identify nearby businesses, properties, service providers, hotels, clinics, restaurants, and other commercial actors, but discovery frequently transitions into communication through a persistent telephone number, reusable virtual number, open message thread, callback route, or other contact path. A person may intend only a short first conversation with several candidates, while the communication mechanism unintentionally creates continuing reachability after that inquiry has ended.¶
This document describes an architecture in which first contact and future reachability are separate authorization events. After a user creates a map search, property inquiry, service request, booking inquiry, quote request, or similar context, a platform can create a query-scoped non-bearer communication reference and bounded preview authority. A user or eligible business can participate in a real but limited first interaction. Continued communication is separately authorized and remains bound to attributes such as the original query, business identity, purpose, channel, effect, validity window, nonce, quota, revocation state, and enforcement point. Possession of a number, handle, previous conversation, lead assignment, API credential, or payment event is not by itself sufficient future-contact authority.¶
The architecture separates marketplace policy from communication effectuation. A Communication Authority Service creates a protected authorization binding, while an enforcement point reconstructs the actual attempted communication, checks current protected state, atomically reserves or consumes relevant authority, and releases the communication-bearing resource only after successful verification. This permits privacy-preserving first contact, controlled future reachability, preview-qualified lead monetization, and AI-assisted business discovery without requiring a new public telecom protocol for initial deployment. Google Maps and Apple Maps are used as recognizable illustrative examples; no affiliation, endorsement, implementation, adoption, or technical alignment by Google, Apple, or any other named provider is implied.¶
The architecture's binding of recipient identifiers to pseudonymous, query-scoped, time-limited, purpose-bound, and revocable authorizations rather than persistent contact data is consistent with the data protection principles of the EU General Data Protection Regulation (GDPR) -- including data minimization and purpose limitation (Article 5), storage limitation through bounded validity and quota, and privacy by design and by default (Article 25). This document describes a technical architecture only; it does not constitute a legal compliance determination, and conformance with GDPR or any other data protection law depends on the specific deployment, controller and processor roles, and operational practices of an implementing platform.¶
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 5 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Map and local-search systems are effective discovery mechanisms, but the transition from discovery to communication exposes a separate architectural problem. A user may wish to talk briefly with several candidate businesses or property agents before choosing one. The first conversation is useful precisely because neither side yet knows whether the relationship should continue.¶
Conventional communication mechanisms often collapse those two stages. Once a real number, masked number, virtual number, message thread, callback route, email alias, or other communication identifier is made usable, possession or persistence of that identifier can create a longer-lived contact path than the user intended.¶
The central architectural principle of this document is:¶
First contact is communication; it is not permanent reachability.¶
The corresponding protocol principle is:¶
Identifier possession, prior contact, lead assignment, payment, or application approval is not by itself authority for a later communication effect.¶
The design therefore separates discovery, marketplace decision-making, authority creation, protected state, verification of the actual attempted communication, and final allocation of the communication-bearing resource.¶
Google Maps, Google Business Profile, Google Local Services, Apple Maps, Apple Business Connect, Android, iOS, Siri, Gemini, and other named platforms or services are referenced only as recognizable examples that make the architecture easier to understand. No affiliation with, endorsement by, implementation by, adoption by, evaluation by, or technical alignment with those providers is implied. The architecture is provider-neutral.¶
This document is a companion to [I-D.das-6g-query-scoped-communication-handles], which defines the underlying query-scoped, non-bearer communication-authority (CVID) architecture in transport- and provider-neutral terms; this document applies that architecture specifically to map-based and local-search business discovery. An earlier community-facing treatment of the spam-resistance rationale for this architecture in the context of AI-native map-based discovery and 6G-era communication systems was submitted to the European Commission's AI Alliance community platform [EU-AI-ALLIANCE-SPAM-ARCH].¶
This document is an Informational problem-space and architecture document. It does not define a registered SIP header, a new OAuth token type, a new EAT claim, a new WebRTC or TURN extension, a CPaaS API standard, a telecom routing standard, or an IANA registry.¶
The document focuses on communication paths that are intentionally placed under the described enforcement architecture. It does not claim that a user becomes unreachable through every possible alternate channel. If a business also possesses an ordinary E.164 number, email address, social-media account, or another independent route to the user, that alternate route is outside the protected-path guarantee unless it is also brought under equivalent enforcement. The precise invariant is: no valid current authority means no protected communication effect through the governed path.¶
The architecture does not replace identity, authentication, SIP, STIR, OAuth, DPoP, RATS, WebRTC, TURN, CPaaS, spam filtering, fraud detection, user consent interfaces, marketplace policy, or legal and regulatory compliance processes. It describes a final communication-authority layer that can consume inputs from those mechanisms and make them load-bearing at the controlled effect boundary.¶
This document also does not require any particular lead-pricing model. Business-side payment, bid, credit, subscription, escrow, or other commercial state can be an input to future-contact authorization, but payment is not itself communication authority. User-side monetization in this document means monetization of booking, transaction, premium-service, subscription, or other user-side platform services. It does not assert a mechanism that pays or revenue-shares with the user merely for accepting communication.¶
Emergency calling, lawful-intercept architecture, emergency-service routing, and mandatory public-safety reachability are outside the scope of this document and would require separate treatment.¶
A user may search for a house for sale or rent near the user's current location and speak briefly with several property agents. The user's intent may be limited: determine availability, rent or sale price, viewing time, location suitability, deposit, or other basic details, and then choose which property to pursue.¶
Once a permanent number or reusable communication path is disclosed, the first conversation can unintentionally become an ongoing relationship. The business may retain the number, the lead may move into a CRM, an employee may copy it, a call center may receive it, an affiliate may obtain it, or the database may later be breached.¶
Masked and virtual numbers are useful because they can hide a user's underlying identifier. The remaining problem is whether possession of an active masked identifier is itself enough to continue attempting communication. Hiding the permanent identifier does not automatically make the temporary identifier non-bearer.¶
This document treats the visible communication handle as a context reference, not as final authority. The handle can tell an enforcement system which protected context to evaluate without granting unrestricted reachability to anyone who copies or retains it.¶
A conventional lead can be stale, duplicated, outside the service area, low-intent, fraudulent, accidental, commercially unsuitable, or distributed to many competitors. A business can therefore pay before it has enough information to know whether the lead is useful.¶
A bounded first interaction permits the business to learn whether the inquiry is genuine and relevant before requesting or paying for extended communication. This creates a different economic unit: preview-qualified reachability rather than raw contact data.¶
AI assistants can search maps, compare listings, draft messages, initiate calls, make bookings, or invoke communication APIs. Tool access alone should not silently create an unlimited communication relationship. The architecture therefore separates an agent's ability to request a communication tool from authority for the resulting communication effect to become effective.¶
Direct numbers, virtual numbers, aliases, and callback routes can provide useful privacy or routing functions. They do not necessarily bind every later use to the original query, business, purpose, channel, effect, quota, revocation state, and enforcement point.¶
Lead-management systems can decide which business receives a lead, how the lead is priced, and which account owns it. Those decisions are not identical to a protocol-level decision about whether a particular later call, message, or notification may become effective at a protected communication boundary.¶
Spam filtering and reputation systems can classify or block unwanted communications. Their question is commonly whether an incoming communication appears suspicious or unwanted. The narrower question here is whether the actor has current authority to create the protected communication effect at all.¶
Bearer tokens intentionally confer use rights through possession while valid. The architecture in this document instead binds communication authority to an attempted act and current protected state. A copied visible handle, prior lead record, or general API credential is insufficient by itself.¶
A database can store agent_d1_allowed = true. If the calling application interprets that flag and directly invokes a CPaaS API that allocates the communication resource, the application remains the final enforcement point. That is ordinary application policy.¶
A design satisfies the communication-finality property described here only when the component capable of creating the protected external communication effect is structurally downstream of the verification decision. The Candidate Communication Act remains non-effective; the enforcement point reconstructs or verifies the attempted act; current protected state is checked and, where required, atomically reserved or consumed; and only then is the communication-bearing resource released.¶
If the application can bypass the decision through an equivalent protected path, if replay can recreate consumed authority, if a stale state replica can re-enable exhausted authority, or if the resource allocator can ignore a failed verification, the design has reduced to a policy gate and does not provide the stronger property claimed by this document.¶
| Mechanism | Primary Function | Remaining Question |
|---|---|---|
| Masked or virtual number | Hide or relay an identifier | Does possession still permit later reachability? |
| Lead-management policy | Assign and price a lead | Can this specific later communication effect occur now? |
| Spam or reputation control | Classify unwanted traffic | Was authority absent before user-facing effect? |
| OAuth or API authorization | Authorize use of a protected API/resource | Does API access imply this communication consequence? |
| This document | Gate protected communication effect at the finality boundary | Does the actual attempted act match current bounded authority and state? |
The architecture separates discovery, marketplace policy, authority issuance, verification, protected state, and external communication effect.¶
User / Map Inquiry
|
v
Map or Discovery Platform
|
| query context / eligibility / selection
v
Communication Authority Service
|
| bounded preview or future authority
v
Candidate Communication Act
|
| remains non-effective
v
Communication Enforcement Point
|
| reconstruct actual attempt
| verify scope and protected state
| atomically reserve / consume
v
Bounded Release Capability
|
+---- invalid ----> DENY / NO PROTECTED EFFECT
|
+---- valid ------> ALLOCATE BOUNDED RESOURCE
C can construct a canonical Communication Scope Descriptor instead of issuing a vague instruction such as "Business D1 may contact User A". An illustrative representation is:¶
CommunicationScopeDescriptor: inquiry_id query_context_id user_binding communication_handle_id requesting_actor_id business_identity authorized_business_group communication_phase = PREVIEW | FUTURE direction channel purpose permitted_effect validity_start validity_end nonce_or_freshness_value quota revocation_epoch policy_epoch commercial_state [when applicable] selected_business_state [when applicable] enforcement_point_id enforcement_point_key_ref [when applicable] device_or_platform_binding [when applicable]¶
The descriptor can be canonically encoded and committed to by a signature, MAC, protected database record, sealed object, or another deployment-appropriate integrity mechanism. The essential property is that authorization for one materially defined communication scope does not silently authorize a different scope.¶
Preview Authority permits a bounded first interaction. It can allow one short call, a limited message count, a short WebRTC session, a callback, or another bounded effect. The preview can be initiated by the user or, after the user creates an inquiry, by an eligible business under an applicable platform rule.¶
Future-Contact Authority is distinct. Some deployments can require explicit user selection, shortlisting, booking, callback approval, quote acceptance, appointment confirmation, or another user-side event. Other deployments can allow the original user inquiry to establish a platform rule under which an eligible business can request bounded continuation after satisfying defined commercial or qualification conditions. In either case, payment or business preference is an input to issuance, not self-executing communication authority.¶
When D attempts communication, E can reconstruct an Attempt Descriptor from observed or trusted signaling information. The attempt can include the actual business identity, query context, handle, direction, channel, requested effect, nonce, and enforcement point.¶
AttemptDescriptor: observed_query_context observed_business_identity observed_handle observed_direction observed_channel observed_effect observed_nonce observed_enforcement_point AttemptHash = HASH(CanonicalEncode(AttemptDescriptor))¶
E compares the actual attempted act with the protected authorized scope. A request for a preview voice call cannot silently become authority for an unlimited future call, a different property, a marketing message, or a different business identity.¶
Some authorization properties are inherently stateful. E or a protected verifier can check nonce state, quota, counter, revocation epoch, policy epoch, selected-business state, query state, business binding, and consumed-authority state.¶
Where a single-use or quota-bound authority is involved, the state transition must be ordered so that concurrent attempts cannot both consume the same remaining authority. A production implementation therefore needs atomic reservation or consumption before protected effectuation, plus defined crash-recovery and uncertain-outcome semantics.¶
Successful verification can produce a short-lived Bounded Release Capability scoped to the exact communication resource or effect. It can be consumed by an SBC, SIP gateway, WebRTC service, TURN relay, messaging service, push gateway, CPaaS service, marketplace communication server, operating-system broker, or another controlled allocator.¶
The capability is not intended to become a new general-purpose bearer token. It is the downstream consequence of successful act-specific verification and protected-state transition.¶
The key transition is Non-Effective to Effective. A request can be parsed, routed internally, authenticated, priced, and evaluated while the user-facing protected effect remains unavailable. Only after E verifies the current authority and required protected state is the protected call bridge, session, relay, thread, notification, or other communication resource allocated.¶
No valid current authority means no protected communication effect through the governed path.¶
Consider a user searching a map or property-discovery service for "House for sale or rent near me." The purpose of the example is to answer five implementation questions: who decides, who issues authority, who creates the protected binding, who verifies it, and who actually prevents the communication effect.¶
A is the prospective buyer or renter. B is the map or property-discovery platform. C is the Communication Authority Service. D is the property owner, broker, estate agent, or property business. E is the Communication Enforcement Point.¶
B can decide which properties to display and which agents are eligible. A can decide which properties or agents remain interesting. D can decide whether a lead is commercially worth pursuing. C converts applicable decisions into bounded machine-verifiable authority. E controls whether the real call, message, WebRTC session, callback, notification, or other protected communication resource becomes effective.¶
A searches for "2-bedroom house for rent near me." B creates Query Context Q1007 and identifies five relevant properties P1 through P5 associated with agents D1 through D5.¶
B's ranking result does not itself authorize D1 through D5 to reach A. Eligibility for discovery and authority for communication are different states.¶
D1 attempts communication using H88271. H88271 identifies the context E should evaluate; possession of H88271 is not itself sufficient authority.¶
D1 | | communication attempt v E | | HOLD NON-EFFECTIVE | verify PA1 | reconstruct actual attempt | compare attempted and authorized context | verify nonce / quota / revocation | atomically reserve or consume state | +---- FAIL ----> NO PROTECTED CALL EFFECT | +---- PASS ----> RELEASE BOUNDED PREVIEW CALL
E does not merely trust C's signature in isolation. E also verifies that the real attempted communication matches the signed or otherwise protected scope.¶
C creates the protected authorization binding. E verifies the real attempt against that binding at the communication-finality boundary. This separation prevents a platform UI decision from becoming the final technical act.¶
For example, C may authorize D1 for Q1007, P1, voice, and PREVIEW_CALL. When D1 actually calls, E independently observes or resolves the business, query, property context, channel, requested effect, nonce, and enforcement point. A change to UNLIMITED_FUTURE_CALL or to a different property produces a material mismatch.¶
After successful verification, A and D1 can speak for the bounded preview period. A may ask whether the property is still available and whether a viewing is possible. When the preview ends, E terminates or deallocates the protected preview resource.¶
D1 has now spoken with A, but D1 still does not automatically possess future reachability to A.¶
Future reachability can depend on multiple inputs. A may select P1, save it, shortlist D1, book a viewing, request a callback, confirm an appointment, accept an offer, or otherwise approve continued contact. D1 may separately determine that the inquiry is genuine and commercially useful and may satisfy a lead fee, bid, platform credit, subscription entitlement, callback-extension fee, escrow condition, or another commercial predicate.¶
Some deployments can require both a user-side event and a business-side condition. Other deployments can rely on an original user inquiry that expressly establishes a platform rule permitting a qualified business to request bounded continuation. In all cases, the architecture keeps a separate technical step between those marketplace events and actual future reachability.¶
Payment is not communication authority.¶
The next day D1 calls A about P1. E verifies that the business is D1, the query remains Q1007, the property context remains P1, the purpose remains property viewing or rental discussion, voice remains permitted, the quota remains available, and revocation state is current. If the checks succeed, E releases a bounded call. If the quota is exhausted or authority is revoked or expired, no new protected resource is released.¶
If D1 attempts to reuse FA1 to promote Property P99, the context no longer matches. If D1 transfers the lead to an external call center D6, the actual actor no longer matches unless D6 is explicitly inside the authorized delegation scope. If the original purpose was rental discussion and the new purpose is unrelated marketing, the purpose no longer matches.¶
If an attacker steals H88271 from D1's CRM, the attacker has a context reference but not necessarily the authorized business identity, current future authority, correct query and property context, valid nonce state, remaining quota, correct purpose, current revocation epoch, or correct enforcement-point binding. Handle possession is therefore not equivalent to protected reachability.¶
A searches "House for sale or rent near me"
|
v
B returns P1, P2, P3, P4, P5
|
v
A requests first contact with selected properties
|
v
C creates separate bounded preview authority
|
v
D1 attempts communication
|
v
E holds attempt NON-EFFECTIVE
|
v
E verifies actor / query / property / channel /
effect / nonce / quota / revocation / sink binding
|
+----+----+
| |
FAIL PASS
| |
v v
NO EFFECT LIMITED FIRST CONTACT
|
v
preview ends
|
v
A selection and/or applicable marketplace condition
|
v
C creates NEW future authority FA1
|
v
D1 later attempts communication
|
v
E independently verifies FA1
|
+----+----+
| |
INVALID VALID
| |
v v
NO EFFECT BOUNDED FUTURE CONTACT
The architecture creates a different economic unit for digital marketplaces. Traditional advertising and lead generation can progress from impression to click to form submission to lead. A lead remains uncertain. Preview-qualified communication moves the marketplace further down the commercial funnel.¶
LOWER COMMERCIAL SIGNAL
Advertisement impression
|
v
Listing view
|
v
Click
|
v
Lead form
|
v
Contact request
|
v
Verified first conversation
|
v
Qualified business interest
|
v
Authorized future contact
|
v
Booking / viewing / transaction
HIGHER COMMERCIAL SIGNAL
A verified first-contact opportunity can be more valuable than a raw click because both sides have started to reduce uncertainty. Possible product descriptions include Pay Per Verified Contact, Pay Per Qualified Communication, or Pay Per Authorized Continuation. These are commercial labels, not protocol primitives.¶
Consider an illustrative property agent receiving 100 conventional leads at INR 200 each. The total expenditure is INR 20,000. If only ten are commercially useful, the effective cost per useful opportunity is INR 2,000. These figures are illustrative only and do not represent market data.¶
Under a preview-qualified model, the business can participate in bounded first contact and decide which inquiries justify extended reachability. Spending can occur closer to demonstrated relevance instead of before any real interaction. The architecture can therefore reduce expenditure on stale, duplicated, low-intent, non-serviceable, irrelevant, fraud-risk, or commercially unsuitable leads.¶
After bounded first contact, a business can satisfy a fixed lead fee, bid, platform credit, subscription entitlement, verified-lead fee, callback-extension fee, booking-inquiry fee, quote-response fee, escrow condition, or another marketplace condition. The business is not necessarily buying the user's permanent contact information. It is satisfying a condition for bounded, scoped, revocable, verified continuation.¶
The user side can generate platform value through booking, reservation, payment, verified callback, premium buyer or renter assistance, transaction or escrow services, privacy services, concierge services, or subscription features. This creates a second monetization surface around the same protected relationship.¶
Two-sided marketplace monetization in this document means the platform can monetize both the business-side continuation opportunity and the user-side transaction or service journey. It does not mean that this architecture itself specifies direct payment or revenue sharing to a user for accepting communication.¶
A searches for a house to rent. Five agents participate in bounded first-contact opportunities, and A speaks with three. D1 learns that A is genuinely interested in P1. D2 learns that A's budget does not match P2 and can stop without purchasing unnecessary continuation. D3 learns that A wants a viewing and can receive future authority after the applicable booking or selection condition is satisfied.¶
The marketplace can therefore remain involved across discovery, first contact, qualification, selection, authorized continuation, viewing, booking, rental, or purchase rather than losing the relationship as soon as a raw telephone number is dialed.¶
The architecture is not limited to a user-interface feature inside a map application. The technical function occurs at the point where signaling, routing, relay, media, messaging, notification, or another communication-bearing resource is about to become usable.¶
Discovery determines who may be considered. Authorization determines what communication is permitted. The communication protocol carries or references the authorization. The enforcement point verifies the actual attempted communication. Protected state determines whether the authorization is still current and usable. Only then is the protected communication resource released.¶
COMMUNICATION REQUEST
|
v
+----------------------+
| NON-EFFECTIVE |
| no usable resource |
+----------+-----------+
|
v
verify authorization
|
v
verify actual context
|
v
check protected state
|
v
reserve / consume nonce, quota, or state
|
+---- failure ----> DENY / REMAIN NON-EFFECTIVE
|
v
bounded release decision
|
v
+----------------------+
| EFFECTIVE |
| verified scope only |
+----------+-----------+
|
v
expiry / quota / termination / revocation
|
v
DEALLOCATE / TERMINATE
SIP [RFC3261] establishes, modifies, and terminates multimedia sessions. This architecture does not replace SIP. A SIP profile could carry or reference bounded communication authority so that an SBC, proxy, or other controlled gateway can make the finality decision before releasing the protected session or media path.¶
INVITE sip:protected-reference@example.net SIP/2.0 Communication-Authority: context="Q18482"; actor="B742"; phase="preview"; effect="voice"; authz-ref="A8F31...";¶
The Communication-Authority field above is illustrative only. This document does not define or request registration of that SIP header.¶
The relevant interoperability question is how a SIP network would carry, verify, consume, reject, and propagate bounded communication authority associated with a specific attempted session while preserving SIP's existing architecture. If a generally applicable SIP extension were eventually proposed, [SIPCORE] is an obvious scope discussion point; this document does not assert working-group adoption or fit.¶
STIR identity mechanisms such as [RFC8224] help a verifier reason about the asserted identity associated with a SIP request. Identity and reachability authority are different questions. An authenticated property agent can still lack current authority for a completed or revoked property inquiry.¶
A STIR-verified identity can therefore become an input to the business-identity predicate rather than a replacement for the communication-finality decision. The relationship to current secure telephone identity work can be discussed with [STIR-WG] without implying that this architecture is already a STIR work item.¶
OAuth [RFC6749] provides delegated access to protected resources. Bearer-token usage [RFC6750] means that possession of a valid bearer token is sufficient to use the associated access right. This document intentionally does not treat the visible communication handle as a bearer capability.¶
OAuth can authorize access to the map platform's authority service or a CPaaS API, while a separate communication-finality check still determines whether the requested call or message may become effective for this recipient, under this query, for this purpose, through this channel, at this time, with this remaining quota, at this enforcement point.¶
DPoP [RFC9449] can sender-constrain OAuth tokens and provide replay-related protections. Proof of possession can establish that the presenter controls an expected key. The communication architecture additionally verifies that the requested communication effect matches the authorized effect and that current protected state still permits release.¶
Proof of possession can therefore be one predicate inside the architecture, but it is not equivalent to act-specific, stateful, pre-effectuation communication authority.¶
The same architecture can operate without SIP. A WebRTC signaling service can verify authority before room creation, media admission, recipient notification, or device wake. A TURN service can be placed downstream of the authorization decision so that relay allocation does not automatically follow possession of a communication handle.¶
WebRTC architectural context is described in [RFC8825], and TURN is specified in [RFC8656]. This document does not define new WebRTC or TURN fields.¶
For map platforms, marketplaces, and AI agents, an initial interoperable implementation can be HTTP or API based rather than carrier-native SIP. A simplified request might contain a context identifier, business identifier, handle, channel, effect, and protected authorization reference.¶
POST /communication-attempt context_id = Q18482 business_id = B742 handle = H9921 channel = voice effect = preview authorization = <protected-artifact-or-reference>¶
The CPaaS gateway can parse the request, reconstruct the attempted scope, verify authority, compare authorized and attempted scope, check nonce, quota, and revocation, reserve or consume required state, and create the communication bridge only if verification succeeds.¶
Large map-to-communication systems consist of multiple workloads: search, ranking, authorization, payment, CPaaS, and regional edge services. WIMSE work is relevant to identity and context propagation among distributed workloads. Its principal contribution to this architecture is control-plane identity: which workload is making the request. Communication finality answers a different question: which externally effective communication act may that workload ultimately cause.¶
The two concepts are complementary. Workload identity can be included in the Communication Scope Descriptor and checked at the final enforcement point. The current [WIMSE] charter is principally about workload identity across multi-system and multi-service environments; it should not be read as a SIP standardization venue.¶
For ordinary map discovery, software-based verification can be sufficient. A higher-assurance deployment can also require evidence that the expected verifier, protected keys, state mechanism, or device-side broker is running in an acceptable environment. The RATS architecture [RFC9334] provides a framework for Evidence, Verifiers, Attestation Results, and Relying Parties.¶
RATS does not replace communication authority. It can strengthen trust in the component that performs the finality decision. Attestation asks whether the enforcement environment is in an acceptable state; communication finality asks whether this specific attempted communication currently has authority to become effective.¶
A standards effort would not need to standardize map ranking, property-listing logic, lead pricing, UI design, or commercial policy. A smaller interoperability surface can focus on the authority object and its behavior at communication boundaries.¶
A profile would need to state which fields are reconstructed from the actual attempt, which fields can be trusted from an upstream authority, which identities are authenticated by existing mechanisms, and which mismatches are fatal to protected release.¶
The protocol must define when a nonce, quota, counter, or single-use authority is reserved, consumed, committed, released after failure, or poisoned after an uncertain outcome. Consuming authority only after the external effect can create races; consuming it too early without recovery rules can create unnecessary denial of service.¶
Replay of a previously consumed authority for a materially new act must fail. A transport retransmission of the same transaction, however, is not necessarily a new communication act. A protocol-specific profile therefore needs a stable transaction identity or equivalent rule so that retransmissions do not accidentally consume additional quota.¶
SIP forking creates another open design question. A profile must define whether authority applies to the fork set, to one selected downstream branch, or to some other bounded outcome. The safe property is that multiple branches must not independently turn one single-use authority into multiple effective communication consequences.¶
Interoperability can benefit from distinctions among invalid authority, expired authority, revoked authority, wrong actor, wrong context, wrong purpose, wrong channel, wrong effect, quota exhausted, replay detected, stale state, and verification unavailable. Whether these are protocol-visible error codes, structured metadata, or local-only status is left for future protocol-specific work.¶
The protocol should minimize disclosure of the user's permanent number, raw search history, exact location, full payment record, or complete marketplace state. Pseudonymous identifiers, hashes, commitments, blinded references, or selectively disclosed state can be sufficient depending on the deployment.¶
A profile must define what happens when communication is forwarded, retargeted, or delegated from a business to an employee, call center, AI agent, affiliate, or outsourced provider. Identity delegation must not silently widen the original communication scope.¶
A single user journey can begin with map search over HTTP, continue through an AI assistant, invoke a CPaaS callback, traverse SIP and RTP, and end as a device-side call or notification. The same bounded authority must retain meaning across those boundaries if cross-provider interoperability is desired.¶
A practical communication system cannot synchronously repeat map search, ranking, payment calculation, fraud scoring, AI inference, user-selection logic, and remote authorization signing every time a call or message is about to be released. The architecture therefore separates a slower preparation path from a small real-time verification path.¶
No universal latency figure is asserted. Actual performance depends on cryptographic primitives, state-protection mechanism, cache topology, persistence, concurrency, regional placement, CPaaS architecture, operating-system integration, and failure-recovery policy. Implementations need measurement rather than assumed microsecond or millisecond claims.¶
The cold path can perform query processing, property or business retrieval, ranking, eligibility, fraud scoring, pricing, payment computation, AI processing, user selection, authority construction, signing, and regional state replication. Those operations do not need to occur while a call is waiting to connect.¶
The hot path can receive the communication attempt, hold the protected resource non-effective, parse or resolve the authority, reconstruct the Attempt Descriptor, verify integrity, check actor/context/channel/effect/validity, check nonce/quota/revocation, atomically reserve or consume state, and release or deny.¶
The map search is not repeated. The lead auction is not repeated. Payment computation is not repeated. AI reasoning is not repeated. The goal is to reduce the communication-critical path to deterministic verification over precomputed authority and locally available or efficiently reachable protected state.¶
A global map platform can distribute verification horizontally. State can be partitioned by query, pseudonymous user binding, business, region, handle, or nonce domain. Successful authorization for D1 does not authorize D2, and a failure for D3 does not require global serialization of unrelated queries.¶
Caching introduces a critical requirement: stale state must not recreate authority that has been revoked or consumed. Short validity windows, revocation epochs, policy epochs, freshness deadlines, protected counters, or equivalent mechanisms can bound stale-cache risk. If current required state cannot be established, the protected effect remains non-effective or is escalated to a higher-assurance verifier.¶
Ordinary map discovery can use pre-issued authority, regional verification, local public keys, short-lived state, batched revocation epochs, and asynchronous audit. Higher-risk deployments can add HSM-backed verification, TEE or secure-enclave state, stronger user presence, attestation, shorter validity, stricter revocation, or synchronous state commitment. The communication-authority semantics remain the same while the assurance mechanism changes.¶
Existing infrastructure already supports termination of SIP dialogs, RTP paths, WebRTC sessions, TURN allocations, callback bridges, message quotas, and other resources. The new property is not the existence of a timer; it is that expiry of the preview does not silently become future contact. Future communication requires separately valid authority.¶
An illustrative Google Maps-type deployment can keep map search, local discovery, ranking, listing UI, and commercial logic in the ordinary application layer while adding a Communication Authority Service and protected communication relay.¶
Map / Local Search
|
v
Property or Business Results
|
v
Query Context Service
|
v
Communication Authority Service
|
| pre-issued protected authority
v
Regional Edge Verification
|
v
CPaaS / SIP / WebRTC Enforcement
|
| verified bounded release
v
Ordinary Telecom / Internet Transport
The downstream carrier need not understand the map query if the platform-controlled relay makes the finality decision before creating the ordinary carrier leg.¶
An illustrative Apple Maps-type deployment can use the same cloud authority model and optionally add a device-side communication or notification broker. The cloud side can verify business identity, query context, commercial state, and quota, while the device side can enforce user revocation, notification permission, device state, user presence, or AI-agent scope where appropriate.¶
The cloud and device checks are logical roles; this document does not assert that Apple implements or plans to implement such a design.¶
Initial deployment can occur at a platform relay, CPaaS gateway, virtual-number service, callback bridge, SIP/SBC boundary, WebRTC service, messaging gateway, push service, or operating-system broker. The platform controls the protected boundary where reachability is created and can then hand an ordinary permitted communication leg to existing transport infrastructure.¶
A user can instruct an AI assistant to find houses for rent within a radius, contact several agents, ask whether pets are allowed, compare answers, and present the best options. Search, ranking, natural-language reasoning, and message generation can remain in the cold path. Each resulting call or message can still require bounded authority at the communication-finality boundary.¶
The design is compatible with horizontally distributed verification because unrelated queries and businesses can have independent authority and state domains. The principal scaling challenge is not global coordination of every map query; it is correct consistency and failure semantics for the protected state associated with each bounded communication authority.¶
The architecture can be deployed in stages:¶
Platform-local gateway: a map or marketplace service uses its existing callback, virtual-number, messaging, or CPaaS integration and applies query-scoped authority before protected connection.¶
Regional protected verification: authority and protected state are replicated to regional enforcement points to reduce central round trips.¶
Cross-provider CPaaS or SIP integration: independent services carry a common authority reference and apply shared verification semantics.¶
Device-side or attested enforcement: higher-assurance deployments can include operating-system, TEE, secure-enclave, or attested enforcement where the threat model requires it.¶
Existing application verbs such as Call, Message, Contact Agent, Request Callback, or Book Viewing do not need to disappear. The implementation changes the internal meaning: the application requests a Candidate Communication Act, and the protected effect is released only after finality verification.¶
Google Maps, Google Business Profile, Google Local Services, Android, and related services are recognizable examples of map-based discovery, local business identity, mobile communication, and AI-assisted workflows in which query-scoped protected reachability can be evaluated. These references are illustrative only.¶
Apple Maps, Apple Business Connect, iOS, Siri, calling, messaging, notification, booking, and application-handoff environments are recognizable examples in which cloud-side and device-side communication control could be composed. These references are illustrative only.¶
Property portals, map-based property search, real-estate marketplaces, brokers, owners, and rental services can use bounded first contact to let users compare multiple listings without automatically creating permanent future reachability for every participating agent.¶
The same architecture can apply to travel, hospitality, appointment systems, healthcare inquiries, home services, classified marketplaces, local retail, professional services, and other discovery environments where temporary inquiry and persistent contact are currently coupled.¶
Virtual-number providers, callback services, SIP gateways, SBCs, WebRTC services, TURN relays, SMS/RCS services, push services, operating-system brokers, and device-side communication components are potential enforcement locations.¶
The IETF need not standardize map ranking, lead pricing, property data, user-interface design, commercial eligibility, or the internal architecture of Google, Apple, or any other provider. The interoperable problem begins when independent systems need a common machine-verifiable meaning for bounded communication authority.¶
Potential future standardization work could define semantics for:¶
Existing mechanisms should be reused where they already provide the needed semantics. New claims, headers, token types, or containers should be proposed only after the relevant working groups determine that an interoperability gap remains.¶
The central architecture question is:¶
How can an Internet communication endpoint, intermediary, relay, gateway, or application-controlled communication service determine that possession of a routable identifier is not itself sufficient authority to create a communication effect, and instead require verifiable, context-bound, non-bearer authority immediately before that effect becomes usable?¶
The architecture is ineffective if a protected communication effect can be created through an equivalent controlled path that bypasses the finality decision. Implementations need an explicit inventory of protected communication-bearing resources and a closure argument for each path included in the security claim.¶
Threats include handle theft, replay, concurrent double consumption, stale revocation state, stale policy state, rollback, forked state, destination substitution, business-identity substitution, call-center or affiliate pivot, purpose laundering, channel widening, effect widening, forwarding, retargeting, compromised application logic, compromised authority service, compromised verifier, compromised enforcement keys, state desynchronization, denial of service, and bypass through an alternate relay or ordinary contact address.¶
Transport retransmission and application retry need explicit semantics. A duplicate transport message representing the same transaction should not automatically consume a second quota unit, while a materially new call or message after a completed or failed transaction can require fresh or remaining authority. Protocol profiles must define the boundary.¶
Uncertain outcomes also matter. If authority is reserved and the process crashes before effectuation, the implementation must define whether the reservation is released, finalized, retried idempotently, or poisoned. Silently recreating authority after an uncertain dispatch can defeat single-use guarantees.¶
Forwarding and delegation require special care. A business that is authorized for one query must not be able to widen authority merely by moving the lead to an affiliate, outsourced call center, employee identity, AI agent, or reseller. Delegation, if supported, must remain inside the original bounded scope.¶
Attestation does not prove a communication-finality property that the measured implementation does not actually enforce. Similarly, cryptographic integrity of an authority object does not help if the resource allocator can ignore the result or if an equivalent egress path is uncontrolled.¶
Query context can reveal sensitive information including location, property interest, travel plans, healthcare inquiries, service needs, commercial intent, timing, business relationships, and transaction state. A protocol should expose only the minimum information required for verification.¶
Globally stable identifiers should be avoided where pseudonymous, query-scoped, pairwise, or ephemeral identifiers are sufficient. A verifier can often validate a commitment or reference without receiving a raw phone number, full search string, exact address, full booking history, or complete payment record.¶
Logs and receipts can themselves become privacy-sensitive. Retention, access, linkage, and disclosure should therefore be bounded according to deployment need. This document does not claim that use of the architecture by itself establishes compliance with any particular privacy or communications law.¶
References to Google, Google Maps, Google Business Profile, Google Local Services, Apple, Apple Maps, Apple Business Connect, Android, iOS, Siri, Gemini, and other named products, platforms, services, protocols, or companies are used solely for illustrative, technical, educational, and industrial-relevance purposes. The names place the architecture within familiar examples of map-based business discovery, local search, communication, mobile, AI, and marketplace infrastructure.¶
No reference should be interpreted as indicating or implying affiliation, association, partnership, collaboration, sponsorship, endorsement, approval, technical alignment, commercial relationship, licensing arrangement, adoption, implementation, evaluation, planned implementation, or participation by Google, Apple, or any other named organization.¶
The integration examples are hypothetical implementation scenarios. All trademarks, service marks, product names, platform names, and company names remain the property of their respective owners. The architecture is intended to be platform-neutral and provider-independent.¶
This document has no IANA actions.¶
This document does not define licensing terms. Any IPR disclosures related to this Internet-Draft are handled through the IETF IPR disclosure process under the applicable IETF rules and are separate from the technical architecture described here.¶
Map-based discovery can be separated from permanent reachability. A user can participate in a real first conversation with several candidate businesses or property agents without treating that first conversation as automatic future-contact authority. A business can qualify an inquiry before paying for or requesting bounded continuation. A platform can monetize verified communication opportunity and user-side transaction services without making permanent contact information the primary product.¶
The technical distinction is load-bearing: the user, business, and platform can determine that continued contact is desirable, but those decisions do not directly create the protected communication effect. C creates context-bound machine-verifiable authority; E verifies that authority against the actual attempted communication and current protected state; and only then can the protected communication resource become effective.¶
The resulting principle is simple:¶
A map search may authorize a real first conversation, but first contact does not create permanent reachability. No valid current authority means no protected communication effect through the governed path.¶
The author welcomes review from the IETF applications, SIP, real-time communication, OAuth, workload-identity, remote-attestation, privacy, security, CPaaS, mobile-platform, and marketplace communities, particularly on whether the described communication-authority gap is already covered by existing mechanisms and where interoperable semantics would be useful.¶