Early Review of draft-ietf-oauth-sd-jwt-vc-18
review-ietf-oauth-sd-jwt-vc-18-httpdir-early-nottingham-2026-08-12-00

*[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,