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 < michael_b_jo...@hotmail.com> 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 -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
