Document: draft-ietf-oauth-sd-jwt-vc Title: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) Reviewer: Christian Amsüss Review result: Ready with Issues
# ART-ART focus points ad 5.5 (also 6.2): name and description are human readable. As it should be, they have a language tag, but lack writing direction information (rtl). Previous IETF specifications of the recent years (as opposed to the older RFC5646) cater for bidirectional text, for example <https://www.rfc-editor.org/rfc/rfc9290.html#name-language-tagged-strings>. # Clarity and rationale ad 1: From the introduction (also the later text), it is not clear to me how being a *verifiable* credential (which AIU is about being a signed JWT and containing a cnf of which possession can be proven) is related to the vct (which is about explaining to a user what a credential means and how to make informed decisions about selective disclosure). ad 2.1: Are SD-JWT VCs intended to exclusively be used in places where a media type is assigned? Or should the paragraph start with "Where media types are used, …"? ad 4: Why is there a well-known path inserted? Usually, links would just go to the right resource, and if there's something else served from that path too, media type negotiation comes to the rescue. ad 5.6: What happens to SVG processing when path selects multiple elements? # Completeness ad 2.2.2.3: Why can only the vct have a vct#integrity, but the aka_vct not? # Non-actionable remarks ad 5.3, 7.5 and 8.3/8.4: There is some overlap with draft-bormann-t2trg-deref-id, but the texts seem like a good enough that enough is said. _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
