[OAUTH-WG] Re: AD comments on draft-ietf-oauth-sd-jwt-vc

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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 [e-mail], 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._