This looks right to me (and I'm in a boring meeting processing errata:-) so I'm gonna mark it as verified. Please let me know if that's wrong.
S On 02/26/2013 05:07 PM, RFC Errata System 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_search.php?rfc=6749&eid=3500 > > -------------------------------------- > Type: Editorial > Reported by: John Field <johnp.fi...@emc.com> > > Section: 4.1 > > Original Text > ------------- > (E) The authorization server authenticates the client, validates the > authorization code, and ensures that the redirection URI > received matches the URI used to redirect the client in > step (C). If valid, the authorization server responds back with > an access token and, optionally, a refresh token. > > Corrected Text > -------------- > (E) The authorization server authenticates the client, validates the > authorization code, and ensures that the redirection URI > received matches the URI used to redirect (the resource owner's > user-agent) > to the client in step (C). If valid, the authorization server > responds back with an access token and, optionally, a refresh token. > > Notes > ----- > The URI in question is the URI that was used to redirect the resource owner's > user-agent back to the client to deliver the code. The original text in step > (E) seems to say that this URI was used to redirect the client, but I think > this is an ambiguous/imprecise use of the word "client." It was not the > OAuth client that was redirected using that URI, it was the resource owner's > user-agent that was redirected, *to* the client. > > The parenthetical (the resource owner's user-agent) is more precise but may > perhaps be too verbose. I think, at minimum, we must say "....the URI used > to redirect *to* the client in step (C)." > > Instructions: > ------------- > This errata 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 (IESG) > 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
