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

[Dick Hardt]

The "can" works better, agreed. Thanks!
ᐧ

On Sat, Aug 29, 2020 at 8:25 AM Justin Richer  wrote:

> Thanks, Dick. I agree with removing the excess parenthetical, but I
> intentionally avoided using a lowercase “may” in the middle of the
> text  (in favor of “can”) to avoid normative-sounding non-normative
> language, so I’d recommend that change be kept:
>
> Implementers should be aware that a token introspection request lets the
> AS know when the client
> 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.
>
> On Aug 27, 2020, at 12:15 PM, Dick Hardt  wrote:
>
> 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

[Torsten Lodderstedt]

I gone draft this section.

> Am 29.08.2020 um 17:22 schrieb Justin Richer :
> 
> I completely agree with the utility of the function in question here and it 
> needs to be included. I’m in favor of creating a dedicated section for 
> redirect_uri management, so that we can explain exactly how and why to relax 
> the requirement from core OAuth. In addition, I think we want to discuss that 
> the AS might have its own restrictions on which redirect URIs an 
> authenticated client might be able to use. For example, registering a client 
> with a Redirect URI prefix, or allowing only a query parameter to vary at 
> runtime. All of these can be enforced in PAR because the client is presenting 
> its authentication, as you point out, so the AS can determine which policies 
> should apply.
> 
> — Justin
> 
>>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> 
>>> 
>>> 
>>>   ¶6: Does the AS really have "the ability to authenticate and authorize 
>>> clients”? I think what we mean here is "the ability to authenticate clients 
>>> and validate client requests”, but I’m not positive of the intent. 
>>> 
>>> I think the intent is that the AS can check whether a client is authorized 
>>> to make a particular authorization request (specific scopes, response type, 
>>> etc.). But checking authorization to request authorization is confusing 
>>> wording. I think your working is less confusing and still allows for the 
>>> intent. 
>>> 
>>> I'll let Torsten interject if he feels differently as I think he originally 
>>> wrote the text in question. 
>> 
>> that was the original intent. I think “validate" is fine. 
>> 
>>> 
>>> 
>>> 
>>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed 
>>> externally, the association with a set or pattern of allowed redirect URIs 
>>> is still important, and the AS will need to know what that is. I think this 
>>> example could lead an AS developer to (erroneously and dangerously) 
>>> conclude that they don’t have to check any other values in a request, 
>>> including scope and redirect URI. It’s important that DynReg doesn’t 
>>> alleviate that issue, but removal of DynReg doesn’t really change things in 
>>> that regard. Suggest removing example or reworking paragraph.
>>> 
>>> I'm going to have to defer to Torsten on this because, to be honest, I'm 
>>> not too sure about it myself. I tend to lean towards thinking the draft 
>>> would be better off without it.
>>> 
>> 
>> In the traditional authorization flow, the redirect_uri serves as way to 
>> make sure the AS is really talking to the legit client and the allowed 
>> redirect_uri values are determined by the legit client at registration time 
>> (might be manually).
>> 
>> With PAR, we have a much stronger means to ensure the AS is talking to the 
>> legit client. That’s why I don’t see an issue with letting the client set a 
>> per transaction redirect_uri. This will give the client more flexibility 
>> (mint AS-specific redirect URIs on the fly) and makes client management much 
>> easier since redirect URIs are the most volatile part of a client policy. 
>> 
>> It also makes use of OAuth much easier in deployments where client 
>> identities are managed by external entities (even without any idea of 
>> OAuth). A prominent example is open banking in the EU (aka PSD2). The 
>> (technical) identity of any PSD2-licensed client is asserted by an eIDAS 
>> compliant CA in a special X.509 certificate. Those certificates contain the 
>> permissions (access to account information and/or payment initiation 
>> allowed) and the identity (member state specific). But they don’t contain 
>> OAuth policy values. Nevertheless, the regulation requires any financial 
>> institution in the EU to at runtime, without any registration, to accept and 
>> process calls from any licensed PSD2 clients.
>> 
>> There are two ways to cope with it in OAuth context:
>> a) use dynamic client registration with the X.509 cert as credential. 
>> Unfortunately, RFC 7591 does not support other client authentication means 
>> then an initial access token. Beside that, it would violate the text of the 
>> regulation. 
>> b) establish a redirect URL with every transaction. This is the recommended 
>> approach in at least one of the PSD2 specs.
>> 
>> PAR is a clean way to solve that problem. 
>> 
>> I don’t want this text to cause confusing. On the other hand this potential 
>> of PAR is way too important to not mention it at all. What about moving it 
>> into a special section "redirect_uri management”?
>> 
>>> 
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
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]

