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