Out-of-band — PASSporT delivery across signaling boundaries — library

Out-of-band is a general model for delivering signed PASSporTs outside traditional in-band signaling. The architecture works for any interaction between two parties that uses a telephone number as the entity identifier — calls, messages, asynchronous credential-retrieval flows, anywhere a verifier needs access to a signed trust artifact that can’t reach it through the in-band protocol path. The originating motivating use case in the SHAKEN context is TDM-bridging — handling call paths where SIP signaling can’t carry the Identity header end-to-end — and most of the deployed and proposed infrastructure today is shaped by that application. But the architectural pattern is broader, and the active work at the IETF (especially the VESPER-OOB draft) is positioning out-of-band as the substrate for a more general PASSporT-delivery and authentication model. RFC 8816 establishes the foundational architecture; ATIS specifications operationalize the TDM application; the FCC’s April 2025 Notice of Proposed Rulemaking proposes mandating non-IP caller authentication on a defined timeline. This is the most active corner of the framework right now.

I co-chair the ATIS IP-NNI Task Force, which produces SHAKEN’s foundational specifications. Most of the TDM/non-IP work covered on this page comes from the adjacent Non-IP Call Authentication Task Force (NIPCA-TF) — a separate ATIS PTSC group that complements the IP-NNI work. I’m authoring the VESPER draft at the IETF, which includes an out-of-band extension (draft-wendt-stir-vesper-oob) exploring directions covered toward the end of this page. The framing here is from inside the work, with appropriate humility about the parts of it that aren’t directly under my chair.

The general model

The broader purpose worth stating explicitly: out-of-band is a mechanism for getting signed PASSporTs to verifiers when the in-band protocol path can’t carry them. The verifier might be a terminating SIP provider whose call arrived over a TDM hop; might be a called party’s device receiving a message rather than a call; might be an authentication system retrieving a credential asynchronously to verify a claimed identity in a non-call context. The trust artifact is the PASSporT regardless of the verification context; out-of-band is what makes the PASSporT reachable when the natural in-band channel can’t.

This generalization matters because it positions out-of-band as a foundational piece of the broader trust framework rather than a narrowly-scoped TDM workaround. The framework is moving toward a model where any party-to-party interaction using a telephone number as the entity identifier can use signed PASSporTs to authenticate the parties involved — A asserting identity to B, B asserting identity back to A through Connected Identity, or both parties mutually authenticating each other. The in-band protocol channel handles this naturally for SIP-end-to-end calls; out-of-band handles every other case. VESPER’s broader contribution is making this general model deployable, with VESPER’s certificate profile as the trust foundation and VESPER-OOB as the delivery and discovery mechanism that doesn’t depend on bilateral provisioning between specific peers.

A practical consequence: many proprietary branded-calling solutions deployed today are using OOB-style techniques — pre-call APIs, separate channels for delivering verified caller identity, vendor-operated trust artifacts that supplement in-band signaling. The architectural pattern these solutions use is structurally similar to OOB SHAKEN. What differs is the trust model — proprietary branded-calling solutions establish trust through commercial arrangements between specific vendors and specific terminating providers, rather than through open certificate hierarchies that any participating entity can establish. The broader OOB direction (especially VESPER-OOB) is positioned as the open-standard alternative that proprietary branded-calling deployments could evolve toward, replacing the gatekeeper-mediated trust signal with one that derives from the certificate hierarchy and works across any interaction context. The architectural ingredients are the same; what changes is whether trust comes from a commercial relationship or from authoritatively-issued credentials.

TDM bridging: the originating use case

SHAKEN’s design assumes that SIP signaling carries the call from origination to termination. The originating provider signs a PASSporT and inserts it as a SIP Identity header; the call traverses one or more intermediate networks via SIP signaling; the terminating provider extracts and verifies the Identity header. The cryptography is end-to-end in the sense that the PASSporT is signed by the originating provider’s certificate and verified by the terminating provider’s verification service.

Real call paths don’t always cooperate with that assumption. Many North American carriers — particularly smaller wireline operators, rural carriers, and several large operators in specific transit scenarios — still use TDM (Time Division Multiplexing) somewhere in their networks. When a call transitions from SIP to TDM, the SIP Identity header has nowhere to go: TDM signaling (SS7, ISUP) doesn’t have a structured field to carry arbitrary headers. The PASSporT is dropped at the boundary, and the terminating provider receives a call that appears unsigned even though it was signed at origination.

The result is a verification failure mode that has nothing to do with the security of the cryptography: the call was legitimately signed, the certificate was valid, the PASSporT was correctly formed — and none of that information reaches the terminating side because the carrier in the middle uses TDM. The framework’s trust model fails at the network architecture level rather than the protocol level.

