Re: [OAUTH-WG] draft-ietf-oauth-v2

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.hardt@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