rfc9795v1.txt   rfc9795.txt 
Internet Engineering Task Force (IETF) C. Wendt Internet Engineering Task Force (IETF) C. Wendt
Request for Comments: 9795 Somos Inc. Request for Comments: 9795 Somos Inc.
Category: Standards Track J. Peterson Category: Standards Track J. Peterson
ISSN: 2070-1721 Neustar Inc. ISSN: 2070-1721 Neustar Inc.
May 2025 June 2025
Personal Assertion Token (PASSporT) Extension for Rich Call Data Personal Assertion Token (PASSporT) Extension for Rich Call Data
Abstract Abstract
This document extends Personal Assertion Token (PASSporT), a token This document extends Personal Assertion Token (PASSporT), a token
for conveying cryptographically signed call information about for conveying cryptographically signed call information about
personal communications, to include rich metadata about a call and personal communications, to include rich metadata about a call and
caller that can be signed and integrity protected, transmitted, and caller that can be signed and integrity protected, transmitted, and
subsequently rendered to the called party. This framework is subsequently rendered to the called party. This framework is
skipping to change at line 58 skipping to change at line 58
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Terminology 2. Terminology
3. Overview of the Use of the Rich Call Data PASSporT Extension 3. Overview of the Use of the Rich Call Data PASSporT Extension
4. Overview of Rich Call Data Integrity 4. Overview of Rich Call Data Integrity
5. PASSporT Claim "rcd" Definition and Usage 5. "rcd" PASSporT Claim: Definition and Usage
5.1. PASSporT "rcd" Claim 5.1. PASSporT "rcd" Claim
5.1.1. "nam" key 5.1.1. "nam" key
5.1.2. "apn" key 5.1.2. "apn" key
5.1.3. "icn" key 5.1.3. "icn" key
5.1.4. "jcd" key 5.1.4. "jcd" key
5.1.5. "jcl" key 5.1.5. "jcl" key
6. "rcdi" RCD Integrity Claim Definition and Usage 6. "rcdi" PASSporT Claim: Definition and Usage
6.1. Creation of the "rcd" Element Digests 6.1. Creation of the "rcd" Element Digests
6.1.1. "nam" and "apn" Elements 6.1.1. "nam" and "apn" Elements
6.1.2. "icn" Elements 6.1.2. "icn" Elements
6.1.3. "jcd" Elements 6.1.3. "jcd" Elements
6.1.4. "jcl" Elements 6.1.4. "jcl" Elements
6.2. JWT Claim Constraints for "rcd" Claims 6.2. JWT Claim Constraints for "rcd" Claims
6.3. JWT Claim Constraints Usage for "rcd" and "rcdi" Claims 6.3. JWT Claim Constraints for "rcd" and "rcdi" Claims
7. PASSporT "crn" Claim - Call Reason Definition and Usage 7. "crn" PASSporT Claim: Definition and Usage
7.1. JWT Constraint for "crn" Claim 7.1. JWT Constraint for "crn" Claim
8. Rich Call Data Claims Usage Rules 8. Rich Call Data Claims Usage Rules
8.1. "rcd" PASSporT Verification 8.1. "rcd" PASSporT Verification
8.2. "rcdi" Integrity Verification 8.2. "rcdi" Integrity Verification
8.3. Example "rcd" PASSporTs 8.3. Example "rcd" PASSporTs
9. Compact Form of "rcd" PASSporT 9. Compact Form of "rcd" PASSporT
9.1. Compact Form of the "rcd" PASSporT Claim 9.1. Compact Form of the "rcd" PASSporT Claim
9.2. Compact Form of the "rcdi" PASSporT Claim 9.2. Compact Form of the "rcdi" PASSporT Claim
9.3. Compact Form of the "crn" PASSporT Claim 9.3. Compact Form of the "crn" PASSporT Claim
10. Third-Party Uses 10. Third-Party Uses
skipping to change at line 153 skipping to change at line 153
for the "display-name" field of SIP requests, or similar name fields for the "display-name" field of SIP requests, or similar name fields
in other protocols, as well as further "rich call data" (RCD) about in other protocols, as well as further "rich call data" (RCD) about
the caller, which includes the contents of the Call-Info header field the caller, which includes the contents of the Call-Info header field
or other data structures that can be added to the PASSporT. In or other data structures that can be added to the PASSporT. In
addition, Section 12 describes use cases that enable external third- addition, Section 12 describes use cases that enable external third-
party authorities to convey rich information associated with a party authorities to convey rich information associated with a
calling number via an "rcd" PASSporT while clearly identifying the calling number via an "rcd" PASSporT while clearly identifying the
third-party as the source of the Rich Call Data information. third-party as the source of the Rich Call Data information.
Finally, this document describes how to preserve the integrity of the Finally, this document describes how to preserve the integrity of the
RCD in scenarios where there may be non-authoritative users RCD in scenarios where there may be non-authoritative users
initiating and signing RCD and therefore a constraint on the RCD that initiating and signing RCD, therefore limiting a PASSporT and the RCD
a PASSporT can attest via certificate-level controls. claims it asserts via certificate-level controls.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Overview of the Use of the Rich Call Data PASSporT Extension 3. Overview of the Use of the Rich Call Data PASSporT Extension
skipping to change at line 215 skipping to change at line 215
4. Overview of Rich Call Data Integrity 4. Overview of Rich Call Data Integrity
When incorporating call data that represents a user, even in When incorporating call data that represents a user, even in
traditional calling name services today, often there are policy and traditional calling name services today, often there are policy and
restrictions around what data elements are allowed to be used. restrictions around what data elements are allowed to be used.
Whether preventing offensive language or icons, enforcing uniqueness, Whether preventing offensive language or icons, enforcing uniqueness,
notifying about potential trademark or copyright violations, or notifying about potential trademark or copyright violations, or
enforcing other policies, there might be the desire to pre-certify or enforcing other policies, there might be the desire to pre-certify or
"vet" the specific use of RCD. This document defines a mechanism "vet" the specific use of RCD. This document defines a mechanism
that allows for a direct or indirect party that enforces the policies that allows for a direct or indirect party that (a) enforces the
to approve or certify the content, create a cryptographic digest that policies to approve or certify the content, (b) creates a
can be used to validate that data and applies a constraint in the cryptographic digest that can be used to validate that data, and (c)
certificate to allow the recipient and verifier to validate that the applies a constraint in the certificate to allow the recipient and
specific content of the RCD is as intended at its creation and its verifier to validate that the specific content of the RCD is as
approval or certification. intended at its creation and its approval or certification.
There are two mechanisms that are defined to accomplish that for two There are two mechanisms that are defined to accomplish that for two
distinct categories of purposes. The first of the mechanisms include distinct categories of purposes. The first of the mechanisms include
the definition of an integrity claim. The RCD integrity mechanism is the definition of an integrity claim. The RCD integrity mechanism is
a process of generating a cryptographic digest for each resource a process of generating a cryptographic digest for each resource
referenced by a URI within a claim value (e.g., an image file referenced by a URI within a claim value (e.g., an image file
referenced by "jcd" or a jCard referenced by "jcl"). This mechanism referenced by "jcd" or a jCard referenced by "jcl"). This mechanism
is inspired by and based on the W3C Subresource Integrity is inspired by and based on the W3C Subresource Integrity
specification [W3C-SubresourceIntegrity]. The second of the specification [W3C-SubresourceIntegrity]. The second of the
mechanisms uses the capability called JWT Claim Constraints, defined mechanisms uses the capability called JWT Claim Constraints, defined
skipping to change at line 283 skipping to change at line 283
Integrity or "rcdi" claim MUST be included. This integrity claim is Integrity or "rcdi" claim MUST be included. This integrity claim is
defined later in this document and provides a digest of the "rcd" defined later in this document and provides a digest of the "rcd"
claim content so that, particularly for the case where there are URI claim content so that, particularly for the case where there are URI
references in the RCD, the content of that RCD can be comprehensively references in the RCD, the content of that RCD can be comprehensively
validated that it was received as intended by the signer of the validated that it was received as intended by the signer of the
PASSporT. PASSporT.
The third and fourth modes cover cases where there is a different The third and fourth modes cover cases where there is a different
authoritative entity responsible for the content of the RCD, separate authoritative entity responsible for the content of the RCD, separate
from the signer of the PASSporT itself, allowing the ability, in from the signer of the PASSporT itself, allowing the ability, in
particular when delegating signing authority for PASSporT, to enable particular when delegating signing authority for PASSporT, for agreed
a mechanism for allowing agreed or vetted content included in or or vetted content to be included in or referenced by the RCD claim
referenced by the RCD claim contents. The primary framework for contents. The primary framework for allowing the separation of
allowing the separation of authority and the signing of PASSporTs by authority and the signing of PASSporTs by non-authorized entities is
non-authorized entities is detailed in [RFC9060], although other detailed in [RFC9060], although other cases may apply. As with the
cases may apply. As with the first and second modes, the third and first and second modes, the third and fourth modes differ with the
fourth modes differ with the absence or inclusion of referenced absence or inclusion of referenced external content using URIs.
external content using URIs.
5. PASSporT Claim "rcd" Definition and Usage 5. "rcd" PASSporT Claim: Definition and Usage
5.1. PASSporT "rcd" Claim 5.1. PASSporT "rcd" Claim
This document defines a new JSON Web Token claim for "rcd", Rich Call This document defines a new JSON Web Token claim for "rcd", Rich Call
Data, the value of which is a JSON object that can contain one or Data, the value of which is a JSON object that can contain one or
more key value pairs. This document defines a default set of key more key value pairs. This document defines a default set of key
values. values.
5.1.1. "nam" key 5.1.1. "nam" key
skipping to change at line 336 skipping to change at line 335
telephone number per [RFC8224], Section 8.3. If present, this key telephone number per [RFC8224], Section 8.3. If present, this key
MUST be included once as part of the "rcd" claim value JSON object. MUST be included once as part of the "rcd" claim value JSON object.
The use of the optional "apn" key is intended for cases where the The use of the optional "apn" key is intended for cases where the
signer of an "rcd" PASSporT or "rcd" claims authorizes the use of an signer of an "rcd" PASSporT or "rcd" claims authorizes the use of an
alternate presentation number by the user. How the signer determines alternate presentation number by the user. How the signer determines
that a user is authorized to present the number in question is a that a user is authorized to present the number in question is a
policy decision outside the scope of this document. However, the policy decision outside the scope of this document. However, the
vetting of the alternate presentation number should follow the same vetting of the alternate presentation number should follow the same
level of vetting as telephone identities or any other information level of vetting as telephone identities or any other information
contained in an "rcd" PASSporT or "rcd" claims. This usage is contained in an "rcd" PASSporT or "rcd" claims. The use of the "apn"
intended as an alternative to conveying the presentation number in key is intended as an alternative to conveying the presentation
the "tel" key value of a jCard, in situations where no other rich number in the "tel" key value of a jCard, in situations where no
jCard data needs to be conveyed with the call. Only one "apn" key other rich jCard data needs to be conveyed with the call. Only one
may be present. "apn" MUST be used when it is the intent of the "apn" key may be present. "apn" MUST be used when it is the intent of
caller or signer to display the alternate presentation number even if the caller or signer to display the alternate presentation number
"jcd" or "jcl" keys are present in a PASSporT with a "tel" key value. even if "jcd" or "jcl" keys are present in a PASSporT with a "tel"
key value.
5.1.3. "icn" key 5.1.3. "icn" key
The "icn" key value is an optional HTTPS URL reference to an image The "icn" key value is an optional HTTPS URL reference to an image
resource that can be used to pictorially represent the originator of resource that can be used to pictorially represent the originator of
personal communications. This icon key value should be used as a personal communications. This icon key value should be used as a
base or default method of associating an image with a calling party. base or default method of associating an image with a calling party.
When being used for SIP [RFC3261], this claim key value is used to When being used for SIP [RFC3261], this claim key value is used to
protect the Call-Info header field with a purpose parameter value of protect the Call-Info header field with a purpose parameter value of
skipping to change at line 391 skipping to change at line 391
built-in extensibility of the jCard specification to add additional built-in extensibility of the jCard specification to add additional
information. The "jcd" key is optional. Either a "jcd" or "jcl" MAY information. The "jcd" key is optional. Either a "jcd" or "jcl" MAY
appear in the "rcd" claim, but not both. appear in the "rcd" claim, but not both.
The jCard object value for "jcd" MUST be a jCard JSON object that MAY The jCard object value for "jcd" MUST be a jCard JSON object that MAY
have URI-referenced content, but that URI-referenced content MUST NOT have URI-referenced content, but that URI-referenced content MUST NOT
further reference URIs. Future specifications may extend this further reference URIs. Future specifications may extend this
capability, but [RFC9796] constrains the security properties of RCD capability, but [RFC9796] constrains the security properties of RCD
information and the integrity of the content referenced by URIs. information and the integrity of the content referenced by URIs.
Note: Even though we refer to [RFC9796] as the definition of the | Note: Even though we refer to [RFC9796] as the definition of
jCard properties for usage in "rcd" claims, using Call-Info as | the jCard properties for usage in "rcd" claims, using the Call-
protocol with the addition of an identity header carrying the | Info header field with RCD information in a SIP request beyond
PASSporT is not required. The identity header carrying a PASSporT | the use of identity header as defined in this document is not
with an "rcd" claim including a "jcd" value can be used as the | required. Identity header fields are generally encouraged for
primary and only transport of the RCD information. | all transport of authenticated and protected RCD information
| over Network-to-Network Interfaces (NNIs) between untrusted
| parties or over untrusted networks. The use of Call-Info
| header fields to carry RCD information as defined in [RFC9796]
| is suggested for use in trusted networks relationships,
| generally for User-Network Interfaces (UNIs).
5.1.5. "jcl" key 5.1.5. "jcl" key
The "jcl" key value is an HTTPS URL that refers to a jCard JSON The "jcl" key value is an HTTPS URL that refers to a jCard JSON
object [RFC7095] on a web server. The web server MUST use the media object [RFC7095] on a web server. The web server MUST use the media
type for JSON text as application/json with a default encoding of type for JSON text as application/json with a default encoding of
UTF-8 [RFC8259]. This link may correspond to the Call-Info header UTF-8 [RFC8259]. This link may correspond to the Call-Info header
field value defined in [RFC9796] with a type of "jcard". As also field value defined in [RFC9796] with a type of "jcard". As also
defined in [RFC9796], the format of the jCard and properties used defined in [RFC9796], the format of the jCard and properties used
should follow the normative usage and formatting rules and should follow the normative usage and formatting rules and
procedures. The "jcl" key is optional. The "jcd" or "jcl" keys MAY procedures. The "jcl" key is optional. The "jcd" or "jcl" keys MAY
only appear once in the "rcd" claim but MUST be mutually exclusive. only appear once in the "rcd" claim but MUST be mutually exclusive.
The jCard object referenced by the URI value for "jcl" MUST be a The jCard object referenced by the URI value for "jcl" MUST be a
jCard JSON object that MAY have URI-referenced content, but that URI- jCard JSON object that MAY have URI-referenced content, but that URI-
referenced content MUST NOT further reference URIs. Future referenced content MUST NOT further reference URIs. Future
specifications may extend this capability, but [RFC9796] constrains specifications may extend this capability, but [RFC9796] constrains
the security properties of RCD information and the integrity of the the security properties of RCD information and the integrity of the
content referenced by URIs. content referenced by URIs.
6. "rcdi" RCD Integrity Claim Definition and Usage 6. "rcdi" PASSporT Claim: Definition and Usage
The "rcdi" claim is included for the second and fourth modes The "rcdi" claim is included for the second and fourth modes
described in the integrity overview (Section 4). "rcdi" and "rcd" described in the integrity overview (Section 4). "rcdi" and "rcd"
claims MAY each appear once in a PASSporT, but if "rcdi" is included, claims MAY each appear once in a PASSporT, but if "rcdi" is included,
the "rcd" MUST be present correspondingly. The value of the "rcdi" the "rcd" MUST be present correspondingly. The value of the "rcdi"
claim is a JSON object that is defined as follows. claim is a JSON object that is defined as follows.
The claim value of the "rcdi" claim key is a JSON object with a set The claim value of the "rcdi" claim key is a JSON object with a set
of JSON key/value pairs. These objects correspond to each of the of JSON key/value pairs. Each "rcdi" claim key/value pair
elements of the "rcd" claim object that require integrity protection corresponds to each of the elements of the "rcd" claim object that
with an associated digest over the content referenced by the key require integrity protection with an associated digest over the
string. The individual digest of different elements of the "rcd" content referenced by the key string. The individual digest of
claim data and URI-referenced external content is kept specifically different elements of the "rcd" claim data and URI-referenced
separate to allow the ability to verify the integrity of only the external content is kept specifically separate to allow the ability
elements that are ultimately retrieved, downloaded, or rendered to to verify the integrity of only the elements that are ultimately
the end user. retrieved, downloaded, or rendered to the end user.
The key value references a specific object within the "rcd" claim The key value references a specific object within the "rcd" claim
value using a JSON pointer defined in [RFC6901] with a minor value using a JSON pointer defined in [RFC6901] with a minor
additional rule to support URI references to external content that additional rule to support URI references to external content that
include JSON objects themselves, for the specific case of the use of include JSON objects themselves, for the specific case of the use of
"jcl", defined in Section 6.1.4. JSON pointer syntax is the key "jcl", defined in Section 6.1.4. JSON pointer syntax is the key
value that documents exactly the part of JSON that is used to value that documents exactly the part of JSON that is used to
generate the digest that produces the resulting string that makes up generate the digest that produces the resulting string that makes up
the value for the corresponding key. Detailed procedures are the value for the corresponding key. Detailed procedures are
provided below, but an example "rcdi" is provided here: provided below, but an example "rcdi" is provided here:
skipping to change at line 472 skipping to change at line 477
support the hash algorithms SHA-256, SHA-384, and SHA-512. These support the hash algorithms SHA-256, SHA-384, and SHA-512. These
hash algorithms are identified by "sha256", "sha384", and "sha512", hash algorithms are identified by "sha256", "sha384", and "sha512",
respectively. SHA-256, SHA-384, and SHA-512 are part of the SHA-2 respectively. SHA-256, SHA-384, and SHA-512 are part of the SHA-2
set of cryptographic hash functions [RFC6234] defined by the US set of cryptographic hash functions [RFC6234] defined by the US
National Institute of Standards and Technology (NIST). National Institute of Standards and Technology (NIST).
Implementations MAY support additional recommended hash algorithms in Implementations MAY support additional recommended hash algorithms in
[IANA-COSE-ALG], that is, the hash algorithms with "Yes" in the [IANA-COSE-ALG], that is, the hash algorithms with "Yes" in the
"Recommended" column of the IANA registry. Hash algorithm "Recommended" column of the IANA registry. Hash algorithm
identifiers MUST use only lowercase letters, and they MUST NOT identifiers MUST use only lowercase letters, and they MUST NOT
contain hyphen characters. The character following the algorithm contain hyphen characters. The character following the algorithm
string MUST be a hyphen character, "-", or ASCII 45. The subsequent string MUST be a hyphen character ("-", %x2D). The subsequent
characters are the base64 encoded [RFC4648] digest of a canonicalized characters are the base64 encoded [RFC4648] digest of a canonicalized
and concatenated string or binary data based on the JSON pointer and concatenated string or binary data based on the JSON pointer
referenced elements of the "rcd" claim or the URI-referenced content referenced elements of the "rcd" claim or the URI-referenced content
contained in the claim. The next section covers the details of the contained in the claim. The next section covers the details of the
determination of the input string used to determine the digest. determination of the input string used to determine the digest.
6.1. Creation of the "rcd" Element Digests 6.1. Creation of the "rcd" Element Digests
"rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl" "rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl"
keys as part of the "rcd" JSON object claim value. This document keys as part of the "rcd" JSON object claim value. This document
defines the use of JSON pointer [RFC6901] as a mechanism to reference defines the use of JSON pointer [RFC6901] as a mechanism to reference
specific "rcd" claim elements. specific "rcd" claim elements.
In order to facilitate proper verification of the digests and to In order to facilitate proper verification of the digests and to
determine whether the "rcd" elements or content referenced by URIs determine whether the "rcd" elements or content referenced by URIs
were modified, the input to the digest must be completely were modified, the input to the digest must be completely
deterministic at three points in the process. First, at the deterministic at three points in the process. First, it must be
certification point where the content is evaluated to conform to the deterministic at the certification point when the content is
application policy and the JWT Claim Constraints is applied to the evaluated to conform to the application policy and when the JWT Claim
certificate containing the digest. Second, when the call is signed Constraints are applied to the certificate containing the digest.
at the Authentication Service, there may be a local policy to verify Second, when the call is signed at the Authentication Service, there
that the provided "rcd" claim corresponds to each digest. Third, may be a local policy to verify that the provided "rcd" claim
when the "rcd" data is verified at the verification service, the corresponds to each digest. Third, when the "rcd" data is verified
verification is performed for each digest by constructing the input at the verification service, the verification is performed for each
digest string for the element being verified and referenced by the digest by constructing the input digest string for the element being
JSON pointer string. verified and referenced by the JSON pointer string.
The procedure for the creation of each "rcd" element digest string The procedure for the creation of each "rcd" element digest string
corresponding to a JSON pointer string key is as follows. corresponding to a JSON pointer string key is as follows.
1. The JSON pointer either refers to a value that is a part or the 1. The JSON pointer either refers to a value that is a part or the
whole of a JSON object or to a string that is a URI referencing whole of a JSON object or to a string that is a URI referencing
an external resource. an external resource.
2. For a JSON value, serialize the JSON to remove all white space 2. For a JSON value, serialize the JSON to remove all white space
and line breaks. The procedures of this deterministic JSON and line breaks. The procedures of this deterministic JSON
skipping to change at line 524 skipping to change at line 529
Note that the digest is computed on the JSON representation of the Note that the digest is computed on the JSON representation of the
string, which necessarily includes the beginning and ending double- string, which necessarily includes the beginning and ending double-
quote characters. quote characters.
6.1.1. "nam" and "apn" Elements 6.1.1. "nam" and "apn" Elements
In the case of "nam" and "apn", the only allowed value is a string. In the case of "nam" and "apn", the only allowed value is a string.
For both of these key values, an "rcdi" JSON pointer or integrity For both of these key values, an "rcdi" JSON pointer or integrity
digest is optional because the direct value is protected by the digest is optional because the direct value is protected by the
signature and can be constrained directly with JWTClaimConstraints. signature and can be constrained directly with JWT Claim Constraints.
6.1.2. "icn" Elements 6.1.2. "icn" Elements
In the case of "icn", the only allowed value is a URI value that In the case of "icn", the only allowed value is a URI value that
references an image file. If the URI references externally linked references an image file. If the URI references externally linked
content, there MUST be a JSON pointer and digest entry for the content, there MUST be a JSON pointer and digest entry for the
content in that linked resource. When creating a key/value content in that linked resource. When creating a key/value
representing "icn", the key is the JSON pointer string "/icn", and representing "icn", the key is the JSON pointer string "/icn", and
the digest value string is created using the image file byte data the digest value string is created using the image file byte data
referenced in the URI. referenced in the URI.
skipping to change at line 578 skipping to change at line 583
"/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
The use of a JSON pointer and integrity digest for the "jcd" claim The use of a JSON pointer and integrity digest for the "jcd" claim
key and value is optional. The "jcd" value is the directly included key and value is optional. The "jcd" value is the directly included
jCard array; it can be protected by the signature and can be jCard array; it can be protected by the signature and can be
constrained directly with JWTClaimConstraints. However, for data constrained directly with JWT Claim Constraints. However, for data
length reasons (as with "icn" above) or more importantly for length reasons (as with "icn" above) or more importantly for
potential privacy and/or security considerations with a publicly potential privacy and/or security considerations with a publicly
accessible certificate, the use of the "rcdi" JSON pointer and accessible certificate, the use of the "rcdi" JSON pointer and
integrity digest as the constraint value in JWTClaimConstraints over integrity digest as the constraint value in JWT Claim Constraints
the jCard data is RECOMMENDED. over the jCard data is RECOMMENDED.
It is important to remember the array indices for JSON pointer are It is important to remember the array indices for JSON pointer are
dependent on the order of the elements in the jCard. The use of dependent on the order of the elements in the jCard. The use of
digest for the "/jcd" corresponding to the entire jCard array string digest for the "/jcd" corresponding to the entire jCard array string
can be included as a redundant mechanism to avoid any possibility of can be included as a redundant mechanism to avoid any possibility of
substitution, insertion attacks, or other potential techniques to substitution, insertion attacks, or other potential techniques to
undermine integrity detection. undermine integrity detection.
Each URI referenced in the jCard array string MUST have a Each URI referenced in the jCard array string MUST have a
corresponding JSON pointer string key and digest value. corresponding JSON pointer string key and digest value.
6.1.4. "jcl" Elements 6.1.4. "jcl" Elements
In the case of the use of a "jcl" URI reference to an external jCard, In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the exception and the minor the procedures are similar to "jcd" with the minor modification to
modification to JSON pointer, where "/jcl" is used to refer to the the JSON pointer, where "/jcl" is used to refer to the external jCard
external jCard array string and any following numeric array indices array string. Also, any following numeric array indices added to the
added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the "jcl" (e.g., "/jcl/1/2/3") are treated as if the external content
external content referenced by the jCard was directly part of the referenced by the jCard were directly part of the overall "rcd" claim
overall "rcd" claim JSON object. The following example illustrates a JSON object. The following example illustrates a "jcl" version of
"jcl" version of the above "jcd" example. the above "jcd" example.
"rcd": { "rcd": {
"jcl": "https://example.com/qbranch.json", "jcl": "https://example.com/qbranch.json",
"nam": "Q Branch Spy Gadgets" "nam": "Q Branch Spy Gadgets"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
skipping to change at line 656 skipping to change at line 661
or optionally MAY contain multiple entries with the intent of or optionally MAY contain multiple entries with the intent of
supporting cases where the certificate holder is authorized to use supporting cases where the certificate holder is authorized to use
different sets of rich call data corresponding to different call different sets of rich call data corresponding to different call
scenarios. scenarios.
Only including "permittedValues" for "rcd", with no "mustInclude", Only including "permittedValues" for "rcd", with no "mustInclude",
provides the ability for the construction a valid PASSporT that can provides the ability for the construction a valid PASSporT that can
either have no "rcd" claim within or only the set of constrained either have no "rcd" claim within or only the set of constrained
"permittedValues" values for an included "rcd" claim. "permittedValues" values for an included "rcd" claim.
6.3. JWT Claim Constraints Usage for "rcd" and "rcdi" Claims 6.3. JWT Claim Constraints for "rcd" and "rcdi" Claims
The use of JWT Claim Constraints with an "rcdi" claim is for cases The use of JWT Claim Constraints with an "rcdi" claim is for cases
where URI-referenced content is to be protected by the authoritative where URI-referenced content is to be protected by the authoritative
certificate issuer. The objective for the use of JWT Claim certificate issuer. The objective for the use of JWT Claim
Constraints for the combination of both "rcd" and "rcdi" claims is to Constraints for the combination of both "rcd" and "rcdi" claims is to
constrain the signer to only construct the "rcd" and "rcdi" claims constrain the signer to only construct the "rcd" and "rcdi" claims
inside a PASSporT to contain and reference only a predetermined set inside a PASSporT to contain and reference only a predetermined set
of content. Once both the contents of the "rcd" claim and any of content. Once both the contents of the "rcd" claim and any
referenced content are certified by the party that is authoritative referenced content are certified by the party that is authoritative
for the certificate being issued to the signer, the "rcdi" claim is for the certificate being issued to the signer, the "rcdi" claim is
constructed and linked to the STIR certificate associated with the constructed and linked to the STIR certificate associated with the
signature in the PASSporT via the JWT Claim Constraints extension as signature in the PASSporT via the JWT Claim Constraints extension as
defined in [RFC8226], Section 8 and extended in [RFC9118]. It should defined in [RFC8226], Section 8 and extended in [RFC9118]. It should
be recognized that the "rcdi" set of digests is intended to be unique be recognized that the "rcdi" set of digests is intended to be unique
for only a specific combination of "rcd" content and URI-referenced for only a specific combination of "rcd" content and URI-referenced
external content, and therefore the set provides a robust integrity external content, and therefore the set provides a robust integrity
mechanism for an authentication service being performed by a non- mechanism for an authentication service being performed by a non-
authoritative party. This would often be associated with the use of authoritative party. For example, this may be used with delegate
delegate certificates [RFC9060] for the signing of calls by the certificates [RFC9060] for the signing of calls by the calling party
calling party directly, as an example, even though the "authorized directly, even though the "authorized party" is not necessarily the
party" is not necessarily the subject of a STIR certificate. subject of a STIR certificate.
For the cases where both "rcd" and "rcdi" claims should always be For the cases where both "rcd" and "rcdi" claims should always be
included in the PASSporT, the certificate JWT Claims Constraint included in the PASSporT, the certificate JWT Claims Constraint
extension MUST include both of the following: extension MUST include both of the following:
* a "mustInclude" for the "rcd" claim, which simply constrains the * a "mustInclude" for the "rcd" claim, which simply constrains the
fact that an "rcd" must be included fact that an "rcd" must be included
* a "mustInclude" for the "rcdi" claim and a "permittedValues" equal * a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
to the created "rcdi" claim value string. to the created "rcdi" claim value string.
Note that optionally the "rcd" claims may be included in the Note that optionally the "rcd" claims may be included in the
"permittedValues"; however, it is recognized that this may be "permittedValues"; however, it is recognized that this may be
redundant with the "rcdi" permittedValues because the "rcdi" digest redundant with the "rcdi" permittedValues because the "rcdi" digest
will imply the content of the "rcd" claims themselves. will imply the content of the "rcd" claims themselves.
The "permittedValues" for the "rcdi" claims (or "rcd" claims more The "permittedValues" for the "rcdi" claims (or "rcd" claims more
generally) may contain multiple entries to support the case where the generally) may contain multiple entries to support the case where the
certificate holder is authorized to use different sets of RCD. certificate holder is authorized to use different sets of RCD.
7. PASSporT "crn" Claim - Call Reason Definition and Usage 7. "crn" PASSporT Claim: Definition and Usage
This document defines a new JSON Web Token claim for "crn", Call This document defines a new JSON Web Token claim for "crn", Call
Reason, the value of which is a single string that can contain Reason, the value of which is a single string that can contain
information as defined in [RFC9796] and corresponding to the "call- information as defined in [RFC9796] and corresponding to the "call-
reason" parameter for the Call-Info header. This claim is optional. reason" parameter for the Call-Info header. This claim is optional.
Example "crn" claim with "rcd": Example "crn" claim with "rcd":
"crn" : "For your ears only", "crn" : "For your ears only",
"rcd": { "nam": "James Bond", "rcd": { "nam": "James Bond",
"jcl": "https://example.org/james_bond.json"} "jcl": "https://example.org/james_bond.json"}
7.1. JWT Constraint for "crn" Claim 7.1. JWT Constraint for "crn" Claim
The integrity of the "crn" claim contents can optionally be protected The integrity of the "crn" claim contents can optionally be protected
by the authoritative certificate issuer using JWT Constraints in the by the authoritative certificate issuer using JWT Claim Constraints
certificate. When the signer of the PASSporT intends to always in the certificate. When the signer of the PASSporT intends to
include a call reason string of any value, a "mustInclude" for the always include a call reason string of any value, a "mustInclude" for
"crn" claim in the JWT Claim Constraints indicates that a "crn" claim the "crn" claim in the JWT Claim Constraints indicates that a "crn"
must always be present and is RECOMMENDED to be included by the claim must always be present and is RECOMMENDED to be included by the
certificate issuer. If the signer of the "crn" claim wants to certificate issuer. If the signer of the "crn" claim wants to
constrain the contents of "crn", then "permittedValues" for "crn" in constrain the contents of "crn", then "permittedValues" for "crn" in
JWT Claim Constraints should match the contents of the allowed JWT Claim Constraints should match the contents of the allowed
strings and is RECOMMENDED to be included by the certificate issuer. strings and is RECOMMENDED to be included by the certificate issuer.
8. Rich Call Data Claims Usage Rules 8. Rich Call Data Claims Usage Rules
The "rcd" or "crn" claims MAY appear in any PASSporT claims object as The "rcd" or "crn" claims MAY appear in any PASSporT claims object as
optional elements. The creator of a PASSporT MAY also add a PASSporT optional elements. The creator of a PASSporT MAY also add a PASSporT
extension ("ppt") value, defined in [RFC8225], Section 8.1, of "rcd" extension ("ppt") value, defined in [RFC8225], Section 8.1, of "rcd"
to the header of a PASSporT. In that case, the PASSporT claims MUST to the header of a PASSporT. In that case, the PASSporT claims MUST
contain at least one or both an "rcd" or "crn" claim. Any entities contain at least one "rcd" or "crn" claim (or both). Any entities
verifying the PASSporT claims defined in this document are required verifying the PASSporT claims defined in this document are required
to understand the PASSporT extension in order to process the PASSporT to understand the PASSporT extension in order to process the PASSporT
in question. An example PASSporT header with the PASSporT extension in question. An example PASSporT header with the PASSporT extension
("ppt") value of "rcd" included is shown as follows: ("ppt") value of "rcd" included is shown as follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
skipping to change at line 857 skipping to change at line 862
] ], ] ],
"nam": "Q Branch Spy Gadgets" "nam": "Q Branch Spy Gadgets"
}, },
"rcdi": { "rcdi": {
"/jcd/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcd/1/3/3":"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcd/1/4/3":"sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcd/1/5/3":"sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
In an example PASSporT, where a jCard is linked via HTTPS URL using In the following PASSporT example, a jCard is linked via HTTPS URL
"jcl", a jCard file is served at a particular URL. using "jcl", and a jCard file is served at a particular URL.
An example jCard JSON file hosted at the example web address of Example jCard JSON file hosted at https://example.com/qbranch.json:
https://example.com/qbranch.json is shown as follows:
["vcard", ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], ["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ]
] ]
skipping to change at line 926 skipping to change at line 930
defined in [RFC8225], Section 7, has some restrictions that will be defined in [RFC8225], Section 7, has some restrictions that will be
enumerated below, but it mainly follows standard PASSporT compact enumerated below, but it mainly follows standard PASSporT compact
form procedures. Compact form only provides the signature from the form procedures. Compact form only provides the signature from the
PASSporT, requiring the reconstruction of the other PASSporT claims PASSporT, requiring the reconstruction of the other PASSporT claims
from the SIP header fields as discussed in Section 4.1 of [RFC8224]. from the SIP header fields as discussed in Section 4.1 of [RFC8224].
The reconstruction of the "nam" claim, if using the SIP protocol, The reconstruction of the "nam" claim, if using the SIP protocol,
should use the display-name string in the From header field. For should use the display-name string in the From header field. For
other protocols, if there is a display name field that exists, the other protocols, if there is a display name field that exists, the
string should be used; otherwise, the string should be an empty string should be used; otherwise, the string should be an empty
string, e.g., "". "jcl" and "jcd" MUST NOT be used with compact form string, e.g., "". The claims "jcl" and "jcd" MUST NOT be used with
due to integrity rules and URI reference rules in this document compact form because the integrity rules and URI reference rules
leading to too restrictive of a set of constraints. Future defined in this document would lead a set of constraints that is too
specifications may revisit this to propose a consistent and restrictive. Future specifications may revisit this to propose a
comprehensive way of addressing integrity and security of information consistent and comprehensive way of addressing integrity and security
and to provide specific guidance for other protocol usage. of information and to provide specific guidance for other protocol
usage.
9.2. Compact Form of the "rcdi" PASSporT Claim 9.2. Compact Form of the "rcdi" PASSporT Claim
The use of the compact form of a PASSporT using an "rcdi" claim is The use of the compact form of a PASSporT using an "rcdi" claim is
not supported, so if "rcdi" is required, compact form MUST NOT be not supported, so if "rcdi" is required, compact form MUST NOT be
used. used.
9.3. Compact Form of the "crn" PASSporT Claim 9.3. Compact Form of the "crn" PASSporT Claim
Compact form of a "crn" PASSporT claim shall be reconstructed using Compact form of a "crn" PASSporT claim shall be reconstructed using
skipping to change at line 956 skipping to change at line 961
While rich data about the call can be provided by an originating While rich data about the call can be provided by an originating
authentication service, an intermediary in the call path could also authentication service, an intermediary in the call path could also
acquire rich call data by querying a third-party service. Such a acquire rich call data by querying a third-party service. Such a
service effectively acts as a STIR Authentication Service, generating service effectively acts as a STIR Authentication Service, generating
its own PASSporT, and that PASSporT could be attached to a call by its own PASSporT, and that PASSporT could be attached to a call by
either the originating or terminating side. This third-party either the originating or terminating side. This third-party
PASSporT attests information about the calling number, rather than PASSporT attests information about the calling number, rather than
the call or caller itself, and as such its RCD MUST NOT be used when the call or caller itself, and as such its RCD MUST NOT be used when
a call lacks a first-party PASSporT that assures verification a call lacks a first-party PASSporT that assures verification
services that the calling party number is not spoofed. It is services that the calling party number is not spoofed. A third-party
intended to be used in cases when the originating side does not PASSporT is intended to be used in cases when the originating side
supply a display-name for the caller, so instead some entity in the does not supply a display-name for the caller, so instead some entity
call path invokes a third-party service to provide rich caller data in the call path invokes a third-party service to provide rich caller
for a call. data for a call.
In telephone operations today, a third-party information service is In telephone operations today, a third-party information service is
commonly queried with the calling party's number in order to learn commonly queried with the calling party's number in order to learn
the name of the calling party, and potentially other helpful the name of the calling party, and potentially other helpful
information could also be passed over that interface. The value of information could also be passed over that interface. The value of
using a PASSporT to convey this information from third parties lies using a PASSporT to convey this information from third parties lies
largely in the preservation of the third party's signature over the largely in the preservation of the third party's signature over the
data, and the potential for the PASSporT to be conveyed from data, and the potential for the PASSporT to be conveyed from
intermediaries to endpoint devices. Effectively, these use cases intermediaries to endpoint devices. Effectively, these use cases
form a sub-case of out-of-band use cases [RFC8816]. The manner in form a sub-case of out-of-band use cases [RFC8816]. The manner in
skipping to change at line 1072 skipping to change at line 1077
credentials accepted to sign PASSporTs when third parties generate credentials accepted to sign PASSporTs when third parties generate
PASSporT objects, per Section 10.1. This may include accepting a PASSporT objects, per Section 10.1. This may include accepting a
valid signature over a PASSporT even if it is signed with a valid signature over a PASSporT even if it is signed with a
credential that does not attest authority over the identity in the credential that does not attest authority over the identity in the
"orig" claim of the PASSporT, provided that the verification service "orig" claim of the PASSporT, provided that the verification service
has some other reason to trust the signer. No further guidance on has some other reason to trust the signer. No further guidance on
verification service authorization policy is given here. verification service authorization policy is given here.
11. Levels of Assurance 11. Levels of Assurance
As "rcd" can be provided by either first-party providers that are A set of "rcd" claims can be provided by either first-party providers
directly authorized to sign PASSporTs in the STIR ecosystem or third- that are directly authorized to sign PASSporTs in the STIR ecosystem
party providers that are indirectly or delegated authority to sign or third-party providers that are indirectly or delegated authority
PASSporTs. Relying parties could benefit from an additional claim to sign PASSporTs. Relying parties could benefit from an additional
that indicates the identification, in the form of a uniquely claim that indicates the identification, in the form of a uniquely
identifiable name, of the attesting party to the caller. Even in identifiable name, of the attesting party to the caller. Even in
first-party cases, the Communications Service Provider (CSP) to which first-party cases, the Communications Service Provider (CSP) to which
a number was assigned might in turn delegate the number to a a number was assigned might in turn delegate the number to a
reseller, who would then sell the number to an enterprise, in which reseller, who would then sell the number to an enterprise, in which
case the CSP might have little insight into the caller's name. In case the CSP might have little insight into the caller's name. In
third-party cases, a caller's name could be determined from any third-party cases, a caller's name could be determined from any
number of data sources, on a spectrum between public data scraped number of data sources, on a spectrum between public data scraped
from web searches to a direct business relationship to the caller. from web searches to a direct business relationship to the caller.
As multiple PASSporTs can be associated with the same call, As multiple PASSporTs can be associated with the same call,
potentially a verification service could receive attestations of the potentially a verification service could receive attestations of the
caller name from multiple sources, which have different levels of caller name from multiple sources, which have different levels of
granularity or accuracy. Therefore, third-party PASSporTs that carry granularity or accuracy. Therefore, third-party PASSporTs that carry
"rcd" data are RECOMMENDED to also carry an indication of the "rcd" data are RECOMMENDED to also carry an indication of the
identity of the generator of the PASSporT in the form of the 'iss' identity of the generator of the PASSporT in the form of the 'iss'
claim. claim.
12. Use of "rcd" PASSporTs in SIP 12. Use of "rcd" PASSporTs in SIP
This section documents SIP-specific usage for "rcd" PASSporTs and in This section documents SIP-specific usage for "rcd" PASSporTs in the
the SIP Identity header field value. Other protocols using PASSporT SIP Identity header field value. Other protocols using PASSporT may
may define their own guidance for "rcd" PASSporTs. define their own guidance for "rcd" PASSporTs.
12.1. Authentication Service Behavior for SIP Protocol 12.1. Authentication Service Behavior for SIP Protocol
An authentication service creating a PASSporT containing an "rcd" An authentication service creating a PASSporT containing an "rcd"
claim MAY include a PASSporT extension ("ppt" value) of "rcd". claim MAY include a PASSporT extension ("ppt" value) of "rcd".
Third-party authentication services following the behavior in Third-party authentication services following the behavior in
Section 10.1 MUST include a PASSporT extension value of "rcd". If Section 10.1 MUST include a PASSporT extension value of "rcd". If
the PASSporT extension does contain an "rcd", then any SIP the PASSporT extension does contain an "rcd", then any SIP
authentication services MUST add a PASSporT extension "ppt" parameter authentication services MUST add a PASSporT extension "ppt" parameter
to the Identity header field containing that PASSporT with a value of to the Identity header field containing that PASSporT with a value of
skipping to change at line 1174 skipping to change at line 1179
If the PASSporT is in full form with a PASSporT extension value of If the PASSporT is in full form with a PASSporT extension value of
"rcd", then the verification service MUST extract the value "rcd", then the verification service MUST extract the value
associated with the "rcd" claim "nam" key in the object. If the associated with the "rcd" claim "nam" key in the object. If the
PASSporT signature is verified successfully, then the verification PASSporT signature is verified successfully, then the verification
service MUST additionally compare the string value of the "rcd" claim service MUST additionally compare the string value of the "rcd" claim
"nam" key value with the From header field value or the preferred "nam" key value with the From header field value or the preferred
value. The preferred value depends on local policy of the SIP value. The preferred value depends on local policy of the SIP
network technique that conveys the display name string through a network technique that conveys the display name string through a
field other than the From header field to interoperate with this field other than the From header field to interoperate with this
specification (e.g., P-Asserted-Identity) as discussed in [RFC8224]. specification (e.g., P-Asserted-Identity) as discussed in [RFC8224].
Similarly, "jcd" or "jcl" jCard information, "icn", "apn", or "crn" Similarly, "jcd", "jcl", "icn", "apn", or "crn" elements can be used
can be optionally, based on local policy for devices that support it, optionally (based on local policy for devices that support it) to
used to populate a Call-Info header field following the format of populate a Call-Info header field following the format of [RFC9796].
[RFC9796]. If PASSporT RCD claims types defined in the future are If PASSporT RCD claims types defined in the future are present, they
present, they should follow similar defined proceedures and policies. should follow similar defined proceedures and policies.
The behavior of a SIP User Agent Server (UAS) upon receiving an The behavior of a SIP User Agent Server (UAS) upon receiving an
INVITE or other type of session initiation request containing a INVITE or other type of session initiation request containing a
PASSporT object with an "rcd" claim largely remains a matter of PASSporT object with an "rcd" claim largely remains a matter of
implementation policy. In most cases, implementations would render implementation policy. In most cases, implementations would render
this calling party name information to the user while alerting. Any this calling party name information to the user while alerting. Any
user interface additions to express confidence in the veracity of user interface additions to express confidence in the veracity of
this information are outside the scope of this specification. this information are outside the scope of this specification.
13. Using "rcd", "rcdi", and "crn" as Additional Claims to Other 13. Using "rcd", "rcdi", and "crn" as Additional Claims to Other
skipping to change at line 1220 skipping to change at line 1225
The verification service that receives the PASSporT, if it supports The verification service that receives the PASSporT, if it supports
this specification and chooses to, should interpret the "rcd" claim this specification and chooses to, should interpret the "rcd" claim
as simply just an additional claim intended to deliver and/or as simply just an additional claim intended to deliver and/or
validate delivered Rich Call Data. validate delivered Rich Call Data.
13.2. Example for Applying RCD Claims as Claims Only 13.2. Example for Applying RCD Claims as Claims Only
In the case of [RFC8588], which is the PASSporT extension supporting In the case of [RFC8588], which is the PASSporT extension supporting
the Signature-based Handling of Asserted information using toKENs the Signature-based Handling of Asserted information using toKENs
(SHAKEN) specification [ATIS-1000074.v002], a common case is for an (SHAKEN) specification [ATIS-1000074.v003], a common case is for an
authentication service to coexist in a CSP network along with the authentication service to coexist in a CSP network along with the
authority over the calling name used for the call. Rather than authority over the calling name used for the call. Rather than
require two identity headers, the CSP authentication service can require two identity headers, the CSP authentication service can
apply both the SHAKEN PASSporT claims and extension and simply add apply both the SHAKEN PASSporT claims and extension and simply add
the "rcd" required claims defined in this document. the "rcd" required claims defined in this document.
For example, the PASSporT claims for the "shaken" PASSporT with "rcd" For example, the PASSporT claims for the "shaken" PASSporT with "rcd"
claims would be as follows: claims would be as follows:
Protected Header Protected Header
skipping to change at line 1376 skipping to change at line 1381
(for example, SIP) is information that is carried in the clear (for example, SIP) is information that is carried in the clear
anyway. Transport-level security can hide those SIP fields from anyway. Transport-level security can hide those SIP fields from
eavesdroppers, and the same confidentiality mechanisms would protect eavesdroppers, and the same confidentiality mechanisms would protect
any PASSporT(s) carried in SIP. any PASSporT(s) carried in SIP.
The dereferencing and download of any RCD URI-linked resources as The dereferencing and download of any RCD URI-linked resources as
part of verification either in-network or on device could provide part of verification either in-network or on device could provide
some level of information about calling patterns, so this should be some level of information about calling patterns, so this should be
considered when making these resources available. considered when making these resources available.
The use of JWTClaimConstraints, a mechanism defined in [RFC8226] and The use of JWT Claim Constraints, a mechanism defined in [RFC8226]
extended in [RFC9118], to constrain any of the RCD information in the and extended in [RFC9118], to constrain any of the RCD information in
public certificate by including that information in the certificate, the public certificate by including that information in the
depending on the availability in the deployment of the PKI system, certificate, depending on the availability in the deployment of the
may present a privacy issue. The use of the "rcdi" claim and digests PKI system, may present a privacy issue. The use of the "rcdi" claim
for representing JWT claim contents is RECOMMENDED for the prevention and digests for representing JWT claim contents is RECOMMENDED for
of the exposure of that information through the certificates that are the prevention of the exposure of that information through the
often publicly accessible and available. certificates that are often publicly accessible and available.
Since computation of "rcdi" digests for URIs requires the loading of Since computation of "rcdi" digests for URIs requires the loading of
referenced content, it would be best practice to validate that referenced content, it would be best practice to validate that
content at the creation of the "rcdi" or corresponding JWT claim content at the creation of the "rcdi" or corresponding JWT claim
constraint value by checking for content that may cause issues for constraint value by checking for content that may cause issues for
verification services or that doesn't follow the behavior defined in verification services or that doesn't follow the behavior defined in
this document, e.g., unreasonably sized data, the inclusion of this document, e.g., unreasonably sized data, the inclusion of
recursive URI references, etc. Along the same lines, the recursive URI references, etc. Along the same lines, the
verification service should also use precautionary best practices to verification service should also use precautionary best practices to
avoid attacks when accessing URI-linked content. avoid attacks when accessing URI-linked content.
skipping to change at line 1500 skipping to change at line 1505
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>. September 2021, <https://www.rfc-editor.org/info/rfc9060>.
[RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim [RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim
Constraints for Secure Telephone Identity Revisited (STIR) Constraints for Secure Telephone Identity Revisited (STIR)
Certificates", RFC 9118, DOI 10.17487/RFC9118, August Certificates", RFC 9118, DOI 10.17487/RFC9118, August
2021, <https://www.rfc-editor.org/info/rfc9118>. 2021, <https://www.rfc-editor.org/info/rfc9118>.
[RFC9796] Wendt, C. and J. Peterson, "SIP Call-Info Parameters for [RFC9796] Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", RFC 9796, DOI 10.17487/RFC9796, May 2025, Rich Call Data", RFC 9796, DOI 10.17487/RFC9796, June
<https://www.rfc-editor.org/info/rfc9796>. 2025, <https://www.rfc-editor.org/info/rfc9796>.
17.2. Informative References 17.2. Informative References
[ATIS-1000074.v002] [ATIS-1000074.v003]
Alliance for Telecommunications Industry Solutions, Alliance for Telecommunications Industry Solutions,
"Signature-based Handling of Asserted information using "Signature-based Handling of Asserted information using
toKENs (SHAKEN)", November 2021. toKENs (SHAKEN)", ATIS-1000074.v003, August 2022,
<https://access.atis.org/higherlogic/ws/public/
download/67436>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
skipping to change at line 1539 skipping to change at line 1546
<https://www.rfc-editor.org/info/rfc8816>. <https://www.rfc-editor.org/info/rfc8816>.
[TS.3GPP.24.229] [TS.3GPP.24.229]
3GPP, "IP multimedia call control protocol based on 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 16.7.0, 3GPP TS 24.229, Protocol (SDP); Stage 3", 16.7.0, 3GPP TS 24.229,
September 2020, September 2020,
<https://www.3gpp.org/ftp/Specs/html-info/24229.htm>. <https://www.3gpp.org/ftp/Specs/html-info/24229.htm>.
[W3C-SubresourceIntegrity] [W3C-SubresourceIntegrity]
Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J. Braun, F., Ed., "Subresource Integrity", W3C First Public
Weinberger, Ed., "Subresource Integrity", W3C Working Draft, 25 April 2025,
Recommendation, 23 June 2016, <https://www.w3.org/TR/2025/WD-sri-2-20250422/>.
<https://www.w3.org/TR/2016/REC-SRI-20160623/>.
Acknowledgements Acknowledgements
We would like to thank David Hancock, Robert Sparks, Russ Housley, We would like to thank David Hancock, Robert Sparks, Russ Housley,
Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard, Jordan Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard, Jordan
Simpson for helpful suggestions, review, and comments. Simpson for helpful suggestions, review, and comments.
Authors' Addresses Authors' Addresses
Chris Wendt Chris Wendt
 End of changes. 36 change blocks. 
123 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.48.