This isn’t a small problem. The proportion of US calls that traverse some TDM segment is non-trivial; for some originating provider populations it’s the majority of outbound calls. Without out-of-band mechanisms, those calls are effectively outside the SHAKEN trust framework regardless of how scrupulously the originator signed them.

The out-of-band architecture

Out-of-band SHAKEN solves the problem by detaching PASSporT transmission from SIP signaling. The originating provider’s authentication service signs a PASSporT as it normally would, but instead of (or in addition to) inserting it in the SIP Identity header, it transmits the PASSporT to a Call Placement Service. The CPS holds the PASSporT, indexed by metadata that identifies the call (typically including the calling and called telephone numbers and a timestamp). When a call arrives at the terminating provider, that provider’s verification service queries one or more CPS instances for any PASSporT matching the incoming call’s metadata. If a match is found, the verification proceeds normally on the retrieved PASSporT.

The architecture is straightforward in principle. The operational complexity is in three places:

Discovery. The terminating provider needs to know which CPS to query for any given call. The originating provider posted the PASSporT to one CPS, possibly several; the terminating provider has to find it.
Timing and matching. The CPS lookup needs to complete fast enough that it doesn’t add objectionable call setup latency, and the matching has to be reliable enough that the terminating provider trusts the retrieved PASSporT actually belongs to the call it’s verifying.
Trust in the CPS itself. The CPS becomes a participant in the trust framework — not as a signing authority, but as the conveyance mechanism through which signed PASSporTs reach verifiers. Compromise or misbehavior of a CPS has framework- level consequences.

These complexities shape the design choices in the operational profiles.

       ┌──────────────┐ ─── TDM call ───────► ┌──────────────┐
       │ Originating  │ (no SIP Identity hdr) │ Terminating  │
       │   Provider   │                       │   Provider   │
       │ Auth Service │                       │ Verif Service│
       └──────┬───────┘                       └──────────────┘
              │                                      ▲
              │                                      │
              │ POST                                 │ GET PASSporT
              │ PASSporT                             │ (matched by
              │ + metadata                           │  call metadata)
              ▼                                      │
              ┌───────────────────────────────┐      │
              │             CPS               ├──────┘
              │     (Call Placement Service)  │
              │  stores PASSporTs by metadata │
              │  (calling/called/timestamp)   │
              └───────────────────────────────┘

The call goes through TDM with no Identity header; the PASSporT travels separately via the CPS, with metadata as the join key between the two paths.

RFC 8816 and the foundational architecture

RFC 8816 — Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases — is the IETF specification that established the architectural model. The RFC defines the CPS abstraction, the message flow between authentication services and verification services, the metadata structure used for indexing PASSporTs in the CPS, and the security and operational considerations that the architecture has to address. It’s the foundational reference for everything that follows.

RFC 8816 is deliberately abstract about deployment specifics. It specifies the what — the CPS abstraction, the operational workflow — without prescribing the how — which entity operates the CPS, how discovery works, what bilateral arrangements look like. Those questions are left to operational profiles, which is where the ATIS work and follow-on IETF drafts fill in.

Two operational models: broadcast and hop-by-hop

The out-of-band architecture admits two structurally different deployment patterns, each addressed by its own ATIS specification.

The broadcast model — addressed in ATIS-1000097 (currently at v004, Alternatives for Caller Authentication for Non-IP Traffic) — treats the CPS infrastructure as a shared, multi-participant service. Originating providers post PASSporTs to one or more CPS instances within a recognized CPS network; terminating providers query that network without needing to know in advance which specific CPS holds the PASSporT for a given call. The model trades operational coupling between specific provider pairs for broader, more diffuse infrastructure that any participant can use. The discovery problem is correspondingly larger, which motivates the discovery work covered below.

The hop-by-hop model — addressed in ATIS-1000105 (SHAKEN: Out-of-Band PASSporT Transmission Between Service Providers that Interconnect using TDM) — treats CPS arrangements as bilateral between specific pairs of interconnecting providers. When two providers know they have a TDM interconnection between them, they agree on a CPS that each will use for calls crossing that boundary. The model trades the broader interoperability of the broadcast approach for tighter operational control between specific peers, with simpler discovery (the CPS for a given peer-pair is known by prior agreement). It’s the more pragmatic deployment pattern in many real-world TDM-interconnect scenarios.

