Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Document title: We expanded "JWT" in the document title. Please let us know if you have any concerns. Original: Selective Disclosure for JWTs (SD-JWT) Currently: Selective Disclosure for JSON Web Tokens (SD-JWTs) --> 2) <!-- [rfced] Regarding <artwork> and <sourcecode> settings in this document: a) Section 4.2.6: We see that the first entry with '"family_name": "Möbius"' is labeled as '<sourcecode type="json">' but the next two entries in this section are labeled as '<sourcecode>' (no type included). May we change '<sourcecode>' to '<sourcecode type="json">' for these other two entries? b) We see several entries with '<sourcecode type="txt">'. Please note that "txt" is not listed as an approved type on <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. Would "test-vectors" be more appropriate? RFC 9879 provides an example of using the "test-vectors" type; please see <https://www.rfc-editor.org/info/rfc9879> for access to its XML file. If not, do you suggest that "txt" be added as an additional sourcecode type? c) Please review the items labeled as <artwork> in Appendices A.5 and B, and let us know if we may label them as <sourcecode> with type="json" instead. For example, should the JSON object shown under the text "a JSON object such as this" be set to <sourcecode> with type="json"? --> 3) <!-- [rfced] Sections 4 and 4.2.4.2: The following lines are too long for the text output. We get the following warnings from xml2rfc: (252): Warning: Too long line found (L423), 5 characters longer than 72 characters: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT> (512): Warning: Too long line found (L786), 2 characters longer than 72 characters: ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"] Would the suggested line breaks be acceptable? If not, please let us know where these lines should be broken. Perhaps: <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~... ~<Disclosure N>~<KB-JWT> ... ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}, "US"] --> 4) <!-- [rfced] Regarding the use of font styling (i.e., <tt> and <strong>), please review the questions below. Note: For <tt>-related items, view the list here: https://www.rfc-editor.org/authors/rfc9901tt.txt a) May we update instances of <tt>none</tt> to "none" for increased clarity in the text file, and for consistency with RFCs 8725 and 9781? It MUST NOT use the none algorithm. - alg: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST NOT be none. The none algorithm MUST NOT be accepted. (2x) b) In general, please review the use of <tt> and note that there are no visual marks in the text file. Is the goal of <tt> to indicate fixed-width font or to call attention to the various items? Some similar text seems to be marked as both <sourcecode> and <tt>. Please review and consider updating the XML file for consistency as needed. For example, we see the following, which seem similar. Was <tt> used in running text? <sourcecode type=“json”><![CDATA[ [“_26bc4LT-ac6q2KI6cBW5es”, “family_name”, “Möbius”] ]]> </sourcecode> <tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]</tt> c) May we reformat the bulleted items that use <strong> as shown below? Note that we reformatted the entry for "Claim given_name:" in Section 5.1 so you can see the update in context. We believe this will make the groupings more clear and allow us to avoid the use of bold, which displays as asterisks in the text (which looks awkward because the *claim name* (with asterisks) is followed by a list with asterisks as bullets). Original: *Claim given_name*: * SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4 * Disclosure: WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o biJd * Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"] *Claim family_name*: Perhaps: * Claim given_name: - SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4 - Disclosure: WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ d - Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"] *Claim family_name*: --> 5) <!-- [rfced] Sections 4.1.2 and subsequent: We have changed instances of <blockquote> to <aside> throughout. Please review and let us know if any updates are needed. Per <https://authors.ietf.org/en/rfcxml-vocabulary#aside>, the <aside> element is defined as "a container for content that is semantically less important or tangential to the content that surrounds it". --> 6) <!-- [rfced] May we change "taken" to "chosen" or "preferred" for clarity? Section 4.2.3: In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON Serialization, and the digest in the sd_hash claim MUST be taken over the SD-JWT as described in Section 4.3.1. Section 4.3.1: The sd_hash value MUST be taken over the US-ASCII bytes of the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character, and zero or more Disclosures selected for presentation to the Verifier, each followed by a tilde character: Section 8.1: In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON Serialization, and the digest in the sd_hash claim MUST be taken over the SD-JWT as described in Section 4.3.1. --> 7) <!-- [rfced] We are having trouble parsing this sentence. Please consider whether the suggested text below is a correct interpretation. Original: An _sd key can be present at any level of the JSON object hierarchy, including the top- level, nested deeper as described in Section 6, or in recursive disclosures as described in Section 4.2.6. Perhaps A (the "or" is connecting two things): An _sd key can be present at any level of the JSON object hierarchy (including at the top level or nested deeper as described in Section 6) or in recursive disclosures as described in Section 4.2.6. Perhaps B (the "or" is connecting three things: at the top level, nested deeper, and recursive disclosures): An _sd key can be present at any level of the JSON object hierarchy, including at the top level, nested deeper as described in Section 6, or in recursive disclosures as described in Section 4.2.6. --> 8) <!-- [rfced] Would it be appropriate to treat "Content of Disclosures:" as regular text, and include a separate <sourcecode> block for the text that follows? Note that we have set type="" (empty) as "ascii-art" seems to indicate <artwork>. Please let us know if this should be considered <artwork> rather than <sourcecode>. For example, currently, the xml includes the following: <sourcecode type="ascii-art"><![CDATA[{ "family_name": "Möbius", "nationalities": [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" } { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ] } Content of Disclosures: PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] ]]> </sourcecode> Perhaps: <sourcecode type=""><![CDATA[{ "family_name": "Möbius", "nationalities": [ { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" } { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" } { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" } ] } ]]> </sourcecode> <t>Content of Disclosures:</t> <sourcecode type=""><![CDATA[{ PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"] ]]> </sourcecode> --> 9) <!-- [rfced] Note that we have adjusted this text to remove a specific character count that is allowed per line. The number of characters is different depending on whether the text is running text (69 chars), sourcecode (69 chars), or artwork (72 chars). Original: | Note: Throughout the examples in this document, line breaks had to | be added to JSON strings and base64-encoded strings to adhere to | the 72-character limit for lines in RFCs and for readability. | JSON does not allow line breaks within strings. Current: | Note: Throughout the examples in this document, line breaks | were added to JSON strings and base64-encoded strings to adhere | to the line-length limit in RFCs and for readability. JSON | does not allow line breaks within strings. --> 10) <!-- [rfced] For clarity in the text output, may we add "claim" after address here? While "claim" is enclosed in <tt>, which makes it visually distinct from surrounding text in the html and pdf, there is no such visual distinction in the text. Original: | Note: The following examples of the structures are non-normative | and are not intended to represent all possible options. They are | also not meant to define or restrict how address can be | represented in an SD-JWT. Perhaps: | Note: The following examples of the structures are non-normative | and are not intended to represent all possible options. They are | also not meant to define or restrict how an address claim can be | represented in an SD-JWT. --> 11) <!-- [rfced] In the Security Considerations, please note the following: a) We have nested the second paragraph under Integrity. Please verify that this is correct. b) May we remove the bold here since the headings are more clear? Original: *Integrity:* A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential. Current: *Integrity:* A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier. Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential. --> 12) <!-- [rfced] We are wondering whether "but" should be "and" here? That is, it must be preimage resistant and not allow an observer to infer any partial information? Original: This implies the hash function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content. --> 13) <!-- [rfced] We updated the format of the media type registrations to better align with the format used by IANA. We also created subsections for each of the registrations. Please review Section 11.2 carefully and let us know if a) any changes are desired for the section titles or b) if you object to the updated format. --> 14) <!-- [rfced] References: Please note that we moved the listing for RFC 5234 to the Normative References section, per the first bullet under "Formal languages" on <https://datatracker.ietf.org/doc/statement-iesg-guidelines-for-the-use-of-formal-languages-in-ietf-specifications-20011001/>. Please let us know any concerns. --> 15) <!-- [rfced] We updated this text for clarity. Please review and let us know if any updates are needed. Original: In this example, in contrast to Section 5, the Issuer decided to create a structured object for the address claim, allowing to separately disclose individual members of the claim. Current: In this example, in contrast to Section 5, the Issuer decided to create a structured object for the address claim, allowing individual members of the claim to be disclosed separately. --> 16) <!-- [rfced] Acknowledgements: As it appears that "John Mattsson" is "John Preuß Mattsson", we updated his name in this list, per his preference. (His last name is "Preuß Mattsson".) Please let us know if this is a different "John Mattsson". Also, we saw that names were mostly ordered by first name and then by last name. We made adjustments between "Shawn Emery" in the original and "Takahiko Kawasaki" accordingly. Please let us know any concerns. Original: ... Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, ... Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Emery, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten ... Currently: ... Yasskin, John Preuß Mattsson, Joseph Heenan, Justin Richer, Kushal ... Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Shawn Emery, Simon Schulz, Takahiko Kawasaki, Tobias ... --> 17) <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Selective Disclosure for JWTs (SD-JWT) / Selectively Disclosable JWT (SD-JWT) b) holder (4 instances) / Holder also allowing the holder to reveal each of those nationalities With this set of disclosures, the holder could include the disclosure the holder would also need to include the disclosure with hash holder is a military member or may have a substance use disorder. c) key binding (2 instances) / Key Binding 206: cryptographic key binding that can be presented to and verified 2437: Verifier or even for each session with a Verifier. New key binding d) disclosure (35 instances) / Disclosure (251 instances) --> 18) <!-- [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. --> Thank you. Sandy Ginoza RFC Production Center On Nov 15, 2025, at 5:41 PM, [email protected] wrote: *****IMPORTANT***** Updated 2025/11/15 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/rfc9901.xml https://www.rfc-editor.org/authors/rfc9901.html https://www.rfc-editor.org/authors/rfc9901.pdf https://www.rfc-editor.org/authors/rfc9901.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9901-diff.html https://www.rfc-editor.org/authors/rfc9901-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9901-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9901 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 9901 (draft-ietf-oauth-selective-disclosure-jwt-22) Title : Selective Disclosure for JWTs (SD-JWT) Author(s) : D. Fett, K. Yasuda, B. Campbell WG Chair(s) : Hannes Tschofenig, Rifaat Shekh-Yusef Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