Thanks, Dick. I agree with removing the excess parenthetical, but I 
intentionally avoided using a lowercase “may” in the middle of the text  (in 
favor of “can”) to avoid normative-sounding non-normative language, so I’d 
recommend that change be kept:

Implementers should be aware that a token introspection request lets the AS 
know when the client 
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.

> On Aug 27, 2020, at 12:15 PM, Dick Hardt  wrote:
> 
> 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 
>> > > 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 mailto:oauth-boun...@ietf.org>> 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]

I completely agree with the utility of the function in question here and it 
needs to be included. I’m in favor of creating a dedicated section for 
redirect_uri management, so that we can explain exactly how and why to relax 
the requirement from core OAuth. In addition, I think we want to discuss that 
the AS might have its own restrictions on which redirect URIs an authenticated 
client might be able to use. For example, registering a client with a Redirect 
URI prefix, or allowing only a query parameter to vary at runtime. All of these 
can be enforced in PAR because the client is presenting its authentication, as 
you point out, so the AS can determine which policies should apply.

 — Justin

> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
> wrote:
> 
> 
>> 
>> 
>>¶6: Does the AS really have "the ability to authenticate and authorize 
>> clients”? I think what we mean here is "the ability to authenticate clients 
>> and validate client requests”, but I’m not positive of the intent. 
>> 
>> I think the intent is that the AS can check whether a client is authorized 
>> to make a particular authorization request (specific scopes, response type, 
>> etc.). But checking authorization to request authorization is confusing 
>> wording. I think your working is less confusing and still allows for the 
>> intent. 
>> 
>> I'll let Torsten interject if he feels differently as I think he originally 
>> wrote the text in question. 
> 
> that was the original intent. I think “validate" is fine. 
> 
>> 
>> 
>> 
>>¶7: I’m not sure I buy this example. Even if the clientID is managed 
>> externally, the association with a set or pattern of allowed redirect URIs 
>> is still important, and the AS will need to know what that is. I think this 
>> example could lead an AS developer to (erroneously and dangerously) conclude 
>> that they don’t have to check any other values in a request, including scope 
>> and redirect URI. It’s important that DynReg doesn’t alleviate that issue, 
>> but removal of DynReg doesn’t really change things in that regard. Suggest 
>> removing example or reworking paragraph.
>> 
>> I'm going to have to defer to Torsten on this because, to be honest, I'm not 
>> too sure about it myself. I tend to lean towards thinking the draft would be 
>> better off without it. 
>> 
> 
> In the traditional authorization flow, the redirect_uri serves as way to make 
> sure the AS is really talking to the legit client and the allowed 
> redirect_uri values are determined by the legit client at registration time 
> (might be manually).
> 
> With PAR, we have a much stronger means to ensure the AS is talking to the 
> legit client. That’s why I don’t see an issue with letting the client set a 
> per transaction redirect_uri. This will give the client more flexibility 
> (mint AS-specific redirect URIs on the fly) and makes client management much 
> easier since redirect URIs are the most volatile part of a client policy. 
> 
> It also makes use of OAuth much easier in deployments where client identities 
> are managed by external entities (even without any idea of OAuth). A 
> prominent example is open banking in the EU (aka PSD2). The (technical) 
> identity of any PSD2-licensed client is asserted by an eIDAS compliant CA in 
> a special X.509 certificate. Those certificates contain the permissions 
> (access to account information and/or payment initiation allowed) and the 
> identity (member state specific). But they don’t contain OAuth policy values. 
> Nevertheless, the regulation requires any financial institution in the EU to 
> at runtime, without any registration, to accept and process calls from any 
> licensed PSD2 clients.
> 
> There are two ways to cope with it in OAuth context:
> a) use dynamic client registration with the X.509 cert as credential. 
> Unfortunately, RFC 7591 does not support other client authentication means 
> then an initial access token. Beside that, it would violate the text of the 
> regulation. 
> b) establish a redirect URL with every transaction. This is the recommended 
> approach in at least one of the PSD2 specs.
> 
> PAR is a clean way to solve that problem. 
> 
> I don’t want this text to cause confusing. On the other hand this potential 
> of PAR is way too important to not mention it at all. What about moving it 
> into a special section "redirect_uri management”?
> 
>> 
> 

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

Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited

