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]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: draft-ietf-oauth-sd-jwt-vc-19 ietf last call Secdir review 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]<mailto:[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? [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? * 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 :) [IM] Indeed, I'll have another look in case I find some workable suggestion. * 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. [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)"? * 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]
