Subject: [OAUTH-WG] WGLC Review of PAR

From: Justin Richer <[email-masked]>
Date: Wed, 19 Aug 2020 16:06:42 -0400

I’ve done a full read through of the PAR specification, and here are my notes on it.

For additional context, I’ve implemented this specification for both a client and a server in a couple of languages. Overall, I think it’s in good shape and it makes sense from a developer’s perspective. I’ve got a few comments, some small and some that might need more conversation within the WG,

Throughout: Suggest using “credentialed” instead of “confidential” client, as introduced in OAuth 2.1 draft.

§1: Suggest the problems list start with changing scopes or swapping client IDs as scenarios in the first bullet, ACR is an esoteric use case for many and not in OAuth 2 core, either remove it or put it at the end of the bullet.

   Suggest the second bullet note who the information needs to be protected from, at least in passing. It’s not clear from this setup why the parameters should be confidential, and this is a major motivation for this work.

   Avoid use of phrase “so-called” and just give the name “Request Object”.

   ¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a request_uri value usable at the authorization server”. 

   ¶4/5: Alternatively, suggest combining these paragraphs: “This document complements JAR by providing an interoperable way for the client to push its authorization request parameters to the authorization server in exchange for a request_uri usable at the authorization server. The document further allows the client to push request objects as specified in JAR in exchange for a request_uri usable at the authorization server.”

    ¶12: “This is directly utilized” is a little ambiguous into what it’s referring to. Would suggest rewording the start as: “This early stage client authentication is used by this draft to allow confidential clients…” or something of that sort.

    ¶13: Not only is POST much harder to use, it’s also optional for the AS to implement so it can’t be counted on by a client to be available generally. (To be honest in retrospect we shouldn’t have included it in OAuth 2.)

§2: Please provide a reference to JWT client assertion auth here (either the assertion RFC or OIDC’s definition of the client auth methods mentioned). I would also phrase this as direct guidance instead of a note/aside.

§2.1: There’s some potential weirdness about client_id here. Since the authz request was designed around not having client authentication, that request requires client_id. However, here the client is authenticating, and the client_id might be included elsewhere like the Basic header. A developer might be curious about whether they need to include them twice.

    ¶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.

    ¶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. 

    ¶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.

§2.2: Is “expires_in” required? If so, can an AS decide that a request URI doesn’t expire after a certain amount of time? Related, what does a “0” or negative value mean, if anything? 

    I don’t see why a request URI with unguessable values isn’t a MUST for one-time-use, is there a reason?

§2.3: Are the HTTP status codes a normative MAY or just an informative “can” as written?

§3: This bit should be normative as follows: "he authorization server MUST take the following steps beyond the processing rules…"

    Clean up the tenses and voice of the numbered list, which are currently inconsistent.

§7.2: The AS should also make sure that the new redirect URI is applicable within that client’s domain or policies. So you wouldn’t want a legit-but-rogue client registering for someone else’s redirect URI in order to start an attack, for example. I think overall we might need better guidance around the redirect URI variability feature (which, to be clear, I’m hugely in favor of — but OAuth’s assumptions in the client model make this trickier to talk about and implement safely, so we need to be extra careful).

§7.3: As above, is there a reason that this isn’t a MUST? It’s a temporary credential representing a request, much like an authorization code in many ways. I don’t see why a legitimate client would use it more than once, or why a server would want to allow it for AS-generated values. For client-supplied request URIs, sure, but not here.

§X: Missing privacy considerations section. If anything this spec helps alleviate some privacy concerns by trading values for a reference, but the section is still needed.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 25 Aug 2020 16:01:02 -0600

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 <[email-masked]> wrote:

> For additional context, I’ve implemented this specification for both a
> client and a server in a couple of languages. Overall, I think it’s in good
> shape and it makes sense from a developer’s perspective. I’ve got a few
> comments, some small and some that might need more conversation within the
> WG,
>

Always nice to get feedback from implementation experience. Especially when
the overall is that it's "in good shape".

Throughout: Suggest using “credentialed” instead of “confidential” client,
> as introduced in OAuth 2.1 draft.
>

