Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Filip Skokan]

Perhaps we should consider leaving the root level JWT claims as-is per JWT
and push the introspection response unmodified as if it was regular json
response to a JWT claim called "introspection". Since regular introspection
uses the same claim names as JWT this would get around all the conflicts.

Last time i brought it up the authors didn't want to consider it because of
existing implementations.

S pozdravem,
*Filip Skokan*


On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki  wrote:

> Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the
> same concerns in this mailing list about 6 months ago (on Sep. 4, 2019).
> RFC 8707 didn't exist then, though.
>
> *Re: [OAUTH-WG] Question regarding
> draft-ietf-oauth-jwt-introspection-response-05*
> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>
> A JWT puts both (a) information about itself and (b) other data in its
> payload part. When the "other data" have the same claim names as are used
> to express information about the JWT itself, conflicts happen.
>
> Also, it should be noted that Ben pointed out in other thread that the
> requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
> says "jti" is a unique identifier for the access token that MUST be stable
> for all introspection calls, contradicts the definition of "jti", which
> should be unique for each JWT.
>
> *Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)*
> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>
> draft-ietf-oauth-jwt-introspection-response needs to be modified to solve
> the conflicts.
>
> Taka
>
> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  > wrote:
>
>> Hello,
>>
>> I'm wondering if the following conflicts in "JWT Response for OAuth Token
>> Introspection" (draft 8
>> )
>> have already been pointed out.
>>
>> RFC 8707  (Resource Indicators for
>> OAuth 2.0) requires that 'aud' in an introspection response hold the values
>> of the 'resource' request parameters, whereas "JWT Response for OAuth Token
>> Introspection" says that 'aud' MUST identify the resource server receiving
>> the token introspection response. The definitions conflict.
>>
>> RFC 7662  (OAuth 2.0 Token
>> Introspection) requires that 'iat' in an introspection response indicate
>> when the access/refresh token was issued, whereas "JWT Response for OAuth
>> Token Introspection" says that 'iat' indicates when the introspection
>> response in JWT format was issued. The definitions conflict.
>>
>> Best Regards,
>> Takahiko Kawasaki
>> Authlete, Inc.
>>
>>
>>
>> ___
> 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

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Takahiko Kawasaki]

Thank you, Tatsuo Kudo, for showing me that Justin Richer expressed the
same concerns in this mailing list about 6 months ago (on Sep. 4, 2019).
RFC 8707 didn't exist then, though.

*Re: [OAUTH-WG] Question regarding
draft-ietf-oauth-jwt-introspection-response-05*
https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/

A JWT puts both (a) information about itself and (b) other data in its
payload part. When the "other data" have the same claim names as are used
to express information about the JWT itself, conflicts happen.

Also, it should be noted that Ben pointed out in other thread that the
requirement for "jti" in draft-ietf-oauth-jwt-introspection-response, which
says "jti" is a unique identifier for the access token that MUST be stable
for all introspection calls, contradicts the definition of "jti", which
should be unique for each JWT.

*Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)*
https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/

draft-ietf-oauth-jwt-introspection-response needs to be modified to solve
the conflicts.

Taka

On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki  wrote:

> Hello,
>
> I'm wondering if the following conflicts in "JWT Response for OAuth Token
> Introspection" (draft 8
> )
> have already been pointed out.
>
> RFC 8707  (Resource Indicators for
> OAuth 2.0) requires that 'aud' in an introspection response hold the values
> of the 'resource' request parameters, whereas "JWT Response for OAuth Token
> Introspection" says that 'aud' MUST identify the resource server receiving
> the token introspection response. The definitions conflict.
>
> RFC 7662  (OAuth 2.0 Token
> Introspection) requires that 'iat' in an introspection response indicate
> when the access/refresh token was issued, whereas "JWT Response for OAuth
> Token Introspection" says that 'iat' indicates when the introspection
> response in JWT format was issued. The definitions conflict.
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[David Waite]

