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