I'm hesitant to use *new* terminology from the 2.1 draft, which was just
recently adopted by the WG, in this document that is written as an
extension of OAuth 2.0 and is further along in the process going through
WGLC. There's a temporal dependency problem including potential risk of
change after the fact.

Perhaps this draft could avoid use of the terms and be more explicit and
wordy with something like "clients having established authentication
credentials with the AS"?

> §1: Suggest the problems list start with changing scopes or swapping
> client IDs as scenarios in the first bullet, ACR is an esoteric use case
> for many and not in OAuth 2 core, either remove it or put it at the end of
> the bullet.
>

Fair suggestion. Will look at reworking it a bit.

   Suggest the second bullet note who the information needs to be protected
> from, at least in passing. It’s not clear from this setup why the
> parameters should be confidential, and this is a major motivation for this
> work.
>

Also a fair suggestion. Although there are some subtleties and complexities
that I think make this a little tricky to write. Will try though.

>    Avoid use of phrase “so-called” and just give the name “Request Object”.

Okay, yeah. I think a moment of terminology frustration slipped into the
text there.

>    ¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a
> request_uri value usable at the authorization server”.
>

I like the pedanticness.

>
>    ¶4/5: Alternatively, suggest combining these paragraphs: “This document
> complements JAR by providing an interoperable way for the client to push
> its authorization request parameters to the authorization server in
> exchange for a request_uri usable at the authorization server. The document
> further allows the client to push request objects as specified in JAR in
> exchange for a request_uri usable at the authorization server.”
>

 Yeah, I think that working works better.

>     ¶12: “This is directly utilized” is a little ambiguous into what it’s
> referring to. Would suggest rewording the start as: “This early stage
> client authentication is used by this draft to allow confidential clients…”
> or something of that sort.
>

Makes sense to be less ambiguous there.

>
>     ¶13: Not only is POST much harder to use, it’s also optional for the
> AS to implement so it can’t be counted on by a client to be available
> generally. (To be honest in retrospect we shouldn’t have included it in
> OAuth 2.)
>

Connect says the AS/OP must support both get and post. But your point on
optionality stands with respect to pure OAuth only ASs. Will add something
about that to the paragraph.

>
> §2: Please provide a reference to JWT client assertion auth here (either
> the assertion RFC or OIDC’s definition of the client auth methods
> mentioned). I would also phrase this as direct guidance instead of a
> note/aside.
>

Will do.

>
> §2.1: There’s some potential weirdness about client_id here. Since the
> authz request was designed around not having client authentication, that
> request requires client_id. However, here the client is authenticating, and
> the client_id might be included elsewhere like the Basic header. A
> developer might be curious about whether they need to include them twice.
>

Fair point about the weirdness. Suggestions on some text to preempt
curiosity or confusion? My thinking is that the client_id parameter should
always be sent so as to conform to the syntax of a regular authz request.
But I'll admit that, due to reusing client auth logic, my server
implementation won't strictly require client_id when it's included
elsewhere like the Basic header.

>
>     ¶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.

>     ¶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.

>
>     ¶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.

>
> §2.2: Is “expires_in” required? If so, can an AS decide that a request URI
> doesn’t expire after a certain amount of time? Related, what does a “0” or
> negative value mean, if anything?
>

Yes, no, and that it's already expired, respectively. I guess anyway. But
maybe better to say that it has to be there and is a positive integer
value. Will clarify all that.

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

> §2.3: Are the HTTP status codes a normative MAY or just an informative

It's meant to be more of an informative “can” or even just a "does". It's
supposed to just say that the error response looks the same as a token
endpoint error response - same JSON and same status code, which is a 400
unless otherwise stated. There have been other similar WGLC comments on
this particular text so it's already on the list to reword for clarity.

>
> §3: This bit should be normative as follows: "he authorization server MUST
> take the following steps beyond the processing rules…"
>

Yep and yep, respectively.

