appliedbits
LIBRARY LIBRARY TOPIC
Last updated 2026-05-03 0 entries

VESPER — Verifiable STI Presentation and Evidence for RTU

VESPER — Verifiable STI Presentation and Evidence for Right-to-Use — defines a delegate-certificate profile that brings three trust elements into a single auditable artifact. Telephone-number authority is carried in the certificate’s TNAuthList extension, grounded in an Authority Token issued by the responsible numbering authority. The responsible entity’s domain is carried as a SubjectAltName, providing a corroborating identity signal grounded in WebPKI. A Signed Certificate Timestamp is embedded in the certificate, proving it was recorded in a public transparency log before use. The certificate itself is the trust artifact; standard PASSporTs (RFC 8225) signed by the certificate carry the assertions on the wire.

The architecture is straightforward in mechanism — it builds entirely on existing X.509 extensions, ACME authority-token issuance, and standard PASSporT signing — and consequential in what it makes verifiable. A relying party validating a VESPER PASSporT can confirm that the calling number was assigned to the entity whose domain is named in the certificate, that the originating provider is among those authorized by the right-to-use holder, and that the certificate was publicly logged before use. The combination of TN authority, domain corroboration, and transparency is what’s new.

I’m the author of the VESPER drafts at the IETF — draft-wendt-stir-vesper (currently -07), draft-wendt-stir-vesper-oob (the out-of-band interface, currently -02), and draft-wendt-stir-vesper-use-cases (the informational companion, currently -03). The drafts are individual rather than working group items at this point, but VESPER has been the primary motivation for the STIR working group’s expanded rechartering scope. The framing on this page is from inside the work.

What VESPER addresses

The STIR architecture (RFC 8224, 8225, 8226) provides cryptographic integrity for telephone-number assertions in real-time communications: a verifier can confirm that a calling number was not modified in transit and that it was signed using credentials authorized for that number. STIR does not establish what entity holds the right-to-use for that number, how that entity can be identified across communication channels, or whether an originating provider was explicitly authorized by the right-to-use holder. VESPER addresses each of these gaps within the existing STIR framework.

The shape of the gap matters. STIR/SHAKEN’s attestation model includes an “A” claim that represents a direct, authorized customer relationship — but the claim is self-certified by the originating provider with no external validation. A relying party today has no objective basis on which to evaluate whether an A-attestation is well-grounded in actual right-to-use authorization. VESPER provides that objective basis: when an SPC in the right-to-use holder’s TNAuthList includes a specific originating provider, that provider’s attestation is backed by an explicit authorization in the trust artifact. When it isn’t, the absence is verifiable too.

The same gap shows up in adjacent contexts. Branded calling deployments (see rich call data) have run into the limit imposed by weak entity-level identity: without verifiable binding to the responsible entity, RCD content claims are limited in how broadly they can be trusted. Messaging applications, where there’s no in-band protocol for caller-identity PASSporTs at all, need a credential mechanism that works asynchronously across channels. Cross-border interoperability needs a transparency layer that lets misissuance be detected across jurisdictions. VESPER’s design addresses these as applications of the same underlying mechanism.

The mechanism: a delegate certificate

VESPER’s central artifact is a delegate certificate issued under the STIR certificate policy in RFC 8226. The certificate carries:

  • TNAuthList extension with telephone-number entries (representing the right-to-use the certificate holder has been assigned) and optionally service-provider-code (SPC) entries (identifying the originating providers authorized to place calls from those numbers). TN entries and SPC entries may appear together in the same TNAuthList, as RFC 8226 permits.
  • SubjectAltName dNSName carrying the responsible entity’s internet domain. The domain must be one the entity controls and for which it holds WebPKI certificate credentials.
  • Embedded SCT (Signed Certificate Timestamp) proving that the certificate was submitted to a STIR certificate transparency log and recorded before deployment.
  • Optional JWTClaimConstraints / EnhancedJWTClaimConstraints authorizing additional PASSporT claims (such as Rich Call Data), with the constraints backed by a JWTClaimConstraints Authority Token.

