Hi Brian, Thanks for the update and the clarification on the metadata elements' extensibility. LGTM.
Thanks, Ketan On Wed, Oct 28, 2026 at 4:25 AM Brian Campbell <[email protected]> wrote: > 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]
