draft-wendt-stir-vesper-use-cases — VESPER use cases and requirements
draft-wendt-stir-vesper-use-cases (Wendt) is the informational companion to the VESPER core specification. I am the primary author. The draft develops ten concrete use cases that motivate VESPER’s design and articulates the requirements those use cases impose on the technical mechanism. The VESPER topic page lists and summarizes each use case; this page covers what’s specific to the draft itself.
What this draft contributes
The draft serves two purposes that the core specification
(draft-wendt-stir-vesper) doesn’t directly address. First, it
provides the requirements lens — the use cases collectively
articulate what a verifiable origination-authorization mechanism
needs to provide, and the requirements distilled from them
(Verifiable Enablement, Lifecycle Management, Transparency and
Auditability, Cross-Channel Applicability, Policy Separation,
Attestation Grounding) are the criteria against which the core
spec’s design choices can be evaluated. Second, it provides
detailed treatment of each use case beyond what the topic page
or the core draft can carry — the operational scenario for each,
the trust requirements specific to that case, and how the VESPER
mechanism addresses it.
Design principles
Ahead of the use cases, the draft sets out the reasoning the rest of it rests on: VESPER is a profile that composes existing STIR tools rather than a redefinition of them, and the value of domain binding comes from having two independently revocable chains — telephone-number authority and domain control — that corroborate the same entity. Neither chain alone is new. The corroboration is.
The requirements it distills
The ten use cases are the evidence; the requirements are the output. Six recur across them:
- Verifiable enablement — a relying party can check that an originating provider was actually authorized by the right-to-use holder, rather than inferring it.
- Lifecycle management — authorization can be granted, narrowed and revoked, and revocation takes effect.
- Transparency and auditability — issuance is publicly observable, so unauthorized duplicate issuance is detectable.
- Cross-channel applicability — the same proof works for voice, messaging and web contexts, not just SIP.
- Policy separation — governance and regulatory policy stay outside the protocol.
- Attestation grounding — SHAKEN attestation claims rest on something objective rather than on provider self-assessment.
These are the criteria the core specification’s design choices can be measured against, which is the reason the draft exists as a separate document.
One use case worth naming
Most of the ten are what the titles suggest. The fourth is worth calling out because its name changed to match what it actually describes: “Self-Declared Signals About a Number’s Intended Use” covers the SPC-in-TNAuthList mechanism that lets a right-to-use holder declare which originating providers may place calls from its numbers. It is the case that most directly grounds an attestation claim in something checkable, and the requirements section that follows it is scoped to it.
Status
draft-wendt-stir-vesper-use-cases-04 (6 July 2026), individual
informational draft. Current revision and state on the
IETF datatracker.