Short-lived certificates are required, following the profile in draft-ietf-stir-certificates-shortlived. The short lifetime reduces dependence on revocation and aligns with the high-frequency issuance patterns that delegate-cert deployment at scale would involve.

PASSporTs signed using a VESPER delegate certificate are standard RFC 8225 PASSporTs — there is no new VESPER-specific PASSporT claim. The certificate itself is what makes the assertion verifiable beyond the standard STIR model. Two header parameters are required on every VESPER PASSporT: x5c, conveying the certificate chain inline, and x5u, carrying the HTTPS URL of the certificate at its location in the domain-hosted repository. The verifier confirms that the domain in the x5u URL matches the dNSName SubjectAltName of the signing certificate, providing proof of domain control without requiring a network fetch.

                ┌──────────────────────────────────┐
                │   VESPER Delegate Certificate    │
                │       (RFC 8226 profile)         │
                ├──────────────────────────────────┤
                │  TNAuthList extension:           │
                │  - TN entries (RTU)              │
                │  - SPC entries (optional, naming │
                │    authorized originators)       │
                ├──────────────────────────────────┤
                │  SubjectAltName dNSName:         │
                │  domain controlled by holder     │
                │  (links cert to web identity)    │
                ├──────────────────────────────────┤
                │  Embedded SCT:                   │
                │  proof of CT log inclusion       │
                │  (no network fetch needed)       │
                ├──────────────────────────────────┤
                │  Optional JWTClaimConstraints /  │
                │  EnhancedJWTClaimConstraints:    │
                │  authorizes additional PASSporT  │
                │  claims (e.g., Rich Call Data)   │
                └──────────────────────────────────┘

Short-lived certificates are required by the profile, per draft-ietf-stir-certificates-shortlived.

Domain as a corroborating trust credential

The role the domain plays in VESPER warrants explicit framing. STIR’s existing certificate hierarchy authenticates that a service provider is authorized to sign for telephone numbers; it doesn’t authenticate the entity behind those numbers. WebPKI’s domain-validation infrastructure is established for exactly the opposite question: confirming that a specific entity controls a specific domain, with thirty years of operational practice behind it.

VESPER uses the domain as a corroborating identity signal rather than as the trust root. The trust root for telephone-number authority remains the STIR certificate hierarchy and the right-to-use chain it represents. The domain in the SubjectAltName is independent evidence — the entity demonstrating WebPKI domain control corroborates the identity established through the STI right-to-use chain. When both chains independently point to the same entity, the combined signal is substantially stronger than either alone.

This pattern — two independent trust chains validating the same entity — is the structural insight VESPER builds on.

The four roles

VESPER’s architecture defines four functional roles. Governance, policy, and regulatory considerations remain external to the protocol; the roles describe operational responsibility within the technical framework.

Domain Operator — the entity that controls a domain and holds the right-to-use for one or more telephone numbers. The Domain Operator is the subject of the VESPER delegate certificate. It publishes the certificate at a stable HTTPS location under its domain and uses the certificate’s private key to sign PASSporTs and, where applicable, RTU Tokens.

Right-to-Use (RTU) Authority — the responsible provider or organization that allocates telephone numbers and issues TNAuthList Authority Tokens as RTU evidence for delegate-certificate issuance. In North American deployment, this is typically a Telephone Number Service Provider (TNSP) or, for toll-free numbers, a RespOrg.

STI Certification Authority (STI CA) — issues VESPER delegate certificates after validating RTU evidence and domain association, operating under the certificate policy defined in RFC 8226. The STI CA’s role is unchanged in essence from existing SHAKEN deployment; what changes is that VESPER certificates carry the additional extensions (SubjectAltName dNSName, embedded SCT) the profile requires.

Transparency Log Operator — records issued delegate certificates and returns Signed Certificate Timestamps that prove log inclusion. The role is borrowed directly from the WebPKI Certificate Transparency ecosystem, where multiple operators run logs that collectively make certificate issuance publicly auditable. Implementations are expected to submit to multiple logs to ensure broad visibility.