[Torsten Lodderstedt]

> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen 
>  wrote:
> 
> Hi all,
> 
> I think we all agree that proper countermeasures of mix-up attacks should 
> definitely be part of the BCP and 2.1 due to the severe impact successful 
> mix-up attacks have.
> Theoretically speaking every client which supports multiple AS is potentially 
> vulnerable to mix-up attacks. While in practice it might seem unlikely it is 
> possible that one of the honest AS the client supports gets compromised and 
> can be utilized for a mix-up attack. 
> 
> In a previous thread of last November 
> (https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/) I 
> discussed why “use distinct redirect URIs for each AS” is not an effective 
> countermeasure against mix-up attacks (if dynamic client registration is 
> used). I would argue that this is especially important for mobile 
> applications, SPAs, and other native applications because it is very common 
> for them to use dynamic client registration. Many iOS applications now must 
> support multiple AS since Apple forces the support for “Sign in with Apple” 
> if any single sign-on provider is supported. This policy makes mix-up attacks 
> applicable.
> 
> I fully agree with Daniel, Brian, and Mike that it is important to define and 
> register the “iss” parameter properly to ensure that both clients and AS 
> understand and use it in the correct way. I understand that OAuth 2.1 is not 
> meant to introduce and define new parameters but I strongly suggest that the 
> “iss” parameter should be introduced and defined elsewhere so that it can be 
> natively included in 2.1. In other words the “iss” parameter should be 
> integrated in 2.1 the same way PKCE is: the initial definition of the 
> parameter(s) is in another document (RFC 7636 in the case of PKCE) and then 
> included in 2.1.
> 
> What do you think would be the best place to define and register the “iss” 
> parameter? Would it be worthwhile to reactivate and update 
> “draft-ietf-oauth-mix-up-mitigation”?

That’s a decision of the authors. Alternatively, a new small draft (referring 
to the BCP’s attack description) should do the job as well. Mind to write an 
ID? :-)

