Subject: Re: [OAUTH-WG] overreach of the scope of when client_id is required from public clients?

From: Mike Jones <[email-masked]>
Date: Thu, 26 Jul 2012 17:21:19 +0000

I agree that we need to mitigate this unintended side effect of the change.  Stephen and chairs, I don't know where we are with the RFC editor submission process, but if you need to do anything to put a hold on that, it might be a good idea.

The fact that this change breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ is pretty clear evidence that we can't just let this go.

Thanks for looking into a mitigating change, John.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, July 26, 2012 9:39 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] overreach of the scope of when client_id is required from public clients?

In thinking some more about this.  Affecting grants other than code was unintentional, and due to document structure.

I will talk to Brian today and come up with some wording that could go to the RFC editor to make that clear.

John B.
On 2012-07-25, at 12:07 PM, Brian Campbell wrote:

> In -29 the quoted text below was introduced to §3.2.1 Client 
> Authentication [1] to protect clients against authorization code 
> substitution. However, the text's placement under 3.2. Token Endpoint 
> [2] and some of the wording suggest that public clients must use 
> client_id on all requests to the token endpoint, regardless of grant 
> type, even though the change was introduced only to mitigate an issue 
> with the authentication code.
> 
> "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.)"
> 
> Was the change intended to be that broad? I think it goes too far.
> There are cases, like extension grants and even the resource owner 
> credentials grant type, where it's useful to allow requests from 
> unidentified clients.
> 
> Could that text (or the spirit of it) be moved somewhere under the 
> specific sections on the Authorization Code Grant so that it only 
> applies to that grant type?
> 
> 
> A somewhat related issue is the following text from §2.3. Client 
> Authentication
> 
> "the authorization server MUST NOT rely
>   on public client authentication for the purpose of identifying the
>   client."
> 
> which seems to contradict the text from  §3.2.1 above as well as the 
> following from 4.1.3. Access Token Request [3]
> 
> "o  ensure the authorization code was issued to the authenticated
>      confidential client or to the public client identified by the
>      "client_id" in the request,
> 
> Should the text in §2.3 be loosened or somehow qualified so it doesn't 
> read like a contradiction?
> 
> Thanks,
> Brian
> 
> 
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2.1
> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.2
> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-2.3
> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-4.1.3
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth