+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
