Thanks Ionut! Replying below again, this time with [BC] and some old content sniped out.
On Mon, Oct 19, 2026 at 2:20 PM Ionut Mihalcea <[email protected]> wrote: > Hi Brian, > > Thank you for the update! Replying below with [IM]. I'll have a look at > the PR as well. > > *From: *Brian Campbell <[email protected]> > *Date: *Friday, 16 October 2026 at 13:42 > *To: *Ionut Mihalcea <[email protected]> > <snip> > * Section 4 describes the use of a well-known URL to find issuer metadata, > and > mandates the shape of the starting URL in iss. However, no requirement is > made for > that URL to be parsed and normalised as per sec. 6 of RFC3986 before the > well-known > URL is constructed. Is that on purpose? > > > Only in as much as it didn't seem necessary and I am not aware of other > similar spec text about constructing a well-known URI for metadata > retrieval that does. But maybe I'm not seeing something. Is there a > specific way you'd envision such a requirement manifesting in this text > that would be useful? > > [IM] Ok, then I can share the attack I was envisioning and if that is > outside your scope or if it fails because of some spec text that I've > missed we can silently drop this. > > [IM] The starting point is a domain under which privileged control is > maintained over the well-known endpoint ( example.com/.well-known ) but > other entities might upload random content to other paths ( > example.com/upload/... ). If the attacker provides the issuer URL as ' > example.com/../../upload/mal.json' the well-known GET request will land > on example.com/upload/mal.json , which would serve metadata under the > attacker's control. For some consumers this might make them assume the > attacker is authorised by example.com . Does this make sense, and does it > raise any concern? > Thank you for the explanation, which does make sense. I'm a little uncertain, to be honest, but I'm inclined to say that because issuer values are treated as literal string values (even when they are URLs) and the draft requires "employing a key discovery and validation mechanism (defined in Section 2.5) that is permitted for the Issuer according to policy", that an issuer value of "https://example.com/../../upload/mal.json"; is exactly that value, distinctly different from "https://example.com/";. Does that make sense? Am I overlooking something, do you think? > > * The processing of path components in Section 5.6.1.2 and of claim > mandatory > metadata in 5.6.3 seems prone to issues, when combined. For example, for > string > path components, you state "If the key does not exist in an element > currently > selected, remove that element from the selection." This does not take into > account > whether the element at the end of the path is expected to be mandatory. And > actually, 5.6.3 is not clear on this either: if the claim is within > elements of an > array, MUST all elements include that claim or at least one? Does this > apply only > at the "leaf element" level, or must all arrays along the path have > elements that > allow traversal all the way to this mandatory element? Either way, this > should be > stated explicitly, and the path traversal text should also reflect it. If > my > description is not clear I can provide an example. > > > It's difficult to articulate but your description does a pretty good job > of it. Thank you. I thought we (the editor team) talked about this, more or > less, awhile back, and I somehow got the impression that it had been fixed. > But looking again at the content, that impression seems to be mistaken. > > I'll try to fix or at least clarify some of the text. But, to be honest, > I'm not sure how to do that easily (or at all) in the context of the > current text and structure. So you can maybe imagine my disappointment upon > realizing that my prior impression was off and work was still needed here. > > The text at > https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-19.html#section-5.6.1.2-4 > kind of speaks to the issue but probably not in a sufficient capacity. > > "The path property MUST point to the respective claim as if all > selectively disclosable claims were disclosed to a Verifier. That means > that a consuming application which does not have access to all disclosures > may not be able to identify the claim which is being addressed." > > Suggestions on this one would be welcome :) > > [IM] Indeed, I'll have another look in case I find some workable > suggestion. > We did come up with some text regarding this, and updated the PR with it after the email. Please take a look at that before spending any cycles working on a suggestion. That text is around here https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/443/changes#diff-e750c0958ca10e395b4d3b77bb5aafccc668b4a1a50675dda79a8d90b39a2468R1094 <snip> Second, this requirement > seems to assume that SD-JWT VCs will be used exclusively on the open > internet, and > never in internal deployments. Is this on purpose? If closed / private > environments > are out of scope, it would be good to make that explicit. > > > I think that use on the open internet is assumed but not exclusively so. > The purpose of this text was to say something reasonable about avoiding > SSRF, not necessarily preclude a deployment environment. Maybe that MUST > could be changed to a SHOULD to allow more leeway in deployment models? I'd > be reluctant to say more though. > > [IM] I think the MUST is needed, maybe changing the last part of the > sentence to something like "... and that it does not point to resources an > issuer cannot access (e.g., resources internal to the Consumer)"? > That makes sense, thanks, I've updated the PR accordingly with this change https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/443/changes/f18983572aa191b5b2e3da60fc25e9ce8df5f856 <snip> > -- _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]
