Thanks Éric, we'll work on getting an update published during the cutoff window addressing the DISCUSS
On Thu, Nov 5, 2026 at 3:42 AM Éric Vyncke via Datatracker <[email protected]> wrote: > Éric Vyncke 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: > ---------------------------------------------------------------------- > > # Éric Vyncke INT AD comments for draft-ietf-oauth-sd-jwt-vc-23 > CC @evyncke > > Thank you for the work put into this document. > > Please find below some blocking DISCUSS points (easy to address), some > non-blocking COMMENT points/nits (replies would be appreciated even if > only for > my own education). > > I hope that this review helps to improve the document, > > Regards, > > -éric > > Note: this ballot comments follow the Markdown syntax of > https://github.com/mnot/ietf-comments/tree/main, i.e., they can be > processed by > a tool to create github issues. > > ## DISCUSS (blocking) > > As noted in > > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ > , > a DISCUSS ballot is a request to have a discussion on the points below; I > really think that the document would be improved with a change here, but > can be > convinced otherwise. > > ### Section 2.2.2.2 > > Why not a MUST in `For the purpose of type matching, a Holder or Verifier > SHOULD treat an SD-JWT VC as being of a given type,`? Also, this is not > really > about interoperability per BCP14, so, a "should" will still be normative > and > more appropriate (uppercase in BCP14 is not for emaphasis). > It's kind of meant to be about helping interoperability at layers above this (e.g., OIDF's DCQL, OpenID4VP, etc.) and wasn't a MUST b/c it was added very late in the process lifecycle, at a time when we didn't think introducing breaking normative changes was an appropriate thing to do. That said, avoiding the BCP14 language here would probably be better. > > See also: > > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ > I.e., please provide guidance for the implementers about when to bypass the > SHOULD or what are the consequences of bypassing it. > > ### Section 2.4 > > Why not a MUST in `If status is present in the verified payload of the > SD-JWT, > the status SHOULD be checked` ? The next sentence provides what to do with > the > status check. > It's not a MUST because there are cases where a verifier might be offline or otherwise unable to check the status that shouldn't be outright precluded. Will add a little more text about the implications of not doing that SHOULD. > > I did not check/mention the other SHOULD/RECOMMEND in the document and I am > trusting the authors and responsible AD to address them. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ## COMMENTS (non-blocking) > > ### RFC 7800 is updated > > I second Mike Bishop's DISCUSS about the missing formal update of RFC 7800. > > ### Section 7.1 > > Strongly suggest to replace the normative reference to RFC 6890 by the two > special use registries > https://www.iana.org/assignments/iana-ipv4-special-registry > https://www.iana.org/assignments/iana-ipv6-special-registry. > > > > -- _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]
