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

RFC 9410 — Handling of Identity Header Errors for STIR

RFC 9410 (Wendt — July 2023) is the IETF specification that fills a gap RFC 8224 §6.2.2 explicitly left for future work: how a verification service communicates errors back to an upstream authentication service when local policy says the call should continue despite verification failure, and how to identify which Identity header field produced the error in messages that carry several of them. I am the sole author. The document is small in scope but operationally consequential — without a way to signal errors non-fatally and to disambiguate them, deployments that process multiple PASSporTs (delegated calls, RCD-bearing PASSporTs alongside SHAKEN, messaging) have no protocol-level feedback path.

Why it was needed

The base STIR specification (RFC 8224) specifies 4xx error codes for verification failures, but those codes are meant to terminate the SIP transaction. Two practical problems followed:

  • Verification policy isn’t always “fail-closed.” Many deployments treat verification failures as informational — the call should still complete, but the originating side (or its upstream authentication service) should know that something went wrong so corrective action can be taken. A 4xx response terminates the call, which is the wrong outcome when the policy is “continue but inform.”
  • A SIP message can carry multiple Identity header fields — one for SHAKEN attestation, another for delegated-authority signing, others for diversion or RCD extensions. A 4xx response identifies an error in the message overall, not in a specific Identity header. Without a way to point the authentication service at which PASSporT failed, diagnostics are guesswork.

RFC 8224 §6.2.2 acknowledges both gaps and explicitly defers them to future work. RFC 9410 is that future work.

What it specifies

Three pieces of mechanism, all small:

  • A new Reason header field protocol — STIR. Registered in the SIP Reason Protocols registry (alongside SIP and Q.850). A Reason: STIR ;cause=NNN ;text="..." header field carries a STIR error cause code (the 4xx codes from RFC 8224) attached to a provisional or final response, conveying the verification outcome to the authentication service without requiring the call to terminate.
  • A new Reason header field parameter — ppi. Stands for PASSporT Identifier. Registered in the SIP Header Field Parameters registry. The parameter value is either a full PASSporT or a compact form (just the JWS signature, prefixed by two periods per RFC 8225 §7). Compact form is recommended for privacy. A ppi parameter binds a Reason header field to the specific Identity header field that produced the error.
  • Procedures for multiple Identity header fields. When more than one Identity header field has errors, the verification service includes multiple Reason: STIR header fields, each with its own ppi parameter pointing at the corresponding PASSporT. This composes with RFC 9366 (Multiple SIP Reason Header Field Values), which formalizes carrying more than one Reason header field on a single response.

The mechanism is opt-in and additive — RFC 8224’s existing 4xx behavior remains valid for fail-closed deployments. RFC 9410 gives the alternative mechanism the deployment community has been asking for since SHAKEN went into production.

Design choices worth knowing

The main design decision is the provisional-response-as-feedback channel. The mechanism uses provisional (1xx) responses, which don’t terminate the SIP transaction, so the call can continue even as the verification outcome is reported. A final response can also carry the Reason header field if local policy decides the call shouldn’t continue, but the more interesting use case is the provisional-response one — it cleanly separates the verification feedback channel from the call-disposition decision.

Another is the PASSporT-as-identifier choice. The ppi parameter could have used some abstract index (“Identity header field #2”), but pointing at the actual PASSporT (or its signature in compact form) is unambiguous regardless of header ordering or routing rewrites. The compact form — just the JWS signature with the two-period prefix from RFC 8225 §7 — keeps the Reason header field short and avoids leaking the PASSporT contents in error responses.

A third is the explicit composition with RFC 9366. The multiple-error scenario depends on the ability to carry multiple Reason header fields, which RFC 9366 formalized separately. RFC 9410 doesn’t redefine that mechanism; it just references it. This kept the scope of 9410 narrow and let the multi-Reason work be reusable beyond STIR.

Where this document is referenced

  • RFC 8224 is the base STIR/SIP specification this document supplements. The errata-style framing — “8224 §6.2.2 said this needed future work; here it is” — captures the relationship.
  • RFC 8225 defines the PASSporT format and the compact-form signature representation that the ppi parameter uses.
  • STIR is the topic page for the protocol layer this document supplements.
  • For deployments where verification feedback matters in practice — SHAKEN, RCD, delegated authority — see SHAKEN.