Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5708)

From: Justin Richer <[email-masked]>
Date: Mon, 13 May 2019 18:05:56 +0000

I see the intent of the change but I don’t think this is actually at the level of an erratum. This seems to be a normative change on a key extension point.

Additionally, with the singleton nature imposed by the current text, there’s a 1:1 mapping between the request parameters and a JSON object, as would be found in a signed request object. Anything that changes that assumption should not be taken lightly.

— Justin

On Apr 29, 2019, at 8:29 AM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5708

--------------------------------------
Type: Editorial
Reported by: Brian Campbell <[email-masked]>

Section: 3.1 and 3.2

Original Text
-------------
Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server MUST ignore
unrecognized request parameters.  Request and response parameters
MUST NOT be included more than once.

Corrected Text
--------------
Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server MUST ignore
unrecognized request parameters.  Request and response parameters
defined by this specification MUST NOT be included more than once.

Notes
-----
Adds the text "defined by this specification" to the last sentence to clarify that the restriction only applies to parameters defined in RFC 6749 and not to unrecognized parameters or parameters defined by extension.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG

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

---

From: William Denniss <[email-masked]>
Date: Mon, 13 May 2019 12:20:42 -0700

+1 to Justin

Could this be handled in the extension spec potentially? Eg calling out
that OAuth has that requirement, but documenting an extension-specific case
that modifies it?

William

*From: *Justin Richer <[email-masked]>
*Date: *Mon, May 13, 2019 at 11:06 AM
*To: *RFC Errata System
*Cc: [email-masked]

I see the intent of the change but I don’t think this is actually at the
> level of an erratum. This seems to be a normative change on a key extension
> point.
>
> Additionally, with the singleton nature imposed by the current text,
> there’s a 1:1 mapping between the request parameters and a JSON object, as
> would be found in a signed request object. Anything that changes that
> assumption should not be taken lightly.
>
> — Justin
>
> On Apr 29, 2019, at 8:29 AM, RFC Errata System <[email-masked]>
> wrote:
>
> Adds the text "defined by this specification" to the last sentence to
> clarify that the restriction only applies to parameters defined in RFC 6749
> and not to unrecognized parameters or parameters defined by extension.
>
> Instructions:
> -------------