Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and Requirements
draft-wendt-stir-vesper-use-cases-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Chris Wendt | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wendt-stir-vesper-use-cases-04
Secure Telephone Identity Revisited C. Wendt
Internet-Draft Somos, Inc.
Intended status: Informational 6 July 2026
Expires: 7 January 2027
Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and
Requirements
draft-wendt-stir-vesper-use-cases-04
Abstract
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.
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wendt Expires 7 January 2027 [Page 1]
Internet-Draft VESPER Use Cases July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Trusted Caller ID and Verified Messaging . . . . . . . . 6
4.2. Preventing Impersonation and Business Communication
Fraud . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Preventing Financial Fraud Through Caller
Impersonation . . . . . . . . . . . . . . . . . . . . . 6
4.4. Self-Declared Signals About a Number's Intended Use . . . 7
4.5. Authenticated Access and Identity Assurance for Digital
Services . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Public Sector and Emergency Communications Integrity . . 8
4.7. Carrier-Backed Consumer Identity . . . . . . . . . . . . 8
4.8. Bidirectional Identity Verification . . . . . . . . . . . 9
4.9. Credential Retrieval Across Communication Channels . . . 9
4.10. Platform and Multi-Tenant Number Authorization . . . . . 10
5. Requirements for Self-Declared Number-Use Signals . . . . . . 10
6. Roles and Responsibilities . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
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
Wendt Expires 7 January 2027 [Page 2]
Internet-Draft VESPER Use Cases July 2026
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.
Wendt Expires 7 January 2027 [Page 3]
Internet-Draft VESPER Use Cases July 2026
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.
2. Conventions
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.
3. Design Principles
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.
Wendt Expires 7 January 2027 [Page 4]
Internet-Draft VESPER Use Cases July 2026
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.
4. 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.
Wendt Expires 7 January 2027 [Page 5]
Internet-Draft VESPER Use Cases July 2026
4.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.
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.
4.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.
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.
4.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.
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.
Wendt Expires 7 January 2027 [Page 6]
Internet-Draft VESPER Use Cases July 2026
4.4. Self-Declared Signals About a Number's Intended Use
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.
Wendt Expires 7 January 2027 [Page 7]
Internet-Draft VESPER Use Cases July 2026
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.
4.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.
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.
4.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.
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.
4.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.
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
Wendt Expires 7 January 2027 [Page 8]
Internet-Draft VESPER Use Cases July 2026
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.
4.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.
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.
4.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.
Wendt Expires 7 January 2027 [Page 9]
Internet-Draft VESPER Use Cases July 2026
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.
4.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.
What is needed is a way for the platform RTU holder to declare which
originating providers are authorized to place calls from those
numbers on the platform's behalf, as part of the same credential that
establishes its right-to-use for the pool. Individual tenants would
interact with the platform's calling infrastructure without needing
to establish independent RTU or certificate relationships, and the
platform's credential would serve 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.
5. Requirements for Self-Declared Number-Use Signals
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.
Wendt Expires 7 January 2027 [Page 10]
Internet-Draft VESPER Use Cases July 2026
* 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.
6. 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.
Wendt Expires 7 January 2027 [Page 11]
Internet-Draft VESPER Use Cases July 2026
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].
7. Security Considerations
This informational use-case document defers security considerations
to the resulting technical specifications.
8. 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-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-
02, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-stir-certificate-transparency-02>.
Wendt Expires 7 January 2027 [Page 12]
Internet-Draft VESPER Use Cases July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/rfc/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/rfc/rfc8226>.
[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
(PaSSporT) Extension for Signature-based Handling of
Asserted information using toKENs (SHAKEN)", RFC 8588,
DOI 10.17487/RFC8588, May 2019,
<https://www.rfc-editor.org/rfc/rfc8588>.
[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases",
RFC 8816, DOI 10.17487/RFC8816, February 2021,
<https://www.rfc-editor.org/rfc/rfc8816>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/rfc/rfc9060>.
[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,
<https://www.rfc-editor.org/rfc/rfc9447>.
Wendt Expires 7 January 2027 [Page 13]
Internet-Draft VESPER Use Cases July 2026
[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,
<https://www.rfc-editor.org/rfc/rfc9448>.
[RFC9475] Peterson, J. and C. Wendt, "Messaging Use Cases and
Extensions for Secure Telephone Identity Revisited
(STIR)", RFC 9475, DOI 10.17487/RFC9475, December 2023,
<https://www.rfc-editor.org/rfc/rfc9475>.
[RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT) Extension for Rich Call Data", RFC 9795,
DOI 10.17487/RFC9795, July 2025,
<https://www.rfc-editor.org/rfc/rfc9795>.
[RFC9970] Peterson, J. and C. Wendt, "Connected Identity for Secure
Telephone Identity Revisited (STIR)", RFC 9970,
DOI 10.17487/RFC9970, June 2026,
<https://www.rfc-editor.org/rfc/rfc9970>.
Informative References
[CABF.CT] CA/Browser Forum, "Baseline Requirements for TLS Server
Certificates", CABForum CA-Browser-Forum TLS BR 2.1.6,
2025, <https://cabforum.org/working-groups/server/
baseline-requirements/documents/>.
[E.164] International Telecommunication Union, "The international
public telecommunication numbering plan",
ITU-T Recommendation E.164, November 2010,
<https://www.itu.int/rec/T-REC-E.164>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
Author's Address
Chris Wendt
Somos, Inc.
United States of America
Email: chris@appliedbits.com
Wendt Expires 7 January 2027 [Page 14]