Subject: [OAUTH-WG] Proposed note to RFC Editor

From: John Bradley <[email-masked]>
Date: Thu, 26 Jul 2012 13:33:33 -0700

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.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 Jul 2012 14:56:05 -0600

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-masked]> wrote:
> 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
>
>

---

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

+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-masked]] 
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-masked]> 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
>
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 26 Jul 2012 15:35:50 -0700

+1

On Jul 26, 2012, at 3:06 PM, Mike Jones wrote:

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

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 27 Jul 2012 10:07:56 +0900

+1

=nat via iPhone

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 27 Jul 2012 11:29:57 +1000

> this change breaks https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/

An underlying cause of this issue is that a single URI (the token endpoint) is overloaded for a dozen different tasks by a bunch of specs — and the list of tasks is still growing.

OAuth2 has built a RPC-style API, but almost pretends not to have done so by using grant_type names/URIs and a parameter registry instead of a more formal SOAP-style structure.

John’s proposed note to the RFC editor should address the immediate issue. Perhaps future enhancements, though, could consider a more RESTful approach. I think that would significantly clarify some of the complexities OAuth2 grapples with and minimise clashes between the various flows.

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Thu, 26 Jul 2012 22:24:13 -0700

Understood, however at this point major reworking of the token endpoint is going to have to wait on the next release of OAuth.

I suspect that there will eventually be a 2.1.

For now this should let us close the book on this 3 year odyssey and address some of the other issues like JWT etc.

John B.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 27 Jul 2012 07:40:44 +0200

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 <[email-masked]> schrieb:

Section 3.2.1

Change  to

Add

  client_id

Change

To:

---

From: Brian Campbell <[email-masked]>
Date: Fri, 27 Jul 2012 07:47:46 -0600

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:

   client_id

On Thu, Jul 26, 2012 at 11:40 PM, Torsten Lodderstedt
<[email-masked]> 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.
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 27 Jul 2012 16:36:06 +0200

Hi Brian,

I know. But there is this sentence in 3.2.1,

----------
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".
-----------

which explicitely discusses the authz code w/o saying this behavior is 
mandatory. People might "feel" a contradiction or difference to 4.1.3. I 
would suggest to either remove this sentence in 3.2.1 or change it to:

----------
In the "authorization_code" grant_type request to the token endpoint,
an unauthenticated client MUST send its "client_id" to prevent itself 
from
inadvertently accepting a code
intended for a client with a different "client_id".
-----------

regards,
Torsten.

Am 27.07.2012 15:47, schrieb Brian Campbell:
>>> parts of
>>> the spec caused by
>>> 4.1.4
>>> ** This allows any client to send client ID and explains the threat 
>>> to
>>> code.
>>>
>>>
>>> ** This makes client_id only REQUIRED for the code flow if the 
>>> client is
>>> not otherwise authenticated.
>>>
>>> Change
>>>
>>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 27 Jul 2012 09:08:22 -0600

Fair enough. I read 3.2.1 as being more informative and explanatory
while 4.1.3 has the actual normative requirements. But I see what you
are saying too.

On Fri, Jul 27, 2012 at 8:36 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> an unauthenticated client MUST send its "client_id" to prevent itself from
>
>>>> The changes introduced in Draft 29 had unintended consequences on parts
>>>> of
>>>> the spec caused by

---

From: John Bradley <[email-masked]>
Date: Fri, 27 Jul 2012 09:42:20 -0700

The text in 3.2.1 is informational to explain why there is a  REQUIRED is in 4.1.3. 

Putting the explanation in the parameter description seems awkward that is why I left it in 3.2.1 where the description that public clients can send client_id originally lived.

I also note that there is no other normative text in Sec 3.2.1 other than the first MUST that refers to sec 2.3, the rest of the text reads as an explanation of rationale for client authentication.   That is why I phrased it that way.

I personally try to make normative requirements once as I get enough stick about long specs:)

I am OK with making it normative by adding a MUST,  though I will leave it up to the Editor to decide on if  duplicating normative text is the preferred style.

On 2012-07-27, at 7:36 AM, Torsten Lodderstedt wrote:

> which explicitely discusses the authz code w/o saying this behavior is mandatory. People might "feel" a contradiction or difference to 4.1.3. I would suggest to either remove this sentence in 3.2.1 or change it to:
> 
> ----------

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Jul 2012 23:56:27 +0200

Hi John,

I would prefer to make it a MUST.

regards,
Torsten.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 30 Jul 2012 15:56:54 -0400

+1

Reason: Clarity is always good!

Igor

On 7/28/2012 5:56 PM, Torsten Lodderstedt wrote:
>> Putting the explanation in the parameter description seems awkward 
>> that is why I left it in 3.2.1 where the description that public 
>> clients can send client_id originally lived.
>>
>> I also note that there is no other normative text in Sec 3.2.1 other 
>> than the first MUST that refers to sec 2.3, the rest of the text 
>> reads as an explanation of rationale for client authentication.   
>> That is why I phrased it that way.
>>
>> I am OK with making it normative by adding a MUST,  though I will 
>> leave it up to the Editor to decide on if  duplicating normative text 
>> is the preferred style.
>>
>>
>>> which explicitely discusses the authz code w/o saying this behavior 
>>> is mandatory. People might "feel" a contradiction or difference to 
>>> 4.1.3. I would suggest to either remove this sentence in 3.2.1 or 
>>> change it to:
>>>
>>> ----------
>>>>>> ** This allows any client to send client ID and explains the 
>>>>>> threat to
>>>>>> code.
>>>>>>
>>>>>>