Internet Engineering Task Force S. Das Internet-Draft: draft-das-6g-query-scoped-communication-handles-01 Intended status: Informational August 25, 2026 Expires: February 25, 2027 6G-Era Privacy-Preserving, Anti-Harassment and Spam-Free Communication for Map-Based Business Discovery and AI-Native Telecommunication Using Query-Scoped Communication Handles Author: Sangam Das Independent Inventor Balasore, Odisha, India Email: info@sangamdas.com Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract A basic architectural weakness remains embedded in modern telecommunications: knowing how to reach someone is often practically equivalent to having permission to attempt contact. A phone number, email address, SIP URI, messaging handle, marketplace contact reference, or similar identifier commonly acts simultaneously as an identity reference, a routing locator, and a reusable path to the recipient. Once that identifier is exposed, copied, leaked, scraped, sold, forwarded, or retained after a legitimate interaction, the recipient may remain reachable long after the original purpose has ended. Existing protections, including caller authentication, spam scoring, AI-based filtering, blacklists, temporary aliases, number masking, and application-level policies, generally operate on top of this persistently reachable architecture rather than changing it. This problem becomes more significant as communications become increasingly automated. AI agents, autonomous workflows, programmable network APIs, AI-RAN systems, digital twins, machine-to-machine services, and future 5G/6G infrastructures can generate communication actions at machine speed and scale. A communication attempt may therefore originate not only from a human caller, but from an AI model, software agent, automated business process, network controller, or chained multi-agent workflow. This patent-pending work introduces the concept of a Capability-Validated Inbound Descriptor (CVID): a communication architecture in which possession of an exposed identifier does not itself constitute authority to reach the recipient. The central principle is: Possession of an identifier is not permission to reach. Under the proposed model, an inbound communication request is treated first as a proposed or Candidate Act rather than as an automatically executable communication event. The act may remain non-effective until a protected authority mechanism determines that the communication is within an authorized scope. Only after successful validation is the limited capability necessary for the particular communication effect released. The authorization may conceptually be limited by factors such as purpose, sender or business identity, permitted channel, time, usage quantity, freshness, revocation state, recipient scope, and jurisdiction. The objective is to transform communication authority from persistent reachability into bounded and consumable authority associated with a particular permitted interaction. This changes the underlying communication model from: persistent identifier + downstream filtering to: bounded authority + protected validation + controlled effectuation The distinction is important. Conventional spam filtering asks: "Is this communication probably unwanted?" The proposed architecture asks an earlier and structurally different question: "Does this requester presently possess valid authority to cause this communication to become effective at all?" The approach is intended to complement, not replace, existing telecommunications, identity, anti-fraud, AI-safety, and network- security mechanisms. Potential applications include voice and messaging systems, business callbacks, marketplaces, customer-support interactions, email, AI-agent communications, programmable telecom networks, 5G/6G, AI-RAN, satellite and non-terrestrial networks, machine-to-machine communications, and other environments in which persistent identifiers create unwanted or excessive reachability. The broader technical objective is to separate: identity from reachability; knowledge of an endpoint from authority to use it; and communication preparation from permission for communication effect. This public record describes the problem space and patent-pending architectural concept only. Detailed cryptographic constructions, protected-state mechanisms, enforcement sequences, implementation variants, and claim-specific technical limitations remain subject to pending patent rights. 1. Introduction Modern communication systems generally assume that a routable identifier is sufficient to initiate a communication attempt. Access controls, reputation systems, spam filters, fraud detection, and recipient preferences may subsequently determine whether the request is completed, blocked, silenced, or classified as suspicious. This document explores a different architectural model in which routing knowledge and communication authority are separated. In the proposed model, a caller, software process, AI agent, business, application, or network service may know or possess a contact reference without thereby possessing an independent right to cause a call, message, notification, session, or equivalent communication effect to reach the intended recipient. Communication authority is instead represented as bounded, context-specific, revocable, and potentially consumable authorization that is validated before the communication becomes effective. 2. Problem Statement Persistent identifiers create persistent reachability. Once a conventional phone number, virtual number, SIP URI, relay address, messaging handle, or similar reference is disclosed, it may be retained and reused beyond the purpose for which it was originally provided. Existing mitigations often reduce abuse without eliminating the underlying bearer-like property of the identifier. Examples include: * caller authentication, which may improve identity confidence without determining whether the caller is authorized to contact the recipient; * spam scoring and AI filtering, which evaluate a communication after an attempt has already been initiated; * virtual or masked numbers, which may conceal an underlying endpoint while the proxy remains independently dialable; * blocklists and access-control lists, which generally operate after a request reaches a service or gateway; * temporary numbers and aliases, which reduce exposure duration but still function as bearer routing references while active; and * application-layer policies, which may not control lower-level or alternate communication paths. In highly automated environments, these limitations may become more significant because AI agents and software systems can generate contact attempts at a scale and frequency beyond normal human behavior. 3. Architectural Principle The architecture described here is based on the following invariant: Identifier possession MUST NOT, by itself, constitute communication authority. A CVID or comparable contact reference is therefore intended to behave as a non-bearer handle. Observation, copying, storage, forwarding, prior use, or leakage of the handle does not independently authorize future contact. A communication request is first represented as a Candidate Act. The Candidate Act remains non-effective until a protected authorization mechanism determines that the requested communication satisfies the currently applicable authorization scope. The architecture therefore separates: * identity reference from reachability; * endpoint knowledge from authority; * communication preparation from effectuation; and * policy evaluation from release of the capability required to produce the communication effect. 4. Capability-Validated Inbound Descriptor A Capability-Validated Inbound Descriptor (CVID) is a communication reference associated with protected authorization state. A CVID is not intended to operate as an independently reusable routing credential. An implementation may bind authorization to one or more of the following: * sender identity; * business or service identity; * recipient scope; * permitted purpose; * communication channel; * destination; * time window; * permitted number of uses; * nonce or freshness state; * revocation epoch; * policy epoch; * jurisdiction; * device, application, agent, or workload identity; and * other context required by the applicable communication policy. The exact cryptographic representation or protected-state mechanism is implementation-specific and outside the scope of this informational document. 5. Candidate-Act Processing A conceptual communication flow may operate as follows: 1. A requester prepares an inbound communication request. 2. The request is represented as a Candidate Act and is not yet treated as an effective call, message, notification, or media session. 3. A protected authorization mechanism evaluates whether the requester presently possesses valid authority for the requested communication effect. 4. Validation may consider identity, purpose, scope, time, freshness, revocation state, quota, jurisdiction, recipient policy, and other applicable constraints. 5. If validation fails, the communication remains non-effective. 6. If validation succeeds, only the bounded capability required for the authorized communication effect is released. 7. Where required, the capability is consumed, invalidated, or updated atomically so that replay or unauthorized reuse does not recreate communication authority. This model places the decisive authorization question before communication effectuation rather than relying exclusively on downstream classification or filtering. 6. Comparison with Conventional Approaches 6.1. Identifier Nature Conventional approach: A phone number, virtual proxy number, SIP URI, or similar reference usually behaves as a bearer handle. Possession is sufficient to attempt a connection. CVID approach: The contact reference is non-bearer. Possession or observation alone provides no independent communication authority. 6.2. Enforcement Timing Conventional approach: Signaling is initiated and routed toward a service, gateway, session border controller, application, or recipient-side filter before policy determines whether the interaction is permitted or rejected. CVID approach: The requested communication effect remains non-effective until the required authority is validated. 6.3. Network and Compute Impact Conventional approach: Unauthorized attempts may still consume signaling, transit, gateway, fraud-analysis, filtering, compute, notification, and other resources before rejection. CVID approach: An implementation may prevent unauthorized requests from obtaining the capability required to resolve or activate the effective communication path, thereby reducing unnecessary downstream processing. 6.4. Interaction Lifecycle Conventional approach: A static or temporary number may remain dialable for its entire validity period. CVID approach: Preview, discovery, inquiry, and actual contact authority may be separated. A preview or inquiry reference need not mature into reusable future contact authority. 6.5. State Handling Conventional approach: Policy may depend primarily on software-side database records, blocklists, access-control lists, or session tables. CVID approach: Authorization state may include protected atomic transitions for nonces, quotas, revocation epochs, single-use permissions, or other consumable authority. 6.6. Lead and Contact-Data Security Conventional approach: Platforms may disclose actual contact information or reusable relay identifiers, creating risks of retention, resale, leakage, scraping, or continued contact. CVID approach: A platform may provide scoped and time-bounded reachability without transferring the recipient's underlying persistent contact information. 6.7. AI-Agent Governance Conventional approach: AI voice or messaging agents commonly invoke ordinary communication APIs that can directly initiate calls or messages whenever API-level credentials permit. CVID approach: AI-generated communication requests may remain non-effective Candidate Acts until a distinct communication capability is validated for the requested effect. A deployment may use a Capability-Bound Authorization Token (CBAT) or functionally similar construct for this purpose. The precise token structure is implementation-specific. 7. The Hotel Hack Example - Structural Non-Bearer Property This example illustrates the structural non-bearer property of the architecture and the distinction from a conventional masked-number, virtual-number, substitute-address, or gateway-filtered communication system. A traveler uses a privacy-preserving communication platform to contact three hotels simultaneously. The platform assigns a session-scoped Virtual Identity handle to the traveler's session. Each hotel receives or uses that handle as the visible communication identifier for the permitted interaction. Hotel B's internal system is subsequently compromised in a cyberattack. An attacker obtains access to Hotel B's database and extracts the traveler's session-scoped Virtual Identity handle. In a conventional masked-number or substitute-address system, the stolen handle may itself remain a reachable substitute address while active. Possession of the handle may therefore be sufficient to initiate a routing attempt toward the traveler or toward the gateway controlling the substituted address. Under the architecture described in this document, the attacker cannot obtain communication authority merely by possessing the stolen handle. The session-scoped Virtual Identity handle has zero independent beyond-preview authority. Possession, copying, storage, extraction, leakage, or replay of the visible handle does not by itself create a valid communication path to the traveler. To create an authorized communication effect, the request may be required to satisfy, simultaneously, protected conditions including: * a provider-bound or business-bound authorization associated with Hotel B's specific provider leg or verified business identity; * a session-bound authorization associated with the specific session in which the traveler's handle was issued; * a query-context or inquiry binding identifying the permitted booking or hotel-discovery purpose; * a quota condition reflecting unconsumed preview or future-contact authority; * an expiry condition that remains inside the permitted validity window; * an anti-replay nonce, counter, freshness value, or equivalent state that has not already been consumed; * a permitted communication channel and permitted communication effect; * applicable revocation and policy state; and * successful verification at the protected enforcement point before any communication-bearing resource becomes effective. The protected authorization state may be generated, maintained, verified, or consumed within a Protected Enforcement Domain. Such an enforcement domain may include an HSM, TEE, secure enclave, secure element, TPM-backed module, carrier-controlled enforcement service, platform-controlled enforcement service, gateway-controlled verifier, application-controlled communication broker, cryptographically isolated enforcement domain, or equivalent protected arrangement. The controlling property is functional: the protected enforcement arrangement controls whether the communication-bearing resource can become effective and maintains the required authorization state in a manner resistant to ordinary application-layer bypass. In one implementation, the protected authorization token or equivalent protected state is not stored in Hotel B's ordinary database, is not transmitted to Hotel B as reusable bearer authority, and cannot be reconstructed merely from the visible handle. The attacker may therefore possess the handle while lacking the provider-bound, session-bound, quota-bound, expiry-bound, nonce-bound, purpose-bound, and enforcement-point-verified authority required to produce the communication effect. The result is: stolen handle != communication authority and, when the required authority is absent: communication effect = none 7.1. Anti-Replay Finality After Preview The same property applies when a legitimate preview interaction has already occurred. A preview authorization may contain or reference a nonce, monotonic counter, quota value, validity window, revocation epoch, or equivalent protected state. The enforcement point may atomically consume or advance the applicable state when the permitted communication event is released. Once the preview quota is exhausted, the authorization expires, the nonce is consumed, or the relevant state is revoked, the unchanged visible handle does not recreate authority. A later communication attempt using the same handle must satisfy a new or still-valid authorization state. If the required provider identity, session, query context, purpose, channel, nonce, quota, expiry, revocation state, or enforcement-point binding does not validate, the request remains non-effective. This differs from a blacklist model. The architecture does not depend on learning that the caller is unwanted and then adding that caller to a denial list. The requester must possess valid bounded authority for the particular communication effect each time authority is required. 7.2. Blocked Path Versus Absent Path A conventional gateway-filtered architecture may use a masked or virtual number that remains routable to a gateway. Even if the gateway ultimately rejects an unauthorized attempt, the communication path still exists far enough for the network to route signaling toward the enforcement boundary. In that blocked-path model: the address resolves; a routing sequence begins; network or gateway resources may be consumed; and the gateway evaluates and rejects the attempt. A stronger non-bearer deployment may instead use an absent-path model. In the absent-path model, the visible handle alone does not resolve to an effective communication path, gateway destination, media allocation, notification path, or other communication-bearing resource. Protected authority must first be successfully resolved or verified before the effective path can be created or released. In that model: possession of the handle alone does not activate routing; the handle alone does not create reachability; the leaked handle does not provide a reusable attack path to the recipient; and only a properly authorized request can cause the relevant communication-bearing resource to become effective. The distinction is therefore: blocked path: a reachable path exists and is later rejected; absent path: handle possession alone creates no effective path. Implementations that cannot prevent all upstream signaling MAY still apply the non-bearer principle at the earliest enforceable communication-finality boundary. The essential requirement of this document is that possession of the visible handle does not itself constitute authority to produce the protected communication effect. 8. 5G, 6G, AI-RAN, and Programmable Telecom Relevance Future telecommunications environments are expected to include increasingly programmable, software-defined, AI-assisted, and autonomous control mechanisms. Network APIs, AI-RAN, intent-driven orchestration, autonomous service agents, satellite and non-terrestrial networks, digital twins, and machine-to-machine systems may increase the number of entities capable of initiating communication effects. In such environments, identity authentication alone may not be sufficient. A system may correctly identify the requesting entity while still lacking a reliable answer to a different question: Is this entity authorized, at this moment and for this purpose, to cause this particular communication effect? Capability-validated communication attempts to make that distinction explicit. 9. Privacy Considerations The architecture may reduce unnecessary disclosure of persistent contact identifiers. A marketplace, directory, search service, AI assistant, or business discovery platform may permit authorized communication without disclosing a recipient's underlying phone number, email address, or other long-lived identifier. The authorization mechanism SHOULD minimize disclosure of unrelated identity or policy information and SHOULD avoid creating a new persistent cross-service tracking identifier. 10. Security Considerations Implementations SHOULD consider replay, forwarding, token theft, capability duplication, stale authorization, revocation races, confused-deputy behavior, policy rollback, identifier correlation, privilege escalation, compromised AI agents, malicious applications, unauthorized alternate routing paths, and denial-of-service attacks. Authorization state SHOULD be bound to the minimum scope required for the permitted communication. Where single-use or quota-limited authorization is used, state consumption SHOULD be atomic. Failure to validate required authority SHOULD result in failure to produce the protected communication effect. A non-bearer communication handle SHOULD NOT become independently routable merely because it has been observed, copied, retained, or previously used. 11. Deployment Considerations This document does not require replacement of existing telephone numbering, SIP, messaging, email, CPaaS, session border controllers, or network-security infrastructure. CVID-style authorization may be introduced as an additional control layer at directories, brokers, gateways, communication APIs, application servers, network functions, recipient-side systems, or other enforcement boundaries. Transitional deployments may coexist with conventional identifiers and anti-spam mechanisms. 12. Relationship to Existing Anti-Spam Mechanisms The architecture is complementary to caller authentication, reputation systems, fraud detection, spam scoring, content filtering, blocklists, abuse reporting, robocall mitigation, and regulatory controls. Those mechanisms attempt to identify or suppress unwanted communication. CVID-style authorization addresses a different architectural question: whether the requester has valid authority to create the communication effect in the first place. 13. Intellectual Property Notice This document describes a problem space and a patent-pending architectural concept. Publication of this Internet-Draft does not constitute a waiver, dedication, abandonment, or disclaimer of patent rights. Detailed cryptographic constructions, protected-state mechanisms, enforcement sequences, implementation variants, and claim-specific limitations may be subject to pending patent applications. 14. IANA Considerations This document has no IANA actions. 15. References 15.1. Informative References This document is intended as an architectural and problem-space contribution. Specific protocol references may be added in future revisions as the proposal is refined within the IETF community. Author's Address Sangam Das Independent Inventor Balasore, Odisha India Email: info@sangamdas.com