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> 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, > *e**ven 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 opaqu**e* 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