On Mar 1, 2020, at 10:11 PM, Andrii Deinega  wrote:
> 
> How would the authorization server know who actually uses the
> introspection endpoint assuming that a protected resource and a client
> application use the same credentials (client_id and client_secret)?

In the external context, you have a client accessing a protected resource with 
an access token. The client should treat the token as opaque, and RFC7662 makes 
no allowances for that client to introspect its tokens.

If you control both the client and protected resource, you may decide to 
short-cut and have them share credentials. However, the client logic still 
should never be introspecting the tokens.

The security considerations also say that you must prove the authentication of 
the protected resource, which I have interpreted to mean that access tokens 
used to authorize the call to the introspection endpoint must be issued to a 
confidential client - public clients cannot protect credentials to perform an 
authentication. You want to limit introspection to prevent denial of service 
and probing attacks, and to limit the amount of information on viable attacks 
conveyed if someone steals a token.

-DW

> 
> Regards,
> Andrii
> 
> On Sun, Mar 1, 2020 at 7:38 PM David Waite  
> wrote:
>> 
>> I would expect the AS to invalidate the refresh token in this case, which 
>> would not require a refresh token mode nor necessarily any signaling back to 
>> the resource.
>> 
>> -DW
>> 
>>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega  
>>> wrote:
>>> 
>>> Hello Bill,
>>> 
>>> I'm just thinking out loud about possible scenarios for a protected
>>> resource here... It may decide to revoke a refresh token if a client
>>> application tried to use it instead of an access token when the
>>> protected resource is paranoid about security. In order to do that an
>>> introspection response should include a non-standard parameter which
>>> indicates that the requested token is refresh_token.
>>> 
>>> A user of the introspection endpoint should rely only on a value of
>>> the active parameter (which is a boolean indicator) of the endpoint
>>> response. This applies to both types of tokens. Note, the expiration
>>> date, as well as other parameters, are defined as optional in the
>>> specification. Both token types can be revoked before the expiration
>>> date comes even if this parameter is presented as part of the
>>> response. In my opinion, there are a number of reasons why this check
>>> (for a refresh token) can be useful on the client application side.
>>> 
>>> --
>>> Regards,
>>> Andrii
>>> 
>>> 
>>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
>>>  wrote:
 
 Hello, hopefully I am using the right email address.
 
 Simply put, can this spec be enhanced to clarify "Who can use the 
 introspection endpoint for a refresh token? A resource provider or a 
 client app or both?"
 
 RFC7662 clearly mentions that the user of introspection endpoint is a 
 'protected resource' and that makes sense for an access token. If we allow 
 this to client apps, it'll give unnecessary token information to them.
 However, the spec also mentions that refresh tokens can also be used 
 against the endpoint.
 In case of refresh tokens, user of the endpoint should be a client app 
 because refresh tokens are used by clients to get another access token. 
 (Cannot imagine how/why a resource server would introspect a refresh token)
 
 Is it correct to assume that the endpoint should be allowed to client apps 
 if they want to examine refresh token's expiry time? Then the RFC should 
 clearly mention it.
 
 Thanks in advance.
 
 
 In https://tools.ietf.org/html/rfc7662
 In '1.  Introduction' section says,
 "This specification defines a protocol that allows authorized
 protected resources to query the authorization server to determine
 the set of metadata for a given token that was presented to them by
 an OAuth 2.0 client."
 Above makes clear that user of the endpoint is a "protected resource".
 
 And under 'token' in '2.1.  Introspection Request' section says,
 "For refresh tokens,
 this is the "refresh_token" value returned from the token endpoint
 as defined in OAuth 2.0 [RFC6749], Section 5.1."
 So looks like a refresh token is allowed for this endpoint.
 
 
 Bill Jung
 Manager, Response Engineering
 bj...@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._

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Andrii Deinega]

How would the authorization server know who actually uses the
introspection endpoint assuming that a protected resource and a client
application use the same credentials (client_id and client_secret)?

Regards,
Andrii

