Personal Assertion Token (PASSporT) Extension for Rich Call Data
Extracted elements (33)
Per-element digests in "rcdi" (rather than a single digest over the entire "rcd") allow a verifier to validate only those elements actually retrieved and rendered to the end user, avoiding unnecessary fetching of URI-linked content solely for integrity verification.
The "crn" call-reason claim is intentionally kept separate from the "rcd" claim because call reason is per-call data that may change frequently, whereas "rcd" contains stable caller-identity information. Future extensibility should maintain this grouping: jCard data refers to the caller as an entity; other claims like "crn" describe the specific call.
The integrity framework defines four modes based on two independent axes: whether the signer is authoritative and whether URI references to external content are present. Mode 1 (authoritative, no URIs) requires no additional integrity mechanism; mode 2 requires "rcdi"; modes 3 and 4 (non-authoritative) use JWT Claim Constraints, optionally combined with "rcdi".
The "rcdi" digest mechanism is inspired by W3C Subresource Integrity, applying the same model of cryptographic hashes over URI-referenced external content to the PASSporT/STIR context. Digest input for JSON values uses deterministic JSON serialization per RFC 8225 Section 9; for URI-referenced binary content, the HTTP response body bytes are used directly.
The "rcd", "rcdi", and "crn" claims MAY be added directly as additional claims to PASSporTs using other extensions (e.g., SHAKEN/RFC 8588), avoiding the need for multiple Identity header fields. A verifier that understands only the other extension will still validate the signature over the RCD claims but is permitted to ignore them.
A verification service processing a third-party "rcd" PASSporT MUST confirm that the calling party number in the "orig" claim matches the actual calling party number of the received call, and that the "iat" field falls within an acceptable date interval.
A verifier that successfully verifies a PASSporT with an "rcd" claim MUST ensure: valid signature per RFC 8225, correct claim construction per Section 5, and compliance with any JWT Claim Constraints in the certificate. If any criterion is not met, relying parties MUST NOT use any claims from the PASSporT.
Compact PASSporT form MUST NOT be used when an "rcdi" claim is required. Additionally, "jcl" and "jcd" MUST NOT appear in compact form PASSporTs because integrity and URI-reference rules create constraints that are too restrictive.
During "rcdi" integrity verification, any digest mismatch MUST be treated as a verification failure for the referenced content. HTTP/HTTPS errors when fetching URI-referenced content MUST cause that content to be considered not verified, though this SHOULD NOT affect verification of claims embedded directly in the PASSporT.
Each URI referenced in a "jcd" jCard array MUST have a corresponding JSON pointer string key and digest value in the "rcdi" claim. Use of the digest for the entire "/jcd" array is RECOMMENDED as a redundant protection against substitution or insertion attacks.
For the "jcl" (linked jCard) case, the "rcdi" claim MUST include a "/jcl" key/digest entry protecting the referenced jCard object, and each URI referenced within that jCard MUST have a corresponding JSON pointer key and digest in "rcdi".
If an authentication service generates an "rcd" claim with a "nam" value that is not string-equivalent to the From header field display-name, it MUST use the full (non-compact) form of the PASSporT in SIP. The use of Call-Info via SIP as a trusted source of RCD on the authentication side is NOT RECOMMENDED.
RCD implementations MUST support SHA-256, SHA-384, and SHA-512 hash algorithms for computing "rcdi" digests. Hash algorithm identifiers MUST use only lowercase letters and MUST NOT contain hyphen characters; the character following the algorithm string MUST be a hyphen, with the subsequent base64-encoded digest.
The "jcd" and "jcl" keys are mutually exclusive: both MAY appear at most once in the "rcd" claim but MUST NOT both be present simultaneously. The "jcl" key MUST NOT be used with compact PASSporT form.
The "nam" key MUST be included exactly once in every "rcd" claim value JSON object. Its syntax MUST follow the display-name ABNF from RFC 3261, and if no display name exists, it MUST be an empty string.
Third-party PASSporT authentication services MUST include a PASSporT extension ("ppt") value of "rcd", and their RCD MUST NOT be used when the call lacks a first-party PASSporT assuring the calling party number is not spoofed. Third-party crowdsourced RCD elements MUST use a third-party "rcd" PASSporT with the "iss" claim.
When an "rcd" claim contains URI references to external content and the signer is authoritative (mode 2), an "rcdi" claim MUST be included. If "rcdi" is present, a corresponding "rcd" claim MUST also be present.
When JWT Claim Constraints are used together for both "rcd" and "rcdi", the certificate MUST include a "mustInclude" for the "rcd" claim and a "mustInclude" plus "permittedValues" equal to the "rcdi" claim value string. The "permittedValues" for "rcdi" may contain multiple entries to support multiple authorized RCD sets.
Rich Call Data can reveal the name, location, affiliation, or other personal information of the caller. While baseline PASSporT relies on transport-level security (e.g., SIP over TLS) for confidentiality, including rich personal data in RCD increases exposure risk and the verifier's dereferencing of URIs may leak calling patterns to third-party servers.
The "crn" (Call Reason) JWT claim is an optional single string describing the intent or purpose of the call, corresponding to the "call-reason" parameter of the SIP Call-Info header (RFC 9796). It is intentionally kept separate from "rcd" because call reason is per-call data rather than stable caller-identity data.
The "nam" key within the "rcd" claim carries the display name of the call originator, corresponding to the SIP From header display-name. It is mandatory in every "rcd" claim; if no name string exists, the value MUST be an empty string, and its syntax MUST follow the display-name ABNF in RFC 3261.
The optional "apn" (alternate presentation number) key carries a canonicalized telephone number that the originator is authorized to display in lieu of their default number, such as a call-center main number. Only one "apn" key may appear; it MUST be used when the intent is to display the alternate number even if "jcd" or "jcl" keys are also present.
The optional "icn" key is an HTTPS URL referencing an image resource (icon) pictorially representing the call originator, corresponding to a SIP Call-Info header with purpose=icon. It serves as a base or default image; jCard usage is preferred when richer image-type guidance is needed.
The optional "jcd" key contains an inline jCard JSON object (RFC 7095) with structured caller information. It is mutually exclusive with "jcl"; the jCard MAY contain URI-referenced content but those URIs MUST NOT further reference additional URIs.
The optional "jcl" key is an HTTPS URL pointing to a jCard JSON object served with media type application/json. It is mutually exclusive with "jcd", MUST appear at most once, and the referenced jCard MUST NOT contain recursively nested URI references.
The "rcd" (Rich Call Data) JWT claim is a JSON object that may contain one or more key/value pairs conveying caller and call metadata beyond the telephone number, including display name, alternate presentation number, icon, and jCard data. It extends PASSporT with an extensible set of caller-identity information comparable to traditional Caller ID.
The "rcdi" (Rich Call Data Integrity) JWT claim is a JSON object whose key/value pairs provide cryptographic digests over "rcd" elements, using JSON Pointer (RFC 6901) as keys and base64-encoded SHA-2 digests as values. It is modeled after W3C Subresource Integrity and provides per-element integrity validation especially for URI-referenced external resources.
IANA has added a new entry for the PASSporT extension type "rcd" to the "Personal Assertion Token (PASSporT) Extensions" registry, referencing RFC 9795.
IANA has created the "PASSporT RCD Claim Types" registry under the "Personal Assertion Token (PASSporT)" registry group, with Specification Required policy. It is initially populated with "nam", "apn", "icn", "jcd", and "jcl"; new registrations require expert review to avoid conflict or overlap with existing types.
IANA has registered three new JWT claims in the "JSON Web Token Claims" registry: "rcd" (Rich Call Data Information), "rcdi" (Rich Call Data Integrity Information), and "crn" (Call Reason), all referencing RFC 9795.
All information signed in an "rcd" PASSporT should undergo a vetting process by an authoritative entity enforcing ecosystem policies. The chain of trust—where signers are either directly authoritative or have been delegated authority via JWT Claim Constraints and integrity mechanisms—is critical to maintaining ecosystem integrity.
Dereferencing URI-linked RCD resources during verification (in-network or on device) can reveal calling patterns to the resource host. The use of "rcdi" digests within JWT Claim Constraints certificates is RECOMMENDED over embedding raw claim content, to avoid exposing private caller information through publicly accessible certificates.
Non-authoritative signers using delegate certificates may attempt to include unauthorized PASSporT claims not vetted by the certificate issuer. JWT Claim Constraints (RFC 9118) should be used to explicitly exclude claims beyond those authorized, preventing injection of unvetted RCD into signed PASSporTs.