Privacy-by-Design, GDPR-Aligned Communication Finality for Google Maps, Apple Maps, and Other Map-Based Business Discovery Using Query-Scoped Non-Bearer Authorization

Privacy-by-Design, GDPR-Aligned Communication Finality for Google Maps, Apple Maps, and Other Map-Based Business Discovery Using Query-Scoped Non-Bearer Authorization Independent Inventor

Balasore Odisha India info@sangamdas.com

Applications and Real-Time map-based business discovery Google Maps Apple Maps communication authority privacy-preserving reachability non-bearer authorization verified lead monetization SIP WebRTC CPaaS AI agents agentic AI execution finality robocall prevention spam call blocking STIR/SHAKEN caller ID spoofing zero trust architecture data privacy GDPR compliance TCPA compliance lead generation real estate technology proptech marketplace monetization API security telecom fraud prevention voice AI conversational AI 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.

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

Scope and Non-Goals 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.

Terminology

Query Context: The bounded discovery or marketplace context that gives meaning to a communication opportunity, such as a particular property search, service request, booking inquiry, quote request, or local-search interaction.
Query-Scoped Communication Handle: A visible or machine-usable reference associated with a Query Context. Possession of the handle is not by itself sufficient authority to communicate.
Preview Authority: Bounded authority for a real but limited first interaction. It can be user-initiated or, after a user has created an inquiry, business-initiated where the applicable platform rule permits.
Future-Contact Authority: Distinct authority for later communication after the preview stage. It can be conditioned on user selection, booking, approval, callback request, transaction state, business-side commercial conditions, or another applicable rule.
Communication Scope Descriptor: A canonical machine-readable representation of load-bearing communication attributes such as query, business, recipient binding, channel, purpose, effect, validity, quota, nonce, revocation epoch, policy epoch, and enforcement-point binding.
Candidate Communication Act: A proposed call, message, callback, notification, session, media allocation, thread creation, or other communication effect that has not yet become effective through the governed path.
Non-Effective State: The state in which a Candidate Communication Act exists as a request but the protected communication-bearing resource has not yet been released.
Attempt Descriptor: A representation reconstructed from the actual communication attempt, using observed or trusted signaling and session attributes rather than relying only on an application's asserted intent.
Protected State: State relevant to freshness, quota, consumption, replay, revocation, policy epoch, business selection, query context, or another authorization predicate that cannot safely be represented by a static reusable token alone.
Bounded Release Capability: A short-lived result of successful verification that permits only the specific communication resource or effect for which validation succeeded. It is not a general-purpose transferable bearer credential.
Communication Enforcement Point: The first controlled point capable of preventing the relevant communication-bearing resource from becoming usable. It can be a CPaaS gateway, SIP proxy, SBC, callback bridge, WebRTC service, TURN controller, messaging gateway, push broker, operating-system broker, device-side protected component, or another equivalent boundary.
Communication Finality: The property that a protected communication effect becomes externally effective only after current bounded authority and required protected state have been verified at the relevant Communication Enforcement Point.

Problem Space

Temporary Inquiry Can Create Persistent Reachability 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 Identity Is Not the Same as Controlled Reachability 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.

Lead Quality and Business-Side Waste 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-Agent Communication 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.

Existing Mechanisms and the Remaining Gap

Direct and Virtual Communication Addresses 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 Assignment and Marketplace Databases 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 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 Authorization 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.

Why This Is Not Merely an Application Policy Flag 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.

Comparison Along Key Dimensions Comparison Along Key Dimensions

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?

Communication-Finality Architecture The architecture separates discovery, marketplace policy, authority issuance, verification, protected state, and external communication effect.

Conceptual Communication-Finality Flow DENY / NO PROTECTED EFFECT | +---- valid ------> ALLOCATE BOUNDED RESOURCE ]]>

Logical Participants

A - User or Intended Recipient: Creates the original inquiry and ultimately receives the call, message, notification, session, or other communication effect.
B - Map or Discovery Platform: Performs search, ranking, listing presentation, eligibility, query-context creation, user selection, pricing, booking, transaction, or other marketplace functions. B does not by itself create final reachability.
C - Communication Authority Service: Converts permitted marketplace state into machine-verifiable bounded authority. C creates the protected binding between the communication context and the permitted act.
D - Business or Requesting Actor: The property owner, broker, agent, business, employee, AI agent, or other actor attempting communication. D may qualify a lead and may satisfy a commercial condition, but D cannot grant itself future reachability.
E - Communication Enforcement Point: Controls the protected communication-bearing resource. E independently checks that the real attempted communication matches C's authority and current protected state before the resource becomes usable.

