Subject: [OAUTH-WG] Finals nits on draft-ietf-oauth-par

From: Roman Danyliw <[email-masked]>
Date: Thu, 29 Jul 2021 17:30:25 +0000

Hi!

Thanks for the -08 version of draft-ietf-oauth-par and the associated discussion in response to the IESG review. 

Can you please spin a quick editorial revision to catch Murray's comments and respond to his question on Section 7.3.  See https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ballot/#murray-kucherawy.  These same comments are annotated below:

(Comment #1) Section 7.2:

* "An attacker could try register ..." -- s/try/try to/

[Roman] Typo still stands.

(Comment #2) In Section 7.3, I think that SHOULD ought to be a MUST.  Is there a good reason not to do what it says?

[Roman] Please explain why MUST doesn't make sense.

(Comment #3) The field names in Section 10.2 don't match the field names in the registry.

[Roman] s/Metadata Name/Client Metadata Name/

[Roman] s/Metadata Description/Client Metadata Description/

Regards,
Roman

---

From: Brian Campbell <[email-masked]>
Date: Thu, 29 Jul 2021 16:51:13 -0600

Apologies, I somehow missed the email with Murray's ballot comments. I'd
like to blame datatracker but just looked in the mail archive and there it
is https://mailarchive.ietf.org/arch/msg/oauth/Lvlk5kgi0NZS3W5mKSBb7r3ASPM/
so it must have been my mistake somewhere.

Comments 1 and 3 are addressed in
https://github.com/oauthstuff/draft-oauth-par/commit/9b6dcec72223cb4851d417facfb327b56234536c
and I'll look to spin a new draft (will actually be -10) soon.

Regarding comment 2 - there was some push from the WG for that SHOULD (vs
MUST) in Section 7.3 and a bit more of the reasoning behind it can be found
in the second paragraph of sec 4
https://www.ietf.org/archive/id/draft-ietf-oauth-par-09.html#name-authorization-request
that says,

"Since parts of the authorization request content, e.g. the code_challenge
parameter value, are unique to a particular authorization request, the
client MUST only use a request_uri value once. Authorization servers SHOULD
treat request_uri values as one-time use but MAY allow for duplicate
requests due to a user reloading/refreshing their user agent. An expired
request_uri MUST be rejected as invalid."

On Thu, Jul 29, 2021 at 11:30 AM Roman Danyliw <[email-masked]> wrote:

> Hi!
>
> Thanks for the -08 version of draft-ietf-oauth-par and the associated
> discussion in response to the IESG review.
>
> Can you please spin a quick editorial revision to catch Murray's comments
> and respond to his question on Section 7.3.  See
> https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ballot/#murray-kucherawy.
> These same comments are annotated below:
>
> (Comment #2) In Section 7.3, I think that SHOULD ought to be a MUST.  Is
> there a good reason not to do what it says?
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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: Thu, 29 Jul 2021 16:57:34 -0600

and the new draft has been spun
https://mailarchive.ietf.org/arch/msg/oauth/IoeHrompr78jKeXInsHNGXg1IjE/

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-par-10.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-10

On Thu, Jul 29, 2021 at 4:51 PM Brian Campbell <[email-masked]>
wrote:

> is
> https://mailarchive.ietf.org/arch/msg/oauth/Lvlk5kgi0NZS3W5mKSBb7r3ASPM/
> client MUST only use a request_uri value once. Authorization servers
> SHOULD treat request_uri values as one-time use but MAY allow for
> duplicate requests due to a user reloading/refreshing their user agent. An
> expired request_uri MUST be rejected as invalid."
>
>
>
>
>
>
>

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 29 Jul 2021 23:56:28 +0000

Hi Brian!

Thanks for this quick revision.  I’ve advanced the doc out of the IESG.

Congrats we’re almost there!

Roman

From: Brian Campbell <[email-masked]>
Sent: Thursday, July 29, 2021 6:51 PM
To: Roman Danyliw <[email-masked]>; Murray Kucherawy <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Finals nits on draft-ietf-oauth-par

Apologies, I somehow missed the email with Murray's ballot comments. I'd like to blame datatracker but just looked in the mail archive and there it is https://mailarchive.ietf.org/arch/msg/oauth/Lvlk5kgi0NZS3W5mKSBb7r3ASPM/ so it must have been my mistake somewhere.

Comments 1 and 3 are addressed in https://github.com/oauthstuff/draft-oauth-par/commit/9b6dcec72223cb4851d417facfb327b56234536c and I'll look to spin a new draft (will actually be -10) soon.

Regarding comment 2 - there was some push from the WG for that SHOULD (vs MUST) in Section 7.3 and a bit more of the reasoning behind it can be found in the second paragraph of sec 4 https://www.ietf.org/archive/id/draft-ietf-oauth-par-09.html#name-authorization-request that says,

"Since parts of the authorization request content, e.g. the code_challenge parameter value, are unique to a particular authorization request, the client MUST only use a request_uri value once. Authorization servers SHOULD treat request_uri values as one-time use but MAY allow for duplicate requests due to a user reloading/refreshing their user agent. An expired request_uri MUST be rejected as invalid."

On Thu, Jul 29, 2021 at 11:30 AM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

Regards,
Roman

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

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.