It’s not really an interop issue either, given that following or not following this requirement doesn’t alter the shape of messages or tokens. It’s more of an architectural requirement, which preserves the relationships between the OAuth2 roles involved and prevents the confusion that might arise by the availability of data that characterizes this particular scenario, but that doesn’t change the more general premises of the protocol. In terms of finding common ground, I am not sure if visions as diametrically opposed as pitting a MUST against a MUST NOT have much of an achievable common ground, especially given that the MUST NOT stance already passed consensus in the past year, and in more than one month of very public debate during last calls, the MUST side had mostly one backer and more than one opposed..
From: Jared Jennings <jaredljenni...@gmail.com> Date: Monday, May 11, 2020 at 20:14 To: Vittorio Bertocci <vittorio.berto...@auth0.com> Cc: Denis <denis.i...@free.fr>, Benjamin Kaduk <ka...@mit.edu>, "oa...@ietf..org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Hi Vittorio, Yeah, this does make a bit of sense. So, the goal is to guide implementors from making bad choices, not from a security perspective. Meaning, it's not a security risk that a client does inspect or analyze the token. Instead, it's is an interop issue and thus we are guiding implementors to never assume or expect the token format to be consistent or of a expected format, for various reasons. I kinda know the answer to this question, but I am kinda asking this way to help restate the intent of the "topic" and maybe help guide to a wording that works for everyone. For example, as a consultant, it can be very helpful to know how to decompile or inspect an "Object", but at the same time knowing that such a method or practice should never be used in production. Jared On May 11, 2020, at 19:24, Vittorio Bertocci <vittorio.berto...@auth0.com<mailto:vittorio.berto...@auth0.com>> wrote: 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 specin 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
