]> Somos, Inc.

US chris@appliedbits.com

art stir telephone number right-to-use 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 . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Secure Telephone Identity Revisited (STIR) framework , , and 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 , , and in terms of describing use cases and deriving associated requirements.

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 when, and only when, they appear in all capitals, as shown here. Terminology This document leverages the terminology defined in , 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.

Overview of VESPER

Relationship to STIR 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: "Is the caller truly who they claim to be?" "Does this caller have the right-to-use this number based on a recognized numbering authority or telecom provider?"

The Role of a VESPER Token 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.

Trust Framework with KYC 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.

Transparency Mechanisms 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: Verification that a given telephone number is assigned to a specific entity. Monitoring revocation or expiration of VESPER tokens or certificates. Accountability to mitigate malicious issuance or misuse of tokens.

Use Cases This section illustrates practical examples where VESPER can strengthen trust in communications.

Enterprise Number Assignment and Attestation 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.

Consumer User Validation 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: The individual's legal name (or a pseudonym if appropriate). The confirmed telephone number(s). 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.

Third-Party Service Provider Integration 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.

Public Certificate and Key Log Transparency 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.

Requirements The following high-level requirements flow from the use cases above.

Functional Requirements 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).

Trust and Security Requirements TS1. Cryptographic Assurance: VESPER tokens MUST be signed using cryptographic methods that are at least as secure as those in STIR . 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.

Transparency and Auditability Requirements 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.

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

IANA Considerations This document has no IANA actions.

Somos, Inc. Somos, Inc. This document extends the STIR architecture by defining a Personal Assertion Token (PASSporT) with a type of "vesper" (VErifiable Sti PERsona) and specifies the use of PASSporTs as a JSON Web Tokens (JWT) and Selective Disclosure JWT (SD-JWT) for representing verifiable claims related to a persona (a person or business entity) associated with a Secure Telephone Identity (STI). This set of extensible claims can include verifiable information such as the assignment of a telephone number, the output of a Know Your Customer (KYC) or Know Your Business (KYB) type of vetting process, Rich Call Data (RCD) or claims of consent provided to the telephone number holder. The architecture, dependencies, and process flow of Vesper includes logical roles that represent certain responsibilities for establishing a secure telephone identity. These roles represent the basis for trusted relationships to information that is being claimed and who is validating and taking responsibility for the accuracy of that information. These roles begin with a Subject Entity (SE) that is the end entity that intended to be represented by the STI telephone number identifier. A Vetting Claim Agent (VCA) establishes the Subject Entity as a vetted entity after performing the initial vetting and existence as a entity that fulfills the criteria and policies of the ecosystem to be associated with an STI. A Notary Agent (NA) is a neutral role that maintains a graph of relationships among all roles, claims, and identities, but importantly, for protecting privacy, doesn't hold any claim information other than the recording of claim events to the STI telephone number. The NA records these claim event transactions with a corresponding transparency log that generates verifiable receipts to "notarize" the recording of these relationships and claims being established. Privacy is enabled in this Notary role because the submitters have the option of submitting hashes of claims to protect information, or may usefully want to publicly declare their association to a claim to allow the public monitoring to avoid duplicate, mistaken or negligent claims which can be identified before illegitimate usage in the eco- system can occur. Other Claim Agents are defined producing claims in the form of SD-JWT + receipts from the NA. There are multiple claim agent types with corresponding extensible claim definitions with key value pairs that can be required or optionally included. These SD- JWT + receipt claim objects are then collected by the SE into a digital wallet that it can then use for selective disclosure presentation and incorporate into a "vesper" PASSporT signed by the a delegate certificate associated with STI telephone number to validate the SE is indeed the authorized holder of the telephone number and vesper token at the time the presentation is required and ties the SE to the STIR eco-system a STIR certificates policy for use in communications. The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR's Personal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP. The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs. Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.