| Internet-Draft | VESPER Use Cases | July 2026 |
| Wendt | Expires 7 January 2027 | [Page] |
This document describes use cases and requirements that motivate VESPER (Verifiable STI Presentation and Evidence for RTU), work within the Secure Telephone Identity Revisited (STIR) framework. STIR establishes that a signing credential is authorized for a telephone number, but not what entity holds that authority, what verifiable information that entity declares about its numbers, or how a relying party obtains and verifies this across the channels where a number appears. This document presents a set of use cases that illustrate the resulting trust gaps and states the requirements a solution should satisfy. It motivates the mechanisms defined in the VESPER framework and its companion specifications rather than defining them.¶
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 7 January 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.¶
The Secure Telephone Identity Revisited (STIR) framework ([RFC8224], [RFC8225], [RFC8226], and [RFC9060]) enables cryptographic signing of calls using credentials constrained by TNAuthList [RFC8226], grounded in explicit Right-to-Use (RTU) validation by recognized numbering authorities or responsible providers. STIR verifies that a signing credential is authorized for a specific telephone number, but does not on its own establish what entity holds that right-to-use, what verifiable information that entity declares about its numbers, or how a relying party obtains and verifies this across the channels where a number appears.¶
Closing these gaps is the aim of VESPER, the work this document motivates. What is needed is verifiable evidence that the right-to-use for a number is held by an accountable entity, established by an authorized issuer and carried in a delegate certificate that serves as an extensible credential. Alongside the right-to-use, such a credential can convey verifiable information the holder declares about its numbers: the providers authorized to originate, whether the numbers originate calls or messages, rich call data, and a binding to a domain the holder controls. This credential should be presentable and verifiable wherever telephone numbers appear, in band or out of band, and its issuance recorded in public transparency logs for independent auditability.¶
One component of this framework, and the newest, addresses the entity side of the trust equation: identifying the entity behind a number by associating it with a second identifier the same entity controls, a domain. The telephone number and the domain are the two identifier systems on which global digital communications rest, the one allocated under the ITU-T E.164 numbering plan [E.164] on the public telephone network, the other under the DNS on the public internet, and both are obtained and governed through responsible providers under the law of the relevant jurisdiction. Binding a number's right-to-use to demonstrated control of a domain would associate the same entity across both networks, reusing the domain trust that the Web PKI and TLS already establish rather than creating a new mechanism to secure the web or email. This would enable cross-validation, a number listed on a website or in an email checked against its associated domain and the reverse, and it would be a signal stronger than either anchor alone, because forging it would require compromising two independent chains.¶
Because each of these resources is provider-governed and jurisdiction-bound, the association also creates accountability: activity that departs from established practice, as judged by provider policy or local law, could be answered by revoking either the number authority or the domain, and anchoring an entity's channels to one verifiable identity would help curb cross-channel impersonation across voice, messaging, email, and the web. This entity association is one important, and new, part of VESPER's larger goal; the broader purpose is the verifiable presentation of telephone number trust, and of the information a holder declares about its numbers, wherever those numbers are used.¶
This document motivates these capabilities through a set of use cases and states the requirements they should satisfy; the mechanisms that provide them are defined in the VESPER framework and its companion specifications.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
STIR has developed a substantial set of tools over its lifetime: PASSporTs [RFC8225], certificates and the TNAuthList [RFC8226], delegate certificates [RFC9060], authority tokens [RFC9447] [RFC9448], rich call data [RFC9795], out-of-band delivery [RFC8816], and certificate transparency [I-D.ietf-stir-certificate-transparency], among others. VESPER does not redefine any of these. It is a profile framework that composes existing STIR tools for a specific purpose: telephone-number-scoped trust in a right-to-use and the associated information a number holder declares, carried in a delegate certificate issued through authoritative chains so that it can be trusted by all participants in the STIR ecosystem.¶
VESPER's core mechanism is a telephone-number-scoped delegate certificate. The certificate carries a verifiable right-to-use for specific telephone numbers, chained to an authorized issuer, a numbering authority or responsible provider accountable for the assignment of those numbers. That chain is what makes the right-to-use trustworthy: a relying party relies on the certificate not because of who presents it, but because it descends from an issuer with authority over the numbers. It is that issuer that establishes the association between a number and the entity assigned to it, at issuance and under the law of its jurisdiction; the relying party validates the chain rather than re-adjudicating who the entity is.¶
A telephone-number-scoped certificate is also an extensible vehicle for verifiable statements about the numbers it authorizes and the entity that holds them. Beyond the right-to-use itself, these can include rich call data such as a calling name or brand, declarations of how a number is used such as whether it originates calls or messages [RFC9475], the providers a holder authorizes to originate on its behalf, and a binding to a domain the holder controls. Each is a self-contained, verifiable statement scoped to the certificate's numbers, and a relying party applies whichever it supports.¶
The domain binding is distinctive among these because it reaches the trust in the telephone number into the trust systems of the internet. A domain is the other identifier on which global digital communications rest, carrying the established trust that already anchors the web and email. Binding a telephone number authority to a domain the same entity controls associates that entity across both networks, a signal stronger than either alone, because forging it would require compromising two independent chains, and it lets misuse be answered by revoking either the telephone number authority or the domain, each independently administered and revocable.¶
None of this makes the network an identity system for people or businesses. The association between a number and a real-world entity is established by its issuer at assignment, and for a domain by the certificate authority at validation, each under its own practices and the law of its jurisdiction. A telephone number and a domain are globally consistent network facts, verifiable the same way everywhere, whereas legal identity, liability, and know-your-customer obligations are defined and adjudicated jurisdiction by jurisdiction; resolving them is genuinely hard and is not the network's role. A relying party validates cryptographic chains and self-asserted attributes mechanically and objectively. The role of this work is to provide the objective substrate that local policy and law can rely on and govern, accommodating and supporting those regimes rather than dictating them, and on which real-world identity, where it is needed, operates separately.¶
The following scenarios illustrate the trust gaps that VESPER is designed to address. Each describes a real-world situation where the absence of verifiable telephone number authority creates meaningful risk, and what becomes possible when that authority can be cryptographically established. These scenarios span both business-to-consumer (B2C) and business-to-business (B2B) contexts, reflecting the range of trust relationships in which telephone number authority matters.¶
Consumers receive fraudulent calls and messages that spoof trusted telephone numbers, often accompanied by coordinated web or messaging interactions to reinforce the deception. Because there is no standard mechanism for a relying party to verify that the entity presenting a number is the same entity it was assigned to, attackers can credibly simulate legitimate communications across channels.¶
What is needed is a way for the RTU holder to cryptographically bind their numbers to credentials that can be validated across SIP signaling, messaging, and web-based contexts, so that relying parties can verify both telephone number authority and, where present, the associated domain-controlled context before applying local trust decisions.¶
Fraudsters impersonate businesses by spoofing well-known telephone numbers and directing targets to fraudulent websites or callback numbers. Because recipients rely on number recognition as a proxy for legitimacy, this attack is effective across voice, messaging, and web channels simultaneously.¶
This calls for a way for enterprises to maintain a consistent cryptographic binding between their assigned numbers and their domain-controlled identity, grounded in RTU validation, so that communications referencing those numbers can be verified as authorized by the same accountable entity across any channel.¶
Financial institutions are frequent targets of impersonation: adversaries spoof bank telephone numbers and reinforce the deception through fraudulent web portals or follow-up messages. Customers who recognize the number often extend that trust to the broader interaction even when the surrounding context is malicious.¶
A solution should let financial institutions cryptographically assert their authorized use of specific telephone numbers and bind those numbers to their domain-controlled context, so that relying applications can validate this authorization before presenting trust indicators or proceeding with sensitive interactions.¶
The entity that holds the right-to-use for a telephone number is uniquely positioned to state how that number is, and is not, intended to be used, and a relying party that can verify those statements gains a strong basis for recognizing illegitimate communications. STIR authenticates that a communication was signed by a credentialed provider, but it does not convey the number holder's own intent about the number's use, so a technically valid signature on a communication the holder would never originate is indistinguishable from a legitimate one.¶
What is needed is a way for the RTU holder to make such statements as verifiable evidence bound to the same credential that establishes its right-to-use. These form a family of self-declared signals about a number's intended use, each a plain, verifiable declaration by the holder about its own network asset.¶
The holder can declare which originating providers it authorizes to attest communications from its numbers. In enterprise and multi-provider deployments, numbers are frequently originated across many providers and platforms, and an originating provider may sign for a number without the holder's knowledge or consent; a STIR/SHAKEN Attestation "A" claim [RFC8588] is today self-certified with no external validation. A verifiable list of authorized originators lets a relying party distinguish authorized origination from technically valid but unauthorized traffic: a provider in the holder's declaration has verifiable authorization behind its attestation, one that is not does not.¶
The holder can declare that a number does not originate calls. Many numbers are inbound-only, an inbound customer-service line, or a number that only receives one-time passcodes, and legitimately never place calls. A verifiable declaration to that effect turns any call purporting to originate from such a number into an unambiguous indication of spoofing.¶
The holder can declare that a number does not originate messages. The same reasoning applies to the messaging channel: a number provisioned only for voice, or only to receive messages, can declare that messages purporting to originate from it are illegitimate. The call and messaging declarations are independent, reflecting that a number may originate on one channel but not the other.¶
In each case the signal is a mechanical declaration of intent about a network asset, applied by a relying party as a policy signal according to local policy. None of these signals requires resolving who the real-world entity is, which is what makes them objective and widely applicable.¶
Digital services increasingly use telephone numbers as account identifiers or recovery mechanisms, yet there is no standard way to verify that a number presented by a domain or application is legitimately associated with the entity operating that service.¶
What is needed is a way for service operators authorized for a telephone number to present cryptographic proof of that authorization, optionally bound to a domain-controlled origin, so that relying services can validate it before granting elevated access, enabling callbacks, or trusting embedded contact references, reducing abuse by attackers who reference well-known telephone numbers without authorization.¶
Public safety communications and official notifications are vulnerable to spoofing, particularly when attackers combine fraudulent calls, messages, and web content to simulate official communications with coordinated credibility.¶
A solution should let authorized public entities assert cryptographic control over designated telephone numbers and bind those numbers to official domain-controlled contexts, so that receiving networks or applications can validate this authorization before elevating trust treatment in emergency or public safety communications.¶
Individual consumers do not directly hold the Right-to-Use for their telephone numbers; that authorization rests with the telephone service provider that assigned the number to them. When a consumer places a call, it is their carrier that backs the legitimacy of that number's use. Today there is no cryptographically verifiable way for the called party to confirm that the originating number is actively backed by a legitimate carrier assignment rather than a spoofed or fraudulently used number.¶
What is needed is a way for carriers to issue credentials covering the telephone numbers assigned to their consumers, with the carrier's RTU authority forming the trust chain, so that the carrier's domain can serve as the corroborating identity signal, giving the called party verifiable evidence that the number is legitimately assigned and actively backed by a responsible provider. This applies equally in B2C contexts: a business receiving a call from a consumer should be able to validate that the number is carrier-backed and legitimately assigned, and a consumer receiving a call from a business should benefit from the same verification in reverse. Connected identity would extend this further, letting each party's carrier independently assert and verify the other's number authority, establishing mutual trust in the call.¶
In many communication contexts, particularly B2B interactions such as a financial institution calling a business customer or two enterprises coordinating a transaction, a single direction of identity proof is insufficient. The called party has no cryptographic mechanism to verify that the entity calling them is the legitimate holder of the telephone number being presented, and the calling party has no way to confirm the called party is who they expect.¶
This calls for bidirectional identity verification, as provided by Connected Identity [RFC9970]. Both parties would hold credentials authorized for their respective telephone numbers; the called party could return a signed PASSporT asserting their number authority, and the calling party could validate it. The result would be a mutually authenticated communication transaction in which both parties' telephone number authority is cryptographically verified.¶
In many communication environments a relying party cannot rely on the signaling path to carry VESPER credentials inline. This includes PSTN/TDM interconnects where SIP Identity headers are stripped, messaging platforms that have no equivalent header mechanism, web-based interactions where a telephone number is referenced but no call is in progress, and asynchronous contexts where verification happens after the communication event.¶
This calls for two complementary capabilities. Credentials should be retrievable from a stable, publicly resolvable location under the entity's domain, independently of how the communication arrived. And a portable, signed proof of right-to-use should be conveyable in any channel, presented in a message, embedded in a web interaction, or delivered asynchronously, as verifiable evidence of telephone number authority outside of in-band signaling. Together these would decouple credential verification from any specific transport, making the approach applicable wherever telephone numbers are used.¶
The use cases above motivate a standardized, verifiable mechanism allowing the responsible RTU holder to make self-declared statements about the intended use of a given telephone number, including which signing identities it authorizes to originate for the number and whether the number originates calls or messages at all. The following requirements capture the intended properties of such a mechanism:¶
Verifiable Declaration: It should be possible to verify a statement the RTU holder has made about a number, whether enabling a specific signing identity to originate for it, or declaring that the number does not originate on a given channel.¶
Lifecycle Management: It should be possible to update and revoke origination eligibility declarations in a timely manner, consistent with RTU state and certificate lifecycles.¶
Transparency and Auditability: Enablement and revocation events should be observable through transparency mechanisms, enabling independent audit without requiring centralized enforcement control.¶
Cross-Channel Applicability: The mechanism should support both voice and messaging use cases and should accommodate scenarios where telephone numbers are referenced within domain-controlled contexts.¶
Policy Separation: The mechanism defines verifiable authorization inputs but does not prescribe enforcement, blocking, presentation, or regulatory policy decisions, which remain local to relying parties.¶
Attestation Grounding: Where the mechanism supports provider-level origination authorization, it should be possible for a relying party to determine whether an originating provider's STIR/SHAKEN attestation is backed by an explicit RTU-holder declaration, providing an objective basis for evaluating attestation claims rather than relying on self-certification. This is particularly important in the common case where the originating provider is different from the responsible provider or organization that assigned the telephone number to the entity.¶
Deploying VESPER builds on existing STIR/SHAKEN operational roles and trust anchors. The following functional roles are relevant to VESPER deployment. Governance, policy, and regulatory considerations remain external to the protocol.¶
Telephone service providers, responsible organizations, and numbering authorities ground RTU validation in existing number assignment and delegation practices. Within the VESPER framework, these entities issue cryptographic RTU evidence (e.g., Authority Tokens) that enables STI Certification Authorities to issue TNAuthList-constrained delegate certificates, and manage revocation and lifecycle controls for those assertions.¶
Application-layer communications providers, including CPaaS and UCaaS platforms, integrate cryptographic identity assertions and delegate certificates into their voice, messaging, and API-based services. They provide token management capabilities for their enterprise customers and implement operational controls for token issuance, expiration, delegation, and revocation.¶
Business and enterprise entities are the RTU holders responsible for issuing and managing delegate credentials for their telephone numbers. They define which originating providers or internal systems are authorized to use those numbers, and are accountable for monitoring and revoking credentials in response to misuse.¶
Transparency log operators maintain independently operated, publicly accessible logs that record certificate and authorization artifacts in a tamper-evident, append-only manner [I-D.ietf-stir-certificate-transparency]. They issue Signed Certificate Timestamps (SCTs) proving log inclusion and support ecosystem-wide auditability without centralizing control. The effectiveness of this model is well established through the CA/Browser Forum's mandate for Certificate Transparency [CABF.CT] in the Web PKI ecosystem [RFC6962].¶
This informational use-case document defers security considerations to the resulting technical specifications.¶
This document has no IANA actions.¶
The author acknowledges the years of industry interactions and innovations that contributed to the technical approaches described here.¶