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

[Rifaat Shekh-Yusef <[e-mail]>]

Visit the following link to subscribe:
https://www.ietf.org/mailman/listinfo/oauth

Regards,
 Rifaat


On Thu, Mar 12, 2020 at 11:46 AM isaac ajonibode <[e-mail]>
wrote:

> 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]..org
>> <[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]..org
>> <[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] <[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]..org
>> <[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
>> **************************************
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>