| Internet-Draft | VESPER Use Cases | April 2026 |
| Wendt | Expires 3 October 2026 | [Page] |
This document describes use cases and requirements for VESPER (Verifiable STI Presentation and Evidence for RTU), an extension to the Secure Telephone Identity Revisited (STIR) framework. VESPER defines a delegate certificate profile that binds telephone number authority, entity identity, and originating provider authorization into a single verifiable trust artifact, grounded in Right-to-Use (RTU) validation and recorded in a public transparency log. The document identifies the trust gaps that motivate this work and describes requirements for verifiable origination authorization.¶
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 3 October 2026.¶
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], and [RFC8226]) 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 establish what entity holds that right-to-use, how that entity can be identified, or whether communications from the originating provider carry valid RTU-backed authorization for the telephone number being presented.¶
VESPER proposes addressing these gaps through a delegate certificate [I-D.wendt-stir-vesper] that binds telephone number authority to the entity that holds the right-to-use. The certificate can additionally carry corroborating identity signals, such as a domain controlled by the entity. Domain credentials carry entity identity assurances through existing validation procedures that are closely analogous to the entity verification practices discussed in many identity and communications trust frameworks, without requiring standardization of those contextual processes. When both RTU validation and domain validation independently point to the same entity, the combined signal is substantially stronger than either provides alone: the two independent trust chains mutually corroborate the entity's identity, making the overall credential significantly more resistant to forgery or misrepresentation. The certificate can also identify which originating providers have been explicitly authorized by the RTU holder. Certificates issued in this framework are recorded in public transparency logs [I-D.ietf-stir-certificate-transparency] before use, supporting independent auditability without centralizing control.¶
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.¶
Right-to-Use (RTU): A cryptographically verifiable authorization binding one or more telephone numbers to the entity that has been assigned and is accountable for their use, established through recognized numbering authorities or responsible providers.¶
Delegate Certificate: A subordinate certificate issued to the entity that has been assigned a telephone number, as defined in [RFC9060], carrying those numbers in a TNAuthList extension. The delegate certificate serves as the primary credential authenticating the assignee's association with their telephone numbers and their right-to-use.¶
TNAuthList: A certificate extension defined in [RFC8226] that conveys the telephone numbers, number ranges, or service provider codes for which a certificate holder is authorized.¶
Service Provider Code (SPC): An identifier assigned to an originating service provider, defined as a choice entry in the TNAuthList extension in [RFC8226]. In North America this is typically an Operating Company Number (OCN) or Service Provider Identifier (SPID).¶
Authority Token: A signed JWT assertion issued by a recognized numbering authority or responsible provider to convey the right-to-use for specific telephone numbers or service provider codes, defined in [RFC9447] and [RFC9448]. A JWTClaimConstraints Authority Token [I-D.ietf-acme-authority-token-jwtclaimcon] may additionally authorize specific PASSporT claims the certificate holder is permitted to assert.¶
Signed Certificate Timestamp (SCT): A cryptographic proof returned by a transparency log, as defined in [I-D.ietf-stir-certificate-transparency], that a certificate has been submitted to and recorded in the log prior to use.¶
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.¶
VESPER enables the RTU holder to cryptographically bind their numbers to delegate certificates that can be validated across SIP signaling, messaging, and web-based contexts. 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.¶
VESPER enables enterprises to maintain a consistent cryptographic binding between their assigned numbers and their domain-controlled identity, issued on the basis of RTU Authority Tokens. 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.¶
VESPER enables financial institutions to cryptographically assert their authorized use of specific telephone numbers and bind those numbers to their domain-controlled context. Relying applications can validate this authorization before presenting trust indicators or proceeding with sensitive interactions.¶
In enterprise deployments, telephone numbers are frequently originated across multiple providers, platforms, and calling applications. STIR authentication confirms that a call was signed by a credentialed provider but does not establish whether that provider was explicitly authorized by the enterprise holding the right-to-use for that number. An originating provider may sign calls without the RTU holder's knowledge or consent. Furthermore, an originating service provider's STIR/SHAKEN Attestation "A" claim, which represents a direct, authorized customer relationship, is today self-certified with no external validation.¶
VESPER addresses this by enabling RTU holders to include service provider codes (SPCs) alongside telephone number entries in the TNAuthList of their delegate certificate. When both are present, the certificate asserts the entity's right-to-use for the telephone numbers and identifies the originating providers it expects to attest calls from those numbers on the entity's behalf. A provider whose SPC appears in the RTU holder's TNAuthList has verifiable enterprise authorization behind its attestation; a provider whose SPC is absent does not. Terminating networks and relying parties can use this signal to distinguish authorized origination from technically valid but unauthorized traffic.¶
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.¶
Under VESPER, service operators authorized for a telephone number can present cryptographic proof of that authorization, optionally bound to a domain-controlled origin. Relying services can validate this 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.¶
VESPER enables authorized public entities to assert cryptographic control over designated telephone numbers and bind those numbers to official domain-controlled contexts. 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.¶
VESPER enables carriers to issue delegate certificates covering the telephone numbers assigned to their consumers, with the carrier's RTU authority forming the trust chain. The carrier's domain serves as the corroborating identity signal, providing the called party verifiable evidence that the number is legitimately assigned and actively backed by a responsible provider. This model applies equally in B2C contexts: a business receiving a call from a consumer can validate that the number is carrier-backed and legitimately assigned, and a consumer receiving a call from a business can benefit from the same verification in reverse. Connected identity extends this further, enabling each party's carrier to 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.¶
VESPER supports bidirectional identity verification through Connected Identity [I-D.ietf-stir-rfc4916-update]. Both parties can hold delegate certificates authorized for their respective telephone numbers. The called party can return a signed PASSporT asserting their number authority, and the calling party can validate it. The result is a mutually authenticated communication transaction where 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.¶
VESPER addresses this through two complementary mechanisms. A domain-hosted certificate repository provides a stable, publicly resolvable HTTPS location under the entity's domain where delegate certificates can be retrieved and validated independently of how the communication arrived. A portable RTU Token provides a signed JWT proof of right-to-use that can be conveyed in any channel, presented in a message, embedded in a web interaction, or delivered asynchronously, as verifiable evidence of telephone number authority outside of SIP signaling. Together these mechanisms decouple credential verification from any specific transport, making VESPER applicable wherever telephone numbers are used [I-D.wendt-stir-vesper-oob].¶
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.¶