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

STIR — the protocol layer of caller authentication

STIR — Secure Telephone Identity Revisited — is the cryptographic protocol layer of caller authentication, specified at the IETF. It defines how an originating provider can sign an assertion about a calling identity, how that signature travels with the call, how a verifier validates it, and what the certificate model behind the signing key looks like. STIR does not specify operational rules, trust anchors, governance, or regulatory compliance — those are SHAKEN’s job, in the North American context, and other regions’ equivalents elsewhere.

This page frames how the STIR documents fit together. For the per-document treatment — what each RFC actually specifies, design choices, where I had a hand in the work — see the IETF catalog. I co-authored several of these documents (8224, 8225, 8226 in the core trilogy; 8588 in the SHAKEN PASSporT extension; 9795 in the rich call data PASSporT extension; and 9796 in the SIPCORE Call-Info delivery for RCD to end devices), and the per-document pages say so where it applies.

The logical model

STIR has four conceptual layers, each specified by its own document or set of documents.

Identity in SIP — How an authenticated identity assertion travels with a call. The mechanism is the SIP Identity header, which carries a signed token alongside the SIP INVITE. Specified by RFC 8224.

The token format — What the signed assertion looks like. PASSporT is a constrained JWT with a claim set tailored to telephone identity (originating number, destination number, timestamp). Specified by RFC 8225. Designed for extensibility: every later development in STIR is implemented as a PASSporT extension rather than a parallel protocol.

The certificate model — What the signing key’s authority is and how that authority is encoded. STI certificates carry a TNAuthList extension naming the telephone numbers, ranges, or service-provider codes the certificate authorizes signing for. Specified by RFC 8226 (page forthcoming).

Extensions — Additional claim types that PASSporTs can carry, each addressing a specific operational case. PASSporT was designed for extensibility: every later development in STIR is implemented as a PASSporT extension or a related auxiliary mechanism rather than a parallel protocol. The catalog of STIR extensions and related work — the SHAKEN extension, diversion, rich call data, identity errors, ACME, messaging, delegation, out-of-band, and the active drafts — lives on the STIR extensions page.

How the pieces compose at runtime

A signed call moves through the layers in a specific order. The originating provider:

  1. Identifies the calling number and the destination number.
  2. Constructs a PASSporT (RFC 8225) with orig, dest, and iat claims, plus any extension-specific claims (the SHAKEN attest and origid claims, in deployed practice).
  3. Signs the PASSporT with a private key whose certificate (RFC 8226) authorizes assertion over the calling number.
  4. Inserts the PASSporT into the SIP Identity header (RFC 8224) alongside the INVITE.

The terminating provider:

  1. Receives the SIP INVITE, sees the Identity header.
  2. Retrieves the certificate from the URL named in the PASSporT’s x5u header field.
  3. Validates the certificate against the trust anchors managed by governance (which anchors specifically depends on the deployment profile — for SHAKEN, the STI-PA-managed trust list).
  4. Verifies the PASSporT signature against the validated certificate.
  5. Confirms that the certificate’s TNAuthList authorizes the calling number actually being asserted.

If all of those checks pass, the assertion is valid: the call arrives with a verified claim that the originating provider asserts the named identity for the named number, signed by a key whose certificate is recognized by the trust anchors in use. What the terminating side does with that — admit, reject, score, brand, log, escalate — is policy, not protocol. STIR specifies the mechanism; the policy lives downstream.

                         ORIGINATING SIDE
                         ────────────────
                  ┌──────────────────────────────┐
                  │  1. Identify calling and     │
                  │     destination numbers      │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  2. Construct PASSporT       │
                  │     (RFC 8225): orig, dest,  │
                  │     iat, + extensions        │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  3. Sign with cert authorized│
                  │     for calling TN (8226)    │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  4. Insert into SIP Identity │
                  │     header (RFC 8224)        │
                  └──────────────┬───────────────┘
                                 │
                                 │ INVITE traverses network
                                 ▼
                         TERMINATING SIDE
                         ────────────────
                  ┌──────────────────────────────┐
                  │  1. Extract Identity header  │
                  │     from inbound INVITE      │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  2. Fetch cert from x5u URL  │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  3. Validate cert against    │
                  │     trust anchors (SHAKEN    │
                  │     STI-PA trust list)       │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  4. Verify PASSporT signature│
                  │     and check TNAuthList     │
                  │     authorizes calling TN    │
                  └──────────────┬───────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │  Verified call ready for     │
                  │  policy decision (admit /    │
                  │  score / reject / log /      │
                  │  brand)                      │
                  └──────────────────────────────┘

Reading order

If you’re new to STIR, the documents to read in order are:

  1. RFC 7340 — STIR Problem Statement and Requirements (foundational, page forthcoming)
  2. RFC 7375 — STIR Threat Model (foundational, page forthcoming)
  3. RFC 8224 — Authenticated Identity Management in the Session Initiation Protocol
  4. RFC 8225 — PASSporT
  5. RFC 8226 — Secure Telephone Identity Credentials: Certificates (page forthcoming)
  6. RFC 8588 — PASSporT Extension for SHAKEN (page forthcoming)

Those six documents cover the core protocol layer. Specific extensions can be picked up as you encounter them in production contexts; the IETF catalog lists all of them.

What’s not here

This page covers the protocol layer only. Operational concerns — who issues certificates, what the trust anchors are, what attestation levels mean in production, how the framework is governed, what regulators have mandated — are SHAKEN’s territory. The two together make a deployable framework; on its own, STIR is a specification waiting for a profile.