IETF Last Call Review of draft-ietf-oauth-sd-jwt-vc-19
review-ietf-oauth-sd-jwt-vc-19-artart-lc-amsuess-2026-09-15-00

# 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.