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

RFC 9795 — PASSporT Extension for Rich Call Data

RFC 9795 (Wendt, Peterson — July 2025) is the IETF specification that extends PASSporT with rich call metadata — caller name, branding, reason for call, jurisdiction-specific identifiers, and other content beyond the calling number — cryptographically signed and integrity-protected so the called party can rely on what they see rather than on a database lookup or an asserted display string. I am co-author. The document is the signed-content half of the verified caller-identity story; the SIP delivery half over the UNI to end devices is RFC 9796 (SIPCORE), a companion specification.

What it specifies

Two pieces of mechanism, paired:

  • A new PASSporT extension type — rcd. Registered in the PASSporT Extensions registry per RFC 8225. An rcd PASSporT carries the rich-call-data claim alongside the base PASSporT claims (orig, dest, iat). The extension can also be combined additively with other PASSporT extension types — for example, an rcd claim added to a shaken PASSporT — through the JSON pointer mechanism the document specifies.
  • A new JWT claim — rcd. Carries a JSON object containing one or more named keys. The document defines an initial set: nam (display name) is the central key; additional keys cover branding, reason for call, jurisdiction information, and other call-context metadata. nam is required when the rcd claim is present; the others are optional and can be added as the trust framework needs more expressive content.

The rcd claim is structured to be extensible. JSON pointer (RFC 6901) is used to reference specific elements within the claim, which makes it possible to constrain what a delegated certificate is permitted to assert at the level of individual rcd keys (rather than all-or-nothing per claim). This connects to the JWT Claim Constraints / Enhanced JWT Claim Constraints model from RFC 8226 and RFC 9118 — a delegate certificate can be issued with constraints saying “this holder may sign rcd.nam but not rcd.brand,” which is what makes large-scale third-party RCD content provisioning workable.

What problem it solves

The pre-RFC-9795 caller-name story relied on CNAM — a database lookup performed by the terminating provider, returning an unsigned string that the consumer device displays as the caller name. CNAM has structural problems: the data isn’t authenticated against the calling party’s identity; the lookup happens at the terminating side without the originating side having any control over what’s returned; the data sources are fragmented across providers and aggregators with no cryptographic binding to the call.

RCD shifts the model. The originating side (or a third-party RCD authority operating on the originating side’s behalf) signs the rich content into a PASSporT, with cryptographic binding to the calling number through TNAuthList. The signed PASSporT travels with the call signaling. The terminating side verifies the signature and the binding, and only then renders the content to the consumer. The trust model collapses from “trust the database” to “trust the certificate hierarchy” — which is the same hierarchy that already authenticates the calling number itself.

The document explicitly notes that some RCD use cases — like third-party reputation services adding context to a call — form a “sub-case of out-of-band (RFC 8816) use cases.” The RCD PASSporT can be conveyed in-band through SIP, or out-of-band through CPS retrieval, or both.

Design choices worth knowing

One is the JSON-pointer-based delegation model. Rather than treating the rcd claim as an opaque blob, the document allows constraints to be expressed against individual keys within the claim. This is what enables a delegate-certificate model where a third-party RCD provider holds a certificate constrained to sign only specific rcd content (a brand attestation but not the calling number itself, for example) — a structurally necessary primitive for the RCD ecosystem to scale beyond originating-provider-as-RCD-authority.

Another is the additive-combination model. An rcd claim can ride alongside other PASSporT extensions on the same Identity header field — a SHAKEN-attested call can also carry RCD content, for example. This composes cleanly because the PASSporT type discriminator and the claims registry are separate axes; there’s no exclusivity between extension types.

A third is the integrity-by-default through PASSporT signing. The RCD content is integrity-protected by virtue of being inside the signed JWT — there’s no separate integrity mechanism, no out-of-band hash. The same signature that authenticates the originator authenticates the content the originator is asserting.

Where this document is referenced

  • Rich call data is the topic page covering how RCD fits into the broader trust framework, including the operational profile (ATIS-1000094) and the verification story.
  • RFC 9796 is the companion SIPCORE specification — RCD delivered over the SIP UNI to end devices, unsigned but derived from the verified PASSporT contents the terminating network has already validated. (Page forthcoming.)
  • RFC 8225 defines the PASSporT extension framework that 9795 plugs into.
  • Delegate certificates describes the certificate model that uses JWT Claim Constraints to bind delegated authority — the mechanism that makes scoped-RCD-signing certificates possible.
  • VESPER, the domain-bound STIR extension I’m authoring, builds on the RCD framework — VESPER’s Certificate Transparency and domain-binding additions are intended to give RCD content a stronger trust foundation than the current TN-only certificate hierarchy provides.
  • The FCC’s Ninth FNPRM (October 2025), which proposes verified caller name via STIR/RCD and asks whether legacy CNAM should be deprecated, treats this document as the reference specification for what “verified caller identity” delivered in protocol terms means. See FCC current rulemaking.