niedz., 3 gru 2023, 11:43 użytkownik Justin Richer <[email protected]> napisał:
> This errata should be rejected, as stated in the write up, the change in > text is too much for an errata. If the WG wants to revise JWT at this level > it should be a full bis document. > > It's worth noting that the two other time based claims, nbf and exp, allow > for clock skew in processing, but both of these claims have defined > semantics about rejection whereas iat does not. One could argue that the > libraries mentioned in the issue are doing things the spec doesn't say to > do, but this kind of processing is extremely common. > > - Justin > > ------------------------------ > *From:* OAuth <[email protected]> on behalf of RFC Errata System < > [email protected]> > *Sent:* Friday, December 1, 2023 5:06 PM > *To:* [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] <[email protected]> > *Subject:* [OAUTH-WG] [Technical Errata Reported] RFC7519 (7720) > > The following errata report has been submitted for RFC7519, > "JSON Web Token (JWT)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7720 > > -------------------------------------- > Type: Technical > Reported by: Timothy Vergenz <[email protected]> > > Section: 4.1.6 > > Original Text > ------------- > 4.1.6. "iat" (Issued At) Claim > > The "iat" (issued at) claim identifies the time at which the JWT was > issued. This claim can be used to determine the age of the JWT. Its > value MUST be a number containing a NumericDate value. Use of this > claim is OPTIONAL. > > Corrected Text > -------------- > 4.1.6. "iat" (Issued At) Claim > > The "iat" (issued at) claim identifies the time at which the JWT was > issued. This claim can be used to determine the age of the JWT. Its > value MUST be a number containing a NumericDate value. Use of this > claim is OPTIONAL. Implementors MUST NOT reject otherwise-valid JWTs > with "iat" claims that appear to be from the future; token issuers > desiring this behavior may require it by including an "nbf" claim. > > Notes > ----- > There is substantial confusion and disagreement among JWT library > implementors about whether to reject JWTs with `iat` claims that appear to > be from the future due to clock drift. This confusion has led to over half > a dozen Github issues & PRs over the years in libraries in many different > ecosystems, and lots of strong disagreement among library developers and > users. > > Based on a sample of the top Google search results for jwt client > libraries in 11 different language ecosystems, the majority (7) of the > libraries sampled do not reject future `iat` claims, while the remaining 4 > *do* reject future `iat` claims by default. Of those 4 who do, *all* of > them have had Github issues filed (by different unique users) in which the > user was having a JWT unexpectedly rejected by a token validator using the > library whose clock had drifted from that of the token issuer enough to > trigger `iat`-based rejection. > > I propose we update the spec to explicitly prohibit rejection of > future-`iat` JWTs (especially since token issuers have always been able to > opt into this behavior using an `nbf` claim). Since this RFC has been > published and cannot be edited, a new superseding RFC will have to be > published and this one deprecated in order for the suggested change to make > it out of the errata and into an actual RFC doc. > > I'm not sure if this merits a full RFC republish -- but as a data point > for impact consideration, it's worth noting that this confusion has almost > certainly wasted at least multiple hours per person (on average) of > *dozens* of developers' time over the years, and led to at least half a > dozen production bugs that I've seen mentioned. One of these bugs cropped > up in my own organization on 2023-11-31 and has been observed previously > but was misunderstood and not resolved; the 2023-11-31 occurence involved > 10+ people in discussion. One Github issue I saw described an elongated > full web server outage attributed to this confusion which cropped up during > a leap-second-related clock drift issue. I'm filing this errata request on > calendar day 3+ of discussing this issue in my organization (if you include > past times this issue has cropped up). > > Thanks for your consideration! I look forward to hearing back. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7519 (draft-ietf-oauth-json-web-token-32) > -------------------------------------- > Title : JSON Web Token (JWT) > Publication Date : May 2015 > Author(s) : M. Jones, J. Bradley, N. Sakimura > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
