| Internet-Draft | Query-Scoped Communication Handles | August 2026 |
| Das | Expires 2 March 2027 | [Page] |
Modern telecommunications usually couple knowledge of a routable identifier with the practical ability to attempt contact. A telephone number, SIP URI, messaging handle, relay address, marketplace contact reference, or similar identifier can therefore remain a reusable reachability path after the original purpose for disclosure has ended.¶
Existing controls solve important but different problems. Virtual or masked numbers hide an underlying endpoint but commonly leave a substitute route active while the alias is valid. STIR and SHAKEN authenticate or attest information associated with the calling identity, but do not by themselves establish that the authenticated caller is presently authorized by the recipient to create this particular communication effect. Combining number masking with STIR/SHAKEN improves privacy and origin authenticity, yet still does not inherently convert reachability into purpose-scoped, revocable, consumable communication authority. OAuth can express delegated and even fine-grained API authorization, including sender-constrained tokens, but it does not define telecommunications-specific semantics in which a visible contact handle alone creates no effective path until recipient-side or policy-bound communication authority is established.¶
This document describes a Capability-Validated Inbound Descriptor (CVID) and related query-scoped communication model. A communication request is represented as a Candidate Act and remains non-effective until current authorization is established for the requested communication effect. Authorization may be bound to sender or business identity, recipient scope, purpose, channel, time, quota, freshness, revocation and policy epochs, jurisdiction, device or agent identity, and other deployment-specific constraints.¶
Two deployment profiles are distinguished. In a blocked-path profile, ordinary routing may proceed to an enforcement point that rejects a request lacking valid communication authority. In a stronger absent-path profile, possession of the visible handle alone does not resolve to or activate the effective communication path; protected authority must be established before routing, gateway resolution, media allocation, notification, or another consequence-bearing resource is released.¶
The model is relevant to IMT-2030/6G because increasingly programmable, AI-assisted, machine-to-machine, and autonomous communications can generate requests at machine speed and scale. Early rejection or non-creation of unauthorized communication paths may reduce unnecessary signaling, gateway processing, fraud-analysis load, notification work, media/resource allocation, and associated energy consumption. These are potential efficiency benefits, not universal guarantees: authorization itself consumes resources, and net bandwidth or energy savings require measurement in the target deployment.¶
The document focuses on the remaining problem space, comparison with existing mechanisms, 6G and sustainability relevance, blocked-path and absent-path operation, deployment feasibility, legacy interworking, latency considerations, security and privacy, and frequently asked questions likely to arise in telecom engineering review.¶
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 2 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.¶
A basic architectural weakness remains embedded in many communication systems: knowing how to reach an endpoint is often practically equivalent to having permission to attempt contact. The network may later authenticate, score, filter, rate-limit, block, or terminate the attempt, but the reachability path itself usually exists before those controls decide whether the communication should continue.¶
This document explores a different architectural separation: identity is not reachability, endpoint knowledge is not communication authority, and preparation of a communication request is not permission for that request to become effective.¶
The proposed model is intended to complement existing telephone numbering, SIP, STIR/SHAKEN, OAuth, spam filtering, reputation systems, anti-fraud controls, virtual-number services, privacy relays, and application policy. It is not premised on those systems being ineffective. Instead, it asks which security property remains after those mechanisms have done their jobs.¶
Once a telephone number, virtual number, SIP URI, relay address, messaging handle, or marketplace contact reference is disclosed, it may be retained and reused beyond the original interaction. The recipient can revoke or block later, but the identifier often remains sufficient to initiate some portion of routing or gateway processing while it is valid.¶
A network can correctly authenticate a caller or service and still lack a standardized answer to a different question: is this authenticated entity authorized, at this moment, for this purpose, through this channel, to cause this particular communication effect toward this recipient?¶
AI agents, autonomous workflows, programmable network APIs, AI-RAN systems, digital twins, machine-to-machine services, and future IMT-2030/6G environments can initiate communication actions at machine speed. A bearer-like identifier that was tolerable in a human-scale model may become a high-throughput abuse surface when software can generate, retry, branch, and delegate contact attempts automatically.¶
Whether possession of a visible identifier should itself be sufficient to activate a communication path.¶
How a recipient, marketplace, directory, enterprise, or network can grant contact authority for one purpose without granting reusable future reachability.¶
How authorization can expire, be consumed, or be revoked without requiring replacement of the underlying permanent identity.¶
How an authenticated caller can still be denied because the caller lacks current recipient-specific or purpose-specific communication authority.¶
How unauthorized attempts can be rejected before expensive downstream signaling, gateway processing, notification, or media allocation where the deployment permits early enforcement.¶
How the same model can apply to human callers, enterprises, AI agents, machine-to-machine systems, and programmable network functions.¶
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals.¶
CVID — Capability-Validated Inbound Descriptor: a communication reference associated with protected or authoritative policy state and not intended to operate as independently reusable reachability authority.¶
Candidate Act — A proposed call, message, notification, session, callback, or comparable communication effect that has not yet been authorized to become effective.¶
Communication Authority — Current authorization to cause a particular communication effect under defined constraints.¶
Blocked Path — A deployment in which a routable path exists and signaling reaches an enforcement point before the unauthorized attempt is rejected.¶
Absent Path — A stronger deployment in which the visible handle alone does not resolve to or activate the effective communication path; authorization is required before the path or consequence-bearing resource is released.¶
CBAT — Capability-Bound Authorization Token, or a functionally similar artifact, that may carry or reference bounded communication authority. The exact token format is outside the scope of this version.¶
Communication-Finality Boundary — The earliest or strongest enforceable boundary at which the requested communication becomes capable of creating the protected communication effect.¶
Virtual numbers and masking services can prevent disclosure of the recipient's underlying telephone number and can apply forwarding rules, expiry, ACLs, and screening. They are valuable privacy mechanisms. The remaining gap is structural: while a substitute number or relay address is active, it commonly remains independently routable to a proxy or gateway. Possession of the alias can therefore still be sufficient to initiate an attempt unless additional authorization logic is imposed.¶
CVID does not merely hide the permanent endpoint. Its stronger property is that the visible handle is not, by itself, communication authority. A deployment may still use a virtual number as a transport-compatible façade, but the virtual number must be backed by bounded authorization if the non-bearer property is claimed.¶
STIR defines mechanisms for securely identifying the originators of SIP requests and verifying authorization to use originating identity information; see [RFC8224]. PASSporT provides signed identity assertions, and SHAKEN adds attestation and origination information; see RFC 8225 and RFC 8588.¶
That solves caller-identity authenticity and supports fraud mitigation. It does not by itself represent recipient-issued, query-scoped, purpose-scoped, consumable permission to contact a particular recipient. A STIR-valid caller may still be unwanted, out of purpose, over quota, expired, revoked for a specific interaction, or otherwise unauthorized to create the requested communication effect.¶
The presence of a destination claim in a PASSporT binds asserted call information; it should not be confused with recipient consent or a recipient-scoped authorization to create reachability.¶
Relevant standards references include [RFC8225], [RFC8588], and [RFC9475].¶
Combining number masking with STIR/SHAKEN improves two important properties at the same time: the callee's persistent number may be hidden, and the originator's asserted telephone identity may be authenticated or attested. The remaining gap is still authorization-to-reach. The masked endpoint may remain dialable while active, and a correctly authenticated caller can still lack current permission for the specific recipient, purpose, channel, quota, or session.¶
CVID therefore should not be presented as a replacement for the combination. It adds a third property: contact authority must exist now for the particular communication effect, and stronger deployments may withhold the effective path until that authority exists.¶
OAuth deployments can express fine-grained authorization. RFC 9396 defines Rich Authorization Requests, and modern OAuth security guidance recommends sender-constrained access tokens using mechanisms such as mTLS or DPoP; see [RFC9396] and RFC 9700.¶
Accordingly, the distinction from CVID is not that OAuth is necessarily coarse-grained or always bearer-only. OAuth can be an implementation building block for CVID. The remaining difference is semantic and architectural: OAuth does not itself define telephone or messaging reachability, recipient-specific contact authority, absent-path resolution, or a requirement that possession of a visible communication handle creates no effective route until communication authorization is established.¶
A deployment could therefore carry CVID authorization using OAuth or another authorization framework, provided the resulting system preserves the non-bearer communication property and enforcement timing described here.¶
Relevant OAuth references include [RFC9396], [RFC9449], and [RFC9700].¶
Spam scoring, reputation, fraud analytics, blocklists, and call screening decide whether an already-present attempt appears legitimate, suspicious, or unwanted. They can be highly effective. Their principal distinction is timing and policy model: they generally classify or reject an attempt after some route, signaling transaction, gateway processing, or recipient-side event exists. CVID instead asks whether the requester has positive authority to create the protected communication effect in the first place.¶
Temporary aliases reduce the time during which an identifier can be reused and can approximate one-time reachability. However, an alias that is independently routable during its lifetime remains bearer-like unless presentation also requires independent authorization. CVID focuses on that separation explicitly: the visible handle may survive as a reference while authority can expire, be consumed, or be revoked independently.¶
The following comparison summarizes the problem each mechanism primarily solves and the gap that can remain.¶
| Approach | Primary Security Property | What May Remain Unsolved |
|---|---|---|
| Virtual / masked number | Hides or substitutes the persistent endpoint; may add forwarding policy. | Alias may still be independently routable while active; possession may be enough to attempt contact. |
| STIR/SHAKEN | Authenticates/attests origin identity and authorization to use calling number information. | Does not by itself establish recipient-specific permission to contact for this purpose, time, quota, or interaction. |
| Virtual number + STIR/SHAKEN | Combines callee privacy with stronger caller-identity authenticity. | Still does not inherently create purpose-scoped, consumable recipient reachability authority. |
| OAuth scopes | Delegated API authorization. | Does not by itself define telecom reachability or absent-path semantics. |
| OAuth RAR + DPoP/mTLS | Can provide fine-grained authorization and sender-constrained tokens. | Can be a CVID building block, but telecom contact-authority semantics and path-release rules still need definition. |
| Spam / reputation / fraud analytics | Classifies risk and abuse. | Often evaluates after some attempt exists; positive authority to contact is not necessarily required. |
| Blocklist / DND / call screening | Rejects known or policy-disallowed communications. | The path typically exists and is then blocked; identifier possession still creates an attempt surface. |
| Temporary alias | Limits exposure duration. | Alias can remain bearer-like during validity unless independent authority is also required. |
| CVID / query-scoped authority | Separates identifier knowledge from current communication authority. | Requires deployment of authorization and enforcement; absent-path guarantees depend on how early the network can enforce them. |
The architecture is based on the following invariant: identifier possession MUST NOT, by itself, constitute communication authority.¶
A caller, business, AI agent, application, marketplace, or network service may possess a contact reference while lacking the independent authority required to create the protected communication effect. Communication authority is instead represented by current policy state or a bounded authorization artifact that can be scoped, revoked, expired, consumed, or denied independently of the visible handle.¶
A CVID is a communication reference associated with protected or authoritative authorization state. It is not intended to operate as an independently reusable routing credential.¶
sender identity or verified business/service identity;¶
recipient or recipient-group scope;¶
query, booking, support-case, marketplace, or other permitted purpose;¶
permitted communication channel and effect;¶
time window and expiry;¶
permitted number of uses or quota;¶
nonce, counter, or freshness state;¶
revocation and policy epochs;¶
jurisdiction or regulatory context where applicable;¶
device, application, AI agent, workload, or network-service identity; and¶
the enforcement point, resolver, gateway, or sink authorized to release the communication path.¶
The exact cryptographic encoding is intentionally not fixed in this version. Existing token, signature, OAuth, PKI, HSM, TEE, or carrier-policy mechanisms may be used if the functional properties are preserved.¶
A requester prepares an inbound communication request using a CVID or comparable query-scoped handle.¶
The request is represented as a Candidate Act. It is not yet treated as an effective call, message, notification, media session, or other protected communication effect.¶
The authorization service or protected enforcement arrangement evaluates current authority for the requested effect.¶
Validation may consider identity, purpose, recipient scope, channel, time, quota, freshness, revocation, policy epoch, jurisdiction, device or agent identity, and other applicable conditions.¶
If validation fails, the protected communication effect remains non-effective.¶
If validation succeeds, the system releases or resolves only the bounded capability or path required for the permitted communication effect.¶
Where single-use or quota-limited authority applies, nonce, quota, or other protected state is atomically reserved, consumed, or advanced.¶
The communication path proceeds only within the authorized scope. Any later reuse requires still-valid or newly established authority.¶
In the compatibility profile, a conventional address or alias resolves and signaling reaches an enforcement point such as a gateway, SBC, application server, API broker, or recipient-side service. The enforcement point validates communication authority and rejects unauthorized attempts before the protected communication effect proceeds further.¶
This profile can be deployed with legacy systems but does not eliminate all upstream signaling or processing. It therefore provides the authorization property without claiming the maximum network-efficiency benefit.¶
A stronger profile inserts authorization before full routing. A requester first proves or obtains communication authority, after which a routing token, temporary route, resolved destination, or equivalent bounded path information is released. Unauthorized attempts can be terminated before more expensive downstream processing occurs.¶
In the strongest profile, the visible handle alone does not resolve to an effective route, gateway destination, media allocation, notification path, or comparable communication-bearing resource. The effective path is absent until authorization succeeds.¶
The absent-path property is functional rather than tied to a specific addressing scheme. It may be realized by protected resolution, indirection, capability-gated routing, policy-controlled service exposure, or another mechanism that prevents the visible handle from independently activating the protected path.¶
Where the underlying PSTN, SIP, messaging, or legacy network cannot suppress all early signaling, an implementation MUST NOT claim complete absent-path behavior. It may instead claim blocked-path or pre-routing behavior at the earliest enforceable boundary.¶
IMT-2030 anticipates increased AI integration, security and resilience, interoperability, and sustainability as important capabilities; see [ITU-M2160]. Future networks may expose more programmable APIs and autonomous service interactions, increasing the number of software entities capable of initiating communication effects.¶
CVID is relevant because authentication alone becomes less sufficient as machine-originated communications scale. The system may need to answer not only who the requester is, but whether the requester has current authority to reach this target for this exact interaction.¶
Sustainability and energy-efficient resource optimization are explicit IMT-2030 objectives, and ITU-T work for IMT-2020 and beyond emphasizes end-to-end energy-efficiency monitoring and control across user equipment, access, core, data networks, services, and applications; see [ITU-Y3329].¶
A blocked-path architecture can still consume signaling, routing, SBC/gateway processing, fraud analysis, policy evaluation, notification, and sometimes media or application resources before rejection. A pre-routing or absent-path implementation may reduce some of that work by refusing to create or release the effective communication path until communication authority exists.¶
Potential energy-conservation mechanisms include reducing repeated unauthorized routing attempts, preventing unnecessary downstream service-chain traversal, avoiding unnecessary media/resource reservation, reducing unwanted notification and application wakeups, and lowering analytics work generated solely to classify traffic that never had positive authorization to reach.¶
These are architectural opportunities, not guaranteed energy savings. Authorization lookup, cryptographic verification, state synchronization, and cache maintenance also consume compute and network resources. Net energy benefit depends on reject rate, placement of enforcement, cache hit ratio, round-trip distance, cryptographic cost, traffic mix, hardware acceleration, and how much downstream work is avoided. Implementations claiming Green 6G benefits SHOULD measure energy per admitted and rejected attempt under representative loads.¶
The architecture may reduce unnecessary downstream bandwidth and signaling when unauthorized requests are rejected before full session establishment, service-chain traversal, notification fan-out, or media allocation. The largest likely savings are in signaling, processing, and avoided session/resource setup rather than in payload bandwidth for calls that would never have been admitted.¶
An authorization protocol also introduces its own messages. A design that requires a remote authorization round trip for every attempt can negate part of the benefit. Local verification, cached epochs, compact authorization objects, batch validation, and authorization co-location are therefore important engineering considerations.¶
This document does not specify a universal millisecond target. Actual latency depends on whether authorization is local or remote, whether the path uses cached policy or online policy, cryptographic primitives, database/state access, network topology, roaming, and the selected deployment profile.¶
For real-time voice and messaging, the preferred engineering pattern is to keep the critical admission check local to or near the routing/enforcement boundary, pre-provision public keys and policy epochs, cache non-sensitive authorization metadata where safe, and avoid introducing a mandatory long-haul round trip for each attempt. Carrier-grade feasibility MUST be demonstrated by measurement under realistic call setup rates and failure modes.¶
The architecture does not require immediate replacement of E.164 numbering, SIP [RFC3261], IMS, messaging systems, CPaaS, session border controllers, or application servers. In legacy deployments, authorization may be enforced at a gateway, SBC, application server, API broker, directory, marketplace, carrier service, or another point that already mediates the communication path.¶
A legacy endpoint that cannot understand CVID can remain unchanged if the preceding mediation layer translates a successfully authorized request into the legacy signaling expected by that endpoint. The guarantee is then limited by the coverage of the mediator: any alternate path that can reach the endpoint without equivalent authorization remains outside the strongest security claim.¶
Inter-carrier and roaming deployment requires agreement on trust anchors, authorization issuer discovery, freshness, failure semantics, privacy, and which network performs enforcement. A federation may carry signed or sender-constrained authorization evidence, or may perform online validation. This version intentionally does not mandate a single federation model.¶
Latency, bandwidth, compute, battery, energy, and legacy-integration behavior described in this document are engineering expectations and design considerations, not peer-reviewed or universally benchmarked guarantees. Results may vary materially in actual environments. Any numerical performance or energy claim used in a deployment should be supported by measurements on the relevant hardware, network topology, traffic mix, cryptographic implementation, software stack, and policy configuration.¶
Replay and duplication: single-use or quota-limited authority requires atomic consumption or equivalent replay-resistant state.¶
Stale authorization: revocation and policy state should be checked sufficiently close to path release to prevent use of obsolete authority.¶
Confused deputy: a service authorized to contact one recipient or for one purpose must not be able to widen that authority to another recipient, channel, or purpose.¶
Authorization-service denial of service: unauthenticated requests should trigger bounded work; rate limiting, local policy, caching, and stateless pre-validation may be needed before expensive cryptography or remote lookups.¶
Alternate paths: a system cannot claim absent-path or complete non-bearer reachability if another route, API, gateway, forwarding rule, or legacy identifier can reach the recipient without equivalent authorization.¶
Credential theft: if OAuth or token mechanisms are used, sender constraint, audience restriction, short lifetimes, protected key storage, and minimum scope should be considered.¶
Resolver compromise: an attacker controlling the resolver or gateway must not be able to mint broader communication authority than policy permits.¶
Availability: fail-closed behavior may be appropriate for ordinary protected communications, but emergency, safety, and legally mandated access paths require separately defined policy and must not be accidentally disabled by CVID failure.¶
A core privacy objective is to reduce unnecessary disclosure of persistent contact identifiers. A platform can expose a query-scoped reference without disclosing the recipient's underlying phone number, email address, or long-lived messaging identity.¶
CVID itself must not become a new global tracking identifier. Handles should be scoped, rotated, or unlinkable where appropriate. Authorization messages should disclose only the minimum information required by the enforcement point. Purpose, jurisdiction, business identity, and policy metadata can themselves be sensitive and may need confidentiality protection.¶
Migration can be incremental. A marketplace or directory may deploy CVID first for business callbacks while ordinary telephone numbers remain available elsewhere. A carrier may introduce pre-routing authorization only for selected high-abuse or AI-generated traffic classes. A CPaaS provider may require bounded communication authority for programmatic callbacks while leaving conventional human-originated calls unchanged.¶
Interworking claims should identify the deployed profile explicitly: blocked path, pre-routing authorization, or absent path. This avoids presenting a gateway-level deployment as though it prevented all upstream routing.¶
This version requests no IANA actions. If future work standardizes a new SIP parameter, URI scheme, media type, OAuth authorization-details type, registry, or other protocol element, the corresponding IANA actions will be specified in that document.¶
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. Any disclosure obligations arising under applicable IETF IPR rules are separate from this explanatory notice and should be satisfied through the IETF disclosure process where required.¶
Virtual numbers can hide the underlying endpoint. STIR/SHAKEN can strengthen origin identity. OAuth can provide sophisticated delegated authorization. Spam and reputation systems can classify risk. These mechanisms are valuable and can be composed.¶
The remaining architectural question is different: should possession of a communication identifier itself be enough to create reachability? CVID answers no. It separates the visible reference from current communication authority, allows authority to be bounded and consumable, and enables deployments ranging from a compatible blocked path to a stronger absent path in which no effective communication route is released until authorization succeeds.¶
For 6G and AI-native telecommunications, the same separation may also provide a resource-control benefit: unauthorized machine-generated attempts can potentially be stopped earlier, reducing avoidable signaling and processing. Whether that produces net bandwidth or energy savings is an empirical question and should be measured rather than assumed.¶
The following questions are intended to expose the engineering assumptions most likely to be challenged during IETF, carrier, SIP/IMS, CPaaS, 5G/6G, and security review. The answers state architectural intent and deployment constraints; they are not substitutes for implementation benchmarks.¶
No. A virtual number primarily substitutes or masks an endpoint. It may have expiry and policy, but while active it commonly remains routable to a proxy or gateway. CVID requires the visible reference not to constitute independent communication authority. A virtual number can be used as a CVID-compatible façade only if separate current authority is required before the protected communication effect is released.¶
STIR/SHAKEN strengthens authenticity of originating identity and the authorization to use telephone-number identity information. CVID addresses whether that authenticated originator is presently authorized to contact this recipient for this purpose, channel, time, quota, and interaction. The two mechanisms are complementary.¶
The destination claim helps bind asserted call information to a signed identity assertion. It is not, by itself, evidence that the recipient granted current, purpose-scoped permission to be reached, nor does it require the destination path to remain absent until such permission exists.¶
That combination can hide the callee's persistent number and authenticate the caller's asserted number. CVID adds a third dimension: current communication authority. A correctly authenticated caller presenting a valid masked destination can still be denied because the particular interaction is expired, out of purpose, over quota, revoked, or otherwise unauthorized.¶
OAuth is a strong authorization framework and can be part of the implementation. Rich Authorization Requests can encode fine-grained details, while DPoP or mTLS can sender-constrain tokens. What OAuth does not standardize by itself is telecom-specific reachability: whether a visible contact handle can resolve, whether the effective path is withheld until authorization, how contact quota is consumed, and how this composes with SIP/PSTN/IMS routing.¶
No. The architecture can use existing signatures, MACs, secure channels, PKI, OAuth tokens, DPoP-style proof of possession, HSMs, TEEs, or carrier policy systems. The principal contribution is the communication-authority and path-release semantics, not a new cipher or signature algorithm.¶
Possible points include a SIP proxy, SBC, application server, service-exposure gateway, carrier API gateway, directory/resolver, or another component that can prevent the protected communication effect from proceeding. Placement should be as early as practical while retaining authoritative knowledge of destination policy and current authorization.¶
Yes through mediation. A gateway can validate CVID authority and, only on success, originate conventional PSTN or SIP signaling toward the legacy endpoint. The endpoint itself need not understand CVID. However, if the same endpoint remains reachable through an uncontrolled ordinary number, the deployment cannot claim complete absent-path protection for that endpoint.¶
In a blocked path, the address resolves and signaling proceeds until a gateway or service rejects it. In an absent path, the visible handle alone does not create the effective route at all. Authorization must first release or resolve the route. The absent-path profile can save more downstream work but is harder to deploy across legacy infrastructure.¶
It can if implemented as a mandatory distant network round trip. The preferred design is local or near-local verification, cached policy/epochs, compact evidence, and co-location with the routing boundary. No universal millisecond figure is claimed. Operators should benchmark setup latency at expected call rates, including cache misses, roaming, failover, and revocation checks.¶
The architecture does not sit in the radio air-interface critical loop by necessity. It is an admission and reachability-control function that can be placed in service, core, edge, or application infrastructure. Whether a particular deployment meets a 6G service latency budget depends on placement and implementation. Local verification and pre-established trust are important for ultra-low-latency use cases.¶
Potentially by preventing unauthorized attempts from traversing deeper service chains, triggering repeated fraud analysis, waking applications, allocating media/session resources, or causing repeated retry traffic. The strongest benefit is expected when rejection occurs before expensive downstream work. Net savings must subtract the cost of authorization lookup, cryptography, and state synchronization and therefore require measurement.¶
Potentially, but not automatically. It can reduce downstream signaling and avoid media or application traffic for attempts that never receive authority. It also adds authorization signaling. Compact local validation can make the trade favorable under high unwanted-traffic rates, while a remote per-attempt authorization exchange could reduce or reverse the benefit.¶
AI agents and machine-to-machine systems can initiate contact at machine speed, branch across many recipients, retry automatically, and combine discovery data with communication APIs. A reusable identifier therefore becomes a programmable reachability capability. CVID allows the network or service to require positive, bounded authority for each class of effect rather than relying only on post-attempt classification.¶
The authorization plane should avoid expensive work before basic authenticity and rate limits are established. Deployments can use local verification, issuer discovery caches, epoch-based revocation, compact signed evidence, batch processing, and hierarchical policy. Stateful single-use guarantees should be reserved for traffic classes that need them; quota or epoch models may scale better for repetitive low-risk traffic.¶
The default for protected ordinary communications should be explicit and policy-driven. A fail-closed profile preserves the authorization property but can reduce availability. Operators may define separately protected fallback classes. Emergency and legally mandated access paths require independent treatment and must not be accidentally disabled by ordinary CVID service failure.¶
A federation needs issuer discovery, trust anchors, freshness semantics, privacy rules, and agreement about which network enforces the authorization. Evidence may be verified locally or validated online. The draft deliberately does not prescribe one federation model because carrier trust and regulatory arrangements vary by jurisdiction.¶
It should not. Query-scoped or session-scoped handles should be rotated, minimized, or made unlinkable where practical. A globally stable CVID would undermine the privacy goal. Policy metadata should also be minimized because purpose, business identity, and authorization state can reveal sensitive information.¶
The resolver should perform bounded work for unauthenticated requests, apply rate limits and source reputation where appropriate, cache safe policy data, and avoid expensive remote lookups or public-key operations until basic admission checks pass. The authorization mechanism must not become a new amplification vector.¶
A credible evaluation should compare baseline and CVID-enabled deployments using the same traffic mix and measure signaling bytes, CPU time, gateway/SBC transactions, database and fraud-analysis work, application wakeups, media/resource reservations, call-setup latency, and energy per admitted and rejected attempt. Results should be reported by deployment profile because blocked-path and absent-path systems have different savings potential.¶
Emergency and legally mandated access paths must not be subject to ordinary CVID authorization and must not be accidentally disabled by CVID service failure; see the Availability item in Security Considerations. An absent-path or fail-closed deployment profile applies to protected ordinary communications, not to emergency numbering, which requires its own separately defined, always-available routing policy outside the scope of this document.¶
The architecture changes when a communication path is created, not whether an authorized communication remains observable to lawful intercept once established. Because CVID moves some enforcement earlier in the call flow, deployments in jurisdictions with lawful intercept obligations need to confirm that intercept points remain positioned after path establishment and that authorization logs do not themselves undermine required intercept capability. This document does not define an intercept architecture; that remains a deployment and regulatory responsibility.¶
CVID is a technical enforcement mechanism, not a substitute for legal consent frameworks. It can be used to technically express and enforce consent or purpose limitation that a regulatory regime already requires, but it does not itself define what counts as valid consent, retention limits, or lawful basis for contact. Deployments remain responsible for aligning CVID's purpose, scope, and expiry fields with applicable consent and data-protection law.¶
This document does not mandate a single issuer model. Depending on deployment, the recipient, a carrier, a marketplace or directory, or a federated authority acting on the recipient's behalf may issue or authorize a CVID. What is required is that the enforcement point can establish current authority back to a trust root it recognizes; the specific issuance hierarchy, delegation model, and trust anchor distribution are deployment-specific and are expected to be defined in companion or follow-on specifications.¶
This version does not mandate a single denial behavior. Deployments may return a silent drop, a standard error or rejection code, a redirect to an alternate authorized channel, or a fallback path, depending on policy and applicable regulatory requirements. Denial behavior is a deployment and protocol-binding decision rather than an architectural requirement of CVID itself, though implementers should avoid denial responses that themselves leak sensitive authorization-state information.¶
This version is informational: it describes a problem space and an architectural model, and the IANA Considerations section requests no actions. It is intended to establish shared terminology and a comparison baseline against existing mechanisms for discussion. Whether a future version pursues a protocol specification, an architectural BCP, or remains an informational reference is an open question for IETF discussion and is not decided by this draft.¶