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 >> > >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
