I think mentioning it when code is first described is sufficient. The token endpoint is normally part of a Authorization server and must both produce and consume the code.
I understand the request, but duplicating text for every step in a flow that parameter is used would cause the spec to be much larger. I don't see a need for a change at this point in the process. Regards John Bradley On 2012-07-17, at 4:56 PM, Dick Hardt wrote: > Thanks for the implementation feedback Michael. > > -- Dick > > On Jul 17, 2012, at 3:46 PM, Michael Scalia wrote: > >> Thanks for your response, Dick, and for pointing out that this is >> RECOMMENDED. I'll just say one more thing about this. While implementing >> the token endpoint of an authorization server, I naturally looked for the >> things I needed to account for in the request under 4.1.3 Access Token >> Request. I missed this because it wasn't with the other information about >> access token requests. Others may miss it as well, for the same reason. >> Just happened to notice this today under 4.1.2 while re-reading the spec. >> >> Regards, >> Michael >> >> On Tue, Jul 17, 2012 at 6:09 PM, Dick Hardt <dick.ha...@gmail.com> wrote: >> Thanks for the feedback Michael. >> >> 4.1.2 is where the authorization code is first talked about, and it makes >> sense to discuss how it is generated and used at that point. I can see how >> it might also be useful to put it in 4.1.3. Note that this is this is >> RECOMMENDED as opposed to MUST so it does not flow into "The authorization >> server MUST" list of points. >> >> Personally, I don't see a need to change. Anyone else have an opinion on >> this? >> >> -- Dick >> >> On Jul 17, 2012, at 2:22 PM, Michael Scalia wrote: >> >> > Dear OAuth Authors, >> > >> > I'm not sure if this is the right way to suggest an edit to the current >> > OAuth draft. Please let me know if I should use a different route. >> > >> > Section 4.1.2 Authorization Response includes the text, "If an >> > authorization code is used more than once, the authorization server MUST >> > deny the request and SHOULD revoke (when possible) all tokens previously >> > issued based on that authorization code. The authorization code is bound >> > to the client identifier and redirection URI." >> > >> > I believe this text is in the wrong place. A client does not supply the >> > authorization code to the authorization endpoint. It supplies it to the >> > token endpoint. This should move to 4.1.3. Access Token Request, in the >> > list of bulleted items under "The authorization server MUST". >> > >> > Thanks for all your work on this protocol. >> > >> > Regards, >> > Michael Scalia >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
