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