The text in 3.2.1 is informational to explain why there is a REQUIRED is in 4.1.3.
Putting the explanation in the parameter description seems awkward that is why I left it in 3.2.1 where the description that public clients can send client_id originally lived. I also note that there is no other normative text in Sec 3.2.1 other than the first MUST that refers to sec 2.3, the rest of the text reads as an explanation of rationale for client authentication. That is why I phrased it that way. I personally try to make normative requirements once as I get enough stick about long specs:) I am OK with making it normative by adding a MUST, though I will leave it up to the Editor to decide on if duplicating normative text is the preferred style. On 2012-07-27, at 7:36 AM, Torsten Lodderstedt 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
