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
>>>
>>
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