The two models aren’t strictly mutually exclusive — a provider might use broadcast for some traffic and hop-by-hop for others — but they reflect different operational philosophies, and the choice between them has implications for who operates CPS infrastructure and how trust in CPS operators is established.

   BROADCAST MODEL (ATIS-1000097)
   ──────────────────────────────
   Shared CPS infrastructure; originators publish, terminators
   query. Any participant can do either.

           ┌────┐    ┌────┐    ┌────┐
           │SP-A│    │SP-B│    │SP-C│   originators
           └─┬──┘    └─┬──┘    └─┬──┘
             │ POST    │ POST    │ POST
             ▼         ▼         ▼
           ┌──────────────────────────────┐
           │      Shared CPS Network      │
           │ (multi-participant service)  │
           └──────────────────────────────┘
             ▲         ▲         ▲
             │ GET     │ GET     │ GET
           ┌─┴──┐    ┌─┴──┐    ┌─┴──┐
           │SP-X│    │SP-Y│    │SP-Z│   terminators
           └────┘    └────┘    └────┘


   HOP-BY-HOP MODEL (ATIS-1000105)
   ───────────────────────────────
   Bilateral CPS per peer pair. Each TDM interconnect uses
   an agreed CPS; discovery is implicit by prior agreement.

       ┌────┐  POST  ┌─────┐  GET   ┌────┐
       │SP-A│ ─────► │ CPS │ ◄───── │SP-X│   peer A↔X
       └────┘        │ A-X │        └────┘
                     └─────┘

       ┌────┐  POST  ┌─────┐  GET   ┌────┐
       │SP-A│ ─────► │ CPS │ ◄───── │SP-Y│   peer A↔Y
       └────┘        │ A-Y │        └────┘
                     └─────┘

       ┌────┐  POST  ┌─────┐  GET   ┌────┐
       │SP-B│ ─────► │ CPS │ ◄───── │SP-X│   peer B↔X
       └────┘        │ B-X │        └────┘
                     └─────┘

The discovery problem

The broadcast model raises a distinctive operational question: how does a terminating provider discover which CPS holds the PASSporT for any given incoming call? ATIS-1000107 — STI-CPS Discovery for Out-of-Band PASSporT Transmission Involving TDM Networks — addresses this directly. It specifies the discovery mechanism a terminating provider uses to locate relevant CPS instances based on the incoming call’s metadata, treating discovery as a first-class operational concern rather than something assumed away.

This is a place where the OOB-SHAKEN design has had to make choices that don’t have analogs in the in-band model. In-band SHAKEN doesn’t have a discovery problem because the PASSporT arrives with the call. Out-of-band SHAKEN inherits the discovery question that DNS-style architectures have grappled with for decades: given a query target, how do you find the authoritative or relevant resource without prior coordination? The ATIS-1000107 mechanism is a pragmatic answer for the SHAKEN context.

The discovery problem has motivated alternative architectural approaches. ATIS-1000107 treats discovery as a CPS-network-internal question — a terminating provider queries the recognized CPS infrastructure based on call metadata. Other approaches propose using DNS itself as the discovery substrate, with telephone-number authority records pointing to authoritative placement servers in much the way DNS records point to mail servers or web hosts. The DNS approach is taken up in the VESPER-OOB work covered below; the choice between discovery architectures is one of the more consequential open questions in the OOB space.

The full ATIS spec map for this area

The TDM/non-IP work crosses several ATIS specifications. The ones in immediate scope:

ATIS-1000095.v002 — Extending STIR/SHAKEN over TDM. The baseline specification for how SHAKEN concepts apply to call paths involving TDM segments. Provides the framing the more specific specs build on.
ATIS-1000096 — SHAKEN: Out-of-Band PASSporT Transmission Involving TDM Networks. The earlier, broader specification for OOB PASSporT transmission across TDM-bearing call paths. The current operational reference for the broadcast-style approach.
ATIS-1000097.v004 — Alternatives for Caller Authentication for Non-IP Traffic. Treats OOB as one alternative among several for handling non-IP scenarios; addresses the broader question of what caller authentication can look like when SIP isn’t end-to-end.
ATIS-1000105 — Out-of-Band PASSporT Transmission Between Service Providers that Interconnect using TDM. The hop-by-hop bilateral-CPS specification.
ATIS-1000106.v002 — Viability of Non-IP Call Authentication Standards. A technical report assessing the operational viability of the various non-IP authentication approaches.
ATIS-1000107 — STI-CPS Discovery. The discovery mechanism for the broadcast model.

Most of these come from the Non-IP Call Authentication Task Force (NIPCA-TF), an ATIS PTSC group separate from the IP-NNI Joint Task Force. NIPCA-TF was specifically chartered to address the non-IP caller-authentication question, and it’s where the operational center of gravity for this work sits within ATIS.

