I agree with the proposed changes and they do adequately address the concerns I raised in a previous message about the unintended breaking changes introduced in 29. Thanks for writing that up John.
On Thu, Jul 26, 2012 at 2:33 PM, John Bradley <ve7...@ve7jtb.com> wrote: > 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
