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

[Giuseppe De Marco <[e-mail]>]

Hi Mike,

Regarding the definition of Holder, here I want to share an open issue that
aims to clarify this kind of entity, even if it is opened for the openid4vc
specs your revision reminds me it
https://github.com/openid/OpenID4VP/issues/225



Il giorno lun 5 ago 2024 alle ore 05:55 Michael Jones <
[e-mail]> ha scritto:

> 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
> <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
>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>