That's the fastest Auth48 I've seen (since being an AD). A mere 4 days? Well done!
Deb On Wed, Nov 19, 2025 at 11:21 AM Sandy Ginoza <[email protected]> wrote: > 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]
