The "can" works better, agreed. Thanks! ᐧ On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <jric...@mit.edu> wrote:
> Thanks, Dick. I agree with removing the excess parenthetical, but I > intentionally avoided using a lowercase “may” in the middle of the > text (in favor of “can”) to avoid normative-sounding non-normative > language, so I’d recommend that change be kept: > > Implementers should be aware that a token introspection request lets the > AS know when the client > is accessing the RS, which can also indicate when the user is using > the client. If this implication is not acceptable, implementers can > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > > On Aug 27, 2020, at 12:15 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > > Here is a crisper revision. > > Implementers should be aware that a token introspection request lets the > AS know when the client > is accessing the RS, which may indicate when the user is using > the client. If this implication is not acceptable, implementers can > use other means to carry > access token data, e.g. directly transferring the data needed by the > RS within the access token. > ᐧ > > On Thu, Aug 27, 2020 at 7:19 AM Justin Richer <jric...@mit.edu> wrote: > >> I would clarify that this doesn’t necessarily say that the user’s there, >> and remove the normative requirement (which doesn’t have enforceable teeth >> in this context): >> >> Implementers should be aware that a token introspection request lets the >> AS know when the client >> (and potentially the user) is accessing the RS, which *can also >> indicate* when the user is using >> the client. If this implication is not acceptable, *implementers can >> use other means* to carry >> access token data, e.g. directly transferring the data needed by the >> RS within the access token. >> >> >> — Justin >> >> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt < >> torsten=40lodderstedt....@dmarc.ietf.org> wrote: >> >> Will the following text work for you? >> >> Implementers should be aware that a token introspection request lets the >> AS know when the client >> (and potentially the user) is accessing the RS, which is also an >> indication of when the user is using >> the client. If this impliction is not accepatable, implementars MUST >> use other means to carry >> access token data, e.g. directly transferring the data needed by the >> RS within the access token. >> >> >> On 26. Aug 2020, at 23:12, Mike Jones < >> Michael.Jones=40microsoft....@dmarc.ietf.org> wrote: >> >> I agree with Dick’s observation about the privacy implications of using >> an Introspection Endpoint. That’s why it’s preferable to not use one at >> all and instead directly have the Resource understand the Access Token. >> One way of doing this is the JWT Access Token spec. There are plenty of >> others. >> >> The downsides of using an Introspection Endpoint should be described in >> the Privacy Considerations section. >> >> -- Mike >> >> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Dick Hardt >> Sent: Wednesday, August 26, 2020 9:52 AM >> To: Torsten Lodderstedt <torsten=40lodderstedt....@dmarc.ietf.org> >> Cc: last-c...@ietf.org; oauth <oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Last Call: >> <draft-ietf-oauth-jwt-introspection-response-09.txt> (JWT Response for >> OAuth Token Introspection) to Proposed Standard >> >> >> >> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt < >> torsten=40lodderstedt....@dmarc.ietf.org> wrote: >> Hi Denis, >> >> On 25. Aug 2020, at 16:55, Denis <denis.i...@free.fr> wrote: >> >> >> The fact that the AS will know exactly when the introspection call has >> been made and thus be able to make sure which client >> has attempted perform an access to that RS and at which instant of time. >> The use of this call allows an AS to track where and when >> its clients have indeed presented an issued access token. >> >> >> That is a fact. I don’t think it is an issue per se. Please explain the >> privacy implications. >> >> As I see it, the privacy implication is that the AS knows when the client >> (and potentially the user) is accessing the RS, which is also an indication >> of when the user is using the client. >> >> I think including this implication would be important to have in a >> Privacy Considerations section. >> >> /Dick >> ᐧ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