The ATIS/SIP Forum IP-NNI Joint Task Force catalogs all the SHAKEN-related ATIS specs together, regardless of which committee produces them.

Active IETF work

Two IETF drafts are advancing the out-of-band architecture beyond RFC 8816:

RFC 9888 — Out-of-Band STIR for Service Providers (formerly draft-ietf-stir-servprovider-oob) — is the published IETF specification (June 2026, Proposed Standard). It refines the RFC 8816 architecture for service-provider deployment, addressing operational concerns that emerged during the years between RFC 8816’s publication and current deployment experience. It is the canonical IETF reference for OOB SHAKEN deployment.

draft-wendt-stir-vesper-oob — an individual draft I’m authoring as part of the broader VESPER work — addresses several questions the existing OOB specs leave open.

First, it specifies an HTTPS publish-and-retrieve interface for VESPER PASSporTs, conceptually aligned with the CPS interface model in ATIS-1000105 §7. The interface defines a small set of endpoints — POST /passports/{DEST}/{ORIG} for the calling party to publish, GET on the same path for the called party to retrieve, plus optional Connected Identity endpoints — with all authenticated operations requiring an Access JWT signed by a VESPER delegate certificate.

Second, it proposes a transparent discovery model based on certificate transparency. Rather than terminating providers querying a CPS network through bilateral provisioning or SHAKEN-specific discovery infrastructure, VESPER-OOB ties CPS discovery to the certificate transparency log itself. A CPS URI extension defined in draft-sliwa-stir-cert-cps-ext is embedded in the VESPER delegate certificate; when the certificate is submitted to a STI-CT log, the CPS URI becomes publicly visible. Monitoring parties extract the TN-to-CPS and SPC-to-CPS mappings from the logs and use them to identify the appropriate CPS for any given call. The discovery substrate is the transparency log, not bilateral provisioning. As a consequence, the bilateral re-publish action defined in ATIS-1000105 isn’t required in VESPER-OOB deployments — discovery handles the inter-CPS coordination problem differently.

Third, the draft extends OOB to bi-directional mutual authentication through Connected Identity. STIR connected identity — defined in RFC 4916 and being updated through draft-ietf-stir-rfc4916-update, which I co-author — lets the called party cryptographically assert its identity back to the caller during call setup. The existing OOB architecture is one-directional: the originating side posts a PASSporT, the terminating side queries it. VESPER-OOB extends the publish-and-retrieve flow to support a Connected Identity exchange: the CPS returns a response_uuid during the publish operation; the called party submits a response PASSporT (rsp type) signed by its own VESPER delegate certificate to a /respond/{UUID} endpoint; the caller polls or subscribes for the response via the response endpoint. The framework’s current trust model doesn’t provide symmetric caller-and-callee authentication; this is the structural change that mutual OOB makes available.

The draft is informational and exploratory rather than a proposed working group document; it’s a place to develop ideas about how the OOB architecture could evolve as the broader trust model evolves.

The regulatory dimension: the FCC NPRM

The FCC has been engaged with the non-IP caller authentication question for years, and as of April 2025 it has formally proposed to mandate it. The Notice of Proposed Rulemaking adopted on April 28, 2025 proposes that effective non-IP caller-authentication frameworks are now sufficiently developed and reasonably available, and accordingly proposes to require providers that have not upgraded their networks to IP to implement one or more of these frameworks by a date certain.

The NPRM matters for this section of the library because it elevates the operational stakes of the OOB work. The technical specifications have been advancing for years; what’s changed is the regulatory pressure for deployment. If the FCC adopts the proposed rule, US providers operating TDM-bearing networks will have to adopt one of the non-IP authentication mechanisms covered in this section by the rule’s effective date. The choice between mechanisms — broadcast vs. hop-by-hop, which CPS operators to use, how to handle discovery — becomes a compliance question rather than just an architectural preference.

The comment cycle on the NPRM closed in mid-2025; the FCC’s disposition of the proceeding will determine whether and when the mandate takes effect. As of this writing the proceeding is unresolved.

What’s hard about this

Out-of-band SHAKEN is the most operationally complex segment of the framework. The structural challenges are real:

CPS operator economics. Running CPS infrastructure costs money; the operator needs a sustainable model. Existing proposals span centralized commercial CPS providers, federated industry-operated infrastructure, and hybrid models. None has emerged as a clear consensus.
Latency budgets. Out-of-band lookups add round trips that in-band verification doesn’t have. For real-time call setup, the latency budget is tight, and discovery + lookup + verification has to fit within it.
Trust in the CPS layer. The CPS becomes part of the trust framework’s threat model. If a CPS misbehaves — fails to return a PASSporT it has, returns the wrong PASSporT, leaks data — the framework’s verification reliability is affected. The governance arrangement has to extend to CPS operators in some form.
Coexistence with in-band. Most calls won’t need OOB; the OOB infrastructure has to coexist with in-band verification without creating ambiguity about which mechanism applies for any given call.

