Secure Telephone Identity Revisited C. Wendt Internet-Draft Somos, Inc. Intended status: Informational 1 April 2026 Expires: 3 October 2026 Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and Requirements draft-wendt-stir-vesper-use-cases-03 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). 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 Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Wendt Expires 3 October 2026 [Page 1] Internet-Draft VESPER Use Cases April 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Trusted Caller ID and Verified Messaging . . . . . . . . 4 3.2. Preventing Impersonation and Business Communication Fraud . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Preventing Financial Fraud Through Caller Impersonation . . . . . . . . . . . . . . . . . . . . . 5 3.4. Explicit Origination Eligibility for Multi-Provider Communications . . . . . . . . . . . . . . . . . . . . . 5 3.5. Authenticated Access and Identity Assurance for Digital Services . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Public Sector and Emergency Communications Integrity . . 6 3.7. Carrier-Backed Consumer Identity . . . . . . . . . . . . 6 3.8. Bidirectional Identity Verification . . . . . . . . . . . 7 3.9. Credential Retrieval Across Communication Channels . . . 7 3.10. Platform and Multi-Tenant Number Authorization . . . . . 8 4. Requirements for Origination Authorization . . . . . . . . . 8 5. Roles and Responsibilities . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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. Wendt Expires 3 October 2026 [Page 2] Internet-Draft VESPER Use Cases April 2026 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. 2. Conventions and Definitions 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). Wendt Expires 3 October 2026 [Page 3] Internet-Draft VESPER Use Cases April 2026 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. 3. Use Cases 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. 3.1. Trusted Caller ID and Verified Messaging 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. 3.2. Preventing Impersonation and Business Communication Fraud 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. Wendt Expires 3 October 2026 [Page 4] Internet-Draft VESPER Use Cases April 2026 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. 3.3. Preventing Financial Fraud Through Caller Impersonation 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. 3.4. Explicit Origination Eligibility for Multi-Provider Communications 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. Wendt Expires 3 October 2026 [Page 5] Internet-Draft VESPER Use Cases April 2026 3.5. Authenticated Access and Identity Assurance for Digital Services 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. 3.6. Public Sector and Emergency Communications Integrity 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. 3.7. Carrier-Backed Consumer Identity 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 Wendt Expires 3 October 2026 [Page 6] Internet-Draft VESPER Use Cases April 2026 this further, enabling each party's carrier to independently assert and verify the other's number authority, establishing mutual trust in the call. 3.8. Bidirectional Identity Verification 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. 3.9. Credential Retrieval Across Communication Channels 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]. Wendt Expires 3 October 2026 [Page 7] Internet-Draft VESPER Use Cases April 2026 3.10. Platform and Multi-Tenant Number Authorization Communication platforms, CPaaS providers, and ISVs commonly control telephone number pools on behalf of multiple tenants, customers, or automated systems. In these deployments the platform holds RTU for the number pool but originates communications through many different downstream parties. Today there is no standard way for a terminating network or relying party to verify that a given tenant's use of a platform number was explicitly authorized by the RTU holder, or to distinguish authorized tenant traffic from misuse by unauthorized parties. VESPER enables the platform RTU holder to declare, via SPC entries in the TNAuthList of their delegate certificate, which originating providers are authorized to place calls from those numbers on the platform's behalf. Individual tenants interact with the platform's calling infrastructure without needing to establish independent RTU or certificate relationships. The platform's delegate certificate serves as the auditable authorization record for the entire number pool, making the authorization chain verifiable end-to-end regardless of how many layers exist between the RTU holder and the originating call. 4. Requirements for Origination Authorization The use cases above motivate a standardized, verifiable mechanism allowing the responsible RTU holder to declare which signing identities are authorized to originate communications for a given telephone number. The following requirements capture the intended properties of such a mechanism: * Verifiable Enablement: It should be possible to verify that the RTU holder explicitly enabled a specific signing identity (e.g., a delegate certificate or SPC-authorized originator) to originate communications for the telephone number. * 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. Wendt Expires 3 October 2026 [Page 8] Internet-Draft VESPER Use Cases April 2026 * 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 SPC-based 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. 5. Roles and Responsibilities 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. Wendt Expires 3 October 2026 [Page 9] Internet-Draft VESPER Use Cases April 2026 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]. 6. Security Considerations This informational use-case document defers security considerations to the resulting technical specifications. 7. IANA Considerations This document has no IANA actions. Acknowledgments The author acknowledges the years of industry interactions and innovations that contributed to the technical approaches described here. References Normative References [I-D.ietf-acme-authority-token-jwtclaimcon] Wendt, C. and D. Hancock, "JWTClaimConstraints profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-jwtclaimcon-01, 26 March 2026, . [I-D.ietf-stir-certificate-transparency] Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad, "STI Certificate Transparency", Work in Progress, Internet-Draft, draft-ietf-stir-certificate-transparency- 01, 23 November 2025, . Wendt Expires 3 October 2026 [Page 10] Internet-Draft VESPER Use Cases April 2026 [I-D.ietf-stir-rfc4916-update] Peterson, J. and C. Wendt, "Connected Identity for STIR", Work in Progress, Internet-Draft, draft-ietf-stir-rfc4916- update-07, 7 July 2025, . [I-D.wendt-stir-vesper] Wendt, C. and R. Śliwa, "VESPER - Verifiable STI Presentation and Evidence for RTU", Work in Progress, Internet-Draft, draft-wendt-stir-vesper-07, 31 March 2026, . [I-D.wendt-stir-vesper-oob] Wendt, C. and R. Śliwa, "VESPER Out-of-Band OOB", Work in Progress, Internet-Draft, draft-wendt-stir-vesper-oob-01, 4 November 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . Wendt Expires 3 October 2026 [Page 11] Internet-Draft VESPER Use Cases April 2026 [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, September 2021, . [RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "Automated Certificate Management Environment (ACME) Challenges Using an Authority Token", RFC 9447, DOI 10.17487/RFC9447, September 2023, . [RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token", RFC 9448, DOI 10.17487/RFC9448, September 2023, . Informative References [CABF.CT] CA/Browser Forum, "Baseline Requirements for TLS Server Certificates", CABForum CA-Browser-Forum TLS BR 2.1.6, 2025, . Author's Address Chris Wendt Somos, Inc. United States of America Email: chris@appliedbits.com Wendt Expires 3 October 2026 [Page 12]