draft-wendt-stir-vesper-oob — VESPER out-of-band interface
draft-wendt-stir-vesper-oob (Wendt, Sliwa) defines how VESPER PASSporTs are delivered out of band. I am the primary author. The conceptual framing — why VESPER OOB matters, what it means for the broader trust framework, how the transparent discovery model relates to existing OOB approaches — lives on the VESPER topic page (in the VESPER OOB section) and on the out-of-band topic page. This page covers what the draft itself specifies.
Three operations, no prescribed API
The draft specifies a mechanism, not an interface. Following the approach RFC 8816 took, it describes the operations and the properties an implementation has to preserve, and leaves the means of conveying and authorizing them undefined. Any interface that preserves the properties conforms.
There are three operations:
- Publish — the originating side deposits one or more signed PASSporTs with a PASSporT Placement Service (PPS) for a given origination and destination.
- Retrieve — the terminating side collects the PASSporTs that apply to a call it has received or is about to receive.
- Respond — the called party returns a response PASSporT, which is what makes connected identity work across the out-of-band path.
The scope is any case where in-band signaling does not carry the identity end to end, or where there is no in-band path between the parties at all. That is broader than the TDM-bridging case OOB is usually associated with: it covers messaging, web interactions that reference a telephone number, and asynchronous verification, none of which have a SIP leg to carry an Identity header.
The credential doing the work is the VESPER delegate certificate, which identifies the entity holding the right-to-use for a telephone number and binds it to that entity’s domain identity. Nothing about the delivery path changes what the certificate attests.
A naming note. This draft uses PASSporT Placement Service (PPS). The certificate extension that carries the endpoint is still called the CPS URI extension, from Call Placement Service, so both abbreviations appear in VESPER material with different referents.
Authentication Service and Verification Service procedures
The draft specifies normative requirements for both sides of the exchange.
For Authentication Services publishing PASSporTs out-of-band:
required certificate extensions (CPS URI extension and
embedded SCT), required PASSporT header parameters (x5c
chain inline, x5u URL with domain match to the SubjectAltName),
required claims, and the obligation to publish to the placement
service identified by the certificate’s CPS URI extension.
For Verification Services retrieving PASSporTs out-of-band:
PPS URI resolution via STI-CT log monitoring, credential
validation, multi-PASSporT handling rules (when multiple PASSporTs are
published for a single call — e.g., a base shaken PASSporT
alongside a div or rcd PASSporT — they MUST share the
same orig, dest, iat, and signing certificate), and the
additional Connected Identity validation steps when a
response PASSporT is involved.
PPS discovery via certificate transparency
The discovery model relies on draft-sliwa-stir-cert-cps-ext, which defines a CPS URI extension embedded in VESPER delegate certificates. The draft normatively describes how monitoring parties extract the TN and SPC mappings from STI-CT logs and use them to identify the appropriate placement service for any given call. Because discovery is grounded in CT log monitoring rather than bilateral provisioning, the re-publish action defined in ATIS-1000105 isn’t required in VESPER OOB deployments — though deployments may support both patterns for compatibility.
Status
draft-wendt-stir-vesper-oob-03 (6 July 2026), individual
draft, exploratory. Current revision and state on the
IETF datatracker.