Thanks for the review and ballot Ketan, We've published a revision -22 <https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/22/> of the draft with changes from this PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/447 incorporating most of your feedback. The observation about the lack of registries or naming rules in the metadata elements is accurate but we don't believe that extension usage will be common or contentious enough to require them.
On Tue, Oct 27, 2026 at 10:06 AM Ketan Talaulikar via Datatracker < [email protected]> wrote: > Ketan Talaulikar has entered the following ballot position for > draft-ietf-oauth-sd-jwt-vc-20: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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> > > > > -- _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]
