+1 On Jul 26, 2012, at 3:06 PM, Mike Jones wrote:
> +1 > > Given that the current spec inadvertently broke both the SAML profile and JWT > profile, I believe we need to make these changes. > > -- Mike > > -----Original Message----- > From: Brian Campbell [mailto:[email protected]] > Sent: Thursday, July 26, 2012 1:56 PM > To: John Bradley > Cc: oauth WG; Mike Jones > Subject: Re: Proposed note to RFC Editor > > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
