[OAUTH-WG] third party applications

[Dima Postnikov]

Hi,

Can "third-party" term be removed from the specification?

The standard and associated best practices apply to other applications that
act on behalf of a resource owner, too (internal, "first-party" and etc).

Regards,

Dima

The OAuth 2.1 authorization framework enables a *third-party*
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749 .
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Dick Hardt]

Here is a crisper revision.

Implementers should be aware that a token introspection request lets the AS
know when the client
is accessing the RS, which may indicate when the user is using
the client. If this implication is not acceptable, implementers can use
other means to carry
access token data, e.g. directly transferring the data needed by the RS
within the access token.
ᐧ

On Thu, Aug 27, 2020 at 7:19 AM Justin Richer  wrote:

> I would clarify that this doesn’t necessarily say that the user’s there,
> and remove the normative requirement (which doesn’t have enforceable teeth
> in this context):
>
> Implementers should be aware that a token introspection request lets the
> AS know when the client
> (and potentially the user) is accessing the RS, which *can also
> indicate* when the user is using
> the client. If this implication is not acceptable, *implementers can
> use other means* to carry
> access token data, e.g. directly transferring the data needed by the
> RS within the access token.
>
>
>  — Justin
>
> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
> Will the following text work for you?
>
> Implementers should be aware that a token introspection request lets the
> AS know when the client
> (and potentially the user) is accessing the RS, which is also an
> indication of when the user is using
> the client. If this impliction is not accepatable, implementars MUST
> use other means to carry
> access token data, e.g. directly transferring the data needed by the
> RS within the access token.
>
>
> On 26. Aug 2020, at 23:12, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> I agree with Dick’s observation about the privacy implications of using an
> Introspection Endpoint.  That’s why it’s preferable to not use one at all
> and instead directly have the Resource understand the Access Token.  One
> way of doing this is the JWT Access Token spec.  There are plenty of others.
>
> The downsides of using an Introspection Endpoint should be described in
> the Privacy Considerations section.
>
>   -- Mike
>
> From: OAuth  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call:
>  (JWT Response for
> OAuth Token Introspection) to Proposed Standard
>
>
>
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
> Hi Denis,
>
> On 25. Aug 2020, at 16:55, Denis  wrote:
>
>
> The fact that the AS will know exactly when the introspection call has
> been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time.
> The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.
>
>
> That is a fact. I don’t think it is an issue per se. Please explain the
> privacy implications.
>
> As I see it, the privacy implication is that the AS knows when the client
> (and potentially the user) is accessing the RS, which is also an indication
> of when the user is using the client.
>
> I think including this implication would be important to have in a Privacy
> Considerations section.
>
> /Dick
> ᐧ
>
>
> ___
> 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] WGLC Review of PAR

[Dick Hardt]

That is not correct.

The authorization code one-time-use is directly between the client and the
AS. The client has a number of mechanisms to ensure it only presents the
authorization code to the AS once, such as a session that was set when the
user started at the client.

In contrast, in a redirect from the client to the AS, the client loses
control on how many times the user-agent loads the URL at the AS.
Additionally, there is unlikely to be an active browser session at the AS,
so the AS can not easily differentiate between a URL load from the same
user, or different users. If one-time-use, one of them MUST fail. If the
two requests happen to be from the same user (because of a reload, which
the user did because the AS was slow to respond), there is no way for the
AS to know which of the requests is the one that is current in front of the
user. While the AS can internally ensure processing of the request once,
one-time-use would dictate that it provides a failure message to one of the
requests.

/Dick


ᐧ

On Thu, Aug 27, 2020 at 7:17 AM Justin Richer  wrote:

