[OAUTH-WG] Review of draft-ietf-oauth-selective-disclosure-jwt-10

[Michael Jones <[e-mail]>]

I read https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html in its entirety, resulting in these suggestions.  Some are for readability.  Some are for consistency with related specifications, including JWT.  Some are for security and correctness.  The most important comments, including those addressing correctness issues, are in red.

Abstract<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#abstract>: In "It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims.", change "encompasses various" to "can be used for multiple" or "is applicable to multiple".  The use of "encompasses" is confusing here, and "various" isn't a strong word.

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  In "However, that does not preclude the mechanism's applicability to other or more general applications of JWS with JSON payloads.", delete "or more general", since it doesn't add anything but length.

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  Change "Web Authorization Protocol (oauth) working group" to "Web Authorization Protocol (OAuth) working group".

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  In "While JWTs with claims describing natural persons are a common use case, the mechanisms defined in this document can be used for other use cases as well." change "can be used for other use cases as well" to "are also applicable other use cases" to tighten the exposition.

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  The usage of "Holder" in "used a number of times by the user (the "Holder" of the JWT)" inconsistent with its usage in the definitions, which defines "Holder" as being "an entity".  The usage here in the introduction makes the holder into a person rather than an entity.  Please adjust the language here to not confuse the user who utilizes the holder with the holder itself.

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  The use of the undefined terms "verifiable credential" and "credential" in "One example of a multi-use JWT is a verifiable credential, an Issuer-signed credential that contains the claims about a subject, and whose authenticity can be cryptographically verified." will almost certainly cause people to ask you to define them, and then people will argue about the definitions.  Get rid of both terms by changing this to "One example of a multi-use JWT is an Issuer-signed token that contains claims about a subject, and whose authenticity can be cryptographically verified." and save us some grief!  (Although I see that "credential" is used later.  At least ditch "verifiable credential" here!)

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  In ""Claims" here refers to both object properties (name-value pairs) as well as array elements." and all other locations in the spec, change "name-value" to "name/value" for consistency with the notation in the "Claim" definition at https://www.rfc-editor.org/rfc/rfc7519.html#section-2.

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  In ""Claims" here refers to both object properties (name-value pairs) as well as array elements." change "array elements" to "elements in arrays that are the values of name/value pairs" (or something like that).  Without saying what the array elements are, readers will be confused about what's being referred to.  I'd apply this clarification in 4.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-4.1> SD-JWT and Disclosures<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-sd-jwt-and-disclosures> and other applicable locations as well.

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  In "they hold the private key associated to the SD-JWT", change "associated to" to "associated with".

1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1> Introduction<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-introduction>:  During IESG and/or RFC Editor review, we're likely going to be asked to add a reference for JSON-LD at "SD-JWT can be used with any JSON-based representation of claims, including JSON-LD."  If we don't want that, I'd delete ", including JSON-LD" now.

1.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1.1> Feature Summary<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-feature-summary>:  Shorten both uses of "The definition in this document comprises the following:" to "This comprises the following:" to tighten the exposition.

1.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1.1> Feature Summary<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-feature-summary>:  In "A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name-value pairs) and array elements", consider expanding "array elements" in the same manner as the preceding comment to make the meaning more evident.

1.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1.1> Feature Summary<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-feature-summary>:  In "A facility for associating an SD-JWT to a key pair", change "to a key pair" to "with a key pair", as it reads more naturally.

1.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1.2> Conventions and Terminology<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-conventions-and-terminology>:  I suggest moving the "base64url" definition to the Terms and Definitions section and use a parallel structure to that at https://www.rfc-editor.org/rfc/rfc7519.html#section-2.  Specifically, say "The "base64url" term denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515]."  Then introduce the rest of the definitions with the phrase "These terms are defined by this specification:" as is done in RFC 7519.  The current presentation is fairly jarring.

1.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-1.2> Conventions and Terminology<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-conventions-and-terminology>:  Change "Selective disclosure" to "Selective Disclosure".

