Fair enough. I read 3.2.1 as being more informative and explanatory while 4.1.3 has the actual normative requirements. But I see what you are saying too.
On Fri, Jul 27, 2012 at 8:36 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi Brian, > > I know. But there is this sentence in 3.2.1, > > ---------- > > In the "authorization_code" grant_type request to the token endpoint, > an unauthenticated client sends "client_id" to prevent itself from > inadvertently accepting a code > intended for a client with a different "client_id". > ----------- > > which explicitely discusses the authz code w/o saying this behavior is > mandatory. People might "feel" a contradiction or difference to 4.1.3. I > would suggest to either remove this sentence in 3.2.1 or change it to: > > ---------- > > In the "authorization_code" grant_type request to the token endpoint, > an unauthenticated client MUST send its "client_id" to prevent itself from > > inadvertently accepting a code > intended for a client with a different "client_id". > ----------- > > regards, > Torsten. > > Am 27.07.2012 15:47, schrieb Brian Campbell: > >> Hey Torsten, >> >> The requirement that public clients send their client_id with an authz >> code grant is in 4.1.3 (Where the Access Token Request for the code >> grant is defined) of John's proposed text: >> >> 4.1.3. Access Token Request >> >> client_id >> REQUIRED if the client is NOT authenticating with the >> authorization server as described in Section 3.2.1 >> >> >> >> >> On Thu, Jul 26, 2012 at 11:40 PM, Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >>> >>> Hi John, >>> >>> I would expect sending a client_id is a MUST for public clients in the >>> authz >>> code grant type. That's not how I read the proposed text for section 3.1. >>> >>> regards, >>> Torsten. >>> >>> >>> >>> John Bradley <ve7...@ve7jtb.com> schrieb: >>>> >>>> >>>> The changes introduced in Draft 29 had unintended consequences on parts >>>> of >>>> the spec caused by >>>> Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 as part of client >>>> authentication. >>>> >>>> This change restricts the requirement to send client_id to only Sec >>>> 4.1.4 >>>> for clients that are not authenticated per Sec 3.2.1 >>>> >>>> >>>> >>>> >>>> Section 3.2.1 >>>> >>>> >>>> A public client that was not issued a client password MUST use the >>>> "client_id" request parameter to identify itself when sending >>>> requests to the token endpoint. This allows the authorization server >>>> to ensure that the code was issued to the same client. Sending >>>> "client_id" prevents the client from inadvertently accepting a code >>>> intended for a client with a different "client_id". This protects >>>> the client from substitution of the authentication code. (It >>>> provides no additional security for the protected resource.) >>>> >>>> >>>> Change to >>>> >>>> A client MAY use the "client_id" request parameter to identify itself >>>> when sending requests to the token endpoint. >>>> In the "authorization_code" grant_type request to the token endpoint, >>>> an unauthenticated client sends "client_id" to prevent itself from >>>> inadvertently accepting a code >>>> intended for a client with a different "client_id". This protects >>>> the client from substitution of the authentication code. (It >>>> provides no additional security for the protected resource.) >>>> >>>> >>>> ** This allows any client to send client ID and explains the threat to >>>> code. >>>> >>>> >>>> 4.1.3. Access Token Request >>>> >>>> >>>> >>>> Add >>>> client_id >>>> REQUIRED if the client is NOT authenticating with the >>>> authorization server as described in Section 3.2.1 >>>> >>>> >>>> >>>> >>>> ** This makes client_id only REQUIRED for the code flow if the client is >>>> not otherwise authenticated. >>>> >>>> Change >>>> >>>> >>>> ensure the authorization code was issued to the authenticated >>>> confidential client or to the public client identified by the >>>> "client_id" in the request, >>>> >>>> >>>> To: >>>> ensure the authorization code was issued to the authenticated >>>> confidential client, or if the client is public, ensure the code >>>> was >>>> issued to "client_id" in the request, >>>> >>>> >>>> ** That removes the implication of authentication. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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