The roles can be filled by different parties, or in simpler deployment scenarios consolidated. A small enterprise might have its TNSP serve as RTU Authority while a single STI CA handles both certificate issuance and CT submission. A large enterprise with sophisticated infrastructure might separate all four roles deliberately.

     ┌──────────────────┐                 ┌──────────────────┐
     │  RTU Authority   │                 │ Transparency Log │
     │ (TNSP/RespOrg)   │                 │    Operator      │
     │                  │                 │                  │
     │ issues TNAuthList│                 │ records certs,   │
     │ Authority Tokens │                 │ returns SCTs     │
     └────────┬─────────┘                 └──────────────────┘
              │                                    ▲
              │ RTU evidence                       │
              │                                    │ submission
              ▼                                    │ + SCT issuance
              ┌─────────────────────────────┐      │
              │          STI CA             │      │
              │ (RFC 8226 issuer)           │      │
              │                             │      │
              │ validates RTU + domain      ├──────┘
              │ control; issues delegate    │
              │ certs with embedded SCTs    │
              └──────────────┬──────────────┘
                             │
                             │ issues
                             │ delegate cert
                             ▼
              ┌─────────────────────────────┐
              │      Domain Operator        │
              │                             │
              │ holds RTU, controls domain, │
              │ publishes cert at HTTPS,    │
              │ signs PASSporTs / RTU Tokens│
              └─────────────────────────────┘

Certificate Transparency for STIR

VESPER’s transparency requirement is the most direct borrowing from WebPKI’s operational lessons. Certificate Transparency, as specified in RFC 6962/RFC 9162 and operationalized across the WebPKI for the past decade, made certificate issuance publicly auditable: every issued certificate is logged in append-only public logs operated by independent parties, with cryptographic proof of log inclusion (the SCT) embedded in the certificate itself. The CA/Browser Forum’s mandate of CT for WebPKI TLS certificates established the operational pattern.

VESPER applies the same pattern to STIR. Every VESPER delegate certificate must be submitted to a STIR certificate transparency log (per draft-ietf-stir-certificate-transparency), with the resulting SCT embedded in the certificate before use. A verifier checking a VESPER certificate validates the embedded SCT as part of certificate validation; if the SCT is missing or invalid, the certificate is rejected.

The trust-model implication is significant. WebPKI’s experience showed that public auditability of certificate issuance enables detection of misissuance that pre-issuance controls alone don’t catch. Importing that operational pattern into STIR makes the caller-authentication ecosystem observable in a way it currently isn’t, enabling independent monitoring without centralizing trust authority.

The certificate repository and the RTU Token

A VESPER certificate must be published at a stable HTTPS location under the entity’s domain. The specific path isn’t prescribed; any HTTPS URL whose domain matches the dNSName SubjectAltName of the certificate is valid. The TLS certificate on the hosting server must match that same domain, validated through standard WebPKI TLS. No cross-signing between the STI delegate certificate and the web TLS certificate is required.

This domain-hosted repository is what makes VESPER credentials retrievable across communication channels. A verifier handling a PASSporT can reach the certificate via the x5u URL; a non-SIP context — a messaging interaction, a web flow asking for verifiable caller identity, an asynchronous verification step — can reach the same certificate via the same URL. The discovery substrate is HTTPS itself, with the entity’s own domain as the naming anchor.

For non-SIP contexts that need a portable proof rather than a PASSporT, VESPER defines an RTU Token — a basic JWT signed by the VESPER delegate certificate’s private key, with the certificate chain conveyed in the JOSE header via x5c. The RTU Token claims include iss (the entity’s domain), iat and exp for issuance and short-validity expiration, and orig (the telephone number being asserted). It can carry additional claims authorized by JWTClaimConstraints, such as RCD content. The token is intended for distribution where portable right-to-use evidence is needed outside SIP signaling.

Connected Identity

