[OAUTH-WG] Re: [Last-Call] Re: draft-ietf-oauth-rfc8725bis-06 ietf last call Artart review

[Valery Smyslov <[e-mail]>]

Hi Yaron,
 
my concerns were addressed, thanks.
 
Regards,
Valery.
 
Hi Valery,
 
Thank you for the detailed review. Your comments should be all addressed in -07 of the draft. Specifically, we have essentially rewritten sec. 3.11 and 3.13, and went through the SHOULD statements across the document. It would be great if you could verify that you're good with these changes.
 
Thanks,
    Yaron
 
[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc8725bis/
On 10/07/2026 9:58, Valery Smyslov via Datatracker wrote:
Document: draft-ietf-oauth-rfc8725bis
Title: JSON Web Token Best Current Practices
Reviewer: Valery Smyslov
Review result: Ready with Issues
 
I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.
 
The document describes Best Current Practices leading to secure implementation 
and deployment of JSON Web Tokens (JWTs). The document lists known treats
and vulnerabilities for JWTs and for each provides possible mitigation.
 
I have some minor issues with this document.
 
1. Sections 3.1, 3.2, 3.6, 3.10, 3.11 contain SHOULDs without clarifying under which conditions
   they can be ignored. While I personally think that in some cases such clarifications
   are redundant, it seems that the IESG treats their absence more seriously these days,
   so I let the AD deside whether they are needed in this document.
 
2. Section 3.11
   The sentence
 
   When
   explicit typing is employed, implementations SHOULD register and use
   the full media type name "application/example+jwt", where "example"
   identifies the specific kind of JWT, and SHOULD set the corresponding
   "typ" value to "example+jwt", because distinct types make cross-JWT
   substitution harder when validators check "typ", and because
   misapplying the Section 4.1.9 prefix rule can cause validators to
   reject otherwise valid tokens or accept the wrong type. 
 
   is hard to parse due to its length and multiple mentioned conditions.
   I suggest to split it into several smaller recommendations.
   In addition, it is not defined under what conditions these SHOUDs 
   can be ignored.
 
3. Section 3.11
 
   In the sentence
 
   This pairing
   SHOULD be omitted only when the JWT cannot be confused with other
   kinds of JWTs in its application context.
 
   shouldn't this SHOULD be MAY? At least it is my feeling from reading 
   this text. And if I'm wrong, then I think the text should be
   re-written (and also include conditions when this SHOULD cab be ignored).
 
4. Section 3.13
 
   I'm a bit confused reading recommendations given in this section.
   I believe that the two RECOMMENDED clauses are not consisting:
 
   Implementations are RECOMMENDED to set a reasonable upper limit on
   the number of hash iterations...
 
   and
 
   Rejecting inputs with a p2c (PBES2 Count) value larger than twice that figure is RECOMMENDED...
 
   So, what values are recommended to reject - larger the limit or larger than twice the limit?
   Am I missing something?
 
5. Section 3.11
 
   In the sentence
 
   For example, for Security
   Event Tokens (SETs) [RFC8417], the media type is "application/
   secevent+jwt" and the "typ" value SHOULD be "secevent+jwt", because...
 
   why uppercase SHOULD is used? I believe, this is just an example, thus must be "should". No?