Thanks again Tim and apologies on behalf of the editorial team for being so slow to get to this. Attempts at responding to individual items are inline below. And this PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387 is collecting the resultant changes.
On Mon, Dec 1, 2025 at 2:26 PM Tim Cappalli <timcappalli= [email protected]> wrote: > Hi! > > Here's my review/feedback of draft-ietf-oauth-sd-jwt-vc-13. > > Overall, it looks great! A few general feedback items and some nits. > Thank you! > An example of a VCT that is versioned would be helpful (e.g. > https://betelgeuse.example.com/education_credential/v1 or something > similar) > I don't love this (as I think I told you off list) but https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387/changes/01798c9708201a705dd043f3529b17e506b5f666 adds that as part of the PR aimed at addressing your comments https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387 > > Should "Verifiable Credential(s)" be lowercase throughout (e.g. verifiable > credentials), to avoid confusion with W3C Verifiable Credentials? Another > alternative would be to use "verifiable digital credentials" which has been > used lately in many circles to refer to the higher level "thing" for > exactly this reason. > Yes, I think some changes along these lines would be worthwhile and welcome by many. Although I want to be careful with not changing things like the draft identifier and name (or at least the acronym), which are used in some downstream standards and have become colloquially known as SD-JWT VC. Same consideration with things like the vct claim name and the media type value. This was a little more awkward than I'd hoped but this change https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387/changes/319d31e67973134f139aa281bf6d2cc1252f7b69 endevors to "Use the three-word term Verifiable Digital Credential as consistently as possible throughout the document" as part of the PR aimed at addressing your comments https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387 > > 6.3.1 > > The Type Metadata is retrieved using the HTTP GET method. The response > MUST be a JSON object as defined in Section 6.2. > > Should this also mention the content type and expected HTTP code? > (application/json & 200 OK) > Sure, why not? https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387/changes/5f1f2c1a157d7b60124aace933387a7dbbd7e9a6 does that and fixes the other similar text as part of that larger PR 11.3 > > If such behaviour is detected, Verifiers are advised to reject SD-JWT VCs > issued by those Issuers. > > Should this also say that verifiers should not fetch the issuer metadata > in cases where this is detected? > Yeah, probably. https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387/changes/e04cc8817312cd78ae040151e2ae6b4fd9389ebe adds that > Holders are advised to reject SD-JWT VCs if they contain easily > correlatable information in the Issuer identifier. > > I found this text to be a bit out of place, as it seems to be making > recommendations to holders, which are not the audience of this spec. I > think reframing this to be something actionable for a credential manager > might make more sense (e.g. credential managers may want to surface a > warning and let the holder reject). > It does feel a bit out of place. But credential manager isn't a defined or used thing in this spec and the meaning of Holder from https://datatracker.ietf.org/doc/html/rfc9901#section-1.2-2.22 via https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-13#section-1.4-1 is meant to broadly encompass "the actual user, the supporting hardware and software in their possession, or both." So Holders are definitely one audience of this spec. In https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387/changes/e04cc8817312cd78ae040151e2ae6b4fd9389ebe though I did move that text and adjust it a little bit to hopefully flow in the section better. > > *Nits* > With one exception, the 3-party model as noted, the ones below are all in https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/387/changes/6935d4b59de1138818133c762aaeedc606e7b2e6 > > 1.1 > > In the so-called Issuer-Holder-Verifier Model, Issuers > > I think it would be useful to say "also sometimes referred to as the > 'three party model'". > I think that term is a confusing misnomer that thankfully seems to be on the decline. I do not want to propagate its use. Or even acknowledge it for that matter. 3.4 > > It depends on the Verifier policy to reject or accept a presentation of a > SD-JWT VC based on the status of the Verifiable Credential. > > > Proposed alternate text: “*Verifier policy decides whether to reject or > accept a presentation of a SD-JWT VC based on the status of the Verifiable > Credential.*” > 6.1 > > Note: The hash of the Type Metadata document > > > I think this could benefit from a "See"-type reference to section 7 > (document integrity) > > 8.1.2.2 > > Consuming application MUST preprocess > > The consuming..." or "Consuming applications" > > 11.1 > > The Privacy Considerations in Section 10.1 > of [I-D.ietf-oauth-selective-disclosure-jwt] apply especially to > the cnf claim. > > Add comma after "apply" > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _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]
