Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752143A0A1B for ; Thu, 12 Mar 2020 07:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcb3xaImpCYB for ; Thu, 12 Mar 2020 07:26:05 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6CF3A0A1C for ; Thu, 12 Mar 2020 07:26:04 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id n6so3800340vsc.3 for ; Thu, 12 Mar 2020 07:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qUn7beol69rZxhdEPtPKKOf7eirH/XtgW1+JyKEP4E8=; b=nNN+iFkEUBfEpgCefCCD5TqfGWZ5oWu5d2szi6AaJu/G5hKb8CzOfhKNWqz58WZ/Wh aB3kWRP9Or4GvxrItEOpu7TIe8ysYTDu7LJLwcPV6JGyqTpqwCTkRyY1ILRlSwBWmGYZ AmSZIJ9Ka7OeSeDj27I5JLSyOsMpwd3NIulpxT7LHjdKGp/6q4i7pV9LuIzcGV8sw/dm AABuvXgQkX6jpPYYAFp8src1+syqjsaVpzQOyIM36jI0KUcU8QMag0CXDGiLx0O+LGPD cfiCzOWnTe0EHcmgUyUEstWq3uuWsCMirMIZhFur1FybqtUAGjv4M6EMZIqA1o2TeDwb xYuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qUn7beol69rZxhdEPtPKKOf7eirH/XtgW1+JyKEP4E8=; b=NkLbTRjDW4l9GGZD4PglTC58xyF3gOn+mmlSGr7BMeli1TaUOZmrfjDtLXPGHIAcNy HZYcuq4MPNOJwZWyRi+pZTOplQz39abLZgpLlTULgpYia5Ico2gbp/NJhtsBKIEtot8F 2ovs22vo1nh3LFf0y57ijf9DDW+thL30WvW1oVUpqHdwxFBw079e2E6waXT9u5j7jb+2 vKYUkk4SvPtRcaCxss4rXaOp8iruVyrxMNkA9UKQEORQy5Bjp7Vq+7HGJRCNcR0IQcrQ sr8rcXkaDpsDyuf+nTBL+srJPbfo8vyk4rjTbGLnTFE6lYMukrLz6NftyHs6sK45jTqu R/GA== X-Gm-Message-State: ANhLgQ0Hn3pzw3dVNz4xs6ZPc5u07EhNCNXGF1VdcEZH2SzDYPZ1UMzb EagIa5k01QRwmkaiWAvQ8cLdGs9o0ypcbtw69hgvaw== X-Google-Smtp-Source: =?utf-8?q?ADFU+vtERIp7/XaBMLGrXOIsQVeK0cllkLukAZGD8dJB?= =?utf-8?q?1OdL5yLUYf1r/q+PO4ZqKo+O7TlO8qWPHL+DFfViyWbkgCs=3D?= X-Received: by 2002:a67:e18c:: with SMTP id e12mr5362182vsl.16.1584023162917; Thu, 12 Mar 2020 07:26:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: isaac ajonibode Date: Thu, 12 Mar 2020 15:25:47 +0100 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f11a6305a0a92197" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 4 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 14:26:10 -0000 --000000000000f11a6305a0a92197 Content-Type: text/plain; charset="UTF-8" Please unsubscribe me from your mailing list Isaac O.Ajonibode C.Director CBMC Nigeria cbmcnigeria2014@gmail.com www.cbmcint.com/Nigeria +2347087552127 FOUNDER/CEO AJOFOLU VENTURES INT'L LTD ajofoluventures@gmail.com +2348164286235 2 Corinthians 5:20 On Mon, 2 Mar 2020, 06:33 , 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-request@ietf.org > > You can reach the person managing the list at > oauth-owner@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 > To: Torsten Lodderstedt > Cc: The IESG , > draft-ietf-oauth-jwt-introspection-response@ietf.org, > oauth-chairs@ietf.org, oauth , Rifaat Shekh-Yusef > , Roman Danyliw > Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on > draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and > COMMENT) > Message-ID: <20200302010341.GZ98042@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 < > noreply@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 > To: Andrii Deinega > Cc: Bill Jung , > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > Refresh token? > Message-ID: > > 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 > 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 > > 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. > >> > >>
> >> 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 > >> bjung@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 > To: David Waite > Cc: Bill Jung , > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > Refresh token? > Message-ID: > gnej+p2GgFD87FV1OQu3w@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 > 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 > 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 > > > 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. > > >> > > >>
> > >> 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 > > >> bjung@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 > To: Andrii Deinega > Cc: Bill Jung , > oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : > Refresh token? > Message-ID: > > Content-Type: text/plain; charset=us-ascii > > On Mar 1, 2020, at 10:11 PM, Andrii Deinega > 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 > 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 > 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 > >>> 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. > >>>> > >>>>
> >>>> 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 > >>>> bjung@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 > ************************************* > --000000000000f11a6305a0a92197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please unsubscribe=C2=A0me from your mailing list