Communication Scope Descriptor 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: 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 and Future-Contact Authority 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.

Verification of the Actual Attempt 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. 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.

Protected State and Atomic Consumption 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.

Bounded Release Capability 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.

Communication Finality Boundary 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.

Desired Security and Communication Properties

R1 - Identifier Possession Is Not Authority: Possession, copying, storage, forwarding, or resale of a communication handle does not by itself authorize a protected communication effect.
R2 - Preview/Future Separation: Successful first contact does not automatically create future-contact authority.
R3 - Attempt-Specific Binding: Authority is bound to load-bearing attributes such as query, business, purpose, channel, effect, validity, and enforcement point.
R4 - Pre-Effectuation Verification: The protected communication resource remains non-effective until the required verification succeeds.
R5 - Atomic Reservation or Consumption: Concurrent attempts cannot independently consume the same final remaining single-use or quota-bound authority.
R6 - Replay Resistance: Previously consumed, expired, revoked, or exhausted authority cannot be reused for a materially new communication act.
R7 - Revocation and Freshness: Stale policy, revocation, nonce, or epoch state does not silently recreate current authority.
R8 - Identity and Delegation Binding: Transfer from a business to an employee, call center, affiliate, reseller, AI agent, or outsourced provider does not silently widen reachability.
R9 - Alternate-Path Closure for the Claimed Scope: Equivalent protected communication resources within the claimed governed path cannot bypass the same finality decision. Uncontrolled external contact routes must not be counted as protected by this property.
R10 - Privacy Minimization: Verification can use pseudonymous identifiers, hashes, commitments, or references rather than unnecessarily exposing the user's permanent contact data, raw search history, or full transaction record.
R11 - Fail-Closed Controlled Release: If required authority or protected state cannot be established, the protected effect remains non-effective rather than silently degrading to unrestricted reachability.

Live Protocol Example: House for Sale or Rent Near Me 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.

Participants A Through E 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.

Search and Query Context 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.

Creation of Preview Authority Assume A wants to speak briefly with D1, D2, and D3. For D1, C creates Preview Authority PA1: C creates the protected authorization binding. The authority is not merely "ALLOW D1"; it commits to D1 plus the house inquiry, property context, channel, effect, duration, nonce, revocation state, and enforcement point.

First Communication Attempt D1 attempts communication using H88271. H88271 identifies the context E should evaluate; possession of H88271 is not itself sufficient authority.

Preview Enforcement Sequence 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.

Who Creates and Who Enforces the Inseparable Binding 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.

First Conversation Ends Without Permanent Reachability 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.

Who Allows Future Reachability 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.

C Creates New Future-Contact Authority Assume the applicable rule requires A to select D1 and D1 to satisfy the relevant commercial condition. C then creates a new Future-Contact Authority FA1 rather than extending PA1 implicitly: The chain is therefore: A or an applicable platform rule supplies the authorization basis; D may satisfy a commercial condition; C creates bounded machine-verifiable future authority; and E controls whether each later attempt actually becomes effective.

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

Property, Business, and Purpose Pivot 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.

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

Complete Property-Discovery Flow

House for Sale or Rent Near Me

ROI Enhancement and Premium-Grade Marketplace Monetization 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.

From Pay-Per-Click to Pay-Per-Verified-Opportunity

Commercial Signal Progression 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.

Why Business ROI Can Increase 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.

Why the Marketplace Can Offer a Premium Product A normal lead record may establish only that a user clicked or submitted an inquiry. A protected communication workflow can additionally establish that a bounded first interaction occurred, the first-contact quota was consumed, the business chose to continue, the user approved or otherwise satisfied the applicable continuation rule where required, future authority was issued for a defined scope, and later communication remains enforceable only while that authority is valid. The premium is not created merely by labeling a database row "high quality". It comes from connecting the quality signal to an actual controlled communication event and enforceable future scope.

Business-Side Monetization 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.

User-Side Transaction and Platform Value 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.

Property Marketplace Example 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.

Protocol-Level Architecture 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.

