Thank you for the review, Ionuț. And apologies for the slow response. I think the editorial team suffered a bit from diffusion of responsibility, which left some things unaddressed for too long.
I've endeavored to respond to individual items inline below. And begun working on this PR with corresponding changes: https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/443 On Tue, Sep 15, 2026 at 10:11 AM Ionuț Mihalcea via Datatracker < [email protected]> wrote: > Document: draft-ietf-oauth-sd-jwt-vc > Title: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) > Reviewer: Ionuț Mihalcea > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort > to review all IETF documents being processed by the IESG. These comments > were > written primarily for the benefit of the security area directors. Document > editors > and WG chairs should treat these comments just like any other last call > comments. > > The summary of the review is Has Issues, though this could be predicated > on my > misunderstanding. > > The draft builds on top of RFC9901 to define a complete, interoperable > data model > and ecosystem profile for SD-JWT Verifiable Digital Credentials (VC). It > provides > not just the model for the VC, but also for metadata for verifying and > displaying > VCs, as well as credential typing and inheritance mechanics, key and > metadata > discovery, and more. > > The document is thorough and quite broad in scope. The shape and flow of > the draft > seems good. The points below cover the issues and nits that stood out to > me. > > * 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? * In section 5.5.1.1, before the bulletpoints you have "The object contains > the > following properties". Should this be normative (i.e., "The object MUST > contain at > least one of the following properties"), since all the properties are > optional? > Asking because Section 5.5.1.2.1 uses normative language in a similar > context. > Hrm, yeah, at the very least the text in those two places should be aligned. > * In section 5.5.1.2.2 you give a list of characters that must be escaped > before > rendering the SVG. However, you should also mandate that invalid XML > characters be > stripped, or that the credential should be rejected if they're encountered. > Fair enough. Although I'd think the SVG rendering shouldn't be done in that case rather than rejecting the credential. And that'd likely be handled by the SVG/XML processing layer. * 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 :) > * In Section 7.1 you mandate that "the Consumer MUST validate the URL to > ensure > that it is a valid HTTPS URL and that it does not point to internal > resources". Two > observations here: this could be subject to a DNS rebinding attack, so it > would be > good to hint towards that and ask that the destination address get cached > and used > after check, instead of performing another request for it. Is there some straightforward and reasonably actionable text you could suggest? I am not well versed in DNS rebinding attacks, their impact, or their mitigations. But, given the layering involved and the APIs these applications likely use, ensuring that kind of caching is probably not at all trivial. > 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. > > * Section 7.10 mandates that "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." It would be helpful to provide some guidance > or > references on how to achieve this. > It's a bit strange, too, to have that privacy-related text in a security considerations section when there's treatment of very similar privacy considerations below in the privacy considerations section. Anyway, yes, I'll try to tie some things together so that sentence doesn't leave the reader hanging like that. > > Nits: > > * I'm struggling to parse the first paragraph in Section 5.3. Not certain > what "the > vct in the reference to the Type Metadata" means. Also, I can't easily > tell what > the relationship is between the text before the brackets and the text in > the > brackets. > You are not the first to struggle with that text. Prompted by a different review, this PR attempted to clarify it https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/429 > > * In Section 5.3.1: "it is at the consumer's discretion whether to attempt > retrieve > Type Metadata" - should probably be "... to attempt to retrieve ...". > yup > > * There are two ways in which optional and required properties / claims are > indicated throughout the document. In some places (e.g., Section 4.2) it's > "claim_name: OPTIONAL. ...". In others (e.g., Section 5.5) it's > "claim_name: ... > This property is OPTIONAL.". In some places (e.g., Section 5.2) it's both. > This is > just an observation, I think both work in conveying the intent. I also think they both work well enough in conveying the intent. -- _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]
