Top posting.... These look good to me. Missed perhaps? Section 6: Either put a link to the SVG security information somewhere in Section 6, or list those recommendations in Section 6 with a link to it from Section 4.5.1.2.2.
Deb On Fri, Aug 14, 2026 at 6:43 PM Brian Campbell <[email protected]> wrote: > These things take time. No apologies needed. Which I guess means I > shouldn't apologize for this reply being slow. Regardless, thank you for > the review. Responses are inline below and updates to the draft are en > route via https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/423 > > On Mon, Aug 10, 2026 at 10:10 AM Deb Cooley <[email protected]> wrote: > >> Apologies for how long this took. Here are my comments on the draft: >> >> General comment (I've left examples below): There are a bunch of nested >> fields (probably the wrong word, maybe claims is better?) where the top >> level is OPTIONAL, but then sub fields are MUST, for example see my comment >> on Section 2.2.2.3, and 4.5.1. [There are more, I just lost the will to >> comment on each of them]. I can think of two ways to 'clarify' this. 1. >> Make a general statement up front (intro, terminology, somewhere like >> that). Or add the phrase 'if used...'. The second is more obvious to a >> reader 'in the moment', but the first might be easier for the author. I'm >> happy to chat about this. Also let me know if I've gotten this wrong (not >> the first, nor the last time). >> > > The wording in 2.2.2.3 was odd at best and maybe wrong. I've tried to > remedy that at > https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/423/changes#diff-e750c0958ca10e395b4d3b77bb5aafccc668b4a1a50675dda79a8d90b39a2468R320 > > I'm pretty firmly of the opinion that the others throughout section 4, > even after you lost your will, can be reasonably understood to mean, "the > thing is optional and when used these are the requirements but when not > used the requirements don't apply." How can requirements apply to something > that doesn't exist? > > > >> >> Section 2.2.1, last paragraph: Any idea how long a 'reasonable >> transitional period' is? Maybe state that determining what is 'reasonable' >> is out of scope for this specification, or similar. I'm fine leaving this >> alone, but it may draw comments. >> > > We aren't really sure but after discussing it further, we feel it's > probably reasonable to consider that period as having reasonably past and > remove that whole paragraph. > > > >> >> Section 2.2.2.1, Figure 3: I had to look up Russ Lasky (don't judge - my >> husband laughed). For some of these fields, the IETF has guidance on >> entries that have been reserved. When you can, please use those. Here is >> the easiest link: >> https://datatracker.ietf.org/doc/statement-iesg-statement-on-assignable-codepoints-for-examples-in-ietf-specifications/ >> . This comment applies everywhere you have examples. >> > > AFAICT Russ's email address is okay because it uses the reserved .example > TLD from https://datatracker.ietf.org/doc/html/rfc2606#section-2 > > I also see John Doe's email address of [email protected], which I think > is also okay because it's using a reserved example second level domain name > from https://datatracker.ietf.org/doc/html/rfc2606#section-3 > > Similarly, all (that I can find) https:// URLs in examples throughout the > document use either a reserved TLD or reserved second-level domain. And all > the URNs start with urn:example:, which seems okay. > > The moose out front shoulda told ya all this. > > > >> Section 2.2.2.2: I would add at least a tiny bit more information about >> why this could/should be used. Perhaps some of the information in this >> message would work: >> https://mailarchive.ietf.org/arch/msg/oauth/1Idb9zZ5Qgjo_QOWyqZqpaUs9Cs/ >> > > Makes sense. Will add a bit. > > > >> >> >> Section 2.2.2.3, para 2: If some of the fields below are optional, then >> how does the 'are used within...' work? Maybe 'if used within...'? (if an >> optional field isn't chosen, then it isn't used within the SD-JWT component) >> > > See prior reply about 2.2.2.3 and fixing it. > > > >> >> Section 4.5: Consider whether sentences 2 and 3 would be better listed >> under the bullet for locale. The advantage is that it puts all the >> normative requirements for this object in one place. >> > > Reading this again, I think it'd be preferable to just not use the big > 2119 langue in sentences 2 and 3. > > > >> >> Section 4.5.1: So according to the bullet above, the rendering object is >> optional, but this section has many MUSTs. Perhaps, add 'if included' >> somewhere in the first sentence? Or perhaps the rendering object is really >> 'REQUIRED'? >> > > See prior reply about all of section 4 and not changing it. > > > >> >> Section 6: Either put a link to the SVG security information somewhere >> in Section 6, or list those recommendations in Section 6 with a link to it >> from Section 4.5.1.2.2. >> >> References: >> RFC 2397 is listed as legacy. is there a more recent specification? [I >> certainly don't see anything linked to it, and I'm fine if there isn't, but >> just in case, I'm asking.] >> > > I am not aware of one, wasn't able to find anything, and one of the LLMs > confidently tells me that the "canonical reference is RFC 2397." > > >> >> Section 8.1 and Informative References: To make these easier to find, >> please add: https://www.iana.org/assignments/jwt#claims >> > > yup > > >> >> >> Section 8.2 and Informative References: To make these easier to find, >> please add: https://www.iana.org/assignments/media-types#application >> > > yup > > > >> >> >> Also, I have asked for an http directorate review in advance of IETF Last >> Call... >> > > Thank you. We've tried to address everything in it, see > https://mailarchive.ietf.org/arch/msg/oauth/dfnha_5m3_v62skUqVDHMd_yI4Q/ > > > >> >> I'm happy to take questions/comments. >> >> Deb >> Sec AD >> >> > *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]