> We already have this same property with authorization codes, and it’s
> managed today reasonably well (in my opinion). If you submit the same
> request URI twice in the same browser (the refresh you’re talking about),
> it shouldn’t start two separate authorization requests, but it would be
> reasonable to detect that the same session attached to the same request URI
> value showed up twice and continue the session as appropriate.
>
> None of this is in conflict with “one time use”, in my view, since you’re
> actively detecting the session and source of the value.
>
>  — Justin
>
> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
>
> I think one-time use may be overly restrictive, and I don't think it is
> the property that we actually want.
>
> Give the request URI is in a redirect from the browser, there is a good
> chance of a race condition where the same browser request is made more than
> once, for example, while the browser is loading the authorization URL at
> the AS, the user could refresh the page causing the authorization URL to be
> reloaded. Would the reload count as a second use? One could argue it
> either way.
>
> What I think we want from what I understand, is the request URI MUST be
> unique so that there is no confusion on which request is being referenced..
>
> I did not see anything about the expiry time of the request URI (but I did
> not look super hard). If that is not there, then I think the request URI
> MUST expire in a "short" period of time.
>
>
>
> ᐧ
>
> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Thanks Justin. Just a couple more responses to responses inline below
>> (but with lots of content that needs no further discussion removed).
>>
>> A TL;DR for the WG is that I'd like to get some wider feedback on the
>> question of changing the one-time-use condition on the request_uri from a
>> SHOULD to a MUST.
>>
>> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
>>
>>> Hi Brian, just a couple responses inline where it seemed fitting. Thanks
>>> for going through everything!
>>>  — Justin
>>>
>>> On Aug 25, 2020, at 6:01 PM, Brian Campbell 
>>> wrote:
>>>
>>> Thanks for the review and comments Justin. Replies (or attempts thereat)
>>> are inline below.
>>>
>>>
>>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
>>>
 I’ve done a full read through of the PAR specification, and here are my
 notes on it.


> ¶2: Of necessity, this spec mixes parameters in the authorization
> endpoint and token endpoint registries into a single request. Is there any
> danger of conflict between them? The registry holds them in one list but
> they could possibly have different semantics in both places.
>

 I think that technically such danger does exist but that it's highly
 unlikely in practice. Especially because the only token endpoint parameters
 that are relevant to PAR are those that deal with client authentication
 (currently client_secret, client_assertion, and client_assertion_type).. 
 I'm
 also not sure what can reasonably be done about it given the way the
 registries are. I guess PAR could update the registration for those three
 (client_secret, client_assertion, and client_assertion_type) to also
 indicate authorization request as a usage location with some commentary
 that it's only for avoiding name collisions. And offer some guidance about
 doing the same for any future client auth methods being defined. But
 honestly I'm not sure what, if anything, to do here?

 And yes it is super unfortunate that client auth and protocol
 parameters got mixed together in the HTTP body. I didn't cause that
 situation but I've certainly contributed to it and for that I apologize.

>>>
>>> I think the only perfect solution is to go back in time and fix the
>>> 

Re: [OAUTH-WG] [Last-Call] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Brian Campbell]

+1

On Thu, Aug 27, 2020 at 8:20 AM Justin Richer  wrote:

> I would clarify that this doesn’t necessarily say that the user’s there,
> and remove the normative requirement (which doesn’t have enforceable teeth
> in this context):
>
> Implementers should be aware that a token introspection request lets the
> AS know when the client
> (and potentially the user) is accessing the RS, which *can also
> indicate* when the user is using
> the client. If this implication is not acceptable, *implementers can
> use other means* to carry
> access token data, e.g. directly transferring the data needed by the
> RS within the access token.
>
>
>  — Justin
>
> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
> Will the following text work for you?
>
> Implementers should be aware that a token introspection request lets the
> AS know when the client
> (and potentially the user) is accessing the RS, which is also an
> indication of when the user is using
> the client. If this impliction is not accepatable, implementars MUST
> use other means to carry
> access token data, e.g. directly transferring the data needed by the
> RS within the access token.
>
>
> On 26. Aug 2020, at 23:12, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> I agree with Dick’s observation about the privacy implications of using an
> Introspection Endpoint.  That’s why it’s preferable to not use one at all
> and instead directly have the Resource understand the Access Token.  One
> way of doing this is the JWT Access Token spec.  There are plenty of others.
>
> The downsides of using an Introspection Endpoint should be described in
> the Privacy Considerations section.
>
>   -- Mike
>
> From: OAuth  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call:
>  (JWT Response for
> OAuth Token Introspection) to Proposed Standard
>
>
>
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt <
> torsten=40lodderstedt@dmarc.ietf.org> wrote:
> Hi Denis,
>
> On 25. Aug 2020, at 16:55, Denis  wrote:
>
>
> The fact that the AS will know exactly when the introspection call has
> been made and thus be able to make sure which client
> has attempted perform an access to that RS and at which instant of time.
> The use of this call allows an AS to track where and when
> its clients have indeed presented an issued access token.
>
>
> That is a fact. I don’t think it is an issue per se. Please explain the
> privacy implications.
>
> As I see it, the privacy implication is that the AS knows when the client
> (and potentially the user) is accessing the RS, which is also an indication
> of when the user is using the client.
>
> I think including this implication would be important to have in a Privacy
> Considerations section.
>
> /Dick
> ᐧ
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>

