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
