Thank you Sandy and RFC-editor team for a thorough review. I approve the content for RFC publication.
On Wed, Nov 19, 2025 at 3:28 AM 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 > <https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/476>). > Just yesterday, however, this message > <https://mailarchive.ietf.org/arch/msg/oauth/y3472XosNBFLzrEiI2tbNTswRec/> > was sent to the list that links back to this issue > <https://github.com/oauth-wg/draft-ietf-oauth-rfc8725bis/issues/15> 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]
