Inline; yes, the PR would address the DISCUSS. ________________________________ From: Brian Campbell <[email protected]> Sent: Wednesday, November 4, 2026 12:58 PM To: Mike Bishop <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mike Bishop's Discuss on draft-ietf-oauth-sd-jwt-vc-23: (with DISCUSS and COMMENT)
I went ahead and added this https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450/changes/07115ebeb576750611b2acdec48d2f5ac58dd0c2 to that PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450 which adds "Updates: 7800<https://www.rfc-editor.org/rfc/rfc7800> (if approved)" and some hopefully not-too-awkward text explaining it. On Tue, Nov 3, 2026 at 4:10 PM Brian Campbell <[email protected]<mailto:[email protected]>> wrote: Thank you for the review, Mike. I've endeavored to respond to individual items inline below. And am working on this PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450 with indicated changes (which doesn't yet have anything for the DISCUSS). On Mon, Nov 2, 2026 at 2:28 PM Mike Bishop via Datatracker <[email protected]<mailto:[email protected]>> wrote: Mike Bishop has entered the following ballot position for draft-ietf-oauth-sd-jwt-vc-23: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # IESG review of draft-ietf-oauth-sd-jwt-vc-23 CC @MikeBishop Thanks to Mark Nottingham for the [HTTP Directorate review](https://datatracker.ietf.org/doc/review-ietf-oauth-sd-jwt-vc-18-httpdir-early-nottingham-2026-08-12/). I appreciate that you incorporated much of his feedback, and you've done a really solid job building on top of HTTP. I have one DISCUSS point more in the process space; hopefully it's easy to resolve. ## Discuss ### Section 2.2.2.3, paragraph 6 ``` Note that Section 3 of [RFC7800] requires that a JWT containing a cnf claim also contain either the sub or iss claim. This specification explicitly overrides that requirement, as there are valid and legitimate uses of key-bound SD-JWT VCs without either of those claims. ``` That sounds like a change is being made to the requirement in RFC 7800, yet I see no Updates: tag on this document. To be honest, that note was added somewhat reluctantly and was really just intended to give the okay to ignore that particular requirement in RFC 7800, which arguably shouldn't have been in 7800 at all and I suspect most are already ignoring it. This PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/430 documents some of that and my choice of words there was softened in https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/447/changes#diff-e750c0958ca10e395b4d3b77bb5aafccc668b4a1a50675dda79a8d90b39a2468R366 Adding the Updates: 7800 tag to this document seems reasonable though, if that would resolve the DISCUSS? And, if so, do you think additional text in the document explaining the update would be needed or warranted? If that requirement shouldn't have been there and is routinely ignored, updating the document to remove it is the right course. Whether that should be this document or another one is something people might opt to shuffle around, but if this spec requires ignoring a MUST, it or something it references needs to remove the MUST. I don't think there needs to be much text for the update at all; the existing text that says it overrides that requirement could get a few-word tweak to say it removes it instead. What's in your PR seems plenty. ### Section 4, paragraph 2 ``` the JWT. The iss MUST be a case-sensitive URL using the HTTPS scheme that contains scheme, host and, optionally, port number and path ``` Scheme and host are case-insensitive by definition (RFC3986) and port numbers by construction, so of the permitted components only path can be case-sensitive. That's meant to say that the whole value should be treated as case-sensitive in this context. Right, I get the intended meaning, but that's not how URLs are defined. RFC 3986, "An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency." A similar rule applies to the host; the port number is a number, hence caseless. Per that spec, <HTTP://www.EXAMPLE.com/> and <http://www.example.com/> are equivalent. "Case-sensitive URL" isn't a defined thing that I'm aware of. Without normalizing the case-insensitive parts, you risk disagreement between people who use a full URL parser and people who do a string comparison. However, doing some digging, I see that RFC 7519 already gave us this ambiguity: iss, sub, and aud are StringOrURI, which says: "any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied." So those URLs are the same URL, but different Issuers. And what you're really doing here is requiring that those StringOrURI be a particular flavor of URI without changing the case-sensitive string handling. Section 7.3 of 7519 also says, "Some applications may include case-insensitive information in a case-sensitive value, such as including a DNS name as part of the "iss" (issuer) claim value. In those cases, the application may need to define a convention for the canonical case to use for representing the case-insensitive portions, such as lowercasing them, if more than one party might need to produce the same value so that they can be compared." So for consistency, you could point to that definition and include a caution to normalize if independent generators need to align. You don't have to fix 7519 here, but putting a Caution sign around the fiddly bit would be appreciated. ### Section 4.2, paragraph 1 ``` Metadata configuration as its content, using the application/json media type. The general requirements for HTTP retrieval defined in Section 3 apply. ``` While this is sufficient, I would encourage a distinct media type so that the server can assert the intended role of this JSON object. Same goes in 5.3.1. I'm struggling to see any tangible benefit to doing so. It's primarily a guard against client confusion, whether accidental or deliberate. If the client can be offered one type of JSON blob and attempt to parse it as a different JSON blob, that's an attack surface. If the server's response says what it understands the JSON blob to be, the client has an easy way to reduce its exposure to such confusion. It's not critical, just a good practice. ### Section 4.3, paragraph 2 It might be worth explicitly stating that this applies regardless of any redirection chain that may have occurred -- if the JWT had an Issuer of one.example.com<http://one.example.com> but redirected the query to two.example.com<http://two.example.com>, the response still has to contain one.example.com<http://one.example.com> to be valid, regardless of who served it. I feel like "MUST be identical to" is sufficient there. Seems like a useful clarification to me, but again, I won't be blocking anything on it.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
