I went ahead and added this https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450/changes/07115ebeb576750611b2acdec48d2f5ac58dd0c2 to that PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450 which adds "Updates: 7800 <https://www.rfc-editor.org/rfc/rfc7800> (if approved)" and some hopefully not-too-awkward text explaining it.
On Tue, Nov 3, 2026 at 4:10 PM Brian Campbell <[email protected]> wrote: > Thank you for the review, Mike. I've endeavored to respond to individual > items inline below. And am working on this PR > https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450 with indicated > changes (which doesn't yet have anything for the DISCUSS). > > On Mon, Nov 2, 2026 at 2:28 PM Mike Bishop via Datatracker < > [email protected]> wrote: > >> 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. > > > To be honest, that note was added somewhat reluctantly and was really just > intended to give the okay to ignore that particular requirement in RFC > 7800, which arguably shouldn't have been in 7800 at all and I suspect most > are already ignoring it. This PR > https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/430 documents some of > that and my choice of words there was softened in > https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/447/changes#diff-e750c0958ca10e395b4d3b77bb5aafccc668b4a1a50675dda79a8d90b39a2468R366 > > Adding the Updates: 7800 tag to this document seems reasonable though, if > that would resolve the DISCUSS? And, if so, do you think additional text in > the document explaining the update would be needed or warranted? > > > > >> >> ---------------------------------------------------------------------- >> 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". >> > > Agreed, a reorder there is in order. Will do. > > >> >> ### 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. >> > > That's meant to say that the whole value should be treated > as case-sensitive in this context. > > >> >> ### 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. >> > > I'm struggling to see any tangible benefit to doing so. > > >> >> ### 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. >> > > I feel like "MUST be identical to" is sufficient there. > > > >> >> ### 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. >> > > Agree, will drop the keyword. > > > >> >> ### 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. >> > > Yeah, will add a reference in that section. > > > >> >> ### 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. >> > > Makes sense. Will replace and rephrase. > > > >> ## 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 >> >> >> >> -- _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._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
