appliedbits
LIBRARY  ·  STIR/SHAKEN LIBRARY ENTRY
Last updated 2026-05-04 drafted

STIR extensions and related work — the family of PASSporT extensions, auxiliary mechanisms, and active drafts

The core STIR protocol — RFC 8224 (identity in SIP), RFC 8225 (PASSporT), RFC 8226 (certificates) — is the foundation. Almost everything else that has happened in the STIR working group is either an extension to PASSporT for a specific operational case, an auxiliary mechanism for certificate management or error handling, or an active draft that hasn’t yet stabilized into an RFC. This page catalogs that body of work.

Some entries are brief because depth lives elsewhere — the concept pages on attestation, RCD, delegate certificates, and out-of-band SHAKEN do the synthesis work, and per-RFC pages in the IETF catalog handle document-level treatment as they’re written. The catalog’s purpose is to make the surface area visible.

   ┌───────────────────────────────────────────────────────────┐
   │             STIR base — RFC 8224, 8225, 8226              │
   │    Identity in SIP  ·  PASSporT format  ·  Cert model     │
   └───────┬─────────────────────┬─────────────────────┬───────┘
           │                     │                     │
           ▼                     ▼                     ▼
   ┌───────────────┐     ┌───────────────┐     ┌───────────────┐
   │   PASSporT    │     │ Certificate / │     │ Transport &   │
   │  extensions   │     │ PKI mechanisms│     │  operational  │
   │               │     │               │     │               │
   │ shaken (8588) │     │ delegated     │     │ OOB STIR      │
   │ div    (8946) │     │ certs (9060)  │     │ (RFC 8816)    │
   │ rcd    (9795) │     │               │     │               │
   │ rph    (8443) │     │ ACME for STIR │     │ identity-hdr  │
   │ rph-em (9027) │     │ (RFC 9447)    │     │ errors (9410) │
   │ msg    (9475) │     │               │     │               │
   │               │     │ TNAuthList    │     │               │
   │               │     │ ACME (9448)   │     │               │
   └───────────────┘     └───────────────┘     └───────────────┘

   Active IETF drafts continue each track (see IETF catalog).

PASSporT extensions

shaken — SHAKEN attestation (RFC 8588)

The most-deployed PASSporT extension. Defines the shaken PASSporT type along with the attest claim (A/B/C attestation levels) and the origid claim (opaque originating-provider identifier). The IETF formalization of the SHAKEN PASSporT type that bridges SHAKEN’s operational profile (ATIS-1000074) into the IETF standards-track family. I’m a primary author. Deep dive on the attestation levels concept page.

div — Diversion (RFC 8946 + ATIS-1000085)

A necessary authentication mechanism to cover real-world diversion that happens in the telephone network — call forwarding and similar scenarios where the destination telephone number gets changed in transit. The div PASSporT type lets the diverting party sign an assertion attesting to the diversion, so the original signature isn’t broken when the destination changes. ATIS-1000085 is the SHAKEN operational profile of div. Deployment in practice has been limited; the mechanism exists for the cases where it matters.

rcd — Rich Call Data (RFC 9795)

The PASSporT extension that carries authenticated rich call data: calling-party display name, branding, reason-for-call, and related metadata. RFC 9795 specifies the PASSporT extension itself; RFC 9796 specifies the SIP Call-Info mechanism that delivers RCD content from the network to end devices over the user-network interface. ATIS-1000094 is the SHAKEN operational profile. I’m a co-author of both 9795 and 9796. Deep dive on the rich call data concept page.

Resource priority — rph (RFC 8443) and emergency services (RFC 9027)

PASSporT extensions for authenticating SIP Resource-Priority header values. RFC 8443 is the base extension; RFC 9027 builds on it for emergency services calling specifically. ATIS-1000078 is the SHAKEN operational profile of 8443; ATIS-1000098 is the operational profile for 9027. Used for NS/EP (National Security / Emergency Preparedness) and emergency-services call prioritization where signaling integrity is needed beyond caller-ID.

Messaging — msg (RFC 9475)

Extends STIR to text messaging by defining the msg PASSporT type and the msgi claim, which carries an integrity hash of the message body. Lets messaging providers sign assertions about sender identity for SMS, MMS, and RCS — the same trust framework applied to text instead of voice. Co-authored with Jon Peterson. This work intersects with the broader messaging trust framework discussions happening in ATIS, GSMA, and the FCC.

Certificate and operational mechanisms

Delegated authority (RFC 9060 + ATIS-1000092)

The certificate model for the customer-of-customer case: a service provider issues a constrained certificate that a downstream party (an enterprise, a delegate of an enterprise) uses to sign calls itself. The mechanism that supports user-level authentication of the responsible entity, distinct from network-level authentication via SHAKEN attestation. Deep dive on the delegate certificates concept page.

