> Am 08.02.2021 um 00:56 schrieb Warren Parad <wpa...@rhosys.ch>: > > >> 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?
Why should we encourage it? > > > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. Implement > Authress. > > >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