>
> §7.2: The AS should also make sure that the new redirect URI is applicable
> within that client’s domain or policies. So you wouldn’t want a
> legit-but-rogue client registering for someone else’s redirect URI in order
> to start an attack, for example. I think overall we might need better
> guidance around the redirect URI variability feature (which, to be clear,
> I’m hugely in favor of — but OAuth’s assumptions in the client model make
> this trickier to talk about and implement safely, so we need to be extra
> careful).
>

Yeah, I think I follow and agree with you here. I'll try and add some more
coverage/guidance on the topic. But if you have any concrete suggestions or
text, I'd welcome it.

>
> §7.3: As above, is there a reason that this isn’t a MUST? It’s a temporary
> credential representing a request, much like an authorization code in many
> ways. I don’t see why a legitimate client would use it more than once, or
> why a server would want to allow it for AS-generated values. For
> client-supplied request URIs, sure, but not here.
>

The intent wasn't to allow it to be used more than once. But rather to
avoid putting a strict requirement on the AS to enforce one-time-use (and
the eventual certification tests that send the same URI twice within
milliseconds). If that distinction makes any sense. It is much like an
authorization code in many ways including the one-time-use text on code in
RFC 6749 being subject to different interpretations :/ I would like to
avoid different interpretations here.

For better or worse, that's some of the reasoning behind what's there now.
But I'm open to changing the normative strength of the statement, if you
and other folks in the WG feel it should be more MUSTy. And I'm certainly
open to suggestions on better wording/explanation.

>
> §X: Missing privacy considerations section. If anything this spec helps
> alleviate some privacy concerns by trading values for a reference, but the
> section is still needed.
>

Because of that and because it's already discussed to some extent in the
body of the document, a separate privacy considerations section didn't seem
needed. But we can look at adding a short section that says as much.

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

---

From: Justin Richer <[email-masked]>
Date: Tue, 25 Aug 2020 18:57:23 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Always nice to get feedback from implementation experience. Especially when the overall is that it's "in good shape".
> 
> 
> I'm hesitant to use *new* terminology from the 2.1 draft, which was just recently adopted by the WG, in this document that is written as an extension of OAuth 2.0 and is further along in the process going through WGLC. There's a temporal dependency problem including potential risk of change after the fact. 
> 
> Perhaps this draft could avoid use of the terms and be more explicit and wordy with something like "clients having established authentication credentials with the AS"? 

Fair point about the terminology, and while it’s verbose I think the more precise wording might be warranted here so as not to extend the problems and confusion with “confidential” clients as a term.

> Also a fair suggestion. Although there are some subtleties and complexities that I think make this a little tricky to write. Will try though. 
> 
>  
> Okay, yeah. I think a moment of terminology frustration slipped into the text there. 
>  
> 
> 
> Connect says the AS/OP must support both get and post. But your point on optionality stands with respect to pure OAuth only ASs. Will add something about that to the paragraph. 
>  
> 
> Fair point about the weirdness. Suggestions on some text to preempt curiosity or confusion? My thinking is that the client_id parameter should always be sent so as to conform to the syntax of a regular authz request. But I'll admit that, due to reusing client auth logic, my server implementation won't strictly require client_id when it's included elsewhere like the Basic header. 
>  
> 
> 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 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. 
> 
>  
> 
> 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. 
> 
>  
> 
> Yes, no, and that it's already expired, respectively. I guess anyway. But maybe better to say that it has to be there and is a positive integer value. Will clarify all that.   
>  
> 
> 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 out there. 

> It's meant to be more of an informative “can” or even just a "does". It's supposed to just say that the error response looks the same as a token endpoint error response - same JSON and same status code, which is a 400 unless otherwise stated. There have been other similar WGLC comments on this particular text so it's already on the list to reword for clarity. 
>  
> 
> Yeah, I think I follow and agree with you here. I'll try and add some more coverage/guidance on the topic. But if you have any concrete suggestions or text, I'd welcome it. 

I’ll see if I can suggest something to help with this. 

