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 <bcampb...@pingidentity.com> Sent: Thursday, July 29, 2021 6:51 PM To: Roman Danyliw <r...@cert.org>; Murray Kucherawy <superu...@gmail.com> Cc: oauth@ietf.org 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 <r...@cert.org<mailto:r...@cert.org>> 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 #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 _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
