It goes both ways for me. I hate the fact that eventually there would need to be an exhaustive list of all the things you shouldn't be doing. But I also understand the value in BCPs and direct guidance on footguns and pits of failure. I can totally imagine there is a story behind this errata, which stemmed from an implementation that actually was doing this and causing a problem, or an arbitrary package that wants to avoid adding functionality that explicitly goes against the spec.
It's a timestamp, because it is a timestamp, people are tempted to do something with it when they should not. I like the errata. I would have preferred it to say something more to the effect of: > This claim has no additional semantic meaning, and must not be used in the > verification or rejection of JWTs. JWTs with an "iat" claim in the future > have to impact on their validity. But in spirit, I accept the errata. On Tue, Dec 5, 2023 at 11:55 PM Brian Campbell <bcampbell= [email protected]> wrote: > I agree that the change in text is too much for an errata. But I am > sympathetic to the problem that the reporter has described. Perhaps it'd be > appropriate as an errata that, in the interest of interoperability, > mentions/reminds that 'iat' doesn't have defined semantics about rejection > and suggests (non-normatively) not to implement/enforce any (in the absence > of an application specific profile anyway)? > > On Sun, Dec 3, 2023 at 4:43 AM Justin Richer <[email protected]> wrote: > >> 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 >> > > *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] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
