Independent Inventor

Balasore Odisha India info@sangamdas.com

Applications and Real-Time Area 6G IMT-2030 CVID query-scoped communication privacy anti-harassment spam resistance STIR/SHAKEN non-bearer handle absent path communication authority AI-native telecommunication 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.

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

Problem Space: The Unsolved Authorization-to-Reach Problem

Persistent Identifiers Create Persistent Reachability 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.

Authentication Does Not Equal Permission to Contact 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?

Machine-Speed Communication Changes the Scale 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.

What Remains Unsolved After Existing Controls

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

Terminology The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in and 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.

Existing Solutions and the Remaining Gap

Virtual Numbers, Number Masking, and Privacy Relays 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 and SHAKEN STIR defines mechanisms for securely identifying the originators of SIP requests and verifying authorization to use originating identity information; see . 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 , , and .

Virtual Number Plus STIR/SHAKEN 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, Fine-Grained Authorization, and Sender-Constrained Tokens 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 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 , , and .

Spam Scoring, Reputation, Blocklists, and Call Screening 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 and One-Time Contact References 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.

Comparison Table The following comparison summarizes the problem each mechanism primarily solves and the gap that can remain. Comparison with Representative Existing Approaches

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.

Architectural Principle 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.

Capability-Validated Inbound Descriptor (CVID) 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.

Candidate-Act Processing

1. A requester prepares an inbound communication request using a CVID or comparable query-scoped handle.
2. 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.
3. The authorization service or protected enforcement arrangement evaluates current authority for the requested effect.
4. Validation may consider identity, purpose, recipient scope, channel, time, quota, freshness, revocation, policy epoch, jurisdiction, device or agent identity, and other applicable conditions.
5. If validation fails, the protected communication effect remains non-effective.
6. If validation succeeds, the system releases or resolves only the bounded capability or path required for the permitted communication effect.
7. Where single-use or quota-limited authority applies, nonce, quota, or other protected state is atomically reserved, consumed, or advanced.
8. The communication path proceeds only within the authorized scope. Any later reuse requires still-valid or newly established authority.

Blocked-Path and Absent-Path Deployment Profiles

Profile A: Blocked Path 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.

Profile B: Pre-Routing Authorization 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.

Profile C: Absent Path 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.

Relevance to IMT-2030 / 6G

AI-Native and Machine-Scale Communications IMT-2030 anticipates increased AI integration, security and resilience, interoperability, and sustainability as important capabilities; see . 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.

Green 6G and Energy-Conservation Relevance 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 . 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.

Bandwidth and Signaling Efficiency 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.

Feasibility, Latency, and Legacy Interworking

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

Legacy PSTN, SIP, IMS, CPaaS, and Application Systems The architecture does not require immediate replacement of E.164 numbering, SIP , 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, Roaming, and Federation 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.

Engineering Disclaimer 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.

Security Considerations

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

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

Deployment and Migration Considerations 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.

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

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

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

Normative References Informative References

Telecom Engineering FAQ 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.

Q1. Is CVID just another virtual number? 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.

Q2. How is CVID different from STIR/SHAKEN? 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.

Q3. STIR PASSporT already contains a destination. Why is that not enough? 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.

Q4. What does CVID add to virtual-number plus STIR/SHAKEN? 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.

Q5. Why not use OAuth alone? 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.

Q6. Does the architecture require a new cryptographic primitive? 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.

Q7. Where would enforcement sit in a SIP or IMS network? 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.

Q8. Can legacy PSTN endpoints participate? 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.

Q9. What is the difference between blocked path and absent path? 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.

Q10. Will pre-routing authorization add unacceptable call-setup latency? 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.

Q11. Can the architecture work at 6G latency targets? 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.

Q12. How can CVID reduce 6G energy consumption? 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.

Q13. Does CVID actually save bandwidth? 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.

Q14. Why is this relevant to AI-native 6G rather than only today's robocalls? 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.

Q15. How does the model scale to millions of machine-generated attempts? 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.

Q16. What happens if the authorization service is unavailable? 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.

Q17. How are roaming and inter-carrier calls handled? 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.

Q18. Does CVID create a new tracking identifier? 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.

Q19. How is denial-of-service against the CVID resolver prevented? 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.

Q20. What evidence would prove the Green 6G claim? 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.

Q21. How does this interwork with emergency services (911/112)? 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.

Q22. Is this compatible with lawful intercept? 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.

Q23. How does CVID relate to consent-to-contact regimes such as TCPA or GDPR? 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.

Q24. Who issues a CVID, and who is the trust root? 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.

Q25. What does the caller see when a Candidate Act is denied? 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.

Q26. What is this document asking the IETF to do? 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.

Author and Version Note Version -02 expands the problem-space analysis, differentiates CVID from virtual numbers, STIR/SHAKEN, their combination, and modern OAuth authorization, and adds blocked-path/absent-path profiles, IMT-2030/6G sustainability analysis, deployment feasibility, legacy interworking, and telecom-engineering FAQs. This revision also corrects an XML structural error in the "Existing Solutions" section (the comparison table is now its own subsection), cites RFC 3261 to resolve an unused-reference nit, and adds Q21-Q26 covering emergency-services interworking, lawful intercept, consent/regulatory frameworks, CVID issuance and trust root, denial behavior, and intended IETF disposition.