VESPER integrates with STIR Connected Identity through draft-ietf-stir-rfc4916-update (which I co-author). Connected Identity lets the called party return a signed PASSporT during call setup, asserting its identity back to the caller. With VESPER, the response PASSporT (rsp type) is signed using a VESPER delegate certificate authorized for the destination telephone number, with the same certificate-validation properties — SCT, TNAuthList authorization, domain corroboration — applied symmetrically.

The result is bidirectional identity verification: both the caller and the called party can cryptographically assert their right-to-use to each other, with both assertions backed by the same certificate-profile guarantees. This is structurally new relative to the existing STIR/SHAKEN model, which is one-directional (originating provider asserts; terminating provider verifies). For B2B use cases — a financial institution calling a business customer, two enterprises coordinating a transaction — bidirectional verification is the trust model the use case actually requires.

VESPER OOB

A separate draft, draft-wendt-stir-vesper-oob, defines an HTTPS-based publish-and-retrieve interface for VESPER PASSporTs in scenarios where SIP-based in-band delivery isn’t available. The interface is conceptually aligned with the call-placement-service (CPS) model in ATIS-1000105 §7, with significant differences in discovery and the addition of Connected Identity support.

Discovery via certificate transparency. Where ATIS-1000105 uses bilateral CPS arrangements with re-publishing between specific provider pairs, VESPER OOB uses transparent discovery via STI-CT log monitoring. A CPS URI extension (draft-sliwa-stir-cert-cps-ext) embedded in the VESPER delegate certificate identifies the CPS endpoint responsible for the certificate’s TNAuthList. When the certificate is logged in a STI-CT log, the CPS URI becomes publicly visible and verifiable. A monitoring party extracts the TN-to-CPS and SPC-to-CPS mappings from the logs and uses them to identify the appropriate CPS for any given call. The discovery substrate is the transparency log, not provider-to-provider provisioning.

HTTPS interface. The OOB interface defines a small set of endpoints. POST /passports/{DEST}/{ORIG} lets the calling party publish PASSporTs; GET on the same path lets the called party retrieve them. POST /respond/{UUID} and GET /passports/response/{UUID} support the Connected Identity exchange via a UUID returned by the CPS during publish. Optional push interfaces (Server-Sent Events, WebSocket) provide alternatives to polling for the response retrieval. All endpoints that handle PASSporTs require an Access JWT signed using a VESPER delegate certificate, with an action claim distinguishing the operation type (publish, retrieve, respond).

Cross-channel applicability. The OOB interface decouples PASSporT delivery from SIP signaling, which means it applies to any communication context where caller-identity verification is needed — TDM-bridging, messaging applications, web-based interactions referencing telephone numbers, asynchronous verification flows. The mechanism doesn’t change based on the context; the same publish-and-retrieve pattern works wherever HTTPS is available.

Out-of-band SHAKEN covers the broader OOB landscape, including how VESPER OOB relates to RFC 9888 (the service-provider OOB spec) and the ATIS specs in the same space.

Ten use cases

The informational companion draft (draft-wendt-stir-vesper-use-cases-03) develops ten use cases that motivate VESPER’s design. Each warrants its own future treatment; for now the list:

  1. Trusted Caller ID and Verified Messaging — verified binding of telephone numbers to domain-controlled entity identity, applicable across voice, messaging, and web channels.
  2. Preventing Impersonation and Business Communication Fraud — consistent cryptographic binding of an enterprise’s numbers to its domain identity, verifiable across channels.
  3. Preventing Financial Fraud Through Caller Impersonation — the financial-institution case where verified caller identity is part of the fraud-prevention pipeline.
  4. Explicit Origination Eligibility for Multi-Provider Communications — the SPC-in-TNAuthList mechanism that lets right-to-use holders declare which originating providers are authorized to place calls from their numbers, providing objective grounding for STIR/SHAKEN attestation claims.
  5. Authenticated Access and Identity Assurance for Digital Services — verified binding of telephone-number identity to domain identity for use in authentication and authorization flows.
  6. Public Sector and Emergency Communications Integrity — strong identity binding for official notifications and public safety communications.
  7. Carrier-Backed Consumer Identity — the case where individual consumers don’t directly hold right-to-use; their carrier holds the RTU and backs the legitimacy of their number’s use through delegate certificates with the carrier’s domain as the corroborating identity signal.
  8. Bidirectional Identity Verification — mutual cryptographic verification of caller and called party through Connected Identity, addressing B2B contexts where single-direction identity proof is insufficient.
  9. Credential Retrieval Across Communication Channels — the mechanism for retrieving VESPER credentials in contexts where in-band signaling isn’t available, via the domain-hosted certificate repository and the portable RTU Token.
  10. Platform and Multi-Tenant Number Authorization — the CPaaS / platform / ISV case where the platform holds RTU for a number pool and originates calls through many tenants, with SPC entries in the TNAuthList serving as the authorization record for tenant traffic.

