Rich call data — extending STIR with verified content beyond the telephone number

Rich call data — RCD — extends STIR with content beyond the telephone number. Where STIR’s core function is establishing trust for the calling number through an explicit certificate hierarchy, RCD adds content that travels with that calling identity: a calling-party name, a logo, an organizational identity, a reason for the call. The framework signs the content cryptographically the same way it signs the calling-number authorization, and the called party’s device is expected to render it as part of the incoming-call presentation. The trust question — and the central concern of this page — is making sure that RCD content inherits the same explicit-trust foundation that STIR provides for the telephone number, rather than being treated as self-asserted content that any caller could fraudulently insert.

I’m a co-author of RFC 9795 (the substantive PASSporT extension for rich call data, in the STIR working group) and RFC 9796 (the supplementary SIPCORE specification for delivering verified RCD content to end-user devices over the trusted SIP UNI). I co-chair the ATIS IP-NNI Task Force that produces ATIS-1000094, the SHAKEN operational profile for RCD. I’m authoring the VESPER draft at the IETF that extends the trust model in directions covered toward the end of this page. The framing here is from inside the work.

What rich call data is

The standard SHAKEN call delivers a verified calling number and an attestation level. That’s a reasonable trust signal but a poor presentation signal — knowing that “+1-555-123-4567” is authorized doesn’t tell the called party who is actually calling. The pre-RCD industry response was Calling Name (CNAM) lookups, where terminating providers queried out-of-band databases to attach a name to incoming calls. CNAM has well-known weaknesses. The data is not authoritative — no authority vouches for the name being correct. The data has no tie to the calling party — neither authoritatively (no process linking the database entry to the actual calling entity) nor cryptographically (no signature, no certificate, no protocol-level binding). The lookup also happens separately from authentication rather than as part of it. CNAM is descriptive metadata attached after the fact; it is not verified content carried with the call.

The FCC’s Ninth Further Notice of Proposed Rulemaking (CG Docket No. 17-59 / WC Docket No. 17-97, adopted October 28, 2025) takes up the CNAM problem directly. The FNPRM characterizes CNAM as unauthenticated, out-of-band data that cannot provide cryptographic or authoritative assurance of caller identity, and proposes a path forward built on a verified calling name signed via STIR/RCD. The specific proposed rule would require terminating providers to display verified caller name when transmitting an indication that a call has received an A-level attestation, with the verified name carried via the RCD framework. The FNPRM also asks whether legacy CNAM should be deprecated in favor of trust-anchored identity systems. The proceeding is open as of this writing, with reply comments due in early 2026.

RCD is the structural answer. The originating side — whether that’s the carrier, an enterprise using delegate certificates, or a service operating on behalf of one — includes RCD content in the signed PASSporT. The content rides with the cryptographic chain rather than being looked up separately. By the time the terminating provider verifies the signature, the displayable content is already trustworthy at the same level as the calling number itself.

What can go in RCD content has expanded over the spec’s development. The current model includes: a calling-party name, a logo (typically by URI reference), one or more JSON-encoded contact-card fields, a reason for the call (in some profiles), a jurisdiction indicator, and metadata about the type of caller (individual, business, government). The content set is extensible; implementations can add fields under the framework’s content-claim structure.

The IETF specs

RFC 9795 is the core RCD specification — the work in the STIR working group that defines how RCD content is signed and travels with the call. RFC 9796 is a supplementary specification from a different working group (SIPCORE), addressing how already-verified RCD content gets delivered to end-user devices over the trusted SIP UNI. The substantive design work is in 9795; 9796 is the delivery layer that gets the verified content from network edge to handset.

RFC 9795 — PASSporT Extension for Rich Call Data defines the extension that lets RCD content be carried in a STIR PASSporT. It specifies the rcd PASSporT type, the structure of the rich-call-data claim (rcd), how the content is encoded for signature coverage, and how it composes with the SHAKEN attestation extension. The RFC was previously draft-ietf-stir-passport-rcd; it went through twenty-six revisions before publication, reflecting the substantial design work required to balance content flexibility with signature coverage.

