+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 protected]> *Date: *Mon, May 13, 2019 at 11:06 AM *To: *RFC Errata System *Cc: *[email protected] 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 protected]> > 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 protected]> > > 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 protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
