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).

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.

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.

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/

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)

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.

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'?

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.]

Section 8.1 and Informative References:  To make these easier to find,
please add:  https://www.iana.org/assignments/jwt#claims

Section 8.2 and Informative References:  To make these easier to find,
please add:  https://www.iana.org/assignments/media-types#application

Also, I have asked for an http directorate review in advance of IETF Last
Call...

I'm happy to take questions/comments.

Deb
Sec AD
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to