Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the XML file.
1) <!--[rfced] For clarity, may the last phrase of this sentence be
reworded as follows or otherwise? It's not clear what is placing the
constraint on the RCD.
Original:
Finally, this document describes how to preserve the integrity of the
RCD in scenarios where there may be non-authoritative users
initiating and signing RCD and therefore a constraint on the RCD data
that a PASSporT can attest via certificate-level controls.
Option A:
Finally, this document describes how to preserve the integrity of the
RCD in scenarios where there may be non-authoritative users initiating
and signing RCD, therefore limiting whether a PASSporT can attest the
RCD via certificate-level controls.
Option B:
Finally, this document describes how to preserve the integrity of the
RCD in scenarios where there may be non-authoritative users initiating
and signing RCD by specifying the use of JWT claims constraints on the
RCD data that a PASSporT can attest to via certificate-level controls.
-->
2) <!--[rfced] Please clarify the list in this sentence.
Original:
This document defines a
mechanism that allows for a direct or indirect party that enforces
the policies to approve or certify the content, create a
cryptographic digest that can be used to validate that data and
applies a constraint in the certificate to allow the recipient and
verifier to validate that the specific content of the RCD is as
intended at its creation and approval or certification.
Option A:
This document defines a mechanism that allows for a party that
(a) enforces X, (b) creates Y, and (c) applies Z.
Option B:
This document defines a mechanism that
(a) allows for a party that enforces X, (b) creates Y, and (c) applies Z.
Perhaps (if Option A is accurate):
This document defines a mechanism that allows for a direct or
indirect party that (a) enforces
the policies to approve or certify the content, (b) creates a
cryptographic digest that can be used to validate that data, and
(c) applies a constraint in the certificate to allow the recipient and
verifier to validate that the specific content of the RCD is as
intended at its creation and its approval or certification.
-->
3) <!--[rfced] May this phrase be reworded for clarity?
Seems "allowing the ability to enable a mechanism for allowing"
could be simplified.
Original:
The third and fourth modes cover cases where there is a different
authoritative entity responsible for the content of the RCD, separate
from the signer of the PASSporT itself, allowing the ability, in
particular when delegating signing authority for PASSporT, to enable
a mechanism for allowing agreed or vetted content included in or
referenced by the RCD claim contents.
Specifically, regarding the last part:
allowing the ability, in particular when [...],
to enable a mechanism for allowing agreed or vetted content included in
or referenced by the RCD claim contents.
Option A:
allowing the ability, in particular when [...],
to enable a mechanism for agreed or vetted content to be included
in or referenced by the RCD claim contents.
Option B:
allowing the ability, in particular when [...],
for agreed or vetted content to be included in or
referenced by the RCD claim contents.
-->
4) <!-- [rfced] This sentence appeared to intend to cite 3GPP TS 24.229,
but there was not a corresponding reference. We added an informative
reference as follows; please review and let us know if this is accurate.
Would you like to update this to the most recent version? (We see
version 19.0.2 from March 2025.)
Original:
The "apn" key value is an optional alternate presentation number
associated with the originator of personal communications, which may
for example match the user component of the From header field value
of a SIP request (in cases where a network number is carried in the
P-Asserted-Identity [RFC3325]), or alternatively from the Additional-
Identity header field value [3GPP TS 24.229 v16.7.0], or a similar
field in other PASSporT using protocols.
Current:
The "apn" key value is an optional alternate presentation number
associated with the originator of personal communications, which may
for example match the user component of the From header field value
of a SIP request (in cases where a network number is carried in the
P-Asserted-Identity [RFC3325]), or alternatively of the Additional-
Identity header field value [TS.3GPP.24.229], or a similar
field in other PASSporT-using protocols.
Added in Section 18.2:
[TS.3GPP.24.229]
3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP); Stage 3", 16.7.0, 3GPP TS 24.229,
September 2020,
<https://www.3gpp.org/ftp/Specs/html-info/24229.htm>.
-->
5) <!--[rfced] What does "This usage" refer to? The preceding sentence
is included for context. Perhaps it refers to the use of the "apn"
key in general?
Original:
How the signer determines
that a user is authorized to present the number in question is a
policy decision outside the scope of this document, however, the
vetting of the alternate presentation number should follow the same
level of vetting as telephone identities or any other information
contained in an "rcd" PASSporT or "rcd" claims. This usage is
intended as an alternative to conveying the presentation number in
the "tel" key value of a jCard, in situations where no other rich
jCard data needs to be conveyed with the call.
Perhaps:
How the signer determines [...]
The use of the "apn" key is intended as an alternative to conveying
the presentation number ...
-->
6) <!--[rfced] Please clarify "using Call-Info as protocol".
Original:
Note: even though we refer to [RFC9796] as the definition of the
jcard properties for usage in "rcd" claims, using Call-Info as
protocol with the addition of an identity header carrying the
PASSPorT is not required.
-->
7) <!--[rfced] Is this a 1:1 relationship? In other words,
should this be "Each of these claims corresponds to each of the elements"?
Original:
These objects correspond to each of the
elements of the "rcd" claim object that require integrity protection
with an associated digest over the content referenced by the key
string.
-->
8) <!--[rfced] Would you like to list the codepoint for this character
in a more typical manner? "ASCII 45" was last used in RFC 1849.
Original:
MUST be a hyphen character, "-", or ASCII 45.
Perhaps:
MUST be a hyphen character ("-", %x2D).
Or:
MUST be a hyphen character, "-" (HYPHEN-MINUS, U+002D).
-->
9) <!--[rfced] How should the first point be changed to a complete
sentence? (The second and third points are complete sentences.)
Also, for subject/verb agreement, should "the JWT Claim Constraints is
applied" be "the JWT Claim Constraints certificate extension is applied"
or "the JWT Claim Constraints are applied" or otherwise?
Preceding sentence for context:
In order to facilitate proper verification of the digests and to
determine whether the "rcd" elements or content referenced by URIs
were modified, the input to the digest must be completely
deterministic at three points in the process:
Original:
First, at the certification point where the content
is evaluated to conform to the application policy and the JWT Claim
Constraints is applied to the certificate containing the digest.
Perhaps:
First, it must be deterministic at the certification point when the
content is evaluated to conform to the application policy and when
the JWT Claim Constraints are applied to the certificate containing
the digest.
-->
10) <!--[rfced] Please clarify this sentence. In particular, what does
"with the exception and the minor modification" mean?
We suggest making this into two sentences.
Original:
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
modification to JSON pointer, where "/jcl" is used to refer to the
external jCard array string and any following numeric array indices
added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the
external content referenced by the jCard was directly part of the
overall "rcd" claim JSON object.
Perhaps:
In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the minor
modification to the JSON pointer, where "/jcl" is used to refer to the
external jCard array string. Also, any following numeric array indices
added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the
external content referenced by the jCard were directly part of the
overall "rcd" claim JSON object.
-->
11) <!--[rfced] May 'usage' be cut from the title of Section 6.3 for
consistency with the title of Section 6.2?
Original:
6.2. JWT Claim Constraints for "rcd" claims
6.3. JWT Claim Constraints usage for "rcd" and "rcdi" claims
Perhaps:
6.2. JWT Claim Constraints for "rcd" Claims
6.3. JWT Claim Constraints for "rcd" and "rcdi" Claims
-->
12) <!--[rfced] Is this whole sentence describing an example? If so, we
suggest moving "as an example" to the start.
Original:
This would often be associated with the use of delegate
certificates [RFC9060] for the signing of calls by the calling party
directly as an example, even though the "authorized party" is not
necessarily the subject of a STIR certificate.
Perhaps:
For example, this may be used with delegate certificates [RFC9060]
for the signing of calls by the calling party directly, even though
the "authorized party" is not necessarily the subject of a STIR
certificate.
-->
13) <!--[rfced] May we update these section titles to make them parallel
and simplified?
Original:
5. PASSporT Claim "rcd" Definition and Usage
6. "rcdi" RCD Integrity Claim Definition and Usage
7. PASSporT "crn" claim - Call Reason Definition and Usage
Option A:
5. PASSporT Claim "rcd" Definition and Usage
6. PASSporT Claim "rcdi" Definition and Usage
7. PASSporT Claim "crn" Definition and Usage
Option B (as this word order is also used within this document):
5. "rcd" PASSporT Claim: Definition and Usage
6. "rcdi" PASSporT Claim: Definition and Usage
7. "crn" PASSporT Claim: Definition and Usage
-->
14) <!--[rfced] There is one instance of "JWT Constraints" (plural) in this
document; should it be "JWT Claim Constraints" to match usage elsewhere
within this document?
Original:
The integrity of the "crn" claim contents can optionally be protected
by the authoritative certificate issuer using JWT Constraints in the
certificate.
-->
15) <!--[rfced] May this be rephrased to clarify "at least one or both an"?
Original:
... in which case the PASSporT
claims MUST contain at least one or both an "rcd" or "crn" claim.
Perhaps:
In that case,
the PASSporT MUST contain at least one "rcd" or "crn" claim (or both).
-->
16) <!--[rfced] Do both of these sentences refer to the example that follows?
Perhaps the text can be clarified?
Original:
In an example PASSporT, where a jCard is linked via HTTPS URL using
"jcl", a jCard file served at a particular URL.
An example jCard JSON file hosted at the example web address of
https://example.com/qbranch.json is shown as follows:
Perhaps:
In the following PASSporT example, a jCard is linked via HTTPS URL
using "jcl", and a jCard file is served at a particular URL.
Example jCard JSON file hosted at https://example.com/qbranch.json:
-->
17) <!--[rfced] Please clarify this sentence. Specifically,
what is "leading to too restrictive a set of constraints"?
Also, please consider starting with "The claims" or similar
to make a clearer break with the preceding sentence (which ends
with the example of the empty string "".).
Original:
"jcl" and "jcd" MUST NOT be used with compact form due to
integrity rules and URI reference rules in this document leading to
too restrictive of a set of constraints.
Perhaps:
The claims
"jcl" and "jcd" MUST NOT be used with compact form because
the integrity rules and URI reference rules defined in this document
would lead to a set of constraints that is too restrictive.
-->
18) <!--[rfced] What is "It" in "It is intended"? The third-party PASSporT?
(The preceding sentence is included for context.)
Original:
This third-party
PASSporT attests information about the calling number, rather than
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
services that the calling party number is not spoofed. It is
intended to be used in cases when the originating side does not
supply a display-name for the caller, so instead some entity in the
call path invokes a third-party service to provide rich caller data
for a call.
-->
19) <!--[rfced] Please clarify "providers that are indirectly or delegated
authority to sign PASSporTs". What is the intended meaning? Is a word missing?
Original:
As "rcd" can be provided by either first party providers that are
directly authorized to sign PASSporTs in the STIR eco-system or third
party providers that are indirectly or delegated authority to sign
PASSporTs.
-->
20) <!--[rfced] Please note that we have removed "and" from the sentence below.
Please let us know if this incorrect.
Original:
This section documents SIP-specific usage for "rcd" PASSporTs and in
the SIP Identity header field value.
Current:
This section documents SIP-specific usage for "rcd" PASSporTs in
the SIP Identity header field value.
-->
21) <!--[rfced] Is this a list of five elements? If so, may it be rephrased
as follows or otherwise?
Original:
Similarly, "jcd" or "jcl" jcard information, "icn", "apn", or "crn"
can be optionally, based on local policy for devices that support it,
used to populate a Call-Info header field following the format of
[I-D.ietf-sipcore-callinfo-rcd].
Perhaps:
Similarly, "jcd", "jcl", "icn", "apn", or "crn" elements
can be used optionally (based on local policy for devices that support
it) to populate a Call-Info header field following the format of
[RFC9796].
-->
22) <!-- [rfced] Regarding [ATIS-1000074.v002], the original URL provided
yields "Sorry, the document could not be found".
We found the following URL of a more recent version of this standard:
https://access.atis.org/higherlogic/ws/public/download/67436
(which appears to be Version 3 of this standard and was published
16 August 2022). May we update this reference to that version?
Original:
[ATIS-1000074.v002]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN)
<https://access.atis.org/apps/group_public/
download.php/62391/ATIS-1000074.v002.pdf>", November
2021.
Perhaps:
[ATIS-1000074.v003]
Alliance for Telecommunications Industry Solutions,
"Signature-based Handling of Asserted information using
toKENs (SHAKEN)", August 2022,
<https://access.atis.org/higherlogic/ws/public/
download/67436>.
-->
23) <!-- [rfced] Regarding [W3C-SubresourceIntegrity], the original URL
for this reference directed the reader to a W3C First Public Working Draft
with a date of 22 April 2025. However, the original date provided for
this reference was 23 June 2016, which matches that of the W3C
Recommendation titled "Subresource Integrity"
(https://www.w3.org/TR/2016/REC-SRI-20160623/). We have updated this
reference to that.
However, please let us know if you intended to point to
the First Public Working Draft (https://www.w3.org/TR/2025/WD-sri-2-20250422/)
or otherwise.
Original:
[W3C-SubresourceIntegrity]
W3C, "Subresource Integrity <https://www.w3.org/TR/SRI/>",
23 June 2016.
Current:
[W3C-SubresourceIntegrity]
Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J.
Weinberger, Ed., "Subresource Integrity", W3C
Recommendation, 23 June 2016,
<https://www.w3.org/TR/2016/REC-SRI-20160623/>.
-->
24) <!--[rfced] Terminology
a) We updated the following terms to the form on the right
based on common usage. Please let us know if you prefer otherwise.
Verification Service -> verification service
JSON Pointer -> JSON pointer
'display-name', "display-name" -> display-name
(because it most often appeared without quotes)
b) JWTClaimConstraints (4 instances) vs.
JWT Claim Constraints (15 instances)
Do these have the same meaning? If so, should one be used
consistently?
c) Note that we added hyphens as shown on the right below. Please let us know
if you have any concerns.
URI referenced content -> URI-referenced content
URI linked content -> URI-linked content
-->
25) <!-- [rfced] Please review the "type" attribute of each sourcecode
element in the XML file to ensure correctness. If the current list of
preferred values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
In addition, review each artwork element. Specifically,
should any artwork element be tagged as sourcecode or another
element?
-->
26) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
27) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
In addition, please consider whether "traditional" should be updated for
clarity in the instances listed below. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
... the traditional "Caller ID" of the telephone network
Traditional telephone network signaling protocols ...
The first data is a more
traditional set of info about a caller associated with "display-name"
in SIP ...
... even in traditional calling name services today ...
While in the traditional telephone network, ...
-->
Thank you.
RFC Editor
On May 23, 2025, at 1:48 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/05/23
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9795.xml
https://www.rfc-editor.org/authors/rfc9795.html
https://www.rfc-editor.org/authors/rfc9795.pdf
https://www.rfc-editor.org/authors/rfc9795.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9795-diff.html
https://www.rfc-editor.org/authors/rfc9795-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9795-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9795
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9795 (draft-ietf-stir-passport-rcd-26)
Title : PASSporT Extension for Rich Call Data
Author(s) : C. Wendt, J. Peterson
WG Chair(s) : Ben Campbell, Robert Sparks, Russ Housley
Area Director(s) : Andy Newton, Orie Steele
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
