Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 4

isaac ajonibode <ajofoluventures@gmail.com> Thu, 12 March 2020 14:26 UTC

Return-Path: <ajofoluventures@gmail.com>
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 <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; Thu, 12 Mar 2020 07:26:04 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id n6so3800340vsc.3 for <oauth@ietf.org>; 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: <mailman.2252.1583127209.10874.oauth@ietf.org>
In-Reply-To: <mailman.2252.1583127209.10874.oauth@ietf.org>
From: isaac ajonibode <ajofoluventures@gmail.com>
Date: Thu, 12 Mar 2020 15:25:47 +0100
Message-ID: <CAChWCXrUKAJgMt-_2ggU0iC2RwgS9=FZWXkH_KHxtY_mwHYbeQ@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f11a6305a0a92197"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/o4T76nu32ivmqdNEJ0CsWLe5qrk>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2020 14:26:10 -0000

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 , <oauth-request@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-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 <kaduk@mit.edu>
> To: Torsten Lodderstedt <torsten@lodderstedt.net>
> Cc: The IESG <iesg@ietf.org>rg>,
>         draft-ietf-oauth-jwt-introspection-response@ietf.org,
>         oauth-chairs@ietf.org, oauth <oauth@ietf.org>rg>, Rifaat Shekh-Yusef
>         <rifaat.ietf@gmail.com>om>, Roman Danyliw <rdd@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.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 <david@alkaline-solutions.com>
> To: Andrii Deinega <andrii.deinega@gmail.com>
> Cc: Bill Jung <bjung=40pingidentity.com@dmarc.ietf.org>rg>,
>         oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
>         Refresh token?
> Message-ID:
>         <C0C40A3E-2455-4C86-B504-AB18F31975D9@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.deinega@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.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 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
> >> 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 <andrii.deinega@gmail.com>
> To: David Waite <david@alkaline-solutions.com>
> Cc: Bill Jung <bjung=40pingidentity.com@dmarc.ietf.org>rg>,
>         oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
>         Refresh token?
> Message-ID:
>         <CALkShct=sYSq-HoG=yMiV2BqT8+F=
> 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 <david@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.deinega@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.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 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
> > >> 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 <david@alkaline-solutions.com>
> To: Andrii Deinega <andrii.deinega@gmail.com>
> Cc: Bill Jung <bjung=40pingidentity.com@dmarc.ietf.org>rg>,
>         oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
>         Refresh token?
> Message-ID:
>         <D3D1BFB8-CE54-4E48-A8B9-45E01ED2B637@alkaline-solutions.com>
> Content-Type: text/plain;       charset=us-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
> 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 <david@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.deinega@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.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 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
> >>>> 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
> *************************************
>