| Internet-Draft | VESPER Use Cases | March 2025 |
| Wendt | Expires 4 September 2025 | [Page] |
This document discusses a set of use cases and requirements for an extension to Secure Telephone Identity Revisited (STIR) called VESPER (Verifiable STI PERsona). VESPER enhances STIR by incorporating a trust framework that associating a responsible business entity and/or human with the assignment and right-to-use a telephone number. Important to the use-cases and requirements are mechanisms for the preservation of privacy and explicit choice to reveal information beyond the communications service provider you have chosen to assign the telephone number with. Core to this premise is the ability to represent and prove the right to use a telephone number resource via the legitimate holder of the Vesper token. Additional metadata and attributes can be vetted and attested via vetting policies and Know-Your-Customer (KYC) processes that are not defined as part of this effort but should follow jurisdiction specific best practices and policies that may exist. The framework allows for the leveraging of trusted and identified issuers to create a signed credential known as a VESPER token that will be defined including associated claims and potential paths for extensibility in the future. In addition, transparency mechanisms are explored to provide public logs or registries of certificates, keys, entity information, or telephone number details, if desired by the telephone number holder to improve trustability, visibility and accountability within the telephone ecosystem.¶
This document covers various scenarios in which VESPER can be used to enhance trust in communications, focusing on common real-world deployments and corresponding requirements. This work is intended to complement and align with the framework described currently as a work in progress in [I-D.wendt-stir-vesper].¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wendt-stir-vesper-use-cases/.¶
Source for this draft and an issue tracker can be found at https://github.com/appliedbits/draft-wendt-stir-vesper-use-cases.¶
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 4 September 2025.¶
Copyright (c) 2025 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] has proven valuable in mitigating caller ID spoofing by creating a cryptographic identity of telephone calls. However, STIR typically centers on validating the calling telephone number itself, without fully leveraging or verifying the human or business entity behind that number assignment. The VESPER extension introduces a trust framework that aligns verified entities with assigned telephone numbers. By issuing VESPER tokens that encapsulate an entity's attributes and its authorized right-to-use specific telephone numbers, VESPER augments the STIR framework to incorporate deeper levels of identity assurance. Entities can undergo a Know-Your-Customer (KYC) process, allowing a trusted authority to verify and attest to relevant information. Additionally, to increase overall trust and transparency, VESPER contemplates using a public registry of trusted information, certificates, keys, or telephone number assignments. This document outlines a series of use cases where such trust frameworks can enhance communication security, as well as a set of requirements needed to facilitate these scenarios. This approach aligns with the style of [RFC9475], [RFC8396], and [RFC7340] in terms of describing use cases and deriving associated requirements.¶
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.¶
Terminology This document leverages the terminology defined in [RFC8224], as well as the following terms: VESPER Token: A cryptographic artifact issued by a trusted issuer that binds an entity (human or organization) to attributes (such as a telephone number or set of telephone numbers, business name, or relevant KYC data). KYC (Know-Your-Customer): A verification process carried out to validate the identity and attributes of an entity. Transparency Mechanism: A publicly accessible record (e.g., a distributed log, blockchain, or registry) that allows authorized parties to query or audit the certificates, keys, entity details, and telephone number assignments. Right-To-Use Authorization: The validation that an entity is authorized to use a specific telephone number, typically confirmed by service providers or numbering authorities.¶
STIR provides a foundation to securely identify the calling party's telephone number by signing it with a certificate. VESPER supplements STIR by binding the telephone number not just to a certificate, but also to a verified identity (individual or business). This approach helps address questions such as:¶
A VESPER token captures relevant vetted information:¶
The entity name and type (e.g., individual, organization).¶
Telephone number(s) or range(s) assigned for use by that entity.¶
Optional attributes (e.g., business category, address, KYC level).¶
This token is digitally signed by a VESPER issuer (e.g., a trusted third party recognized by the telecom ecosystem). When making calls or presenting identity, this token can be included or referenced, allowing relying parties to confirm the entity's legitimacy.¶
The KYC process is crucial in establishing a high level of trust. Entities seeking a VESPER token must supply documentation and proofs as determined by the issuer. The issuer verifies the documents, confirms the right-to-use the telephone number(s), and digitally signs a token containing these validated attributes.¶
VESPER anticipates the need for a public registry of telephone numbers, associated entity data, and issuer certificates or keys. Such a registry—whether implemented via distributed ledger, web-based transparency log, or other mechanisms—provides a public audit function, allowing:¶
This section illustrates practical examples where VESPER can strengthen trust in communications.¶
Large enterprises often handle multiple telephone numbers, including local, toll-free, and international numbers. An enterprise obtains a VESPER token that includes:¶
The set of numbers assigned to the enterprise.¶
The enterprise's registered name, relevant business attributes, and possibly additional KYC data (e.g., tax ID, business license).¶
When employees place outbound calls on behalf of the enterprise, the receiving party (or the terminating network) can check:¶
The STIR identity header for cryptographic validation.¶
The VESPER token to confirm the enterprise's right-to-use the number and presence of KYC-level attributes.¶
This improves overall trust for called parties, who can rely on the verified identity of the business behind the call.¶
A consumer might seek a verified identity token for a personal mobile or landline number. Undergoing a KYC verification ensures that the consumer is who they claim to be. The resulting VESPER token associates:¶
In this scenario, calling parties can present a self-asserted name (as is common in CNAM systems) along with a verifiable token that states the name is validated by an issuer. This extends STIR's cryptographic verification of the number to also verify the calling user's identity.¶
Communication service providers, contact centers, and other third-party platforms often generate calls on behalf of their clients. VESPER can be integrated to ensure:¶
The third party has explicit permission to use the phone numbers belonging to their clients.¶
Proper KYC validation of each client, so any call from the third party can still reflect accurate identity information about the underlying client.¶
For example, a cloud-based contact center platform might store the VESPER tokens for multiple customers and incorporate the tokens in outbound calls, thereby guaranteeing that each call's displayed caller ID is both legitimately used and properly mapped back to the verified client.¶
The establishment of public transparency logs of telephone number right to use associations for certificates and VESPER issuer certificates could enable privacy enabled validation of:¶
"What certificate or public key is associated with the legitimate assignee of phone number +1-800-XXX-XXXX?"¶
Rapid revocation: If an entity's right-to-use a number is revoked, the system can update the registry to reflect the change. This mechanism benefits telecom operators, regulators, and end-users alike, providing a common check point for verifying identities in the calling ecosystem.¶
The following high-level requirements flow from the use cases above.¶
F1. VESPER Token Issuance:¶
A mechanism MUST exist for securely issuing a cryptographically signed token that associates an entity's identity attributes with telephone number assignments.¶
F2. KYC Validation Process:¶
The issuance process MUST incorporate a KYC validation step, ensuring that assigned numbers and entity data are accurate.¶
F3. STIR Integration:¶
Systems MUST integrate with existing STIR architecture to include or reference VESPER tokens within SIP signaling or comparable call setups, facilitating verification by downstream network elements.¶
F4. Token Revocation:¶
VESPER token issuers MUST support revocation or suspension if telephone numbers are reassigned or if an entity fails to meet continued compliance (e.g., KYC invalidation).¶
TS1. Cryptographic Assurance:¶
VESPER tokens MUST be signed using cryptographic methods that are at least as secure as those in STIR [RFC8224]. The token's signature MUST be verifiable by relying parties.¶
TS2. Authorization Validation:¶
The system MUST ensure that only authorized entities (who have completed KYC) can obtain tokens for specific numbers. The process MUST check right-to-use each telephone number.¶
TS3. Privacy Protection:¶
The design SHOULD include mechanisms to protect sensitive personal or corporate data, ensuring minimal information disclosure in scenarios where full identity is not strictly necessary.¶
TA1. Public Registry Interface:¶
An optional yet recommended registry mechanism SHOULD provide a public interface or API, allowing queries of current or historical ownership of telephone numbers, as well as VESPER issuer keys.¶
TA2. Auditability of Token Issuance:¶
Transparency logs or similar mechanisms MUST keep a verifiable record of token issuance and revocation events, enabling third parties to audit the authenticity and status of tokens.¶
TA3. Revocation Logging:¶
Token revocations MUST be promptly logged to the transparency mechanism to ensure relying parties have up-to-date information.¶
VESPER relies on cryptographically verifiable tokens that extend the trust model of STIR to include entity identity attributes. As such, it is critical that VESPER issuers are trustworthy and maintain high security standards for KYC and signing processes. Attackers could attempt to fraudulently obtain VESPER tokens by compromising KYC processes or by forging credentials. Comprehensive vetting and robust multi-factor verification can mitigate such risks.¶
The public registry or transparency mechanism poses another attack vector if it can be manipulated or if unauthorized parties gain write access. Ensuring tamper-evident logs or distributed ledgers can mitigate data manipulation. Privacy considerations must be addressed to minimize unintended exposure of personal or sensitive business information in public registries.¶
This document has no IANA actions.¶
TODO acknowledge.¶