Thank you Jared for your comment! I have to admit I have been very tempted to go that route, mostly for moving things forward, but I still think we’d do the reader a disservice by relaxing the language there. Real world scenarios are full of situations where additional assumptions can lower dangers that must be taken in consideration in the general case, which might make less of a risk going against the spec in those particular circumstances, but their existence doesn’t warrant relaxing guidance for the general case. A concrete example: I worked on scenarios where resource servers wanted to guarantee some degree of business continuity in case of AS outage, which boiled down to RS’ willingness to accept ATs past their declared expiration time, on the condition that the AS outage condition was detectable and the staleness of the AT didn’t cross a tolerance threshold. The business scenario made sense, and the implementer was within their right in deciding that disregarding exp in those circumstances was acceptable. Nonetheless, I would not argue that given the existence of that scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT. There might be circumstances in which the stars align and it is safe for a client to inspect the AT, but in the general case that’s not true (this has been covered in details in the various threads on the topic). Also note, the fact that the client (as the application code) is banned from doing that inspection doesn’t mean that the solution as a whole cannot do it. Developers can examine network traces, or use any other mechanism available in their particular circumstances to inspect traffic that are out of scope for this specification, and that would give them in practice the oversight discussed here where possible. The specification doesn’t aim at preventing that inspection in general, but it does aim at ensuring that the ability to do perform that is excluded from the contract between the roles described in OAuth2, so that any violation is either understood to be high bar, or the logic meant to perform those checks is implemented outside of the client code itself, preserving the protocol invariants and protecting developers from one of the most painful production issues I have observed in many years of real life use of JWT ATs. Ultimately, the latter part is one of the reasons for which I have a hard time relaxing this part, whereas pretty easily relaxed constraints on other areas where my initial position was more strict (multiple resources in audience, etc). I know this to be very painful if not addressed correctly, and the only arguments against it appear to be more about principle than about concrete scenarios, expressive power or security.
From: Jared Jennings <jaredljenni...@gmail.com> Date: Monday, May 11, 2020 at 06:30 To: Denis <denis.i...@free.fr> Cc: Benjamin Kaduk <ka...@mit.edu>, Vittorio Bertocci <vittorio.berto...@auth0.com>, "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" If I may, step in and offer a suggestion. What if instead of "MUST NOT" replace with "SHOULD NOT"? To me, (and this might be me), but MUST NOT describes a violation. As in I broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a guideline, best practice, etc. If then the sentence went on to explain why you should not inspect the token, the risk is therefore known and on the "implementer" of the inspection. Jared On Mon, May 11, 2020 at 7:34 AM Denis <denis.i...@free.fr<mailto:denis.i...@free.fr>> wrote: Hi Benjamin, We are making progress since we now understand better each other. You wrote several sentences on which I agree: "I do in fact agree that token inspection by a client can be useful in at least some situations". "I fully support having privacy considerations sections that discuss the privacy properties of the protocol in question, even including aspects that are currently lacking. "I do not believe that a JWT profile for OAuth use is the place to make changes to the core OAuth protocol that improve its privacy properties". I also accept your apologies. RFC 6749 is quite clear in section 1.4 that "The string [access token] is usually opaque to the client". However, it does not mean that : "The client MUST NOT inspect the content of the access token". I believe the wording I proposed corresponds to the reality: There is no guarantee that token inspection can always be performed.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
