Thanks for the review and suggestions. Comments inline: > On May 23, 2025, at 4:54 PM, rfc-edi...@rfc-editor.org wrote: > > 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. > -->
Option A works well. Maybe slight variation: 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 a PASSporT and the RCD claims it asserts 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. > --> The suggested text above works. > > > 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. > --> Option B is simple and works. > > > 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>. > --> That is correct > > > 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 ... > --> Yes, clearer > > > 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. > --> How about “… using the Call-Info header field with RCD information in a SIP request beyond the use of identity header as defined in this document is not required. Identity header fields are generally encouraged for all transport of authenticated and protected RCD information over Network-to-Network Interfaces (NNI) 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 (UNI).” > > > 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. > --> Correct, it is a 1:1 relationship. Each “rcdi” claim key/value pair corresponds to each of the elements of the “rcd” claim object … > > > 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). > --> Yes the first suggestion works. > > > 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. > --> The suggested text is good. > > > 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. > --> Yes this works. > > > 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 > --> Yes > > > 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. > --> That works. > > > 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 > --> Yes, Option B works. > > > 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. > --> Yes please normalize with “Claim” included. > > > 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). > --> Yes that works. > > > 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: > --> Yes, suggestion is good. > > > 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. > --> Suggested text is good. > > > 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. > --> Yes, Replace “It is” with “A third-party PASSporT is” > > > 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. > --> The word ‘As “rcd”’ should just be replaced with ‘A set of ”rcd” claims’ to make it a complete factual phrase. > > > 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. > --> Yes that works. > > > 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]. > --> That works. > > > 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>. > --> Yes > > > 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/>. > --> Yes > > > 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 > --> For a) Yes. For b), interesting question, looking at RFC8226 and RFC9118 I believe the way this document uses the term it should be made consistent using spaces “JWT Claim Constraints” For c) No concerns, that works. > > > 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? > --> I don’t believe we have the need for any sourcecode elements/types in the document, but this is a bit new to me, so i can defer that to the editor to what looks like convention for JSON examples perhaps. > > > 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). > --> I am ok to make notes aside elements if that is typical. > > > 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, ... > --> I reviewed for inclusive language and did not find any. For the use of “traditional”, i believe this is a common way to refer to the “legacy” telephone network which is sometimes considered a bit derogatory, so I think keeping “traditional” is a good way to conventionally refer to older types of telephony networks and usage and not changed. > > > Thank you. > > RFC Editor > > > > On May 23, 2025, at 1:48 PM, rfc-edi...@rfc-editor.org 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 > > * rfc-edi...@rfc-editor.org (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). > > * auth48archive@rfc-editor.org, 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, > auth48archive@rfc-editor.org 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