On Sun, Mar 1, 2020 at 7:38 PM David Waite  wrote:
>
> I would expect the AS to invalidate the refresh token in this case, which 
> would not require a refresh token mode nor necessarily any signaling back to 
> the resource.
>
> -DW
>
> > On Mar 1, 2020, at 12:12 AM, Andrii Deinega  
> > wrote:
> >
> > Hello Bill,
> >
> > I'm just thinking out loud about possible scenarios for a protected
> > resource here... It may decide to revoke a refresh token if a client
> > application tried to use it instead of an access token when the
> > protected resource is paranoid about security. In order to do that an
> > introspection response should include a non-standard parameter which
> > indicates that the requested token is refresh_token.
> >
> > A user of the introspection endpoint should rely only on a value of
> > the active parameter (which is a boolean indicator) of the endpoint
> > response. This applies to both types of tokens. Note, the expiration
> > date, as well as other parameters, are defined as optional in the
> > specification. Both token types can be revoked before the expiration
> > date comes even if this parameter is presented as part of the
> > response. In my opinion, there are a number of reasons why this check
> > (for a refresh token) can be useful on the client application side.
> >
> > --
> > Regards,
> > Andrii
> >
> >
> > On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
> >  wrote:
> >>
> >> Hello, hopefully I am using the right email address.
> >>
> >> Simply put, can this spec be enhanced to clarify "Who can use the 
> >> introspection endpoint for a refresh token? A resource provider or a 
> >> client app or both?"
> >>
> >> RFC7662 clearly mentions that the user of introspection endpoint is a 
> >> 'protected resource' and that makes sense for an access token. If we allow 
> >> this to client apps, it'll give unnecessary token information to them.
> >> However, the spec also mentions that refresh tokens can also be used 
> >> against the endpoint.
> >> In case of refresh tokens, user of the endpoint should be a client app 
> >> because refresh tokens are used by clients to get another access token. 
> >> (Cannot imagine how/why a resource server would introspect a refresh token)
> >>
> >> Is it correct to assume that the endpoint should be allowed to client apps 
> >> if they want to examine refresh token's expiry time? Then the RFC should 
> >> clearly mention it.
> >>
> >> Thanks in advance.
> >>
> >> 
> >> In https://tools.ietf.org/html/rfc7662
> >> In '1.  Introduction' section says,
> >> "This specification defines a protocol that allows authorized
> >> protected resources to query the authorization server to determine
> >> the set of metadata for a given token that was presented to them by
> >> an OAuth 2.0 client."
> >> Above makes clear that user of the endpoint is a "protected resource".
> >>
> >> And under 'token' in '2.1.  Introspection Request' section says,
> >> "For refresh tokens,
> >> this is the "refresh_token" value returned from the token endpoint
> >> as defined in OAuth 2.0 [RFC6749], Section 5.1."
> >> So looks like a refresh token is allowed for this endpoint.
> >>
> >>
> >> Bill Jung
> >> Manager, Response Engineering
> >> bj...@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
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[David Waite]

I would expect the AS to invalidate the refresh token in this case, which would 
not require a refresh token mode nor necessarily any signaling back to the 
resource.

-DW