Protocol State Machine

SIP-Level Integration SIP 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. 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, is an obvious scope discussion point; this document does not assert working-group adoption or fit.

Relationship to STIR STIR identity mechanisms such as 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 without implying that this architecture is already a STIR work item.

Relationship to OAuth and Bearer Tokens OAuth provides delegated access to protected resources. Bearer-token usage 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.

Relationship to DPoP DPoP 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.

WebRTC and TURN 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 , and TURN is specified in . This document does not define new WebRTC or TURN fields.

HTTP, API, and CPaaS 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. ]]> 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.

Relationship to WIMSE 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 charter is principally about workload identity across multi-system and multi-service environments; it should not be read as a SIP standardization venue.

Relationship to RATS 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 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.

Potential Interoperability Profile 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.

Communication Authority Object A common object or reference could represent context, requesting actor, recipient binding, channel, direction, purpose, effect, validity, quota, nonce or freshness, revocation, and enforcement-point scope. A profile would need canonicalization and integrity semantics sufficient for independent verification.

Authority Carriage A profile could define how the object or reference is associated with SIP, HTTP, WebRTC signaling, CPaaS requests, messaging envelopes, push requests, or another transport without requiring all marketplace data to be exposed to every intermediary.

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

Consumption and Commit Semantics 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, Retransmission, and Fork Semantics 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.

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

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

Forwarding, Retargeting, and Delegation 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.

Cross-Protocol Continuity 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.

Latency and Performance Feasibility 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.

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

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

Pre-Issued Authority Preview or future authority can be created before the communication attempt and replicated to the enforcement region. Verification keys, active context, short-lived authority, nonce state, quota, and revocation epochs can therefore be available without a central round trip on every attempt.

Regional Edge Verification 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.

Cache Freshness and Fail-Closed Behavior 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.

Low-Latency and High-Assurance Modes 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.

Preview Timer and Resource Deallocation 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.

Integration with Map-Based Business Discovery

Google Maps-Type Integration 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.

Illustrative Map-to-Communication Integration The downstream carrier need not understand the map query if the platform-controlled relay makes the finality decision before creating the ordinary carrier leg.

Apple Maps-Type Integration 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.

The Map Platform Does Not Need to Become a Telecom Carrier 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.

AI-Assisted Map Discovery 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.

Map-Platform Scale 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.

Legacy and Incremental Deployment 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.

Industrial Relevance

Google Maps and Google Business Discovery Ecosystems 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 and Apple Business Discovery Ecosystems 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 and Real-Estate Discovery 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.

Other Marketplaces and Local Services 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.

CPaaS, Telecom, and Mobile Infrastructure 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.

AI Agents AI assistants and business agents can use search and communication tools while remaining constrained to specific context-bound effects rather than obtaining general reachability merely from tool possession.

Potential Standardization Boundaries 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:

communication-context identifiers and privacy-preserving recipient bindings;
requesting-actor and business identity binding;
channel, direction, purpose, effect, validity, and enforcement-point scope;
nonce, quota, revocation, policy epoch, and authority-consumption semantics;
authority carriage or references in SIP, HTTP, WebRTC signaling, CPaaS, or messaging systems;
replay, retransmission, fork, forwarding, retargeting, and delegation behavior;
fail-closed verification and interoperable error semantics;
privacy-preserving context commitments; and
evidence or attestation of high-assurance enforcement where appropriate.

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?

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

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

Disclaimer Regarding References to Google and Apple 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.

IANA Considerations This document has no IANA actions.

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

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

References Informative References Query-Scoped, Non-Bearer Communication Authority for Discovery-Initiated Reachability (CVID) Independent Inventor Spam-Resistant Architecture for AI-Native Map-Based Business Discovery in the 6G Era Independent Inventor European Commission, Futurium, EU AI Alliance community contribution SIP: Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol (SIP) The OAuth 2.0 Authorization Framework The OAuth 2.0 Authorization Framework: Bearer Token Usage OAuth 2.0 Demonstrating Proof of Possession (DPoP) Remote ATtestation procedureS (RATS) Architecture Overview: Real-Time Protocols for Browser-Based Applications Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Session Initiation Protocol Core (SIPCORE) Working Group IETF Secure Telephone Identity Revisited (STIR) Working Group IETF Workload Identity in Multi System Environments (WIMSE) Working Group IETF

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