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

[isaac ajonibode <[e-mail]>]

Subscribe me.I didn't understood all the postings since inception of
including my mailing address

Isaac O.Ajonibode
C.Director CBMC Nigeria
[e-mail]
www.cbmcint.com/Nigeria
[phone]

FOUNDER/CEO
AJOFOLU VENTURES INT'L LTD
[e-mail]
[phone]
2 Corinthians 5:20


On Thu, 12 Mar 2020, 15:26 , <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> 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
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: OAuth Digest, Vol 137, Issue 4 (isaac ajonibode)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Mar 2020 15:25:47 +0100
> From: isaac ajonibode <[e-mail]>
> To: [e-mail]
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 137, Issue 4
> Message-ID:
>         <CAChWCXrUKAJgMt-_2ggU0iC2RwgS9=
> [e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Please unsubscribe me from your mailing list
>
> Isaac O.Ajonibode
> C.Director CBMC Nigeria
> [e-mail]
> www.cbmcint.com/Nigeria
> [phone]
>
> FOUNDER/CEO
> AJOFOLU VENTURES INT'L LTD
> [e-mail]
> [phone]
> 2 Corinthians 5:20
>
>
> On Mon, 2 Mar 2020, 06:33 , <[e-mail]> wrote:
>
> > Send OAuth mailing list submissions to
> >         [e-mail]
> >
> > 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
> >         [e-mail]
> >
> > You can reach the person managing the list at
> >         [e-mail]
> >
> > 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 <[e-mail]>
> > To: Torsten Lodderstedt <[e-mail]>
> > Cc: The IESG <[e-mail]>,
> >         [e-mail],
> >         [e-mail], oauth <[e-mail]>, Rifaat
> Shekh-Yusef
> >         <[e-mail]>, Roman Danyliw <[e-mail]>
> > Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> >         draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and
> >         COMMENT)
> > Message-ID: <[e-mail]>
> > 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 <
> > [e-mail]> 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 <[e-mail]>
> > To: Andrii Deinega <[e-mail]>
> > Cc: Bill Jung <bjung=[e-mail]>,
> >         [e-mail]
> > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
> >         Refresh token?
> > Message-ID:
> >         <[e-mail]>
> > 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 <[e-mail]>
> > 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=[e-mail]> 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
> > >> [e-mail]
> > >> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Sun, 1 Mar 2020 21:11:40 -0800
> > From: Andrii Deinega <[e-mail]>
> > To: David Waite <[e-mail]>
> > Cc: Bill Jung <bjung=[e-mail]>,
> >         [e-mail]
> > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
> >         Refresh token?
> > Message-ID:
> >         <CALkShct=sYSq-HoG=yMiV2BqT8+F=
> > [e-mail]>
> > 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 <[e-mail]
> >
> > 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 <
> [e-mail]>
> > 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=[e-mail]> 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
> > > >> [e-mail]
> > > >> 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
> > > >> [e-mail]
> > > >> https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Sun, 1 Mar 2020 22:33:22 -0700
> > From: David Waite <[e-mail]>
> > To: Andrii Deinega <[e-mail]>
> > Cc: Bill Jung <bjung=[e-mail]>,
> >         [e-mail]
> > Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 :
> >         Refresh token?
> > Message-ID:
> >         <[e-mail]>
> > Content-Type: text/plain;       charset=us-ascii
> >
> > On Mar 1, 2020, at 10:11 PM, Andrii Deinega <[e-mail]>
> > 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 <
> [e-mail]>
> > 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 <
> [e-mail]>
> > 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=[e-mail]> 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
> > >>>> [e-mail]
> > >>>> 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
> > >>>> [e-mail]
> > >>>> https://www.ietf.org/mailman/listinfo/oauth
> > >>>
> > >>> _______________________________________________
> > >>> OAuth mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > ------------------------------
> >
> > End of OAuth Digest, Vol 137, Issue 4
> > *************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200312/c2fee232/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 137, Issue 41
> **************************************
>