=
Isaac O.Ajonibode
C.Director CBM= C Nigeria
cbmcnigeria2014@= gmail.com
www.cbmcint.com= /Nigeria
+2347087552127

FOUNDER/CEO
AJOFOLU VENTURES INT= 'L LTD
ajofoluventures@= gmail.com
+2348164286235
2 Corinthians 5:20
=C2=A0=C2=A0=C2= =A0

On Mon, 2 Mar 2020, 06:33 , <oauth-request@ietf.org> wrote:
Send OAuth mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Benjamin Kaduk's Discuss on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-jwt-introspection-response-08: (with = DISCUSS and
=C2=A0 =C2=A0 =C2=A0 COMMENT) (Benjamin Kaduk)
=C2=A0 =C2=A02. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh toke= n?
=C2=A0 =C2=A0 =C2=A0 (David Waite)
=C2=A0 =C2=A03. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh toke= n?
=C2=A0 =C2=A0 =C2=A0 (Andrii Deinega)
=C2=A0 =C2=A04. Re: OAuth 2.0 Token Introspection in RFC7662 : Refresh toke= n?
=C2=A0 =C2=A0 =C2=A0 (David Waite)


----------------------------------------------------------------------

Message: 1
Date: Sun, 1 Mar 2020 17:03:41 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: The IESG <iesg@ietf.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oa= uth-jwt-introspection-response@ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-chairs@ietf.org, oauth <oauth@ietf.= org>, Rifaat Shekh-Yusef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rifaat.ietf@gmail.com>, Roman Dan= yliw <rdd@cert.org>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-jwt-introspection-response-08:= (with DISCUSS and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COMMENT)
Message-ID: <20200302010341.GZ98042@kduck.mit.edu&= gt;
Content-Type: text/plain; charset=3Dutf-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 <norep= ly@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 cu= t 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 her= e:
> > ht= tps://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 th= e
> > substantive issues!=C2=A0 I have a few points remaining on the -0= 8 text but I
> > think there are more localized issues to resolve.
> >
> > Can IANA please confirm that the new allocations in the -08 have<= br> > > received appropriate Expert (e.g., media type) review?=C2=A0 I se= e some
> > updates in the datatracker history relating to the -08 but nothin= g 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 in= trospection response
> > are compatible with the RFC 7519 definition.=C2=A0 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 obje= ct"),
> > and we admit at least the possibility of "active" and &= quot;iat" changing.
>
> I think the key word is ?accidentally?. This spec causes the AS to pur= posefully issue JWTs with the same ?jti? in order to allow replay detection= with respect to the introspected access token. ?iat? is changed in order t= o give the RS an indication and proof when the introspection response was m= inted 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 &qu= ot;of
course you wouldn't deliberately reuse a token identifier".=C2=A0 = This stance
seems to supported by "[t]he 'jti' (JWT ID) claim provides a u= nique
identifier for the JWT".=C2=A0 It's really hard for me to read tha= t 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.=C2=A0 What am I supposed to inter= pret
"the JWT" as meaning if not the actual encoded artifact?

> So I don?t see issues regarding RFC 7519.
>
> >
> > Section 5 says that:
> >
> >=C2=A0 =C2=A0If the access token is considered active, it MUST con= tain the claims
> >=C2=A0 =C2=A0"iss" and "aud" in order to preve= nt misuse of the JWT as an ID or
> >=C2=A0 =C2=A0access 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.=C2=A0 Shouldn't the
> > "iss"+"aud" requirements be unconditional? >
> Introspection responses for inactive tokens won?t contain any data exc= ept ?active?:false. I don?t see how they could be misused and therefore thi= nk the text is ok.