RFC 9796 — SIP Call-Info Header Field for Rich Call Data is the supplementary SIPCORE specification that handles a different problem: delivery to end-user devices once the RCD content has been verified by the network. The Call-Info header in SIP is the established mechanism for conveying descriptive metadata to endpoints over the UNI; RFC 9796 specifies how RCD content already verified at the network endpoint gets conveyed onward to user-agent devices via Call-Info. The on-the-wire content at this layer is unsigned because the device isn’t expected to perform cryptographic verification itself — the network has already done that work, and the SIP header is the trusted conveyance mechanism for the validated content. RFC 9796 was previously draft-ietf-sipcore-callinfo-rcd. The relationship to 9795 is hierarchical rather than parallel: 9795 is the substantive specification that makes RCD trust possible, and 9796 is the delivery mechanism that ensures verified content reaches the device.

Read together the two specifications cover the full path from origination — where RCD content is signed into the PASSporT (RFC 9795) — through verification at the network endpoint and on to delivery (RFC 9796) where the verified content reaches the user-agent device. RFC 8226 underlies the signing model. But the substance is in 9795; 9796 is the supplementary delivery piece that follows from it.

The deployment trajectory for the two specs is also asymmetric. RFC 9795 is a candidate for explicit network-to-network mandate through STIR authentication frameworks — interoperable signing and verification between networks is exactly what STIR/SHAKEN deployment is built around, and 9795’s behavior at the network-to-network boundary makes it a natural target for prescriptive rules. RFC 9796 sits at the UNI, which is generally more proprietary and doesn’t have to follow a prescriptive interoperable framework (though interoperability is welcome when achievable). 9796’s adoption path is more likely through bodies like 3GPP or GSMA picking it up in mobile handset specifications than through a formal cross-network mandate, and it remains an open question how much explicit adoption 9796 will see in practice.

ATIS-1000094 — the SHAKEN operational profile

ATIS-1000094 — Calling Name and Rich Call Data Handling Procedures — is the SHAKEN operational profile that operationalizes RCD for North American deployment. Currently at v002, the spec covers the operational arrangements that the IETF RFCs leave open: what content types are expected to be carried, how RCD interacts with attestation levels, how terminating providers handle calls with and without RCD content, and how the RCD claim coordinates with the older CNAM infrastructure during transition.

The transition story matters. CNAM databases represent decades of operational investment, and they don’t disappear when RCD deploys. ATIS-1000094 specifies how a network handles cases where RCD content arrives in the PASSporT, where it doesn’t and CNAM is available, and where neither is available. This isn’t a glamorous part of the spec, but it’s what makes RCD deployable without breaking the existing display experience for calls that haven’t migrated.

The spec also establishes the operational expectations around which entity is authorized to assert which RCD content — a question that turns out to be more difficult than it first appears, and that motivates the trust discussion below. ATIS-1000081 (Framework for Display of Verified Caller) is the companion spec on the display side, covering how terminating providers and user-agent devices are expected to render verified caller information.

Industry deployment

The deployment landscape for RCD today is dominated by what the market calls “branded calling” — proprietary commercial solutions in which a vendor contracts with terminating providers to display brand identity (name, logo, sometimes additional context) for participating enterprises. Multiple vendors offer these solutions; adoption has grown among enterprises whose calls are commercially valuable enough to justify the fees — banks confirming transactions, healthcare providers reaching patients, delivery services coordinating with recipients, government services delivering notifications. The deployments work, in the sense that participating enterprises see meaningful answer-rate improvements when their calls display verified content.