Out-of-band STIR (RFC 8816 and active drafts)

For call paths where SIP signaling doesn’t travel end to end — TDM segments, certain peering arrangements, gateway providers. RFC 8816 defines the original out-of-band mechanism using a Call Placement Service (CPS) to publish PASSporTs separately from the call signaling. RFC 9888 (Service-Provider OOB) and the active draft draft-wendt-stir-vesper-oob extend the mechanism for service-provider-to-service-provider OOB and for VESPER deployment. Deep dive on the out-of-band concept page.

Identity header errors (RFC 9410)

Defines how SIP identity-header verification failures should be reported and handled — the error codes, response semantics, and operational expectations when verification fails. Sole-author RFC. A small but consequential spec: without it, error reporting across STIR implementations was ad-hoc and made interoperability debugging harder than it needed to be.

ACME for STIR (RFC 9447 + RFC 9448)

Adapts the IETF’s Automated Certificate Management Environment (ACME) protocol — better known for issuing TLS certificates via Let’s Encrypt — to issue STIR certificates. RFC 9447 defines a new ACME challenge type using authority tokens. RFC 9448 defines the TNAuthList profile of ACME authority tokens, which is what actually lets a service provider prove control over a set of telephone numbers when requesting an STI certificate. I’m a primary author of 9448 and a co-author of 9447. Together they make automated STI certificate issuance possible at scale. Active extension work on ACME for STIR — adding JWT claim constraints handling for finer-grained delegation — is covered in the active drafts section below.

Active drafts

Connected Identity (draft-ietf-stir-rfc4916-update)

Updates RFC 4916’s connected-identity mechanism for STIR to support bidirectional identity verification. Lets a called party’s network sign a rsp (response) PASSporT that the calling party can verify, completing the trust loop in both directions. Used by VESPER for transitive-trust scenarios and broadly applicable to any deployment that needs symmetric identity verification.

Service-Provider Out-of-Band STIR (RFC 9888)

A service-provider-to-service-provider out-of-band mechanism distinct from the original RFC 8816 design. Addresses scenarios where two service providers need to exchange STIR PASSporTs out-of-band without involving an end-user CPS. In RFC Editor queue.

Certificate Transparency for STIR

Active draft work on adding certificate transparency to the STIR ecosystem — embedded SCTs in STI certificates, transparency log operators, and the monitoring model that lets relying parties detect certificate misissuance. The transparency model is also the foundation that VESPER’s trust framework builds on.

VESPER (draft-wendt-stir-vesper)

Extends STIR with cryptographic binding between telephone-number authority and internet-domain identity, enabling a transitive trust model that authenticates the responsible caller across both telephone-network and digital-channel contexts. Active draft I’m authoring; the VESPER topic page covers the architecture and use cases. See VESPER.

ACME authority token with JWT claim constraints (draft-ietf-acme-authority-token-jwtclaimcon)

Active IETF ACME working group draft extending the RFC 9447 / RFC 9448 ACME flow to handle JWT Claim Constraints — defined first in RFC 8226 (Secure Telephone Identity Credentials: Certificates) and extended in RFC 9118 (Enhanced JWT Claim Constraints for STIR Certificates). Lets a certificate authority issue a constrained STIR certificate via ACME — useful for delegate-certificate issuance and other cases where the cert should authorize signing for a specific subset of TNs rather than the full set the issuer could authorize. Builds on the foundation of 9447 (challenge mechanism) and 9448 (TNAuthList profile) by adding the constraint-handling needed for finer- grained delegation. Co-authored.

How to read this catalog

The catalog is sorted by category rather than by RFC number or chronology. Each entry is brief on this page; depth lives in the concept pages and per-RFC pages it links to.

If you’re looking for the SHAKEN side of operational deployment — how attestation actually gets assigned, how RCD presents in the display layer, how delegation handles enterprise calls — start with the concept pages on those topics. Each concept page synthesizes the IETF protocol view and the ATIS operational view, with forward pointers to deeper material where it exists.

If you’re looking for the document-level view — what each RFC specifies, design history, references — start with the IETF catalog. Per-RFC pages are added incrementally.

If you’re looking for the ATIS-side companion specifications, the IP-NNI Joint Task Force page lists the full ATIS-1000xxx catalog with topic groupings.

Where this fits

STIR is intentionally a foundation that other work builds on. The extensions catalog reflects that: the core protocol is small and stable, and the ecosystem of extensions, profiles, and auxiliary mechanisms is what actually gets deployed and continues to evolve. New extensions get added when the trust framework needs to authenticate something STIR doesn’t yet cover — which is why the active-drafts section keeps growing.