> > I‘m therefore leaning towards explicitly stating in our draft that it is > not intended to be used with refresh tokens.
I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress <https://authress.io>. On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten= 40lodderstedt....@dmarc.ietf.org> wrote: > Hi Andrii, > > Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.dein...@gmail.com>: > > > Hi Torsten, > > thank you for your response. > > My use case is pretty straight forward > > An OAuth client queries the AS to determine the active state of an access > token and gets the introspection response which indicates that this access > token is active (using RFC7662). > > An OAuth client queries the AS to determine the active state of a refresh > token and gets the introspection response which indicates that this refresh > token is active (using RFC7662). > > An OAuth client queries the AS to determine the active state of an access > token and gets the introspection response (JWT) which indicates that this > access token is active (using this draft). > > Now, an OAuth client queries the AS to determine the active state of a > refresh token (using this draft)... How will the introspection response > look like assuming that the client provides the valid refresh token and > technically, nothing stops it from doing so. > > > why should the state be provided as JWT?I think the plain JSON response is > sufficient in that case. I also think using token introspection for > checking the state of a token from the client side has limited utility. The > definitive decision is always made when the client tries to access a > resource. > > I‘m therefore leaning towards explicitly stating in our draft that it is > not intended to be used with refresh tokens. > > best regards, > Torsten. > > > Regards, > Andrii > > > On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Hi Andrii, >> >> thanks for your post. >> >> The draft is intended to provide AS and RS with a solution to exchange >> signed (and optionally encrypted) token introspection responses in order to >> provide stronger assurance among those parties. This is important in use >> cases where the RS acts upon the introspection response data and wants the >> AS to take liability re the data quality. >> >> I’m not sure whether there are similar use cases if a client introspects >> a refresh token. What is your use case? >> >> best regards, >> Torsten. >> >> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.dein...@gmail.com >> >: >> > >> > Hi WG, >> > >> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 >> Token Introspection [RFC7662] specifies a method for a protected resource >> to query an OAuth 2.0 authorization server to determine the state of an >> access token and obtain data associated with the access token." which is >> true. Although, according to RFC7662, the introspection endpoint allows to >> introspect a refresh token as well. Hence, the question I have is how will >> a token introspection response look like when the caller provides a refresh >> token and sets the "Accept" HTTP header to >> "application/token-introspection+jwt"? >> > >> > I expect there will be no differences, right? >> > >> > If so, I suggest to >> > • replace "a resource server" by "the caller" in section 4 >> (Requesting a JWT Response) >> > • change "If the access token is invalid, expired, revoked" by >> "If a given token is invalid, expired, revoked" in section 5 (JWT Response) >> > If not, my suggestion would be to clarify what the AS should do when it >> asked to introspect the refresh token in general and additionally, what >> should happen in the same case based on the type of the caller from the >> AS's point of view. >> > >> > Regards, >> > Andrii >> > >> >> _______________________________________________ > 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