Could you give me a pointer where in the text it says that if "active&= quot; is
false, no other claims are present?=C2=A0 ("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
> >
> >=C2=A0 =C2=A0To support encrypted token introspection response JWT= s, the
> >=C2=A0 =C2=A0authorization server MUST also be provided with the r= espective
> >=C2=A0 =C2=A0resource server encryption keys and algorithms.
> >
> > IIRC, based on some list discussion this text was going to be twe= aked to
> > avoid implying that JWE is mandatory.=C2=A0 (Unfortunately, this = is the
> > thread that evolved into "client certs and TLS Terminating R= everse
> > Proxies", so it's hard to be sure whether I saw any othe= r followups.)
> >
> >=C2=A0 =C2=A0The AS MUST restrict the use of client credentials by= a RS to the
> >=C2=A0 =C2=A0calls it requires, e.g. the AS MAY restrict such a cl= ient to call the
> >=C2=A0 =C2=A0token introspection endpoint only.=C2=A0 How the AS i= mplements this
> >=C2=A0 =C2=A0restriction is beyond the scope of this specification= .
> >
> > This should probably be clarified a bit more, in the context of &= quot;client
> > credentials tend to be used by privileged, fixed endpoints, and t= he
> > default may just be to allow them all access to all endpoints&quo= t;.=C2=A0 Right
> > now it's not clear what's being restricted (and who "= ;it" is that
> > requires calls)
> >
> > Section 5
> >
> >=C2=A0 =C2=A0This specification registers the "application/to= ken-
> >=C2=A0 =C2=A0introspection+jwt" media type, which is used as = value of the "typ"
> >=C2=A0 =C2=A0header parameter of the JWT to indicate that the payl= oad is a token
> >=C2=A0 =C2=A0introspection response.
> >
> > Do we also want to note that checking 'jti' is not mandat= ory and so this
> > does not necessarily provide full protection?=C2=A0 (I guess Sect= ion 8.1
> > covers this in more detail.)
> >
> >=C2=A0 =C2=A0The value of the "aud" claims MUST identify= the resource server
> >=C2=A0 =C2=A0receiving 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 "cli= ent_id" that an RS
> > might be using (as obtained from dynamic registration)?
> > Does this value need to be different from the audience that is us= ed in
> > access tokens for which this RS is the audience?=C2=A0 (Should it= be the
> > same?)=C2=A0 My instincts lean towards "different" but = I would like broader
> > input.
> >
> >=C2=A0 =C2=A0exp=C2=A0 =C2=A0 =C2=A0The "exp" claim indi= cates when the access token passed in the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0introspection request wil= l 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 processin= g",
> > though upon further examination the distinction is not quite so l= arge.
> > That is, it's in effect saying that the introspection respons= e should
> > not be accepted for processing after the base token has expired, = which
> > usually makes sense.=C2=A0 There is a bit of a complication, thou= gh, in that
> > the "active" claim implies that we might still have RSe= s that plan to
> > use the introspection response after the "exp" date has= passed, which
> > sounds a lot like a DISCUSS-level internal inconsistency.
> >
> >=C2=A0 =C2=A0If possible, the AS MUST narrow down the "scope&= quot; value to the scopes
> >=C2=A0 =C2=A0relevant to the particular RS.
> >
> > This sounds kind of like a "SHOULD"...
> >
> >=C2=A0 =C2=A0The example response header contains the following JS= ON document:
> >
> > I think this is the JOSE header in the HTTP response (body), not = the
> > (HTTP) response header.
> >
> > Section 8.1
> >
> >=C2=A0 =C2=A0As an alternative approach, such an attack can be pre= vented like any
> >=C2=A0 =C2=A0other token substitution attack by restricting the au= dience of the
> >
> > I'd suggest avoiding describing these as "alternatives&q= uot;; they seem more
> > like complementary approaches as part of a defense-in-depth solut= ion
> > (especially since we are basically mandating both of them).
> >
> >=C2=A0 =C2=A0"aud" value set to the resource server'= s identifier.=C2=A0 Any recipient
> >=C2=A0 =C2=A0of an JWT MUST check these values in order to detect = substitution
> >=C2=A0 =C2=A0attacks.
> >
> > This "MUST" might be out of place -- this is a requirem= ent from RFC
> > 7519, and not an attempt by this document to make new requirement= s on
> > the behavior of all JWT consumers (if it was, that would be a DIS= CUSS
> > point!).
> >
> >=C2=A0 =C2=A0Resource servers MUST additionally apply the counterm= easures against
> >=C2=A0 =C2=A0replay as described in [I-D.ietf-oauth-security-topic= s], section 3.2.
> >
> > In a similar vein, which set of resources servers is this normati= ve
> > "MUST" intended to be binding upon?
> >
> > Section 9
> >
> >=C2=A0 =C2=A0In any case, the AS MUST ensure that the scope of the= legal basis is
> >=C2=A0 =C2=A0enforced throughout the whole process.=C2=A0 The AS M= UST retain the scope
> >=C2=A0 =C2=A0of the legal basis with the access token, e.g. in the= scope value,
> >=C2=A0 =C2=A0and the AS MUST determine the data a resource server = is allowed to
> >=C2=A0 =C2=A0receive based on the resource server's identity a= nd suitable token
> >=C2=A0 =C2=A0data, 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 f= or data transfer?
> >
> >
> >
>




------------------------------

Message: 2
Date: Sun, 1 Mar 2020 20:38:45 -0700
From: David Waite <david@alkaline-solutions.com>
To: Andrii Deinega <andrii.deinega@gmail.com>
Cc: Bill Jung <bjung=3D40pingidentity.com@dmarc.ietf.org<= /a>>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Refresh token?
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <C0= C40A3E-2455-4C86-B504-AB18F31975D9@alkaline-solutions.com>
Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3Dus-ascii

I would expect the AS to invalidate the refresh token in this case, which w= ould 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.deinega@g= mail.com> wrote:
>
> Hello Bill,
>
> I'm just thinking out loud about possible scenarios for a protecte= d
> 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<= br> > 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<= br> > (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=3D40pingidentity.com@dmarc.ietf.org> w= rote:
>>
>> 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 c= lient app or both?"
>>
>> RFC7662 clearly mentions that the user of introspection endpoint i= s a 'protected resource' and that makes sense for an access token. = If we allow this to client apps, it'll give unnecessary token informati= on to them.
>> However, the spec also mentions that refresh tokens can also be us= ed 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 toke= n)
>>
>> Is it correct to assume that the endpoint should be allowed to cli= ent 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.=C2=A0 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 b= y
>> an OAuth 2.0 client."
>> Above makes clear that user of the endpoint is a "protected r= esource".
>>
>> And under 'token' in '2.1.=C2=A0 Introspection Request= ' section says,
>> "For refresh tokens,
>> this is the "refresh_token" value returned from the toke= n 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
>> bjung@pingidentity.com
>> w: +1 604.697.7037
>> Connect with us:
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and pr= ivileged material for the sole use of the intended recipient(s). Any review= , use, distribution or disclosure by others is strictly prohibited..=C2=A0 = 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/oau= th



------------------------------

Message: 3
Date: Sun, 1 Mar 2020 21:11:40 -0800
From: Andrii Deinega <andrii.deinega@gmail.com>
To: David Waite <david@alkaline-solutions.com>
Cc: Bill Jung <bjung=3D40pingidentity.com@dmarc.ietf.org<= /a>>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Refresh token?
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CALkShct=3DsYSq-HoG=3DyMiV2BqT8+F=3Dgnej+p2GgFD87FV1OQu3w@mail.gmail.com>
Content-Type: text/plain; charset=3D"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 <david@alkaline-sol= utions.com> wrote:
>
> I would expect the AS to invalidate the refresh token in this case, wh= ich would not require a refresh token mode nor necessarily any signaling ba= ck to the resource.
>
> -DW
>
> > On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.dein= ega@gmail.com> wrote:
> >
> > Hello Bill,
> >
> > I'm just thinking out loud about possible scenarios for a pro= tected
> > resource here... It may decide to revoke a refresh token if a cli= ent
> > application tried to use it instead of an access token when the > > protected resource is paranoid about security. In order to do tha= t an
> > introspection response should include a non-standard parameter wh= ich
> > 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 endpoi= nt
> > response. This applies to both types of tokens. Note, the expirat= ion
> > date, as well as other parameters, are defined as optional in the=
> > specification. Both token types can be revoked before the expirat= ion
> > date comes even if this parameter is presented as part of the
> > response. In my opinion, there are a number of reasons why this c= heck
> > (for a refresh token) can be useful on the client application sid= e.
> >
> > --
> > Regards,
> > Andrii
> >
> >
> > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> > <bjung=3D40pingidentity.com@dmarc.ietf.org&= gt; wrote:
> >>
> >> Hello, hopefully I am using the right email address.
> >>
> >> Simply put, can this spec be enhanced to clarify "Who ca= n use the introspection endpoint for a refresh token? A resource provider o= r a client app or both?"
> >>
> >> RFC7662 clearly mentions that the user of introspection endpo= int is a 'protected resource' and that makes sense for an access to= ken. If we allow this to client apps, it'll give unnecessary token info= rmation 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 c= lient 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 t= o 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.=C2=A0 Introduction' section says,
> >> "This specification defines a protocol that allows autho= rized
> >> protected resources to query the authorization server to dete= rmine
> >> the set of metadata for a given token that was presented to t= hem by
> >> an OAuth 2.0 client."
> >> Above makes clear that user of the endpoint is a "protec= ted resource".
> >>
> >> And under 'token' in '2.1.=C2=A0 Introspection Re= quest' 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
> >> bjung@pingidentity.com
> >> w: +1 604.697.7037
> >> Connect with us:
> >>
> >> CONFIDENTIALITY NOTICE: This email may contain confidential a= nd privileged material for the sole use of the intended recipient(s). Any r= eview, use, distribution or disclosure by others is strictly prohibited..= =C2=A0 If you have received this communication in error, please notify the = sender immediately by e-mail and delete the message and any file attachment= s from your computer. Thank you.___________________________________________= ____
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/l= istinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinf= o/oauth
>



------------------------------

Message: 4
Date: Sun, 1 Mar 2020 22:33:22 -0700
From: David Waite <david@alkaline-solutions.com>
To: Andrii Deinega <andrii.deinega@gmail.com>
Cc: Bill Jung <bjung=3D40pingidentity.com@dmarc.ietf.org<= /a>>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Refresh token?
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <D3= D1BFB8-CE54-4E48-A8B9-45E01ED2B637@alkaline-solutions.com>
Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3Dus-ascii

On Mar 1, 2020, at 10:11 PM, Andrii Deinega <andrii.deinega@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 w= ith an access token. The client should treat the token as opaque, and RFC76= 62 makes no allowances for that client to introspect its tokens.

If you control both the client and protected resource, you may decide to sh= ort-cut and have them share credentials. However, the client logic still sh= ould 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 to= kens used to authorize the call to the introspection endpoint must be issue= d to a confidential client - public clients cannot protect credentials to p= erform 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 <david@alkalin= e-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 signalin= g back to the resource.
>>
>> -DW
>>
>>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega <andrii.d= einega@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 th= e
>>> 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 val= ue of
>>> the active parameter (which is a boolean indicator) of the end= point
>>> response. This applies to both types of tokens. Note, the expi= ration
>>> date, as well as other parameters, are defined as optional in = the
>>> specification. Both token types can be revoked before the expi= ration
>>> date comes even if this parameter is presented as part of the<= br> >>> response. In my opinion, there are a number of reasons why thi= s 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=3D40pingidentity.com@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 provide= r or a client app or both?"
>>>>
>>>> RFC7662 clearly mentions that the user of introspection en= dpoint is a 'protected resource' and that makes sense for an access= token. If we allow this to client apps, it'll give unnecessary token i= nformation to them.
>>>> However, the spec also mentions that refresh tokens can al= so 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 acce= ss token. (Cannot imagine how/why a resource server would introspect a refr= esh token)
>>>>
>>>> Is it correct to assume that the endpoint should be allowe= d to client apps if they want to examine refresh token's expiry time? T= hen the RFC should clearly mention it.
>>>>
>>>> Thanks in advance.
>>>>
>>>> <Details from the spec>
>>>> In https://tools.ietf.org/html/rfc766= 2
>>>> In '1.=C2=A0 Introduction' section says,
>>>> "This specification defines a protocol that allows au= thorized
>>>> protected resources to query the authorization server to d= etermine
>>>> the set of metadata for a given token that was presented t= o them by
>>>> an OAuth 2.0 client."
>>>> Above makes clear that user of the endpoint is a "pro= tected resource".
>>>>
>>>> And under 'token' in '2.1.=C2=A0 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
>>>> bjung@pingidentity.com
>>>> w: +1 604.697.7037
>>>> Connect with us:
>>>>
>>>> CONFIDENTIALITY NOTICE: This email may contain confidentia= l and privileged material for the sole use of the intended recipient(s). An= y review, use, distribution or disclosure by others is strictly prohibited.= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts 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/list= info/oauth
>>



------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 137, Issue 4
*************************************
--000000000000f11a6305a0a92197--