4.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-4.3> Optional Key Binding<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-optional-key-binding>:  Change "use-case" to "use case".

4.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-4.3> Optional Key Binding<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-optional-key-binding>:  This disclaimer seems too strong: "Note: How the public key is included in SD-JWT is out of scope of this document. It can be passed by value or by reference.".  I suggest changing this to "Means of including or referencing the public key in the SD-JWT are described in 5.1.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.1.2> Key Binding<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-key-binding>."

5.2.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.1> Disclosures for Object Properties<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosures-for-object-prop>:  In "It is RECOMMENDED to base64url-encode minimum 128 bits of cryptographically secure random data", insert "a" before "minimum".  Also, consider moving "See Section 10.3<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#salt-entropy> for security considerations." to the end of the paragraph.

5.2.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.1> Disclosures for Object Properties<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosures-for-object-prop>:  In "The value MAY be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, and objects.", consider adding "null".  Likewise in 5.2.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.2> Disclosures for Array Elements<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosures-for-array-eleme>.

5.2.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.1> Disclosures for Object Properties<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosures-for-object-prop>:  In "US-ASCII [RFC0020<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#RFC0020>]", consider changing "RFC0020" to the more readable and standard "RFC20", matching the reference identifier used at https://www.rfc-editor.org/rfc/rfc7519.html#section-13.1.

5.2.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.2> Disclosures for Array Elements<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosures-for-array-eleme>:  Some readers and implementers will be confused at this point because the array disclosure doesn't indicate what Claim Name the disclosed array element corresponds to.  Please say here how the Claim Name information is communicated.  At the very least, add a forward reference saying that the way the array element disclosure is associated with the Claim Name is described in 5.2.4.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.4.2> Array Elements<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-array-elements>.

5.2.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.3> Hashing Disclosures<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-hashing-disclosures>:  Consider changing "(often used)" to "(sometimes used)".

5.2.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.3> Hashing Disclosures<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-hashing-disclosures>:  Change "For example, the SHA-256 digest of the Disclosure" to "For example, the base64url-encoded SHA-256 digest of the Disclosure" .  And add "base64url-encoded" to the second example as well (for correctness).

5.2.4.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.4.1> Object Properties<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-object-properties>:  Change "family_name" to "given_name" to match the example.

5.2.4.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.4.2> Array Elements<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-array-elements>:  I suggest adding an example also enabling disclosing a second array element, so that the syntax will be clear to readers.  In other words, show what "unless a matching Disclosure for the second element is received" would look like.  Or add a forward reference showing a place that it's done.

5.2.6. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.2.6> Recursive Disclosures<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-recursive-disclosures>:  Change "conceal presence" to "conceal the presence".

5.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.3> Key Binding JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-key-binding-jwt>:  Change "MUST NOT be none." to "It MUST NOT be "none".".

5.3.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-5.3.2> Validating the Key Binding JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-validating-the-key-binding->:  In "if the SD-JWT contains a cnf value with a jwk member, the Verifier could parse the provided JWK and use it to verify the Key Binding JWT.", change "could" to "MUST".  Make this normative to increase interoperability!

6.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-6.1> Issuance<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-issuance>:  In "The Issuer is using the following input claim set:", consider changing "claim set" to "JWT Claims Set", so that you're using the standard JWT claims terminology.  Or at least, change "claim set" to "Claims Set" (plural) wherever "claim set" is currently used, such as also in 7. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-7> Considerations on Nested Data in SD-JWTs<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-considerations-on-nested-da>.

6.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-6.1> Issuance<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-issuance>:  There are many places from here on where the label "SHA-256 Hash" is used, for instance "SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4".  Change all of these to "Base64url-Encoded SHA-256 Hash" for correctness.

6.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-6.1> Issuance<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-issuance>:  Change "The payload is then signed by the Issuer to create a JWT like the following:" to "The payload is then signed by the Issuer to create the JWT:"

