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 2E92F3A1924 for ; Fri, 28 Feb 2020 06:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 jvovHbPtLkav for ; Fri, 28 Feb 2020 06:55:08 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4CACE3A0B1E for ; Fri, 28 Feb 2020 06:55:04 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id dm3so3690173edb.1 for ; Fri, 28 Feb 2020 06:55:04 -0800 (PST) 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 :cc; bh=oLqzG0LkT9jxtKE59A0kruZ9OwZOTiX2uxvioYWJJE0=; b=mhzp7XgT6g7Nrs4ZvcLuItNXWOProphN04Ooi4G3FJayUjwaZpK4HQEpmuo8O9YIkV kmxvFW0SHMADTKEZ7KHB+hw4XKoI9vQ1GIQlAy6EB2WauUXgetjxkhti+U/zlMPn0sJS L10G3rOkXOXnTXcbIL8/yQCXfG6P7aVmZ8dZbf89PsgWkRebrOOyB7WVOwF7HEiF855m aditkIED52xytyLifdYeVAGss9NdQ9ax09zpuuQ5JEzw1pJuPaYzM27r/B/iMH0LkS2q mHHGkKXiJIqzghufG/WaRGjt1v/MdVZqbFA4saFE/9dn8tPoxyPVW95sSeALqCDVxbDs Hgug== 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:cc; bh=oLqzG0LkT9jxtKE59A0kruZ9OwZOTiX2uxvioYWJJE0=; b=rYgCA5fwA6UfmIMSC9TiahjPErGyajFzkwW7XgiReriSgXPoqXdQKjvXCB9U5B31I4 cEmXluGUZPX68VdK4y3qhdzLdQJw+aR5v2JFx2l6v1I24NOx5bbtTTOJHwOQTzEkwbuX 7YwowxJgn1DVU4XSudU7khwmi2CdgdCz2uXuqJh2mHlAD+URCmQSqXmaWaG9i1HnV+d1 8Qjizo5oxGVur4bbOmNFLB/YJr23fDAbI89ITewj8HSMFSkUOW9/RRBd2OoAmAAf6Ftd Tm/Yt0BsbOy1h0HsRsUPpmI6WzlnoogSULvUl0fyG5W9ukVuJc3fzM2gMKYsCGHSY7Ht Nq0w== X-Gm-Message-State: APjAAAVipUW+yHd8eaEexg7VyVHnD+pokXRt9WRcKSj4Qz3k0SMecJBI BCdTpQaxHs20IMe62YhnE1New9Nc31NjXt6FfK5u6nH8hT4= X-Google-Smtp-Source: APXvYqwS6CUildrjCFyGR0MP//0PLZNWBtDQz2tS5qLQwTWyhnzbgDn33YcY1y34aqC0hnG183kXBrMqP/QDcsU7tC4= X-Received: by 2002:aa7:d747:: with SMTP id a7mr4658223eds.82.1582901702763; Fri, 28 Feb 2020 06:55:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Fri, 28 Feb 2020 14:54:53 +0000 Message-ID: To: Bill Jung Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b535ba059fa405a0" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token? 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: Fri, 28 Feb 2020 14:55:10 -0000 --000000000000b535ba059fa405a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, In additional to Bill's query, the use of the term "protected resource" in the context of RFC7662 is quite confusing. As defined by RFC6749 (which RFC7662 defers to for definition of the terms), the term "protected resource" is defined as an "access-restricted resource" that a client can request. In the context of RFC7662, it doesn't make sense for an "access-restricted resource" to be making any requests to the introspection endpoints - surely it is the resource server that is the intended consumer of the introspection endpoints? This is also backed up by Section 4 (Security Considerations) of RFC7662 which reverts to using the term "resource server" as the consumer of the introspection endpoints. For example, in these quotes: "However, since resource servers using token introspection rely on the authorization server to determine the state of a token.." and "...the authorization server MUST determine whether or not the token can be used at the resource server making the introspection call" Apologies if I've misinterpreted something here, but if RFC7662 has a different meaning for the term "protected resource" from RFC6749 then it should be stated clearly within that document. I also agree with Bill's observation that it doesn't make sense for a refresh token to passed into an introspection request as a refresh token should only be accessible to the client and the authorization server (neither of which are intended consumers of the introspection endpoints). Many thanks, David Skaife On Fri, Feb 28, 2020 at 9: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 clie= nt > 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 allo= w > 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 toke= n) > > Is it correct to assume that the endpoint should be allowed to client app= s > 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 authorizedprotected > resources to query the authorization server to determinethe set of metada= ta > for a given token that was presented to them byan 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 endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."* > So looks like a refresh token is allowed for this endpoint. > > > [image: Ping Identity] > > Bill Jung > Manager, Response Engineering > bjung@pingidentity.com > w: +1 604.697.7037 > Connect with us: [image: Glassdoor logo] > [image: > LinkedIn logo] [image: twitter > logo] [image: facebook logo] > [image: youtube logo] > [image: Blog logo] > > > > > > *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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b535ba059fa405a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

