+1 =nat via iPhone
On 2012/07/27, at 7:36, Dick Hardt <dick.ha...@gmail.com> wrote: > +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:bcampb...@pingidentity.com] >> 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 <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 > > _______________________________________________ > 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