> The intent wasn't to allow it to be used more than once. But rather to avoid putting a strict requirement on the AS to enforce one-time-use (and the eventual certification tests that send the same URI twice within milliseconds). If that distinction makes any sense. It is much like an authorization code in many ways including the one-time-use text on code in RFC 6749 being subject to different interpretations :/ I would like to avoid different interpretations here.
> 
> For better or worse, that's some of the reasoning behind what's there now. But I'm open to changing the normative strength of the statement, if you and other folks in the WG feel it should be more MUSTy. And I'm certainly open to suggestions on better wording/explanation. 

Same comment as above. 

> Because of that and because it's already discussed to some extent in the body of the document, a separate privacy considerations section didn't seem needed. But we can look at adding a short section that says as much. 

I think having a specific section for privacy is important and should be added, even if it’s short. In this case I don’t think it would actually be all that short since you’re now hiding a lot of potentially privacy-leaking parameters from the browser.

 — Justin

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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 26 Aug 2020 14:44:21 -0600

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 <[email-masked]> wrote:

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

> 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 out there.
>
>
I'd be okay with making it a MUST but think maybe it'd be good to hear from
a few more people in the WG before committing to that change.

Can I ask some folks to weigh in on this one? I'm leaning towards making
the change barring objections.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 26 Aug 2020 15:16:12 -0700

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 <bcampbell=
[email-masked]> wrote:

> I'd be okay with making it a MUST but think maybe it'd be good to hear
> from a few more people in the WG before committing to that change.
>
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 27 Aug 2020 10:17:28 -0400

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 <[email-masked]> 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 <bcampbell=[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 25, 2020, at 6:01 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> I'd be okay with making it a MUST but think maybe it'd be good to hear from a few more people in the WG before committing to that change. 
> 
> Can I ask some folks to weigh in on this one? I'm leaning towards making the change barring objections. 
> 
> 
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 27 Aug 2020 09:11:57 -0700

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 <[email-masked]> 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
>
>> Thanks Justin. Just a couple more responses to responses inline below
>> (but with lots of content that needs no further discussion removed).
>>
>>>> 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.
>>>>
>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 29 Aug 2020 13:24:11 +0200

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 <[email-masked]> 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 Wed, Aug 26, 2020 at 1:45 PM Brian Campbell <bcampbell=[email-masked]> wrote:
>>>     ¶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 so, yes.. And will work on incorporating some text towards that end. 
>> 
>> 
>>  
>> 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
>> [email-masked]
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 29 Aug 2020 13:52:21 +0200

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

> 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”?

---

From: Justin Richer <[email-masked]>
Date: Sat, 29 Aug 2020 11:22:32 -0400

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 <[email-masked]> wrote:
> 
> 
>> 
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 29 Aug 2020 17:48:59 +0200

I gone draft this section.

> Am 29.08.2020 um 17:22 schrieb Justin Richer <[email-masked]>:
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 30 Aug 2020 15:48:01 -0700

I don't have the context of the text to respond to the exact wording, but I
think we can state that the client MUST use the "request_uri" only once,
and then explain that the AS may receive duplicate requests if the browser
is reloaded.

On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt <[email-masked]>
wrote:

> 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.
>
> > 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.
> >
> > 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
> >
> reloaded. Would the reload count as a second use? One could argue it either
> way.
> >>
> >> 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.
> >>
> >>
> >>
> >> ᐧ
> >>
> they could possibly have different semantics in both places..
> >>>
> >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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
> >> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 31 Aug 2020 09:39:50 -0600

I'm not sure how to word it exactly but I think Dick has landed on what we
ultimately want this to say. Basically that the "request_uri" is intended
to be used only once, the client MUST not use it more than once, and that
the AS should also treat it as one-time use but may make reasonable
accommodations to more gracefully handle redundant authorization requests
due to browser reload or similar.

On Sun, Aug 30, 2020 at 4:48 PM Dick Hardt <[email-masked]> wrote:

> I don't have the context of the text to respond to the exact wording, but
> I think we can state that the client MUST use the "request_uri" only once,
> On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt <
> [email-masked]> wrote:
>
>> >> 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.
>> >>
>> >> 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
>> >>>     I don’t see why a request URI with unguessable values isn’t a
>> MUST for one-time-use, is there a reason?
>> >>>