[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.
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.
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
