Thanks Mike, I added a sentence about lowercasing the scheme and host to the PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/450/changes/d1199d1d44bf348312fddea21b802341393d4665
We'll get it merged soon and published soonish (working with or around the submission cutoff window). On Wed, Nov 4, 2026 at 12:24 PM Mike Bishop <[email protected]> wrote: > 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]> > 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]> 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 but redirected the query to two.example.com, the response > still has to contain 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. > -- _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]