These are tractable challenges, and the active work is making progress on each. They’re not invisible challenges, though, and honest treatment of OOB SHAKEN has to acknowledge that the operational deployment is harder than the in-band base case.

Other applications: pre-call APIs, branded calling, and messaging

The ATIS specifications and RFC 9888 address out-of-band specifically as a TDM-bridging mechanism — getting PASSporTs across call paths that lose the SIP Identity header at TDM boundaries. The architectural pattern, though, generalizes well beyond that specific use case, and parts of the industry have been applying it more broadly.

Branded calling pre-call APIs. Several branded calling solutions deploy what are effectively out-of-band mechanisms operating before a call rings — pre-call APIs that deliver verified brand identity to the terminating provider in advance of call signaling, allowing display preparation and analytics decisions to happen with the trust artifact already in hand. The deployment isn’t framed as “out-of-band SHAKEN” in the strict ATIS sense, but the architectural pattern — a separate channel carrying trust artifacts that supplement what arrives in-band — is the same pattern. The branded-calling segment has been an early validator of the OOB approach’s commercial viability outside the TDM-bridging context. The trust model is what differs: today’s deployments are proprietary, with vendor-to- terminating-provider commercial arrangements determining whose calls get displayed and how. VESPER-OOB and the open-standard PASSporT delivery model offer a path for these deployments to evolve toward an open trust foundation — same architectural pattern, but with trust derived from certificate hierarchies that any participating entity can establish, rather than from commercial gatekeepers. Whether the proprietary deployments actually evolve in that direction is one of the open questions the broader OOB trajectory is shaping.

Messaging applications. The OOB architecture applies naturally to SMS and other messaging systems, where there’s typically no protocol channel between the communicating parties to carry signed authentication artifacts at all. The current SMS infrastructure doesn’t support PASSporT conveyance in any form analogous to SIP Identity headers; the absence is structural, not incidental. An OOB-style mechanism — placement servers holding PASSporTs that asserting parties post to and verifying parties query — would let messaging applications participate in caller-authentication trust frameworks in ways the in-band model simply doesn’t enable. ATIS-1000101 (the SMS unwanted-message mitigation landscape) covers some of this territory; the broader question of bringing OOB-style PASSporT infrastructure into messaging-trust frameworks is part of the active work in the IETF STIR rechartering discussions and connects to the messaging-trust thread under trust governance.

Generalization beyond call placement. The CPS abstraction is framed around the call as the unit being placed. As the out-of-band pattern starts being applied to messaging, web-based caller-identity verification, and asynchronous flows, the call-centric framing becomes harder to defend on its own architectural terms. PASSporTs are trust artifacts that can be retrieved by any verifier authorized to do so, regardless of whether the trigger is a specific call, a messaging interaction, or some other protocol context. Whether the deployed infrastructure formalizes a more general placement-server abstraction or continues using CPS as an umbrella term covering non-call use cases is one of the open architectural questions in this space. VESPER-OOB takes a position by example: its HTTPS endpoints serve PASSporTs without privileging any particular call signaling path, and the credential-retrieval use case in the VESPER use cases draft explicitly covers contexts (messaging, web, asynchronous verification) where there’s no call to be placed at all.

Where this fits

Out-of-band SHAKEN is the framework’s answer to the architectural gap between SHAKEN’s design and the deployment reality of TDM-bearing call paths. The in-band model (SHAKEN) handles calls that stay on SIP end-to-end; out-of-band handles the rest. Together they cover the full call-path landscape that the trust framework needs to address.

The work intersects with several adjacent threads in this library. Attestation levels apply identically whether a PASSporT is conveyed in-band or out-of-band — the attestation claim is in the PASSporT regardless of how the PASSporT travels. Delegate certificates work in OOB scenarios on the same terms they work in in-band scenarios; the certificate hierarchy and signing semantics are unchanged. Rich call data carried in OOB-conveyed PASSporTs reaches the terminating provider the same way it would in-band, which means OOB enables RCD over TDM call paths as well — an underappreciated implication of the OOB work. VESPER has specific OOB-related implications through draft-wendt-stir-vesper-oob.

The FCC NPRM means the regulatory pressure on OOB deployment is likely to increase substantially over the next 12-18 months.