Mike Bishop has entered the following ballot position for draft-ietf-oauth-sd-jwt-vc-23: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # IESG review of draft-ietf-oauth-sd-jwt-vc-23 CC @MikeBishop Thanks to Mark Nottingham for the [HTTP Directorate review](https://datatracker.ietf.org/doc/review-ietf-oauth-sd-jwt-vc-18-httpdir-early-nottingham-2026-08-12/). I appreciate that you incorporated much of his feedback, and you've done a really solid job building on top of HTTP. I have one DISCUSS point more in the process space; hopefully it's easy to resolve. ## Discuss ### Section 2.2.2.3, paragraph 6 ``` Note that Section 3 of [RFC7800] requires that a JWT containing a cnf claim also contain either the sub or iss claim. This specification explicitly overrides that requirement, as there are valid and legitimate uses of key-bound SD-JWT VCs without either of those claims. ``` That sounds like a change is being made to the requirement in RFC 7800, yet I see no Updates: tag on this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### Section 1.2, paragraph 6 ``` Claims" registry as defined in [RFC7519], as well as public and private claims. ``` Perhaps reorder the sentence; it's not clear that the [RFC7519] reference is also where I would go to learn about "public and private claims". ### Section 4, paragraph 2 ``` the JWT. The iss MUST be a case-sensitive URL using the HTTPS scheme that contains scheme, host and, optionally, port number and path ``` Scheme and host are case-insensitive by definition (RFC3986) and port numbers by construction, so of the permitted components only path can be case-sensitive. ### Section 4.2, paragraph 1 ``` Metadata configuration as its content, using the application/json media type. The general requirements for HTTP retrieval defined in Section 3 apply. ``` While this is sufficient, I would encourage a distinct media type so that the server can assert the intended role of this JSON object. Same goes in 5.3.1. ### Section 4.3, paragraph 2 It might be worth explicitly stating that this applies regardless of any redirection chain that may have occurred -- if the JWT had an Issuer of one.example.com but redirected the query to two.example.com, the response still has to contain one.example.com to be valid, regardless of who served it. ### Section 5.5.1.2.1, paragraph 1 ``` SVG template. Consuming applications MUST use these properties to find the best SVG template available for display to the user based on ``` This doesn't appear to be an interop requirement. I'd drop the keyword and just describe what these properties are for. ### Section 5.5.1.2.2, paragraph 2 This requires understanding the structure of SVG, rather than treating it purely as a text blob. There should be a normative pointer to where this structure is defined. ### Section 7.6, paragraph 1 ``` such, any consuming application MUST ensure that maliciously crafted information cannot be used to compromise the security of the application or the privacy of the user. To this end, the following ``` How does one test this MUST? I would consider replacing it with "To ensure that..." and then lead into the concrete requirements below. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 3, paragraph 1 ``` - configuration and the JWK Set referenced by jwks_uri Section 4, Type + configuration and the JWK Set referenced by jwks_uri (Section 4), Type + + + ``` ``` - Section 5.3, and rendering resources such as logos, background - images, and SVG templates Section 5.5.1. The requirements in this + (Section 5.3), and rendering resources such as logos, background + + + + images, and SVG templates (Section 5.5.1). The requirements in this + + + ``` ### Section 1.1, paragraph 1 ``` In the so-called Issuer-Holder-Verifier Model, Issuers issue ``` Maybe it's regional, but it feels like there's a certain amount of judgement in calling something "so-called." Is this model described somewhere that would make a more neutral reference possible? "The model defined in [RFCNTJT], sometimes called...." ### Section 2.2.2.3, paragraph 3 ``` * nbf: OPTIONAL. The time before which the Verifiable Digital Credential MUST NOT be accepted before validating. See [RFC7519] for more information. ``` Odd structure. Should this stop at "...be accepted."? ### Section 3, paragraph 3 ``` HTTPS scheme. As an exception, the rendering resource URIs defined ``` "https" like RFC 9110, or `https` like your usage of `data:` ### Grammar/style #### Section 2.2.2.1, paragraph 7 ``` eat the SD-JWT VC as a credential of any of these types. This is typically u ^^^^^^^^^ ``` Consider simply using "of" instead. #### Section 2.2.2.2, paragraph 3 ``` T claims, including any of their sub-claims, when used in the SD-JWT compone ^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 5.6, paragraph 1 ``` ess"]: The claim address with its sub-claims as the value is selected. * ["ad ^^^^^^^^^^ ``` This word is normally spelled as one. #### "A.2.", paragraph 1 ``` ectively disclosed includes their sub-claims not being selectively disclosabl ^^^^^^^^^^ ``` This word is normally spelled as one. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
