appliedbits
LIBRARY  ·  IETF LIBRARY ENTRY
Last updated 2026-05-06 drafted

draft-wendt-stir-vesper-oob — VESPER out-of-band interface

draft-wendt-stir-vesper-oob (Wendt, Sliwa) defines the normative HTTPS interface for VESPER’s out-of-band delivery model. 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.

The HTTPS endpoint set

The draft defines a small set of HTTPS endpoints for authentication services and verification services to exchange PASSporTs out-of-band. The interface model is conceptually aligned with ATIS-1000105 §7, with VESPER-specific differences in authentication and discovery.

  • GET /health — service availability check; no authentication required.
  • POST /passports/{DEST}/{ORIG} — calling party publishes one or more signed PASSporTs, optionally requesting a response_uuid for Connected Identity.
  • GET /passports/{DEST}/{ORIG} — called party retrieves published PASSporTs and optionally receives the response_uuid.
  • POST /respond/{UUID} — called party submits an rsp PASSporT in a Connected Identity exchange.
  • GET /passports/response/{UUID} — caller polls for the Connected Identity response.
  • Optional push interfaces — Server-Sent Events (GET /passports/response/stream/{UUID}) and WebSocket (wss://.../stream/respond/{UUID}) — provide real-time delivery alternatives to polling.

The Access JWT

All authenticated operations require an Access JWT signed (ES256) by a VESPER delegate certificate. The JWT carries claims tying the request to a specific transaction: action (publish | retrieve | respond), aud (the CPS hostname), iss and sub (the SPC or TN of the signer and subject — the same value in the common single-entity case), orig and dest matching the path parameters, and where applicable a base64url-encoded SHA-256 hash over the JCS canonicalization of the PASSporT body (preventing substitution attacks during transit). Validation rules cover signature verification, certificate-chain validation against trusted STI roots, claim matching, and replay prevention via the jti claim.

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 CPS endpoint identified by the certificate’s CPS URI extension.

For Verification Services retrieving PASSporTs out-of-band: CPS URI resolution via STI-CT log monitoring, JWT 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.

CPS 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 TN-to-CPS and SPC-to-CPS mappings from STI-CT logs and use them to identify the appropriate CPS endpoint 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

Currently draft-wendt-stir-vesper-oob-02, an individual draft (not yet a working-group document). Exploratory rather than a proposed working-group document at this stage. The proposed STIR working group recharter discussions have included VESPER OOB as part of the extended scope the working group might formalize.