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> > 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