But branded calling as it exists today is not the end state the open standards work is aimed at, and it’s worth being precise about the distinction. Branded-calling solutions are proprietary, with commercial arrangements between specific vendors and specific terminating providers determining which calls get displayed how. The benefits accrue selectively — to enterprises that pay for the service through the vendors that hold terminating-provider distribution relationships. The trust signal the called party sees is filtered through gatekeepers whose commercial incentives don’t always align with foundational trust.

The open trust framework that STIR + RCD + VESPER are built toward looks fundamentally different. A delegate certificate is issued to the responsible entity by an authority whose role is to validate Right-to-Use of the telephone number and the authority to assert specific RCD claims, with JWT Claim Constraints in the certificate scoping what content the entity is permitted to assert. Vetting happens at the authority level through association to the responsible entity and verification of authority over the displayed identity. The framework allows broad participation by any entity that can establish those credentials — not just enterprises that have negotiated through a gatekeeper. Trust derives from the certificate hierarchy and the verification work the issuer has done, not from a commercial relationship with a particular terminating provider.

Both arrangements coexist today, and elements of branded calling do work over RCD’s technical substrate. But the architectural question — whether the trust framework remains open and broadly participable, or whether commercial gatekeepers consolidate around selective proprietary layers — is a live one. The regulatory direction in the FCC’s Call Branding FNPRM points toward standardizing on the open verification mechanism rather than letting proprietary branded-calling solutions persist as the only viable path. The trajectory of delegate certificates and VESPER as deployable standards is what determines whether the open framework reaches the scale that lets it displace, or coexist on equal terms with, the proprietary layer.

How RCD inherits trust

STIR establishes trust for the telephone number through an explicit certificate hierarchy: the certificate issuer attests that the bearer has authority over the listed telephone numbers, and the verifier can trace that attestation back to recognized authority. The trust isn’t asserted by the caller; it’s established by the issuer of the certificate that signs the call.

RCD needs to inherit that same explicit trust for the content it carries. A signed RCD claim asserting a name and logo is only as trustworthy as the explicit verification behind the claim that the bearer is authorized to represent that identity. Without that verification, RCD becomes self-asserted content — any caller could claim any name and logo, with the same fraud potential as illegitimate caller-ID spoofing, just at the brand layer instead of the telephone-number layer.

The verification mechanism that closes this is JWT Claim Constraints in delegate certificates. JWT Claim Constraints were originally defined in RFC 8226 (Secure Telephone Identity Credentials: Certificates) and extended in RFC 9118 (Enhanced JWT Claim Constraints for STIR Certificates). The constraints let the certificate issuer specify exactly what claims the certificate’s bearer is authorized to assert — including, for RCD specifically, what RCD content is authorized.

The trust pattern is: a delegate certificate issued to the responsible entity carries JWT Claim Constraints that scope what the entity can assert. The issuer signs the constraints into the certificate, which means the issuer has done the verification work — confirming the entity actually represents the identity it will claim — before issuing the certificate. When the entity signs an RCD PASSporT with that constrained delegate certificate, the verifier checks not just that the signature is valid but that the asserted RCD content falls within the constraints the issuer authorized. The issuer’s verification carries into every signed call through the constrained certificate; the RCD content inherits trust transitively, the same way the telephone number does.

Active IETF work on the ACME authority token with JWT claim constraints (draft-ietf-acme-authority-token-jwtclaimcon, co-authored) brings this pattern to scale by adapting the ACME automated certificate issuance flow to handle the constraints. The work is the bridge between the cryptographic mechanism and the operational deployment volumes that broad RCD adoption needs.

What’s still being worked out at the policy layer is which authorities verify which kinds of identity, and what the operational expectations are for that verification. The cryptographic and protocol-level pieces are in place; the operational maturity around brand-identity verification — who acts as the issuer, what verification standards they apply, how they’re held accountable — is what determines deployment scale. This is an active area in industry forums and the topic of ongoing notebook entries.

Why delegate certificates are the right signing position for RCD

