Summary

  • RFC 9796 defines verified, integrity, call-reason and purpose=jcard parameters for Rich Call Data in SIP Call-Info. verified=true says the actor that inserted that particular field successfully verified the represented information.
  • The receiving device still needs an authenticated, trusted relationship with that actor. The indication is field-scoped; it does not automatically authenticate every displayed attribute, the caller’s purpose, the conversation or the eventual outcome.
  • A resource hash can prove that retrieved bytes match a declared digest. It cannot by itself prove origin, freshness, availability, display, human attention or legitimacy.

The handset lights a small green mark beside a caller name. The network has done real work: it received signed evidence, checked it, selected data, and translated the result into a form the handset understands. Yet the handset did not inspect the original signature. It trusts the network actor that inserted the field.

That last sentence is the governance boundary in RFC 9796. The specification adds Rich Call Data conventions to SIP Call-Info: a short call-reason, a verified indication, a digest-bearing integrity parameter, and the jcard purpose token. These mechanisms make a caller card more structured and more accountable. They do not make the word “verified” float free of its issuer.

The RFC is unusually precise. verified=true means the party that included the particular Call-Info field performed a successful verification of the information represented in that field. Whether the recipient can rely on the assertion depends on a trusted relationship with the party from which it received the request. Verification therefore has an actor, an object and a delivery edge. Remove any one of the three and the badge becomes a symbol without a receipt.

A translation of evidence is not the evidence itself

The motivating case is practical. RFC 9795 defines Rich Call Data claims protected through PASSporT. RFC 8225 defines the PASSporT token, using the compact claim and signing patterns rooted in JSON Web Token; RFC 8224 places that identity machinery in SIP. A terminating provider may be able to validate the token while an attached device cannot.

RFC 9796 permits the provider to translate selected successful results into Call-Info for an authenticated device on a trusted user-network interface. This avoids requiring every endpoint to reproduce the provider’s certificate, identity and policy machinery. It also creates a new custody step. The device’s immediate evidence is no longer “I checked this PASSporT”. It is “the actor I trust says it checked this field”.

Those statements can both be sound. They are not interchangeable. A useful receipt ladder keeps them separate:

Receipt Narrow conclusion
RCD supplied candidate information was presented
PASSporT present a signed container arrived
signature and certificate path valid the protected object passed cryptographic validation
claim and resource digest compared specified values matched the protected claims
local policy accepted a named verifier allowed the result to proceed
Call-Info inserted a named network actor translated selected results
UNI peer authenticated the device has a bounded trust edge to that actor
resource retrieved and hash matched the bytes received equal the declared digest
field rendered device policy placed the data on screen
person noticed and acted human behavior occurred
caller and purpose later substantiated wider legitimacy received independent support
service outcome observed the intended result actually happened

The specification does not invite collapsing this table. Its verified parameter applies only to the information in the corresponding field. If it is absent, the recipient should assume that information was not received and verified under the RFC 9795 procedures. Absence is not proof of fraud; presence is not proof of the whole call.

A caller card is assembled from claims with unequal custody

The base signalling system matters. RFC 3261 defines SIP and its Call-Info header. A familiar display name in From is not inherently a verified identity fact, and ordinary header material may be ignored, replaced or transformed along a signalling path. RFC 9796 gives downstream systems a disciplined way to say which selected representation was verified and by whom.

A jCard representation follows the JSON contact-card model in RFC 7095, whose JSON syntax ultimately relies on RFC 8259. RFC 9796 constrains the RCD profile to one entity object and calls for consistency among overlapping names, photos, logos, From, P-Asserted-Identity and icon representations. That consistency rule is important because a caller card is not one atomic fact. It is a composition.

The card may travel inline in a data: URI, in a MIME body addressed through the cid: scheme defined by RFC 2392, or through another source whose integrity can be validated, such as HTTPS tied to a validated domain. Each mode changes custody. Inline data moves with the SIP message. A content identifier points into a message body. An external URL introduces retrieval, availability and server control.

RFC 9796 also allows a compact display-name assertion using a null data: URI and purpose=jcard. No visible contact object needs to travel for the field to carry the network actor’s verified indication. That economy is useful, but it makes provenance more important: the green mark still means “this inserter verified this representation”, not “the device independently proved the person behind the call”.

The hash protects bytes, not meaning

The integrity parameter binds a named hash algorithm and digest to a URI-referenced resource. Implementations must support SHA-256, SHA-384 and SHA-512. If the downloaded image hashes to the declared value, the receiver has strong evidence that it obtained the same byte sequence the assertion named.

That is a narrow and valuable property. It does not identify who controlled the resource when it was created. It does not say the image is current, appropriate, safe to display or available at alert time. It does not establish that rendering succeeded, that a human saw the image, or that the call produced the promised outcome. A digest is an equality check over bytes, not a transferable verdict over context.

The same distinction appears in RFC 7852, which describes the SIP resource-priority namespace used in emergency-service contexts: protocol markings carry bounded operational semantics; they do not erase the policy and authorization systems around them. Rich caller presentation likewise crosses cryptographic, network, device and human layers. Every crossing needs its own observer.

call-reason makes the problem visible in prose. The value is optional, should be short, may be truncated, and cannot be guaranteed to appear. RFC 9796 does not specify how a caller chooses it. A displayed reason can help a recipient decide whether to answer, but it is neither a commitment nor proof that the conversation will match the sentence. Treating intent text as verified identity would merge two different claims before the call even begins.

Untrusted paths do not inherit the badge

The trusted-inserter design assumes a real boundary. RFC 9796 warns that without STIR or another protection mechanism, modifications across untrusted interconnected networks cannot be assumed detectable. It also says RCD-related Call-Info should present one consistent version: intermediaries must not alter it or add conflicting RCD fields.

That rule is a custody discipline. A downstream participant that rewrites the card is not merely improving presentation. It is changing the object to which the upstream verification referred. If a network needs to transform data, the operational record should identify the transformer, input, verification policy, output field and trusted recipient.

The protocol’s publication artifacts describe the rule, not its deployment. The RFC Editor information page, errata record, and IETF history establish document status and revision history. The IANA SIP parameters registry records the standardized parameter names. The canonical plain-text and XML forms make normative language inspectable. None proves that a named carrier, gateway or handset implements the mechanism, or implements it correctly.

This is where Heng Lu’s running-code principle becomes an operational test. The useful question is not whether a standards document contains the word verified. It is which executable component performed which check, on which object, and emitted which observable result. The minimum shared specification is the interoperable floor; local policy may be stricter, but cannot silently inflate a field-scoped assertion into a universal guarantee. And the reality-layer discipline asks that protocol status, cryptographic validation, device display and human belief remain separate even when a single green icon tempts us to merge them.

RFC 9796 is not weakened by this reading. It becomes more useful. It gives a network a vocabulary for handing verified results to a constrained endpoint while preserving the exact point at which trust changes hands. The responsible design is not to remove the badge. It is to keep its issuer visible in the evidence system.

Sources