> 
> Best regards,
> 
> Karsten
> 
> 
> 
> On 18.06.2020 22:49, Mike Jones wrote:
>> I support documenting the use of the issuer to mitigate mix-up attacks.  
>> Note that while issuer was first defined by OpenID Connect, it became art of 
>> OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata.
>>  
>>-- Mike
>>  
>> From: OAuth  On Behalf Of Brian Campbell
>> Sent: Thursday, June 18, 2020 1:32 PM
>> To: Daniel Fett 
>> Cc: oauth 
>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited
>>  
>> In my (probably simplistic) understanding of things, the root underlying 
>> issue that allows for mix-up in its variations is the lack of anything 
>> identifying the AS in the authorization response. Following from that, 
>> introducing and using an `iss` authorization response parameter has always 
>> seemed like the most straightforward approach for mitigating the issue 
>> (which was part of the draft-ietf-oauth-mix-up-mitigation but other 
>> parameters were also included and, for reasons I'm not sure about, interest 
>> in that work faded in favor of telling clients to use per AS redirect URIs) 
>> . Though for the `iss` authorization response parameter to be effective, all 
>> parties involved need to know about it and act on it. So I think it'd need 
>> to be something more than a passing recommendation in the BCP. It should be 
>> defined, registered, explained, etc.. Actually introducing a new parameter 
>> is maybe going beyond the expected scope of the BCP (or 2.1). But maybe 
>> that's ok, if we're at least more intentional about it. 
>>  
>> On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett  wrote:
>> Hi all,
>> I was wondering if we should move towards introducing and (more explicitly) 
>> recommending the iss parameter in the security BCP, for the reasons laid out 
>> below and in the article (which is now 
>> athttps://danielfett.de/2020/05/04/mix-up-revisited/).
>>  
>> Any thoughts on this?
>>  
>> -Daniel
>>  
>> Am 04.05.20 um 19:34 schrieb Daniel Fett:
>> Hi all,
>> 
>> to make substantiated recommendations for FAPI 2.0, the security 
>> considerations for PAR, and the security BCP, I did another analysis on the 
>> threats that arise from mix-up attacks. I was interested in particular in 
>> two questions:
>> 
>>  • Does PAR help preventing mix-up attacks?
>>  • Do we need JARM to prevent mix-up attacks?
>> I wrote down several attack variants and configurations in the following 
>> document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html
>> 
>> The key takeaways are:
>> 
>>  • The security BCP needs to make clear that per-AS redirect URIs are 
>> only sufficient if OAuth Metadata is not used to resolve multiple issuers. 
>> 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt

[Torsten Lodderstedt]

> On 11. Aug 2020, at 23:55, Brian Campbell 
>  wrote:
> 
> Hi Francis, 
> 
> My apologies for the tardy response to this - I was away for some time on 
> holiday. But thank you for the review and feedback on the draft. I've tried 
> to respond inline below.
> 
> 
> On Fri, Jul 31, 2020 at 5:01 PM Francis Pouatcha 
>  wrote:
> Bellow is the only remark I found from reviewing the draft draft:
> 
> 2.1.  Request: 
> 
> requires the parameters "code_challenge" and "code_challenge_method" but
> https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential-client
>  mentions that RFC7636 is not required for confidential clients. I guess 
> those two parameters have to be taken off the mandatory list and pushed to 
> the list below.
> 
> The list of parameters in Section 2.1 is qualified with a "basic parameter 
> set will typically include" and is definitely not intended to convey a set of 
> required parameters. It's just a list of parameters that make up a 
> hypothetical typical request.  Perhaps some text in the section or even the 
> formatting needs to be adjusted so as to (hopefully) avoid any confusion like 
> this that the list somehow conveys normative requirements?

Just a note: according to 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics and 
https://tools.ietf.org/html/draft-ietf-oauth-v2-1, code_challenge is a 
mandatory parameter for any client. That’s why we included it in this list. 

The FAPI WG also considers to make PKCE mandatory in FAPI 1. FAPI 2 requires it 
anyway. 

> 
>  
> - Using jwsreq, non repudiation is provided as request is signed (jws). This 
> section also mentions that the request can be sent as form url  encoded 
> (x-www-form-urlencoded). In this case, there is no way to provide non 
> repudiation unless we mention that request can be signed by client using 
> signature methods declared by the AS (AS metadata).
> 
>  I am not aware of any signature methods or means of an AS declaring support 
> for a signature method in metadata that are sufficiently standardized to be 
> mentioned in the context of this draft. The "request" parameter 
> https://tools.ietf.org/html/draft-ietf-oauth-par-03#section-3 can be sent to 
> the PAR endpoint and should provide the same notation of non-repudiation as 
> does jwsreq. I think that's sufficient treatment of non-repudiation for the 
> PAR draft. 
> 
>  
> 
> 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] WGLC Review of PAR

