Thanks to the authors and the WG for their work on this document.

I have a few comments/suggestions to offer as someone that is not much
familiar with this work. Please take with a pinch of salt and would appreciate
if you could correct me where I am wrong.

The review is inline in the idnits output of v20 of this document. Please look
for the tag <EoRv20> at the end to ensure you are seeing the full review.

478	   *  status: OPTIONAL.  The information on how to read the status of
479	      the Verifiable Credential.  See [I-D.ietf-oauth-status-list] for
480	      more information.  When the status claim is present and using the

<minor> Section 1.4 explains that "Verifiable Digital Credential" was chosen
to keep clear of the W3C Verifiable Credentials Data Model; the status bullet
uses the W3C term. Perhaps:

s/the Verifiable Credential./the Verifiable Digital Credential./

495	   Note that Section 3 of [RFC7800] has a somewhat misguided requirement
496	   that either the sub or iss be present in the JWT.  This specification
497	   explicitly overrides that requirement, as there are valid and
498	   legitimate uses of key-bound SD-JWT VCs without either of those
499	   claims.

<editorial> "Somewhat misguided" passes judgement on another RFC, which the
reader of this one does not need. Suggest stating the departure neutrally:

CURRENT
   Note that Section 3 of [RFC7800] has a somewhat misguided requirement
   that either the sub or iss be present in the JWT.  This specification
   explicitly overrides that requirement, as there are valid and
   legitimate uses of key-bound SD-JWT VCs without either of those
   claims.
SUGGEST
   Note that Section 3 of [RFC7800] requires that either sub or iss be
   present in the JWT.  This specification explicitly overrides that
   requirement, as there are valid and legitimate uses of key-bound
   SD-JWT VCs without either of those claims.

580	                    Figure 6: Unsecured Payload Example

<nit> Figure 6 shows the SD-JWT payload, not an Unsecured Payload (Section
1.4)?

s/Figure 6: Unsecured Payload Example/Figure 6: SD-JWT Payload Example/

1042	   Additional JWT VC Issuer Metadata configuration parameters MAY also
1043	   be used.

<major> Issuer Metadata parameters (Section 4.2), Type Metadata properties
(5.2), rendering method identifiers (5.5.1) and claim metadata properties
(5.6) are all open to extension, with no registry and no rule against
collisions. Is my understanding correct? RFC 8414 created a registry for 
similar parameters. Perhaps registries, or at least a naming rule is
required? E.g. after the last sentence of Section 4.2 (and likewise for the 
others):

NEW
   Names of additional parameters SHOULD be Collision-Resistant Names
   as defined in Section 2 of [RFC7515].

1596	   The display property is an array containing display information for
1597	   the claim.  The array MUST contain an object for each locale that is
1598	   supported by the type.  The consuming application MUST use the
1599	   language tag it considers most appropriate for the user.

<major> In Section 5.6.2 the first MUST seems circular (the array is how the
type declares its locales) and the second governs a judgement? Section 5.5 
says the same without key words. Suggest aligning them. Perhaps:

CURRENT
   The display property is an array containing display information for
   the claim.  The array MUST contain an object for each locale that is
   supported by the type.  The consuming application MUST use the
   language tag it considers most appropriate for the user.
SUGGEST
   The display property is an array containing display information for
   the claim.  The array contains an object for each locale that is
   supported by the type.  The consuming application uses the object
   containing the language tag it considers most appropriate for the
   user.

1923	   When processing credentials, it is important to recognize that the
1924	   ability to extend or reference an existing credential type (e.g., a
1925	   well-known identifier such as urn:ec.eu.x.y.z) does not confer any
1926	   implicit authorization to issue credentials of that type or its
1927	   extensions.  In particular:

1929	   *  *Issuer Authorization*: Verifiers and Holders MUST NOT assume that
1930	      any issuer who issues a credential extending a known type is
1931	      authorized to do so.  The mere presence of an extension or
1932	      reference to a recognized type (e.g., a national type urn:de.bla
1933	      extending a European PID type) does not validate the issuer's
1934	      authority.
1935	   *  *Rogue Issuers*: Attackers may issue credentials with types that
1936	      extend or mimic legitimate types (e.g., urn:attacker extending
1937	      urn:ec.eu.x.y.z).  Such credentials MUST NOT be accepted solely
1938	      based on their type hierarchy or extension relationship.

<nit> Are the example identifiers in Section 7.7 valid URNs? Elsewhere the 
document uses urn:example:. Perhaps:

s/urn:ec.eu.x.y.z/urn:example:eu:pid/
s/urn:de.bla/urn:example:de:pid/
s/urn:attacker/urn:example:attacker:pid/

2124	   *  Encoding considerations: 8-bit code points; SD-JWT VC values are
2125	      encoded as a series of base64url-encoded values (some of which may
2126	      be the empty string) separated by period ('.') and tilde ('~')
2127	      characters.

<minor> "8-bit code points" does not seem to be one of the encoding values 
RFC 6838 defines? RFC 9901 registered both application/sd-jwt and the +sd-jwt
suffix as "binary". Am I missing something? The template also lacks the 
"Fragment identifier considerations" field. Suggest following RFC 9901:

CURRENT
   *  Encoding considerations: 8-bit code points; SD-JWT VC values are
      encoded as a series of base64url-encoded values (some of which may
      be the empty string) separated by period ('.') and tilde ('~')
      characters.
SUGGEST
   *  Encoding considerations: binary; SD-JWT VC values are encoded as a
      series of base64url-encoded values (some of which may be the empty
      string) separated by period ('.') and tilde ('~') characters.

NEW (after "Applications that use this media type")
   *  Fragment identifier considerations: n/a

<minor> Please review and fix the following related to references:
RFC 7515: normative — vct and aka_vcts are Collision-Resistant Names as
   defined in its Section 2, and Section 2.5 uses its x5c header.
I-D.ietf-oauth-status-list: normative — Section 2.2.2.3 sets a MUST on the
   Status List Token format that cannot be implemented without it?

<EoRv20>