Thanks Mark (and AI) for the review. Daniel (and AI) created this PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/422 addressing the feedback. I (without AI) reviewed it and merged the changes, which will be in the next (-19) revision of the draft.
On Thu, Aug 13, 2026 at 12:18 AM Mark Nottingham via Datatracker < [email protected]> wrote: > Document: draft-ietf-oauth-sd-jwt-vc > Title: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) > Reviewer: Mark Nottingham > Review result: Almost Ready > > *[Drafted with AI assistance from a structured review run over the > document and > the WG's record, then reviewed and edited by me.]* > > The draft is reasonable where it touches HTTP. It uses GET throughout, > puts key > material behind HTTPS rather than in the DNS, and uses the > discovery-document-plus-links pattern RFC 9205 recommends. The > `.well-known` > construction in Section 3 is correct. > > The problem is that it specifies requests but is almost silent about > responses. > It defines four fetches -- the `/.well-known/jwt-vc-issuer` document, > `jwks_uri`, Type Metadata from `vct` and `extends`, and the logo / > background / > SVG-template `uri`s -- and gives partial HTTP behaviour for two. Issues 1 > to 5 > all follow from that. > > This WG has already done most of the relevant analysis in > draft-ietf-oauth-client-id-metadata-document: redirects, server-side > request > forgery (SSRF) and special-use addresses, HTTPS versus `data:`, cache > headers. > > # Issues > > **1. Redirect handling is unspecified** > > "redirect" and "3xx" don't appear in the document. RFC 9205 Section 4.6.1 > asks > applications to say whether redirects are followed, because user agents > may or > may not follow them. > > Section 6.1 specifies a check performed *before* the request -- "Before > making > a request to the JWT VC Issuer Metadata endpoint, the Holder or Verifier > MUST > validate the URL...". A 3xx arrives after that check has passed. > > The document needs to say (probably globally) whether redirects are > followed > and under what constraints, and apply the Section 6.1 validation to each > URL > actually connected to, not just the first. > > **2. Rendering URIs are underspecified** > > The rendering URIs get very little specified HTTP behaviour: no method, > status, > media type, size or time bound, no scheme constraint. Is an `http:` logo > URI > conformant? Section 4.5.1.2.2 covers references out of the SVG -- > "consuming > applications MUST ensure that references to external resources (images, > etc.) > from within the SVG cannot be used to track users or the usage of > credentials" > -- but says nothing about the fetch of the SVG itself. Section 7.4 is > scoped to > the Type Metadata document, not the resources it points at. > > Restating Section 6.1's requirements once, generally, for every URL the > specification causes a Consumer to dereference would some of this. > Constraining > the rendering URIs to `https:` or `data:` would also help. > > **3. Pinning success to 200.** > > Sections 3.2 and 4.3.1 both say "A successful response MUST use an HTTP 200 > status code". RFC 9205 Section 3.1 asks applications not to overlay the > semantics of generic protocol elements. > > Instead, describe the semantics -- a representation of the metadata > resource, > retrieved with GET -- rather than pinning a status code. > > **4. The caching rule is incomplete.** > > Otherwise, the Consumer MUST use the Cache-Control header of the HTTP > response to determine how long the metadata can be cached. > > Cache-Control isn't the only input to the HTTP caching model. Point at RFC > 9111 > instead. Also tell publishers to send an explicit freshness lifetime, and > say > whether the integrity-keyed indefinite cache overrides origin directives > such > as `no-store`. > > **5. The integrity mechanism is specified by reference to an algorithm that > fails cross-origin.** > > Section 5 requires a Consumer to "MUST verify the integrity of the > retrieved > document as defined in Section 3.3.5 of [W3C.SRI]". Step 3 of that > algorithm is > "If response is not eligible for integrity validation, return false", and > Section 3.3.2 makes eligibility depend on the response being same-origin or > CORS-permitted. Every URL this document integrity-checks is cross-origin by > construction, and CORS is never mentioned. > > So in a browser-hosted wallet the cited algorithm returns false, Section > 5's > MUST fails, and Section 4.7 rejects the credential. In a native consumer > there's no Fetch response and no loading origin, so step 3 has no meaning > and > every implementer will quietly skip it. > > If browsers are in scope, this needs an `Access-Control-Allow-Origin` > requirement on the fetched documents. If not, cite SRI for the syntax of > the > integrity-metadata string and specify the digest comparison in your own > words. > Note also that the cited section doesn't survive into SRI 2, so the > reference > is to a form of the algorithm current SRI no longer contains. > > **6. `vc+sd-jwt` is now assigned to someone else.** > > Section 2.2.1 says "both vc+sd-jwt and dc+sd-jwt should be accepted as the > value of the typ header for a reasonable transitional period". Is this > intended > to go into the permanent RFC, or will it be removed? > > # Comments > > - No normative reference to RFC 9110 or RFC 9111, though the document > specifies > GET, status codes, a content type and `Cache-Control` behaviour. Same for > RFC > 3986, given Section 3's "scheme, host and, optionally, port number and path > components, but no query or fragment components". > > - `jwks_uri` is defined and never specified: no method, status code, > content > type, caching or integrity, and Section 6.1 doesn't reach it. If that's > deliberate deferral to RFC 7517, say so. > > - `nosniff` and `Content-Security-Policy` appear nowhere. RFC 9205 Section > 4.13 > names them as response-side mitigations for the active-content risk > Sections > 4.5.1.2.2 and 6.5 address entirely on the client side. Your resources > remain > reachable by a browser whether or not that's intended. > > - No response message appears anywhere: Figures 12 and 13 are two-line > requests, Figures 14, 15 and 17 are bare JSON. RFC 9205 Section 4.1 asks > for > both request and response with complete header sections. RFC 8414 Section > 3.2 > and RFC 9728 Section 3.2 both show one, and it's the artefact that would > have > surfaced issues 3 and 5. > > - Distinct media types for the two metadata documents over > `application/json` > would have been nice, per RFC 9205 Section 4.8, but I see this was raised > in > issue #388. > > - Section 6.1 uses "internal" three times and defines it nowhere. > draft-ietf-oauth-client-id-metadata-document cites RFC 6890 for the same > requirement. > > # Nits > > - Section 1.3 uses the pre-RFC 8174 boilerplate. Note there is a lowercase > "should" in Section 2.2.1. > > Cheers, > > > -- _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]
