Hi Brian, Looks great! Left a couple of very small, non-blocking comments for consideration on the PR.
Cheers, > On 15 Aug 2026, at 6:20 am, Brian Campbell <[email protected]> wrote: > > 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. -- Mark Nottingham https://mnot.net/ _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