In additional to Bill's query, = the use of the term "protected resource" in the context of RFC766= 2 is quite confusing. As defined by RFC6749 (which RFC7662 defers to for de= finition=C2=A0of the terms), the term "protected resource" is def= ined as an "access-restricted resource" that a client can request= . In the context of RFC7662, it doesn't make sense for an "access-= restricted resource" to be making any requests to the introspection en= dpoints - surely it is the resource server that is the intended consumer of= the introspection endpoints? This is also backed up by Section 4 (Security= Considerations) of RFC7662 which reverts to using the term "resource = server" as the consumer of the introspection endpoints.
For example= , in these quotes:
"However, since resource servers using token introspection rely on the= =C2=A0authoriza= tion server to determine the state of a token.." and
"...the=C2=A0authorization server MUST determine whe= ther or not the token can=C2=A0be used at the resource server making the introspection cal= l"

Apologies if I've misinterpreted something here, but if RFC7662 = has a different meaning for the term "protected resource" from RF= C6749 then it should be stated clearly within that document. I also agree w= ith Bill's observation that it doesn't make sense for a refresh tok= en to passed into an introspection request as a refresh token should only b= e accessible to the client and the authorization server (neither of which a= re intended consumers of the introspection endpoints).


Many thanks,
David Skaife

On Fri, Feb 28, 2020 at 9:59 AM = Bill Jung <bjung=3D= 40pingidentity.com@dmarc.ietf.org> wrote:
Hello, hopefully I am usi= ng the right email address.=C2=A0

Simply put, can t= his spec be enhanced to clarify "Who can use the introspection endpoin= t for a refresh token? A resource provider or a client app or both?"= =C2=A0

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 client app because refresh tokens are used by clie= nts to get another access token. (Cannot imagine how/why a resource server = would introspect a refresh token)

Is it correct to assume that the e= ndpoint should be allowed to client apps if they want to examine refresh to= ken's expiry time? Then the RFC should clearly mention it.

Than= ks in advance.=C2=A0

<Details from the spec>
In https://tools= .ietf.org/html/rfc7662
In '1.=C2=A0 Introduction' section sa= ys,
"This specification defines a protoc= ol that allows authorized
protected resources to query the authorization= server to determine
the set of metadata for a given token that was pres= ented to them by
an OAuth 2.0 client."
Above makes cl= ear that user of the endpoint is a "protected resource".

= And under 'token' in '2.1.=C2=A0 Introspection Request' sec= tion 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 look= s like a refresh token is allowed for this endpoint.=C2=A0


= = =
3D"Ping
Bill Jung
Manager, Response Engine= ering
bjung@pingidentity.com=
w: +1 604.697.7037
= =
Connect with us: 3D"Glassdoor = 3D"Linke= 3D"twitter 3D"facebook = =

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b535ba059fa405a0--