The use cases vary in current operational maturity. Trusted caller identity and origination eligibility are the most directly addressable today; bidirectional verification and platform multi-tenancy align with deployment patterns that are commercially active right now. The use-cases draft treats each in detail.

Requirements for origination authorization

The use-cases draft also articulates a set of requirements that the technical specification is intended to satisfy. The requirements frame what a verifiable origination-authorization mechanism needs to provide, independent of any specific implementation:

  • Verifiable Enablement — the right-to-use holder explicitly enabled a specific signing identity, and the relying party can verify that.
  • Lifecycle Management — origination-eligibility declarations can be updated and revoked in a timely manner, consistent with RTU state and certificate lifecycles.
  • Transparency and Auditability — enablement and revocation events are observable through transparency mechanisms, enabling independent audit without centralizing enforcement control.
  • Cross-Channel Applicability — the mechanism supports voice, messaging, and contexts where telephone numbers are referenced within domain-controlled flows.
  • Policy Separation — verifiable authorization inputs are defined; enforcement, blocking, presentation, and regulatory policy decisions remain local to relying parties.
  • Attestation Grounding — for SPC-based origination authorization, the relying party can determine whether an originating provider’s STIR/SHAKEN attestation is backed by an explicit RTU-holder declaration, providing an objective basis rather than relying on self-certification.

The attestation-grounding requirement is the one most directly relevant to current deployment debates around the STIR/SHAKEN framework, because it provides the verifiable hook that the existing self-certified attestation model lacks (see attestation levels).

Relationship to STIR rechartering

The IETF STIR working group’s expanded rechartering scope — covering enterprise delegated authority, DNS domain identifiers, out-of-band mechanisms, and transparency — was substantially motivated by the design directions VESPER develops. The recharter discussions explicitly identified VESPER as the work item that surfaced the architectural questions the expanded scope addresses.

The relationship between VESPER and the working group is deliberately structured. VESPER’s drafts are individual (draft-wendt-stir-*) rather than working-group items at this point, which is the standard IETF pattern for proposals being explored before formal WG adoption. The recharter creates the scope under which related working-group documents can develop; VESPER continues as the exploratory ground where design directions get worked out.

Out-of-scope for the recharter (and for VESPER): jurisdiction policy and non-TN identities. Both belong in adjacent forums — trust governance and the broader digital-identity work — rather than in STIR.

Where this fits

VESPER sits at the intersection of multiple library threads. It extends STIR/SHAKEN by adding the entity-binding and transparency that the existing trust model doesn’t provide. It builds on the delegate certificate mechanism as its substrate. It addresses the rich call data trust limitation that constrains broad branded-calling adoption. It provides the objective grounding for attestation levels that the self-certified model has lacked. It reframes out-of-band discovery through CT-log monitoring and adds Connected Identity to the OOB flow. It connects to trust governance through the transparency requirement, and to DNS and domain trust through the domain-hosted certificate repository and the WebPKI corroboration role.

The work is exploratory — these are individual drafts, not deployed standards — but the trajectory is clear and the IETF process is engaged.

Planned