[Torsten Lodderstedt]

> 
> 
> ¶6: Does the AS really have "the ability to authenticate and authorize 
> clients”? I think what we mean here is "the ability to authenticate clients 
> and validate client requests”, but I’m not positive of the intent. 
> 
> I think the intent is that the AS can check whether a client is authorized to 
> make a particular authorization request (specific scopes, response type, 
> etc.). But checking authorization to request authorization is confusing 
> wording. I think your working is less confusing and still allows for the 
> intent. 
> 
> I'll let Torsten interject if he feels differently as I think he originally 
> wrote the text in question. 

that was the original intent. I think “validate" is fine. 

> 
>  
> 
> ¶7: I’m not sure I buy this example. Even if the clientID is managed 
> externally, the association with a set or pattern of allowed redirect URIs is 
> still important, and the AS will need to know what that is. I think this 
> example could lead an AS developer to (erroneously and dangerously) conclude 
> that they don’t have to check any other values in a request, including scope 
> and redirect URI. It’s important that DynReg doesn’t alleviate that issue, 
> but removal of DynReg doesn’t really change things in that regard. Suggest 
> removing example or reworking paragraph.
> 
> I'm going to have to defer to Torsten on this because, to be honest, I'm not 
> too sure about it myself. I tend to lean towards thinking the draft would be 
> better off without it. 
> 

In the traditional authorization flow, the redirect_uri serves as way to make 
sure the AS is really talking to the legit client and the allowed redirect_uri 
values are determined by the legit client at registration time (might be 
manually).

With PAR, we have a much stronger means to ensure the AS is talking to the 
legit client. That’s why I don’t see an issue with letting the client set a per 
transaction redirect_uri. This will give the client more flexibility (mint 
AS-specific redirect URIs on the fly) and makes client management much easier 
since redirect URIs are the most volatile part of a client policy. 

It also makes use of OAuth much easier in deployments where client identities 
are managed by external entities (even without any idea of OAuth). A prominent 
example is open banking in the EU (aka PSD2). The (technical) identity of any 
PSD2-licensed client is asserted by an eIDAS compliant CA in a special X.509 
certificate. Those certificates contain the permissions (access to account 
information and/or payment initiation allowed) and the identity (member state 
specific). But they don’t contain OAuth policy values. Nevertheless, the 
regulation requires any financial institution in the EU to at runtime, without 
any registration, to accept and process calls from any licensed PSD2 clients.

There are two ways to cope with it in OAuth context:
a) use dynamic client registration with the X.509 cert as credential. 
Unfortunately, RFC 7591 does not support other client authentication means then 
an initial access token. Beside that, it would violate the text of the 
regulation. 
b) establish a redirect URL with every transaction. This is the recommended 
approach in at least one of the PSD2 specs.

PAR is a clean way to solve that problem. 

I don’t want this text to cause confusing. On the other hand this potential of 
PAR is way too important to not mention it at all. What about moving it into a 
special section "redirect_uri management”?

> 

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

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

You are making a good point here. The reason we added the one time use 
constraint was the fact the client will include parameters supposed to be used 
only once, e.g. the PKCE code_challenge. For a traditional authorisation 
request, we would recommend the client to use a per transaction (== one time 
use) code_challenge, but PKCE does not require the AS to enforce it. Mapping 
this to PAR means, we SHOULD recommend the client to use the request_uri only 
once but not require the AS to enforce it. 

Would the following text work for you?

Since parts of the request content, e.g. the "code_challenge"
   parameter value, is unique to a certain authorization request, 
the client SHOULD use the "request_uri" only once.

I also would move this text to section 4.

> On 27. Aug 2020, at 18:11, Dick Hardt  wrote:
> 
> 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 
>>  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,