-- 
_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

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Justin Richer]

I would clarify that this doesn’t necessarily say that the user’s there, and 
remove the normative requirement (which doesn’t have enforceable teeth in this 
context):

Implementers should be aware that a token introspection request lets the AS 
know when the client 
(and potentially the user) is accessing the RS, which can also indicate 
when the user is using 
the client. If this implication is not acceptable, implementers can use 
other means to carry 
access token data, e.g. directly transferring the data needed by the RS 
within the access token.


 — Justin

> On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt 
>  wrote:
> 
> Will the following text work for you?
> 
> Implementers should be aware that a token introspection request lets the AS 
> know when the client 
> (and potentially the user) is accessing the RS, which is also an 
> indication of when the user is using 
> the client. If this impliction is not accepatable, implementars MUST use 
> other means to carry 
> access token data, e.g. directly transferring the data needed by the RS 
> within the access token.
> 
> 
>> On 26. Aug 2020, at 23:12, Mike Jones 
>>  wrote:
>> 
>> I agree with Dick’s observation about the privacy implications of using an 
>> Introspection Endpoint.  That’s why it’s preferable to not use one at all 
>> and instead directly have the Resource understand the Access Token.  One way 
>> of doing this is the JWT Access Token spec.  There are plenty of others.
>> 
>> The downsides of using an Introspection Endpoint should be described in the 
>> Privacy Considerations section.
>> 
>>   -- Mike
>> 
>> From: OAuth  On Behalf Of Dick Hardt
>> Sent: Wednesday, August 26, 2020 9:52 AM
>> To: Torsten Lodderstedt 
>> Cc: last-c...@ietf.org; oauth 
>> Subject: Re: [OAUTH-WG] Last Call: 
>>  (JWT Response for OAuth 
>> Token Introspection) to Proposed Standard
>> 
>> 
>> 
>> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>>  wrote:
>> Hi Denis,
>> 
>>> On 25. Aug 2020, at 16:55, Denis  wrote:
>> 
>>> The fact that the AS will know exactly when the introspection call has been 
>>> made and thus be able to make sure which client 
>>> has attempted perform an access to that RS and at which instant of time. 
>>> The use of this call allows an AS to track where and when 
>>> its clients have indeed presented an issued access token.
>> 
>> That is a fact. I don’t think it is an issue per se. Please explain the 
>> privacy implications.
>> 
>> As I see it, the privacy implication is that the AS knows when the client 
>> (and potentially the user) is accessing the RS, which is also an indication 
>> of when the user is using the client.
>> 
>> I think including this implication would be important to have in a Privacy 
>> Considerations section.
>> 
>> /Dick
>> ᐧ
> 
> ___
> 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] WGLC Review of PAR

[Justin Richer]

We already have this same property with authorization codes, and it’s managed 
today reasonably well (in my opinion). If you submit the same request URI twice 
in the same browser (the refresh you’re talking about), it shouldn’t start two 
separate authorization requests, but it would be reasonable to detect that the 
same session attached to the same request URI value showed up twice and 
continue the session as appropriate. 

None of this is in conflict with “one time use”, in my view, since you’re 
actively detecting the session and source of the value.

 — Justin

> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
> 
> I think one-time use may be overly restrictive, and I don't think it is the 
> property that we actually want.
> 
> Give the request URI is in a redirect from the browser, there is a good 
> chance of a race condition where the same browser request is made more than 
> once, for example, while the browser is loading the authorization URL at the 
> AS, the user could refresh the page causing the authorization URL to be 
> reloaded. Would the reload count as a second use? One could argue it either 
> way.
> 
> What I think we want from what I understand, is the request URI MUST be 
> unique so that there is no confusion on which request is being referenced. 
> 
> I did not see anything about the expiry time of the request URI (but I did 
> not look super hard). If that is not there, then I think the request URI MUST 
> expire in a "short" period of time.
> 
> 
> 
> ᐧ
> 
> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
>  > wrote:
> Thanks Justin. Just a couple more responses to responses inline below (but 
> with lots of content that needs no further discussion removed). 
> 
> A TL;DR for the WG is that I'd like to get some wider feedback on the 
> question of changing the one-time-use condition on the request_uri from a 
> SHOULD to a MUST. 
> 
> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  > wrote:
> Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
> going through everything!
>  — Justin
> 
>> On Aug 25, 2020, at 6:01 PM, Brian Campbell > > wrote:
>> 
>> Thanks for the review and comments Justin. Replies (or attempts thereat) are 
>> inline below.
>> 
>> 
>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer > > wrote:
>> I’ve done a full read through of the PAR specification, and here are my 
>> notes on it.
>> 
>> 
>> ¶2: Of necessity, this spec mixes parameters in the authorization 
>> endpoint and token endpoint registries into a single request. Is there any 
>> danger of conflict between them? The registry holds them in one list but 
>> they could possibly have different semantics in both places.
>> 
>> I think that technically such danger does exist but that it's highly 
>> unlikely in practice. Especially because the only token endpoint parameters 
>> that are relevant to PAR are those that deal with client authentication 
>> (currently client_secret, client_assertion, and client_assertion_type). I'm 
>> also not sure what can reasonably be done about it given the way the 
>> registries are. I guess PAR could update the registration for those three 
>> (client_secret, client_assertion, and client_assertion_type) to also 
>> indicate authorization request as a usage location with some commentary that 
>> it's only for avoiding name collisions. And offer some guidance about doing 
>> the same for any future client auth methods being defined. But honestly I'm 
>> not sure what, if anything, to do here?  
>> 
>> And yes it is super unfortunate that client auth and protocol parameters got 
>> mixed together in the HTTP body. I didn't cause that situation but I've 
>> certainly contributed to it and for that I apologize. 
> 
> I think the only perfect solution is to go back in time and fix the 
> registries with based on the last decade of knowledge in using them. :P 
> 
> For this, I think maybe being very prescriptive about the fact that the only 
> parameters from the token endpoint that are allowed here are those used for 
> client authentication and that when they show up, they’re interpreted as in 
> the token endpoint request not the authorization endpoint request. Does that 
> work?
> 
> I think so, yes. And will work on incorporating some text towards that end. 
> 
> 
>  
>> I don’t see why a request URI with unguessable values isn’t a MUST for 
>> one-time-use, is there a reason?
>> 
>> The reason AFAIK was to not be overly prescriptive and allow for eventually 
>> consistent or not atomic storage of the data by not strictly requiring the 
>> AS to enforce one-time-use. Do you think that's too loose or could be 
>> worded/explained differently or better? 
> 
> I do think it’s too loose and it should be a MUST, and the methods for 
> enforcing that “MUST” are going to vary based on the deployments and 
> implementations 

Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard

[Torsten Lodderstedt]

Will the following text work for you?

Implementers should be aware that a token introspection request lets the AS 
know when the client 
 (and potentially the user) is accessing the RS, which is also an 
indication of when the user is using 
 the client. If this impliction is not accepatable, implementars MUST use 
other means to carry 
 access token data, e.g. directly transferring the data needed by the RS 
within the access token.


> On 26. Aug 2020, at 23:12, Mike Jones 
>  wrote:
> 
> I agree with Dick’s observation about the privacy implications of using an 
> Introspection Endpoint.  That’s why it’s preferable to not use one at all and 
> instead directly have the Resource understand the Access Token.  One way of 
> doing this is the JWT Access Token spec.  There are plenty of others.
>  
> The downsides of using an Introspection Endpoint should be described in the 
> Privacy Considerations section.
>  
>-- Mike
>  
> From: OAuth  On Behalf Of Dick Hardt
> Sent: Wednesday, August 26, 2020 9:52 AM
> To: Torsten Lodderstedt 
> Cc: last-c...@ietf.org; oauth 
> Subject: Re: [OAUTH-WG] Last Call: 
>  (JWT Response for OAuth 
> Token Introspection) to Proposed Standard
>  
>  
>  
> On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt 
>  wrote:
> Hi Denis,
> 
> > On 25. Aug 2020, at 16:55, Denis  wrote:
> 
> > The fact that the AS will know exactly when the introspection call has been 
> > made and thus be able to make sure which client 
> > has attempted perform an access to that RS and at which instant of time. 
> > The use of this call allows an AS to track where and when 
> > its clients have indeed presented an issued access token.
> 
> That is a fact. I don’t think it is an issue per se. Please explain the 
> privacy implications.
>  
> As I see it, the privacy implication is that the AS knows when the client 
> (and potentially the user) is accessing the RS, which is also an indication 
> of when the user is using the client.
>  
> I think including this implication would be important to have in a Privacy 
> Considerations section.
>  
> /Dick
> ᐧ

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