6.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-6.1> Issuance<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-issuance>:  Change "The issued SD-JWT might look as follows:" to "The issued SD-JWT would be as follows:" or "The issued SD-JWT would be:".

6.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-6.1> Issuance<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-issuance>:  Change "The following Key Binding JWT payload was created and signed for this presentation by the Holder:" to "The following Key Binding JWT Claims Set was created and signed for this presentation by the Holder:", again, to use the standard JWT claims terminology.

7. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-7> Considerations on Nested Data in SD-JWTs<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-considerations-on-nested-da>:  Change "Important: The following examples" to "Note that the following examples".  It's more standard exposition and less jarring.

7.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-7.2> Example: Structured SD-JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-example-structured-sd-jwt>:  Change "In this case there would be no Disclosure for country since it is provided in the clear." to "In this case, there would be no Disclosure for country, since it is provided in the clear." (adding the two missing commas).

8.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-8.1> Verification of the SD-JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-verification-of-the-sd-jwt>:  Delete "nbf" from "claims such as nbf, iat, and exp" and everywhere else in the spec, other than in 10.7. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.7> Selectively-Disclosable Validity Claims<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-selectively-disclosable-val>, where both "iat" and "nbf" should be listed, as described in my comment there.  "iat" (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas "nbf" (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare.

8.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-8.2> Processing by the Holder<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-processing-by-the-holder>:  In "If the Holder receives an SD-JWT+KB, it SHOULD be rejected.", change "SHOULD" to "MUST".  Make it normative and thereby more secure.

9.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-9.1> New Unprotected Header Parameters<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-new-unprotected-header-para>:  Change "the representation as a regular SD-JWT MUST be created temporarily" to "the representation as a regular SD-JWT where the JWT uses the JWS Compact Serialization MUST be created temporarily" or something similar.  The key point is to indicate that the regular SD-JWT being referenced uses the JWS Compact Serialization for the JWT in the SD-JWT.  You also may want to rework this to also eliminate the somewhat ambiguous "using a . character as a separator" language in favor of describing the result as using the JWS Compact Serialization.

10.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.1> Mandatory Signing of the Issuer-signed JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-mandatory-signing-of-the-is>:  Change "Any of the JWS asymmetric digital signature algorithms registered in [IANA.JWS.Algorithms<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#IANA.JWS.Algorithms>] can be used, including post-quantum algorithms, when they are ready." to "Any of the JWS asymmetric digital signature algorithms registered in [IANA.JWS.Algorithms<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#IANA.JWS.Algorithms>] meeting the security requirements of the application, as described in the last paragraph of Section 5.2 of [RFC7515], can be used."  It's NOT, in general, the case that any registered algorithm can be used.  That's up to the application.  For instance, "ES512" might be acceptable to the application whereas "RS256" isn't.  Also, the post-quantum language seems superfluous and non-actionable, so I'd delete it.

10.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.3> Entropy of the salt<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-entropy-of-the-salt>:  Change "salt" to "Salt" in the title.

10.7. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.7> Selectively-Disclosable Validity Claims<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-selectively-disclosable-val>:  Add "iat (Issued At) to the validity claims list before "nbf", and change "nbf (Not Before)" to "nbf (Not Before) (if present)".  "iat" (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas "nbf" (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare.  Change all uses of "nbf" to "iat" elsewhere in the spec.

10.7. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.7> Selectively-Disclosable Validity Claims<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-selectively-disclosable-val>:  Change "application-specific profile" to "application-specific profiles".

10.10. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-10.10> Integrity of SD-JWTs and SD-JWT+KBs<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-integrity-of-sd-jwts-and-sd>:  In "The specific set of Disclosures, however, is not integrity-protected - the SD-JWT can be modified by adding or removing Disclosures and still be valid.", change the dash to a period or semicolon.

11.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-11.1> Storage of Signed User Data<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-storage-of-signed-user-data>:  Change "OpenID Connect" to "OpenID Connect [OpenID.Core]" and add the following reference to the specification:

      <reference anchor="OpenID.Core" target=https://openid.net/specs/openid-connect-core-1_0.html>
        <front>
          <title>OpenID Connect Core 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization>
          </author>

          <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
            <organization abbrev="Google">Google</organization>
          </author>

                  <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
                    <organization abbrev="Disney (was at Salesforce)">Disney</organization>
                  </author>

          <date day="15" month="December" year="2023"/>
        </front>
      </reference>

12. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-12> Acknowledgements<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-acknowledgements>:  Please change "Mike Jones" to "Michael B. Jones".  (Lots of people share my name so I include my middle initial for disambiguation in professional contexts.)

12. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-12> Acknowledgements<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-acknowledgements>:  Consider sorting the acknowledgements alphabetically by last name, which is the usual convention.

13.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-13.2> Media Type Registration<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-media-type-registration> and 13.3. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-13.3> Structured Syntax Suffix Registration<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-structured-syntax-suffix-re>: In all the Encoding Considerations, change "separated by period ('.') or tilde ('~') characters" to "separated by period ('.') and tilde ('~') characters".

14.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-14.2> Informative References<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-informative-references>:  Add the missing date to the reference "[EUDIW.ARF]".  And if isn't the most current public ARF reference, please update to the latest one.

14.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-14.2> Informative References<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-informative-references>:  Update the reference "[I-D.ietf-oauth-sd-jwt-vc]" to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-04.

14.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-14.2> Informative References<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-informative-references>:  Update the reference "[OIDC.IDA]" to https://openid.net/specs/openid-connect-4-identity-assurance-1_0-14.html and be sure to include the (currently missing) date.

14.2. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#section-14.2> Informative References<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-informative-references>:  Update the reference "[VC_DATA_v2.0]" to use the current editor list and date.  (For instance, Orie resigned.)

Appendix A. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-A> Additional Examples<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-additional-examples>:  Consider changing "Important: The following examples" to "Note that the following examples".  "Important" is unnecessarily jarring.

A.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-A.1> Simple Structured SD-JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-simple-structured-sd-jwt>: Change "allowing to separately disclose individual members of the claim" to "allowing separate disclosure of individual members of the claim".

A.1. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-A.1> Simple Structured SD-JWT<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-simple-structured-sd-jwt>: Change "The following is how a presentation of the SD-JWT that discloses only region and country of the address property could look like:" to "The following is a presentation of the SD-JWT that discloses only region and country of the address:".  Similarly, excise other uses of the extra verbiage "could look like" elsewhere in the specification.

A.5. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-A.5> Elliptic Curve Key Used in the Examples<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-elliptic-curve-key-used-in->: Change "The public key used to validate a Key Binding JWT can be found in the examples as the content of the cnf claim." to "The public key used to validate a Key Binding JWT can be found in the examples as the value of the jwk member of the cnf claim."

Appendix B. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-B> Disclosure Format Considerations<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosure-format-considera>: Change "particularly useful when the content, like JSON, can have differences but be semantically equivalent." to "particularly useful when the content, like JSON, can have different representations but is semantically equivalent, thus avoiding canonicalization."

Appendix B. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-B> Disclosure Format Considerations<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosure-format-considera>: Change "computation over the data need to be performed and verified" to "computation over the data needs to be performed and verified".

Appendix B. <https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#appendix-B> Disclosure Format Considerations<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-disclosure-format-considera>: At the end of the paragraph introduced by "1. Canonicalization", consider adding the sentence "Canonicalization schemes have a long history of creating interoperability problems in practice."

Everywhere:  Consider changing the name "..." to something more indicative of its function, such as "_sd_element" or "_sd_item".  Or alternatively, at least provide rationale for why that non-obvious name was chosen.

I hope that you find this review helpful in improving the specification.  I look forward to its publication as an RFC and its widespread use!

                                                                -- Mike