> On Mar 1, 2020, at 12:12 AM, Andrii Deinega  wrote:
> 
> Hello Bill,
> 
> I'm just thinking out loud about possible scenarios for a protected
> resource here... It may decide to revoke a refresh token if a client
> application tried to use it instead of an access token when the
> protected resource is paranoid about security. In order to do that an
> introspection response should include a non-standard parameter which
> indicates that the requested token is refresh_token.
> 
> A user of the introspection endpoint should rely only on a value of
> the active parameter (which is a boolean indicator) of the endpoint
> response. This applies to both types of tokens. Note, the expiration
> date, as well as other parameters, are defined as optional in the
> specification. Both token types can be revoked before the expiration
> date comes even if this parameter is presented as part of the
> response. In my opinion, there are a number of reasons why this check
> (for a refresh token) can be useful on the client application side.
> 
> --
> Regards,
> Andrii
> 
> 
> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
>  wrote:
>> 
>> Hello, hopefully I am using the right email address.
>> 
>> Simply put, can this spec be enhanced to clarify "Who can use the 
>> introspection endpoint for a refresh token? A resource provider or a client 
>> app or both?"
>> 
>> RFC7662 clearly mentions that the user of introspection endpoint is a 
>> 'protected resource' and that makes sense for an access token. If we allow 
>> this to client apps, it'll give unnecessary token information to them.
>> However, the spec also mentions that refresh tokens can also be used against 
>> the endpoint.
>> In case of refresh tokens, user of the endpoint should be a client app 
>> because refresh tokens are used by clients to get another access token. 
>> (Cannot imagine how/why a resource server would introspect a refresh token)
>> 
>> Is it correct to assume that the endpoint should be allowed to client apps 
>> if they want to examine refresh token's expiry time? Then the RFC should 
>> clearly mention it.
>> 
>> Thanks in advance.
>> 
>> 
>> In https://tools.ietf.org/html/rfc7662
>> In '1.  Introduction' section says,
>> "This specification defines a protocol that allows authorized
>> protected resources to query the authorization server to determine
>> the set of metadata for a given token that was presented to them by
>> an OAuth 2.0 client."
>> Above makes clear that user of the endpoint is a "protected resource".
>> 
>> And under 'token' in '2.1.  Introspection Request' section says,
>> "For refresh tokens,
>> this is the "refresh_token" value returned from the token endpoint
>> as defined in OAuth 2.0 [RFC6749], Section 5.1."
>> So looks like a refresh token is allowed for this endpoint.
>> 
>> 
>> Bill Jung
>> Manager, Response Engineering
>> bj...@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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

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 
> >  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.  (Unfortun

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

[Andrii Deinega]

I would like to add/clarify a couple of things. All our protected
resources share the same logic that uses the introspection endpoint in
order to verify whether a token is valid or not. We use the active
parameter for that. Although, we additionally check the token_type
parameter and its value. If this parameter isn't presented or its
value isn't equal to Bearer we identify this token as an invalid (only
access tokens can have Bearer in the token_type parameter as I
understand it). The main reason for this check is that I don't trust
developers of client applications which may use a refresh instead of
an access token by mistake or on purpose. I can rely on the token_type
parameter because there is a guarantee that our authorization server
returns it. This is an optional parameter according to
https://tools.ietf.org/html/rfc7662#section-2.2. Hence, this approach
may not work if we will decide to switch to another implementation of
the authorization server in our so-called OAuth "agents" and proxies
for our protected resources. I hope this scenario demonstrates why it
can be mportant to know when you deal with a refresh token on a
protected resource and I am unsure what other implementations of OAuth
client libraries and/or "introspect" filters do in this regard.

Regards,
Andrii

On Sat, Feb 29, 2020 at 11:12 PM Andrii Deinega
 wrote:
>
> Hello Bill,
>
> I'm just thinking out loud about possible scenarios for a protected
> resource here... It may decide to revoke a refresh token if a client
> application tried to use it instead of an access token when the
> protected resource is paranoid about security. In order to do that an
> introspection response should include a non-standard parameter which
> indicates that the requested token is refresh_token.
>
> A user of the introspection endpoint should rely only on a value of
> the active parameter (which is a boolean indicator) of the endpoint
> response. This applies to both types of tokens. Note, the expiration
> date, as well as other parameters, are defined as optional in the
> specification. Both token types can be revoked before the expiration
> date comes even if this parameter is presented as part of the
> response. In my opinion, there are a number of reasons why this check
> (for a refresh token) can be useful on the client application side.
>
> --
> Regards,
> Andrii
>
>
> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
>  wrote:
> >
> > Hello, hopefully I am using the right email address.
> >
> > Simply put, can this spec be enhanced to clarify "Who can use the 
> > introspection endpoint for a refresh token? A resource provider or a client 
> > app or both?"
> >
> > RFC7662 clearly mentions that the user of introspection endpoint is a 
> > 'protected resource' and that makes sense for an access token. If we allow 
> > this to client apps, it'll give unnecessary token information to them.
> > However, the spec also mentions that refresh tokens can also be used 
> > against the endpoint.
> > In case of refresh tokens, user of the endpoint should be a client app 
> > because refresh tokens are used by clients to get another access token. 
> > (Cannot imagine how/why a resource server would introspect a refresh token)
> >
> > Is it correct to assume that the endpoint should be allowed to client apps 
> > if they want to examine refresh token's expiry time? Then the RFC should 
> > clearly mention it.
> >
> > Thanks in advance.
> >
> > 
> > In https://tools.ietf.org/html/rfc7662
> > In '1.  Introduction' section says,
> > "This specification defines a protocol that allows authorized
> > protected resources to query the authorization server to determine
> > the set of metadata for a given token that was presented to them by
> > an OAuth 2.0 client."
> > Above makes clear that user of the endpoint is a "protected resource".
> >
> > And under 'token' in '2.1.  Introspection Request' section says,
> > "For refresh tokens,
> > this is the "refresh_token" value returned from the token endpoint
> > as defined in OAuth 2.0 [RFC6749], Section 5.1."
> > So looks like a refresh token is allowed for this endpoint.
> >
> >
> > Bill Jung
> > Manager, Response Engineering
> > bj...@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

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

[Phillip Hunt]

Why not just require service accounts to use mutually acceptable http method of 
authentication?  Eg instead id/password, service acnt client could use mtls 
auth or http basic or some other method.  

AFAIK this is already widely done. 

Is there so much interop value that specifying only the weakest form of 
authentication is warranted?

Phil

> On Mar 1, 2020, at 4:09 AM, Dominick Baier  wrote:
> 
> 
> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
> could continue to be "password", but now clearly in the context of a service 
> account in a different document)
> 
> IMHO - if such a thing gets defined, it should be a separate document. Keep 
> 2.1 as simple as possible.
> 
> ———
> Dominick Baier
> 
>> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:
>> 
>> It looks like there is consensus to remove ROPC for a user -- but that the 
>> password grant is not a bad practice for service accounts. That leads to 
>> providing clarity on service accounts.
>> 
>> 1) add service account grant to the OAuth 2.1 document
>> 
>> 2) write an OAuth 2.1 extension for service account grants. (the grant type 
>> could continue to be "password", but now clearly in the context of a service 
>> account in a different document)
>> 
>> With the goal of OAuth 2..1 being a capture of all the best practices, (2) 
>> makes more sense as it could discuss all aspects of service accounts 
>> including mapping a client to a service account. 
>> 
>> What do others think?
>> 
>> 
>> ᐧ
>> 
>>> On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:
>>> Let us do it then and deprecate ROPC. 
>>> There definitely are use-cases that need this pattern around me as well, 
>>> but we are using JWT bearer grant instead. Standardizing the behavior is 
>>> good. I am fine with new service_account grant type as well, btw. 
>>> 
>>> Nat
>>> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
 I’d be open to defining a new service_account grant type and 
 removing/deprecating the ROPC grant. I’d also be happy if we just said 
 that service account flows should use the JWT bearer grant, and we 
 document the best practices around that and encourage client libs to 
 implement support for it.
 
 Should there be a dedicated draft for best practices for 
 service-to-service usage?
 
 — Neil
 
> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
> 
> I 100% agree that the job of a standard is not to tell people "what they 
> ought to be doing". Instead, a standard is more about documenting the 
> current state of the art as deployed in existing implementations.
> 
> With that in mind, I think that leaves us with two concrete problems with 
> the password grant:
> 
> 1) The actual problem with the password grant is end users entering 
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service 
> accounts or backends that are inflexible, not actually using it for end 
> user credentials
> 
> So it seems like there's actually something missing from OAuth which is 
> leading people to find the password grant and use that because it's the 
> only thing that most closely fits their existing model. It seems like 
> we'd be better off defining a new extension that captures the use case 
> people are actually doing, instead of encouraging the continuing use of 
> the password grant for this purpose.
> 
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> wrote:
> I’m not really sure the WG should be telling people what they “ought to 
> be doing” unless we have concrete security or interoperability reasons 
> for doing so.
> 
> I also don’t agree that people doing this are doing anything wrong. I 
> don’t always agree with what our customers do, but I’ve learnt over the 
> years not to second-guess their reasons for doing it.
> 
> Are Google wrong for using the JWT bearer grant (not client credentials) 
> and service accounts? They even go so far as to say “scopes are not a 
> security mechanism” [1] and tell people to use service account roles 
> instead. (Precisely because they also support non-OA

Re: [OAUTH-WG] postmessage communication in -security-topics-13

[Travis Spencer]

On Tue, Dec 24, 2019 at 12:27 AM Brian Campbell
 wrote:
>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.3.2 
> has "Replace implicit flow with postmessage communication or ..." but without 
> a defined and interoperable way of using postmessage communication in place 
> of the implicit flow that "proposed countermeasure" seems a problematic 
> suggestion..

The WG could pick up
https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.1: dropping password grant

[Dominick Baier]

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

IMHO - if such a thing gets defined, it should be a separate document. Keep
2.1 as simple as possible.

———
Dominick Baier

On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:

It looks like there is consensus to remove ROPC for a user -- but that the
password grant is not a bad practice for service accounts. That leads to
providing clarity on service accounts.

1) add service account grant to the OAuth 2.1 document

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

With the goal of OAuth 2.1 being a capture of all the best practices, (2)
makes more sense as it could discuss all aspects of service accounts
including mapping a client to a service account.

What do others think?


ᐧ

On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura  wrote:

> Let us do it then and deprecate ROPC.
> There definitely are use-cases that need this pattern around me as well,
> but we are using JWT bearer grant instead. Standardizing the behavior is
> good. I am fine with new service_account grant type as well, btw.
>
> Nat
> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>
> I’d be open to defining a new service_account grant type and
> removing/deprecating the ROPC grant. I’d also be happy if we just said that
> service account flows should use the JWT bearer grant, and we document the
> best practices around that and encourage client libs to implement support
> for it.
>
> Should there be a dedicated draft for best practices for
> service-to-service usage?
>
> — Neil
>
> On 25 Feb 2020, at 00:13, Aaron Parecki  wrote:
>
> I think we might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I 100% agree that the job of a standard is not to tell people "what they
> ought to be doing". Instead, a standard is more about documenting the
> current state of the art as deployed in existing implementations.
>
> With that in mind, I think that leaves us with two concrete problems with
> the password grant:
>
> 1) The actual problem with the password grant is end users entering
> passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service
> accounts or backends that are inflexible, not actually using it for end
> user credentials
>
> So it seems like there's actually something missing from OAuth which is
> leading people to find the password grant and use that because it's the
> only thing that most closely fits their existing model. It seems like we'd
> be better off defining a new extension that captures the use case people
> are actually doing, instead of encouraging the continuing use of the
> password grant for this purpose.
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> wrote:
> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I also don’t agree that people doing this are doing anything wrong. I
> don’t always agree with what our customers do, but I’ve learnt over the
> years not to second-guess their reasons for doing it.
>
> Are Google wrong for using the JWT bearer grant (not client credentials)
> and service accounts? They even go so far as to say “scopes are not a
> security mechanism” [1] and tell people to use service account roles
> instead. (Precisely because they also support non-OAuth auth methods, which
> bypass any scopes).
>
> Are we really going to tell them to rewrite it all to use the client
> credentials grant?
>
> [1]:
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>
> On 21 Feb 2020, at 21:04, Justin Richer  wrote:
>
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time
> to get rid of it and send people toward what they really ought to be doing.
>
> Another thing I’ve seen is using different service accounts to get
> different sets of access for one client — if you’re doing that, you’ve got
> a client pretending to do two different things, or your APIs should be
> using scopes to differentiate access instead of client/user identity.
>
> — Justin
>
> On Feb 21, 2020, at 3:28