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

[Brian Campbell <[e-mail]>]

Thanks Mike! The detailed review is appreciated. The document authors will
work on addressing and/or responding to the comments. As you are no doubt
aware, doing so can take some time, so in the meantime I wanted to send
this quick note of acknowledgement and thanks.

On Sun, Aug 4, 2024 at 9:56 PM Michael Jones <[e-mail]>
wrote:

> 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]
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._