Authors, Thank you for your reviews. We have updated the document as requested and posted the revised files. With this update, we believe you have all approved the RFC for publication. As such, we will continue with the publication process shortly.
The approved files remain here until publication: https://www.rfc-editor.org/authors/rfc9901.xml https://www.rfc-editor.org/authors/rfc9901.txt https://www.rfc-editor.org/authors/rfc9901.pdf https://www.rfc-editor.org/authors/rfc9901.html Diffs highlighting more recent updates only: https://www.rfc-editor.org/authors/rfc9901-lastdiff.html https://www.rfc-editor.org/authors/rfc9901-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9901-auth48diff.html https://www.rfc-editor.org/authors/rfc9901-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9901-diff.html https://www.rfc-editor.org/authors/rfc9901-rfcdiff.html (side by side) Thank you, Sandy Ginoza RFC Production Center > On Nov 18, 2025, at 4:27 PM, Brian Campbell <[email protected]> > wrote: > > Thank you Sandy (and Deb, Daniel, et. al), > > I know this is a long and dense draft so have extra appreciation for the > detailed work that's gone into the final editing. Thank you again. > > I would like to request one more small update. Could you please remove Dick > Hardt from the acknowledgements section? In the context of this document, > Dick provided some tremendously unhelpful yet very time consuming feedback to > the WG after the completion of WGLC. Despite frustration with that at the > time, I followed my own somewhat liberal policy of naming everyone of whom > I'm aware that has "contributed" in any fashion and added him to the > Acknowledgements (in this PR). Just yesterday, however, this message was sent > to the list that links back to this issue in the repo of a different draft, > which is unrelated other than the Dick making the preposterous statement that > he "participated in SD-JWT and provided guidance on JWT best practices to be > included in SD-JWT", which is either a gross misrepresentation of his > contribution or demonstrating a profound unawareness of the actual course of > events. Neither is acceptable to me and I don't want the content of this > document to further participate in the illusion. > > Thank you for accommodating this last change request from me. Once that's > done, I approve the content for RFC publication. > > > > > > > > > > On Tue, Nov 18, 2025 at 10:24 AM Sandy Ginoza <[email protected]> > wrote: > Hi Daniel, Deb, > > Deb, thanks for your quick reply; we have noted your approval. > > > Daniel, thanks again for your review. We have updated the document as > discussed below. > > >> [rfced] Unfortunately, it looks like I missed one previously. Please let > >> us know how this line should be broken: > >> > >> Warning: Too long line found (L4759), 1 characters longer than 72 > >> characters: > >> "address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"} > >> > > This instance is in Appendix B, right? Then please add a line break after > > the second colon. > > Correct, Appendix B — apologies for not being more clear. We have broken the > line and indented the text after the break 3 spaces as shown below. Please > let us know if any updates are desired. > > ... > "family_name": "Möbius", > "address": {"locality":"Schulpforta", "street_address": > "Schulstr. 12"} > ... > > > You can view the most recent updates (only) in the following diffs: > https://www.rfc-editor.org/authors/rfc9901-lastdiff.html > https://www.rfc-editor.org/authors/rfc9901-lastrfcdiff.html (side by side) > > AUTH48 diffs (all changes made during AUTH48): > https://www.rfc-editor.org/authors/rfc9901-auth48diff.html > https://www.rfc-editor.org/authors/rfc9901-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9901-diff.html > https://www.rfc-editor.org/authors/rfc9901-rfcdiff.html (side by side) > > > The current files are available here: > https://www.rfc-editor.org/authors/rfc9901.txt > https://www.rfc-editor.org/authors/rfc9901.pdf > https://www.rfc-editor.org/authors/rfc9901.html > https://www.rfc-editor.org/authors/rfc9901.xml > > Please review and let us know if any additional updates are needed or if you > approve the RFC for publication. > > Thank you, > Sandy Ginoza > RFC Production Center > > > > > On Nov 18, 2025, at 1:13 AM, Daniel Fett <[email protected]> wrote: > > > > Hi Sandy, > > Thanks for your response and the changes to the document! > > Am 18.11.25 um 07:06 schrieb Sandy Ginoza: > >> Greetings Authors, Deb*, > >> > >> * Deb, please see the update related to Appendix A.3 below and let us know > >> if you approve. > >> > >> Thank you for your quick and thorough response to our questions! Please > >> see some notes below. Note that we have snipped the resolved items. > >> > >> > >> > >>> - Section 4.2.3: “The bytes of the output of the hash function MUST be > >>> base64url > >>> encoded” > >>> > >>> DF: Is it correct to not hyphenize “base64url encoded” and “hex encoded” > >>> in this sentence? I do understand that (and why) “base64url encoding” is > >>> correct, as well as “base64url-encode”, but I would expect > >>> “base64url-encoded” to be correct as well. (There are other instances in > >>> the document as well.) > >>> > >> [rfced] Per the Hyphenation Guide in the Chicago Manual of Style (Section > >> 7.96), we believe no hyphen is correct. We believe it falls into the > >> category of noun + participle, which means it would be hyphenated when > >> appearing before then noun but otherwise open (for example, “a > >> base64url-encoded value" but "a value that is base64url encoded"). We have > >> not made any updates for this one; please let us know if you have concerns. > > Thank you for the explanation - makes sense. > > > >>> - Appendix A.3, first two sentences. > >>> > >>> DF: The PID Rulebook referenced in the first sentence has since been > >>> updated and an up-to-date example of how to use it with SD-JWT is now > >>> provided in the SD-JWT VC specification. Nonetheless, the example in the > >>> text is useful. The reference to the PID Rulebook should therefore be > >>> removed. Please replace the first paragraph by the following text: > >>> > >>> "This example shows how the artifacts defined in this specification could > >>> be used in the context of SD-JWT-based Verifiable Credentials (SD-JWT VC) > >>> [SD-JWT-VC] to represent a hypothetical identity credential with the data > >>> of a fictional German citizen." > >>> > >> [rfced] * Deb - We updated the text as requested and removed [EUDIW.ARF] > >> from the references. Please review and let us know if this update is > >> approved. > >> > > Thanks for the update, looks good to me. @Deb Let me know if there are any > > questions regarding our preference to remove the ARF reference. > >> > >> > >>> 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) --> > >>> > >>> DF: Works for me, but I don’t think we should use the plural for the > >>> short form. (I see that in the edited document, plural forms were used > >>> for JWT and JWS in the intro. My personal feeling is that this is not > >>> required, but I can live with either.) > >>> > >>> BC: I agree with not using plural for the short form. The title could be > >>> “Selective Disclosure for JSON Web Token (SD-JWT)” or even “Selective > >>> Disclosure for JSON Web Tokens (SD-JWT)” but the s on SD-JWTs doesn’t > >>> work very well at all in my opinion. In the content of the document I’d > >>> also generally prefer non-plural short forms like JWS and JWT as > >>> referring to the conceptual thing. > >>> > >>> KY: I’m ok with Selective Disclosure for JSON Web Token (SD-JWT) > >>> > >> [rfced] We removed the s. However, related to this discussion: > >> > >> > >>> 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) > >>> > >> > >> [rfced] We suggest removing the abbreviation from the document title. > >> Perhaps the title could be: > >> > >> Selective Disclosure for JSON Web Tokens > >> > >> That way, there will be one expansion and future documents will expand > >> "SD-JWT” correctly as Selectively Disclosable JWT. > >> > >> We could add SD-JWT as a keyword in the database, so this document appears > >> in RFC-Editor search results. > > That sounds like a good solution to me. > >> > >> > >>> 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"] --> > >>> > >>> DF: In Section 4, a line break might confuse readers. I would suggest > >>> instead to abbreviate “Disclosure” to “D.” and explain in the text: > >>> “The compact serialized format for the SD-JWT is the concatenation of > >>> each part delineated with a single tilde ('~') character as follows, > >>> where “D.1” to “D.N” represent the respective disclosures: > >>> > >>> <Issuer-signed JWT>~<D.1>~<D.2>~...~<D.N>~” > >>> > >>> — and the same for the following example. > >>> > >> [rfced] We have updated as noted. Please review and let us know if the > >> updates are as expected. > > - In the second example, a quotation mark was appended to the last tilda, > > please remove that. > > - In the new text, typographic quotation marks (”) were used. In the rest > > of the document, we have simple ones ("). > > Other than that, the change looks good to me. > > > >>> For Section 4.2.4.2, the proposed line break works. > >>> > >>> KY: +1 to Daniel’s suggestion! Any other place in the spec we should be > >>> using this abbreviation..? > >>> > >>> DF: Not needed as far as I can see. > >>> > >> [rfced] Unfortunately, it looks like I missed one previously. Please let > >> us know how this line should be broken: > >> > >> Warning: Too long line found (L4759), 1 characters longer than 72 > >> characters: > >> "address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"} > >> > > This instance is in Appendix B, right? Then please add a line break after > > the second colon. > > Correct, Appendix B — apologies for not being more clear. We have broken the > line and indented the text after the break 3 spaces as shown below. Please > let us know if any updates are desired. > > ... > "family_name": "Möbius", > "address": {"locality":"Schulpforta", "street_address": > "Schulstr. 12"} > ... > > > >>> DF: c) looks fine to me. > >>> > >> [rfced] Ok - we have updated the lists using <strong> throughout. Please > >> let us know if any updates are needed. > >> > >> Looking at where <strong> remains, we wonder whether the first 2 terms in > >> section 1.2 should be updated as follows to be similar to the rest of the > >> definition list appearing there. > >> > >> Current (Selective Disclosure included for context): > >> *Base64url* denotes the URL-safe base64 encoding without padding > >> defined in Section 2 of [RFC7515]. > >> > >> Throughout this document, the term "claims" refers generally to > >> object properties (name/value pairs) as well as array elements. > >> > >> Selective Disclosure: > >> Process of a Holder disclosing to a Verifier a subset of claims > >> contained in a JWT issued by an Issuer. > >> > >> > >> Perhaps: > >> Base64url: Denotes the URL-safe base64 encoding without padding > >> defined in Section 2 of [RFC7515]. > >> > >> Claims: In this document, refers generally to object properties > >> (name/value pairs) as well as array elements. > >> > >> Selective Disclosure: > >> Process of a Holder disclosing to a Verifier a subset of claims > >> contained in a JWT issued by an Issuer. > >> > > Works for me, but I would propose to use the singular form for Claims. > > > >>> DF: d) Disclosure(s) should be upper-cased everywhere, except where > >>> preceded by “selective”, “minimal”, or “unauthorized” as these instances > >>> refer to the act of disclosing something instead of the data structure. > >>> (Of course, where ‘disclosures’ refers to the property in the data > >>> structure, it should not be upper-cased. These instances are all > >>> formatted with <tt> or <sourcecode>.) > >>> > >> [rfced] We have reviewed instances of “disclosure” throughout and made > >> some updates based on the guidance above. Please review closely and let us > >> know any corrections. > >> > >> For example, we used Disclosure for "optional disclosure”, “disclosure > >> data”, “disclosure object”, and “respective disclosures”. > >> > >> Should “recursive disclosures” be “recursive Disclosures” as well? > > - Please use "recursive Disclosures", yes. > > - Please use upper case Disclosures in this sentence: " For example, use of > > the ES512 signature algorithm would require a disclosure hash function with > > at least 256-bit collision resistance, such as SHA-512." > > The other changes look good to me. > >> > >> > >> [rfced] New: > >> e) Note that we added a period to <tt>nP5GYjw..</tt> (so it appears as > >> <tt>nP5GYjw...</tt>) - please let us know if this is incorrect. > > That is correct, thanks. > > -Daniel > > > >> > >> > >> Thank you again for your thorough review! > >> > >> 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 > >>> > >> > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