Beyond enabling the JWT Claim Constraints mechanism described above, delegate certificates also resolve a layer mismatch in who ought to be doing the signing. RCD content needs to be asserted by the entity with actual authority over it — not by a carrier or service provider acting on the entity’s behalf. The carrier has authority over the calling number; it doesn’t have authority over the calling-party identity. Asking the carrier to assert RCD content for an entity it doesn’t represent stretches the trust model in a direction it isn’t structured to support.

Delegate certificates put the signing where the authority lives (see delegate certificates). The carrier delegates a constrained certificate to the responsible entity (or to a service operating on the entity’s authority). The entity signs the RCD claim with its own delegate certificate, and the trust chain accurately reflects the actual authority structure: the carrier vouches for the telephone-number authority, the entity vouches for the calling-party identity content, and the issuer’s JWT Claim Constraints establish exactly what content the entity is authorized to assert. ATIS-1000092 specifies the operational profile.

Why VESPER matters for RCD

VESPER takes the verification story further by binding additional trust grounding into the delegate certificate itself.

VESPER defines a delegate-certificate profile that binds three trust elements together: telephone-number authority (via TNAuthList), the responsible entity’s internet-domain identity (via SubjectAltName dNSName), and a Signed Certificate Timestamp proving public log inclusion. For RCD specifically, the domain-identity binding adds an additional verification anchor. An entity asserting RCD content typically also has a domain identity in the WebPKI — chase.com is the canonical example. WebPKI has spent a decade building infrastructure for the question of “who is the legitimate entity behind this domain,” with Certificate Transparency, Extended Validation descendants, and a substantial trust hierarchy. A VESPER-bound RCD claim ties the calling-party identity assertion to that infrastructure on top of the JWT Claim Constraints verification described above.

The mechanism is direct. A VESPER delegate certificate can include the JWTClaimConstraints extension authorizing the holder to assert specific PASSporT claims, including the rcd claim from RFC 9795. The claim constraints are themselves backed by a JWTClaimConstraints Authority Token, issued by an authority recognized to attest the brand’s right to assert specific RCD content. The RCD claim, the telephone-number authority, the domain identity, and (where applicable) the originating-provider authorization end up bound together in a single auditable certificate. The PASSporT carrying the RCD content is signed by that certificate; verification chains the RCD claim through the same trust artifact that establishes the entity’s right to use the calling number.

The combined model — VESPER’s certificate profile plus the JWT Claim Constraints mechanism plus ATIS-1000094’s RCD content claims and operational handling — describes a deployable model for trustworthy RCD at scale. VESPER adds the domain-identity grounding and the transitive trust across digital channels; JWT Claim Constraints provide the content-level authorization; ATIS-1000094 provides the content structure and operational handling. Each layer addresses something the others can’t, and together they make the trust story complete from telephone- network calling identity through to the verified content displayed to the called party.

VESPER also brings Certificate Transparency to the STIR/SHAKEN ecosystem, requiring every delegate certificate to be logged in a STI-CT log with the resulting SCT embedded in the certificate. For RCD specifically, this means misissuance — a delegate certificate authorizing RCD claims without legitimate basis — becomes publicly detectable in a way it isn’t today. CT was the load-bearing trust innovation that made WebPKI tractable at internet scale; bringing it to the caller-identity ecosystem is meaningful for RCD precisely because RCD content is what fraudulent actors most want to misuse.

VESPER covers the full design.

Where this fits

Rich call data sits at the layer where caller authentication extends into content beyond the telephone number itself. The IETF specs (RFC 9795 + RFC 9796) and the SHAKEN operational profile (ATIS-1000094) make the technical layer work. The verification story — how RCD content inherits trust from the certificate hierarchy through JWT Claim Constraints in delegate certificates — is what makes the technical layer trustable at scale. VESPER extends the verification with domain-identity binding and Certificate Transparency. Each layer does specific work that the others can’t; together they describe a deployable model for content that called parties can rely on.