Subscribe me.I didn't understood all the postings since inception of including my mailing address
Isaac O.Ajonibode C.Director CBMC Nigeria cbmcnigeria2...@gmail.com www.cbmcint.com/Nigeria +2347087552127 FOUNDER/CEO AJOFOLU VENTURES INT'L LTD ajofoluventu...@gmail.com +2348164286235 2 Corinthians 5:20 On Thu, 12 Mar 2020, 15:26 , <oauth-requ...@ietf.org> wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: OAuth Digest, Vol 137, Issue 4 (isaac ajonibode) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Mar 2020 15:25:47 +0100 > From: isaac ajonibode <ajofoluventu...@gmail.com> > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 4 > Message-ID: > <CAChWCXrUKAJgMt-_2ggU0iC2RwgS9= > fzwxkh_khxty_mwhy...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Please unsubscribe me from your mailing list > > Isaac O.Ajonibode > C.Director CBMC Nigeria > cbmcnigeria2...@gmail.com > www.cbmcint.com/Nigeria > +2347087552127 > > FOUNDER/CEO > AJOFOLU VENTURES INT'L LTD > ajofoluventu...@gmail.com > +2348164286235 > 2 Corinthians 5:20 > > > On Mon, 2 Mar 2020, 06:33 , <oauth-requ...@ietf.org> wrote: > > > Send OAuth mailing list submissions to > > oauth@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/oauth > > or, via email, send a message with subject or body 'help' to > > oauth-requ...@ietf.org > > > > You can reach the person managing the list at > > oauth-ow...@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of OAuth digest..." > > > > > > Today's Topics: > > > > 1. Re: Benjamin Kaduk's Discuss on > > draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and > > COMMENT) (Benjamin Kaduk) > > 2. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token? > > (David Waite) > > 3. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token? > > (Andrii Deinega) > > 4. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh token? > > (David Waite) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sun, 1 Mar 2020 17:03:41 -0800 > > From: Benjamin Kaduk <ka...@mit.edu> > > To: Torsten Lodderstedt <tors...@lodderstedt.net> > > Cc: The IESG <i...@ietf.org>, > > draft-ietf-oauth-jwt-introspection-respo...@ietf.org, > > oauth-cha...@ietf.org, oauth <oauth@ietf.org>, Rifaat > Shekh-Yusef > > <rifaat.i...@gmail.com>, Roman Danyliw <r...@cert.org> > > Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on > > draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and > > COMMENT) > > Message-ID: <20200302010341.gz98...@kduck.mit.edu> > > Content-Type: text/plain; charset=utf-8 > > > > On Fri, Feb 28, 2020 at 03:44:05PM +0100, Torsten Lodderstedt wrote: > > > Hi Ben, > > > > > > > On 25. Feb 2020, at 23:52, Benjamin Kaduk via Datatracker < > > nore...@ietf.org> wrote: > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-oauth-jwt-introspection-response-08: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to all > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ > > > > > > > > > > > > > > > > > > This post focuses on clarifying your DISCUSS comments in order to get > > the process moving again. > > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > > ---------------------------------------------------------------------- > > > > > > > > Thank you for the updates in the -08; they address the bulk of the > > > > substantive issues! I have a few points remaining on the -08 text > but > > I > > > > think there are more localized issues to resolve. > > > > > > > > Can IANA please confirm that the new allocations in the -08 have > > > > received appropriate Expert (e.g., media type) review? I see some > > > > updates in the datatracker history relating to the -08 but nothing in > > > > the email archives. > > > > > > > > It looks like we need to register 'active' as a JWT claim? > > > > > > That?s correct. Will add this. > > > > > > > > > > > I don't think the new semantics for "jti" in the introspection > response > > > > are compatible with the RFC 7519 definition. Specifically, we say > that > > > > "jti" will be tied to the input access token, but 7519 says that > "jti" > > > > has to change when the contents of the JWT change ("MUST be assigned > in > > > > a manner that ensures that there is a negligible probability that the > > > > same value will be accidentally assigned to a different data > object"), > > > > and we admit at least the possibility of "active" and "iat" changing. > > > > > > I think the key word is ?accidentally?. This spec causes the AS to > > purposefully issue JWTs with the same ?jti? in order to allow replay > > detection with respect to the introspected access token. ?iat? is changed > > in order to give the RS an indication and proof when the introspection > > response was minted by the AS. > > > > I think "accidentally" is just there to emphasize that there's a risk of > > accidental collision when using a random string as an identifier, since > "of > > course you wouldn't deliberately reuse a token identifier". This stance > > seems to supported by "[t]he 'jti' (JWT ID) claim provides a unique > > identifier for the JWT". It's really hard for me to read that sentence > as > > allowing the use of a single identifier for two different JWT values, > since > > it then ceases to be a *unique* identifier. > > > > I seem to have forgotten how this replay detection is supposed to work; > > would you mind giving me a pointer and/or refresher? > > > > > > > > ?Active" does not really change, since the introspection response of an > > inactive token is empty except the ?active? element. > > > > I mean, the token artifact still changes. What am I supposed to > interpret > > "the JWT" as meaning if not the actual encoded artifact? > > > > > So I don?t see issues regarding RFC 7519. > > > > > > > > > > > Section 5 says that: > > > > > > > > If the access token is considered active, it MUST contain the > claims > > > > "iss" and "aud" in order to prevent misuse of the JWT as an ID or > > > > access token (see Section 8.1). > > > > > > > > But I don't think the predicate is correct -- misuse is still > possible > > > > by services that do not check the "active" claim's value. Shouldn't > > the > > > > "iss"+"aud" requirements be unconditional? > > > > > > Introspection responses for inactive tokens won?t contain any data > > except ?active?:false. I don?t see how they could be misused and > therefore > > think the text is ok. > > > > Could you give me a pointer where in the text it says that if "active" is > > false, no other claims are present? ("active" only appears three times, > > but none of them seem to say this.) > > > > -Ben > > > > > Please let me know whether you agree with my statements. I would then > > quickly publish a new revision (including changes to address your > comments). > > > > > > best regards, > > > Torsten. > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > > ---------------------------------------------------------------------- > > > > > > > > [New comments on the added text in the diff from -07 to -08.] > > > > > > > > Section 3 > > > > > > > > To support encrypted token introspection response JWTs, the > > > > authorization server MUST also be provided with the respective > > > > resource server encryption keys and algorithms. > > > > > > > > IIRC, based on some list discussion this text was going to be tweaked > > to > > > > avoid implying that JWE is mandatory. (Unfortunately, this is the > > > > thread that evolved into "client certs and TLS Terminating Reverse > > > > Proxies", so it's hard to be sure whether I saw any other followups.) > > > > > > > > The AS MUST restrict the use of client credentials by a RS to the > > > > calls it requires, e.g. the AS MAY restrict such a client to call > the > > > > token introspection endpoint only. How the AS implements this > > > > restriction is beyond the scope of this specification. > > > > > > > > This should probably be clarified a bit more, in the context of > "client > > > > credentials tend to be used by privileged, fixed endpoints, and the > > > > default may just be to allow them all access to all endpoints". > Right > > > > now it's not clear what's being restricted (and who "it" is that > > > > requires calls) > > > > > > > > Section 5 > > > > > > > > This specification registers the "application/token- > > > > introspection+jwt" media type, which is used as value of the "typ" > > > > header parameter of the JWT to indicate that the payload is a token > > > > introspection response. > > > > > > > > Do we also want to note that checking 'jti' is not mandatory and so > > this > > > > does not necessarily provide full protection? (I guess Section 8.1 > > > > covers this in more detail.) > > > > > > > > The value of the "aud" claims MUST identify the resource server > > > > receiving the token introspection response. > > > > > > > > We may want to dig into this a bit more: should there be any > > > > relationship between this "aud" value and the "client_id" that an RS > > > > might be using (as obtained from dynamic registration)? > > > > Does this value need to be different from the audience that is used > in > > > > access tokens for which this RS is the audience? (Should it be the > > > > same?) My instincts lean towards "different" but I would like > broader > > > > input. > > > > > > > > exp The "exp" claim indicates when the access token passed in > the > > > > introspection request will expire. > > > > > > > > On the face of it this seems divergent from RFC 7519's "the > expiration > > > > time on or after which the JWT MUST NOT be accepted for processing", > > > > though upon further examination the distinction is not quite so > large. > > > > That is, it's in effect saying that the introspection response should > > > > not be accepted for processing after the base token has expired, > which > > > > usually makes sense. There is a bit of a complication, though, in > that > > > > the "active" claim implies that we might still have RSes that plan to > > > > use the introspection response after the "exp" date has passed, which > > > > sounds a lot like a DISCUSS-level internal inconsistency. > > > > > > > > If possible, the AS MUST narrow down the "scope" value to the > scopes > > > > relevant to the particular RS. > > > > > > > > This sounds kind of like a "SHOULD"... > > > > > > > > The example response header contains the following JSON document: > > > > > > > > I think this is the JOSE header in the HTTP response (body), not the > > > > (HTTP) response header. > > > > > > > > Section 8.1 > > > > > > > > As an alternative approach, such an attack can be prevented like > any > > > > other token substitution attack by restricting the audience of the > > > > > > > > I'd suggest avoiding describing these as "alternatives"; they seem > more > > > > like complementary approaches as part of a defense-in-depth solution > > > > (especially since we are basically mandating both of them). > > > > > > > > "aud" value set to the resource server's identifier. Any recipient > > > > of an JWT MUST check these values in order to detect substitution > > > > attacks. > > > > > > > > This "MUST" might be out of place -- this is a requirement from RFC > > > > 7519, and not an attempt by this document to make new requirements on > > > > the behavior of all JWT consumers (if it was, that would be a DISCUSS > > > > point!). > > > > > > > > Resource servers MUST additionally apply the countermeasures > against > > > > replay as described in [I-D.ietf-oauth-security-topics], section > 3.2. > > > > > > > > In a similar vein, which set of resources servers is this normative > > > > "MUST" intended to be binding upon? > > > > > > > > Section 9 > > > > > > > > In any case, the AS MUST ensure that the scope of the legal basis > is > > > > enforced throughout the whole process. The AS MUST retain the > scope > > > > of the legal basis with the access token, e.g. in the scope value, > > > > and the AS MUST determine the data a resource server is allowed to > > > > receive based on the resource server's identity and suitable token > > > > data, e.g. the scope value. > > > > > > > > I suspect I'm just being dense, but could you walk me through how the > > > > access token "scope" value can encode the legal basis for data > > transfer? > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Sun, 1 Mar 2020 20:38:45 -0700 > > From: David Waite <da...@alkaline-solutions.com> > > To: Andrii Deinega <andrii.dein...@gmail.com> > > Cc: Bill Jung <bjung=40pingidentity....@dmarc.ietf.org>, > > oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > > Refresh token? > > Message-ID: > > <c0c40a3e-2455-4c86-b504-ab18f3197...@alkaline-solutions.com> > > Content-Type: text/plain; charset=us-ascii > > > > I would expect the AS to invalidate the refresh token in this case, which > > would not require a refresh token mode nor necessarily any signaling back > > to the resource. > > > > -DW > > > > > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.dein...@gmail.com> > > wrote: > > > > > > Hello Bill, > > > > > > I'm just thinking out loud about possible scenarios for a protected > > > resource here... It may decide to revoke a refresh token if a client > > > application tried to use it instead of an access token when the > > > protected resource is paranoid about security. In order to do that an > > > introspection response should include a non-standard parameter which > > > indicates that the requested token is refresh_token. > > > > > > A user of the introspection endpoint should rely only on a value of > > > the active parameter (which is a boolean indicator) of the endpoint > > > response. This applies to both types of tokens. Note, the expiration > > > date, as well as other parameters, are defined as optional in the > > > specification. Both token types can be revoked before the expiration > > > date comes even if this parameter is presented as part of the > > > response. In my opinion, there are a number of reasons why this check > > > (for a refresh token) can be useful on the client application side. > > > > > > -- > > > Regards, > > > Andrii > > > > > > > > > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > > > <bjung=40pingidentity....@dmarc.ietf.org> wrote: > > >> > > >> Hello, hopefully I am using the right email address. > > >> > > >> Simply put, can this spec be enhanced to clarify "Who can use the > > introspection endpoint for a refresh token? A resource provider or a > client > > app or both?" > > >> > > >> RFC7662 clearly mentions that the user of introspection endpoint is a > > 'protected resource' and that makes sense for an access token. If we > allow > > this to client apps, it'll give unnecessary token information to them. > > >> However, the spec also mentions that refresh tokens can also be used > > against the endpoint. > > >> In case of refresh tokens, user of the endpoint should be a client app > > because refresh tokens are used by clients to get another access token. > > (Cannot imagine how/why a resource server would introspect a refresh > token) > > >> > > >> Is it correct to assume that the endpoint should be allowed to client > > apps if they want to examine refresh token's expiry time? Then the RFC > > should clearly mention it. > > >> > > >> Thanks in advance. > > >> > > >> <Details from the spec> > > >> In https://tools.ietf.org/html/rfc7662 > > >> In '1. Introduction' section says, > > >> "This specification defines a protocol that allows authorized > > >> protected resources to query the authorization server to determine > > >> the set of metadata for a given token that was presented to them by > > >> an OAuth 2.0 client." > > >> Above makes clear that user of the endpoint is a "protected resource". > > >> > > >> And under 'token' in '2.1. Introspection Request' section says, > > >> "For refresh tokens, > > >> this is the "refresh_token" value returned from the token endpoint > > >> as defined in OAuth 2.0 [RFC6749], Section 5.1." > > >> So looks like a refresh token is allowed for this endpoint. > > >> > > >> > > >> Bill Jung > > >> Manager, Response Engineering > > >> bj...@pingidentity.com > > >> w: +1 604.697.7037 > > >> Connect with us: > > >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly > prohibited.. > > If you have received this communication in error, please notify the > sender > > immediately by e-mail and delete the message and any file attachments > from > > your computer. Thank you._______________________________________________ > > >> 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 > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Sun, 1 Mar 2020 21:11:40 -0800 > > From: Andrii Deinega <andrii.dein...@gmail.com> > > To: David Waite <da...@alkaline-solutions.com> > > Cc: Bill Jung <bjung=40pingidentity....@dmarc.ietf.org>, > > oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > > Refresh token? > > Message-ID: > > <CALkShct=sYSq-HoG=yMiV2BqT8+F= > > gnej+p2ggfd87fv1oq...@mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > How would the authorization server know who actually uses the > > introspection endpoint assuming that a protected resource and a client > > application use the same credentials (client_id and client_secret)? > > > > Regards, > > Andrii > > > > On Sun, Mar 1, 2020 at 7:38 PM David Waite <da...@alkaline-solutions.com > > > > wrote: > > > > > > I would expect the AS to invalidate the refresh token in this case, > > which would not require a refresh token mode nor necessarily any > signaling > > back to the resource. > > > > > > -DW > > > > > > > On Mar 1, 2020, at 12:12 AM, Andrii Deinega < > andrii.dein...@gmail.com> > > wrote: > > > > > > > > Hello Bill, > > > > > > > > I'm just thinking out loud about possible scenarios for a protected > > > > resource here... It may decide to revoke a refresh token if a client > > > > application tried to use it instead of an access token when the > > > > protected resource is paranoid about security. In order to do that an > > > > introspection response should include a non-standard parameter which > > > > indicates that the requested token is refresh_token. > > > > > > > > A user of the introspection endpoint should rely only on a value of > > > > the active parameter (which is a boolean indicator) of the endpoint > > > > response. This applies to both types of tokens. Note, the expiration > > > > date, as well as other parameters, are defined as optional in the > > > > specification. Both token types can be revoked before the expiration > > > > date comes even if this parameter is presented as part of the > > > > response. In my opinion, there are a number of reasons why this check > > > > (for a refresh token) can be useful on the client application side. > > > > > > > > -- > > > > Regards, > > > > Andrii > > > > > > > > > > > > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > > > > <bjung=40pingidentity....@dmarc.ietf.org> wrote: > > > >> > > > >> Hello, hopefully I am using the right email address. > > > >> > > > >> Simply put, can this spec be enhanced to clarify "Who can use the > > introspection endpoint for a refresh token? A resource provider or a > client > > app or both?" > > > >> > > > >> RFC7662 clearly mentions that the user of introspection endpoint is > a > > 'protected resource' and that makes sense for an access token. If we > allow > > this to client apps, it'll give unnecessary token information to them. > > > >> However, the spec also mentions that refresh tokens can also be used > > against the endpoint. > > > >> In case of refresh tokens, user of the endpoint should be a client > > app because refresh tokens are used by clients to get another access > token. > > (Cannot imagine how/why a resource server would introspect a refresh > token) > > > >> > > > >> Is it correct to assume that the endpoint should be allowed to > client > > apps if they want to examine refresh token's expiry time? Then the RFC > > should clearly mention it. > > > >> > > > >> Thanks in advance. > > > >> > > > >> <Details from the spec> > > > >> In https://tools.ietf.org/html/rfc7662 > > > >> In '1. Introduction' section says, > > > >> "This specification defines a protocol that allows authorized > > > >> protected resources to query the authorization server to determine > > > >> the set of metadata for a given token that was presented to them by > > > >> an OAuth 2.0 client." > > > >> Above makes clear that user of the endpoint is a "protected > resource". > > > >> > > > >> And under 'token' in '2.1. Introspection Request' section says, > > > >> "For refresh tokens, > > > >> this is the "refresh_token" value returned from the token endpoint > > > >> as defined in OAuth 2.0 [RFC6749], Section 5.1." > > > >> So looks like a refresh token is allowed for this endpoint. > > > >> > > > >> > > > >> Bill Jung > > > >> Manager, Response Engineering > > > >> bj...@pingidentity.com > > > >> w: +1 604.697.7037 > > > >> Connect with us: > > > >> > > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly > prohibited.. > > If you have received this communication in error, please notify the > sender > > immediately by e-mail and delete the message and any file attachments > from > > your computer. Thank you._______________________________________________ > > > >> 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 > > > > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Sun, 1 Mar 2020 22:33:22 -0700 > > From: David Waite <da...@alkaline-solutions.com> > > To: Andrii Deinega <andrii.dein...@gmail.com> > > Cc: Bill Jung <bjung=40pingidentity....@dmarc.ietf.org>, > > oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > > Refresh token? > > Message-ID: > > <d3d1bfb8-ce54-4e48-a8b9-45e01ed2b...@alkaline-solutions.com> > > Content-Type: text/plain; charset=us-ascii > > > > On Mar 1, 2020, at 10:11 PM, Andrii Deinega <andrii.dein...@gmail.com> > > wrote: > > > > > > How would the authorization server know who actually uses the > > > introspection endpoint assuming that a protected resource and a client > > > application use the same credentials (client_id and client_secret)? > > > > In the external context, you have a client accessing a protected resource > > with an access token. The client should treat the token as opaque, and > > RFC7662 makes no allowances for that client to introspect its tokens. > > > > If you control both the client and protected resource, you may decide to > > short-cut and have them share credentials. However, the client logic > still > > should never be introspecting the tokens. > > > > The security considerations also say that you must prove the > > authentication of the protected resource, which I have interpreted to > mean > > that access tokens used to authorize the call to the introspection > endpoint > > must be issued to a confidential client - public clients cannot protect > > credentials to perform an authentication. You want to limit introspection > > to prevent denial of service and probing attacks, and to limit the amount > > of information on viable attacks conveyed if someone steals a token. > > > > -DW > > > > > > > > Regards, > > > Andrii > > > > > > On Sun, Mar 1, 2020 at 7:38 PM David Waite < > da...@alkaline-solutions.com> > > wrote: > > >> > > >> I would expect the AS to invalidate the refresh token in this case, > > which would not require a refresh token mode nor necessarily any > signaling > > back to the resource. > > >> > > >> -DW > > >> > > >>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega < > andrii.dein...@gmail.com> > > wrote: > > >>> > > >>> Hello Bill, > > >>> > > >>> I'm just thinking out loud about possible scenarios for a protected > > >>> resource here... It may decide to revoke a refresh token if a client > > >>> application tried to use it instead of an access token when the > > >>> protected resource is paranoid about security. In order to do that an > > >>> introspection response should include a non-standard parameter which > > >>> indicates that the requested token is refresh_token. > > >>> > > >>> A user of the introspection endpoint should rely only on a value of > > >>> the active parameter (which is a boolean indicator) of the endpoint > > >>> response. This applies to both types of tokens. Note, the expiration > > >>> date, as well as other parameters, are defined as optional in the > > >>> specification. Both token types can be revoked before the expiration > > >>> date comes even if this parameter is presented as part of the > > >>> response. In my opinion, there are a number of reasons why this check > > >>> (for a refresh token) can be useful on the client application side. > > >>> > > >>> -- > > >>> Regards, > > >>> Andrii > > >>> > > >>> > > >>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung > > >>> <bjung=40pingidentity....@dmarc.ietf.org> wrote: > > >>>> > > >>>> Hello, hopefully I am using the right email address. > > >>>> > > >>>> Simply put, can this spec be enhanced to clarify "Who can use the > > introspection endpoint for a refresh token? A resource provider or a > client > > app or both?" > > >>>> > > >>>> RFC7662 clearly mentions that the user of introspection endpoint is > a > > 'protected resource' and that makes sense for an access token. If we > allow > > this to client apps, it'll give unnecessary token information to them. > > >>>> However, the spec also mentions that refresh tokens can also be used > > against the endpoint. > > >>>> In case of refresh tokens, user of the endpoint should be a client > > app because refresh tokens are used by clients to get another access > token. > > (Cannot imagine how/why a resource server would introspect a refresh > token) > > >>>> > > >>>> Is it correct to assume that the endpoint should be allowed to > client > > apps if they want to examine refresh token's expiry time? Then the RFC > > should clearly mention it. > > >>>> > > >>>> Thanks in advance. > > >>>> > > >>>> <Details from the spec> > > >>>> In https://tools.ietf.org/html/rfc7662 > > >>>> In '1. Introduction' section says, > > >>>> "This specification defines a protocol that allows authorized > > >>>> protected resources to query the authorization server to determine > > >>>> the set of metadata for a given token that was presented to them by > > >>>> an OAuth 2.0 client." > > >>>> Above makes clear that user of the endpoint is a "protected > resource". > > >>>> > > >>>> And under 'token' in '2.1. Introspection Request' section says, > > >>>> "For refresh tokens, > > >>>> this is the "refresh_token" value returned from the token endpoint > > >>>> as defined in OAuth 2.0 [RFC6749], Section 5.1." > > >>>> So looks like a refresh token is allowed for this endpoint. > > >>>> > > >>>> > > >>>> Bill Jung > > >>>> Manager, Response Engineering > > >>>> bj...@pingidentity.com > > >>>> w: +1 604.697.7037 > > >>>> Connect with us: > > >>>> > > >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly > prohibited.. > > If you have received this communication in error, please notify the > sender > > immediately by e-mail and delete the message and any file attachments > from > > your computer. Thank you._______________________________________________ > > >>>> 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 > > >> > > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > ------------------------------ > > > > End of OAuth Digest, Vol 137, Issue 4 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200312/c2fee232/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 137, Issue 41 > ************************************** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
