Subject: [OAUTH-WG] Preliminary OAuth Core draft -29

From: Mike Jones <[email-masked]>
Date: Mon, 9 Jul 2012 07:08:56 +0000

A preliminary version of OAuth core draft -29 is attached for the working group's consideration and discussion on today's call.  I believe that this addresses all issues that have been raised, including Julian's issues about the ABNF, character sets, and form encoding.  Changes are:

  *   Added "MUST" to "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" and added text explaining why this must be so.
  *   Added that the authorization server MUST "ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request".
  *   Added Security Considerations section "Misuse of Access Token to Impersonate Resource Owner at Public Client".
  *   Deleted ";charset=UTF-8" from examples formerly using "Content-Type: application/x-www-form-urlencoded;charset=UTF-8".
  *   Added the phrase "and a character encoding of UTF-8" when describing how to send requests using the HTTP request entity-body, per Julian Reschke's suggestion.
  *   Added "The ABNF below is defined in terms of Unicode code points [UNICODE5]; these characters are typically encoded in UTF-8".
  *   For symmetry when using HTTP Basic authentication, also apply the application/x-www-form-urlencoded encoding to the client password, just as was already done for the client identifier.
  *   Reduced multiple blank lines around artwork elements to single blank lines.
  *   Removed Eran Hammer's name from the author list, at his request. Dick Hardt is now listed as the editor.

                                                            Best wishes,
                                                            -- Mike

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jul 2012 15:55:20 +0200

On 2012-07-09 09:08, Mike Jones wrote:
> A preliminary version of OAuth core draft -29 is attached for the
> working group’s consideration and discussion on today’s call.  I believe
> that this addresses all issues that have been raised, including Julian’s
> issues about the ABNF, character sets, and form encoding.  Changes are:
>
>   * Added "MUST" to "A public client that was not issued a client
>     password MUST use the client_idrequest parameter to identify itself
>     when sending requests to the token endpoint" and added text
>     explaining why this must be so.
>   * Added that the authorization server MUST "ensure the authorization
>     code was issued to the authenticated confidential client or to the
>     public client identified by the client_idin the request".
>   * Added Security Considerations section "Misuse of Access Token to
>     Impersonate Resource Owner at Public Client".
>   * Deleted ";charset=UTF-8" from examples formerly using "Content-Type:
>     application/x-www-form-urlencoded;charset=UTF-8".
>   * Added the phrase "and a character encoding of UTF-8" when describing
>     how to send requests using the HTTP request entity-body, per Julian
>     Reschke's suggestion.

I still think that citing HTML4 here doesn't work; the definition of the 
media type in HTML4 is known to be insufficient. What's the reason for 
not citing the HTML4 working draft here?

>   * Added "The ABNF below is defined in terms of Unicode code points
>     [UNICODE5]; these characters are typically encoded in UTF-8".
>   * For symmetry when using HTTP Basic authentication, also apply the
>     application/x-www-form-urlencodedencoding to the client password,
>     just as was already done for the client identifier.

That's kind of surprising; what's the rational for this?

Also, given the complexity of x-www-form-urlencoded, I really really 
believe there should be examples of using it with non-ASCII characters.

Finally, the ABNF still fails to address my concerns from a few weeks 
ago: <https://www.ietf.org/mail-archive/web/oauth/current/msg09219.html>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jul 2012 16:04:17 +0200

On 2012-07-09 15:55, Julian Reschke wrote:
 > ...

s/4/5/, of course.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 9 Jul 2012 14:48:54 +0000

HTML5 is not cited because it's a working draft - not an approved standard.  In what way is "the definition of the media type in HTML4 is known to be insufficient"?  People have been successfully implementing form-urlencoding with it for quite some time. :-)  Is there a specific wording change that you'd suggest that we make that doesn't involve citing a working draft, rather than an approved standard?

I'm not sure what aspect of https://www.ietf.org/mail-archive/web/oauth/current/msg09219.html you feel hasn't been addressed.  The restriction prohibiting colon has been removed from the ABNF, like you asked.  Using form-urlencoding when passing parameters through HTTP Basic enables a wider repertoire of characters to be used - again, something you'd asked for.

I used your example from http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1 when wording the statement that "The ABNF below is defined in terms of Unicode code points".  That covers the topics raised in your message about the ABNF.  So I really don't understand in what way that statement fails to address your concerns.

I've done my best to intuit your intent based on your brief comments and address it, and apparently come up short in some way(s) that I can't identify from your response below.  Again, if you could propose specific wording changes, that would remove the ambiguity from your remarks and we could stop going back and forth on this.

I hope you can be on the call in ~2 hours as well.

				Thank you,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 6:55 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Preliminary OAuth Core draft -29

On 2012-07-09 09:08, Mike Jones wrote:
> working group's consideration and discussion on today's call.  I 
> believe that this addresses all issues that have been raised, 
> including Julian's issues about the ABNF, character sets, and form encoding.  Changes are:
>

I still think that citing HTML4 here doesn't work; the definition of the media type in HTML4 is known to be insufficient. What's the reason for not citing the HTML4 working draft here?

Also, given the complexity of x-www-form-urlencoded, I really really believe there should be examples of using it with non-ASCII characters.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jul 2012 17:01:33 +0200

> HTML5 is not cited because it's a working draft - not an approved standard.  In what way is "the definition of the media type in HTML4 is known to be insufficient"?  People have been successfully i…

For instance, the HTML4 "definition" doesn't even mention what to do 
with non-ASCII characters.

I understand that it's not particularly attractive, but citing HTML4 
just because it's a "standard" isn't really helpful for people who 
actually follow the link and try to understand what needs to be implemented.

> I'm not sure what aspect of https://www.ietf.org/mail-archive/web/oauth/current/msg09219.html you feel hasn't been addressed.  The restriction prohibiting colon has been removed from the ABNF, like…

Sorry, I missed that one; I was looking at the

   UNICODENOCTRLCHAR = <Any Unicode character other than (%x0-1F / %x7F)>

where you had asked for a better way to define it, and that's also in 
the link I sent.

With respect to the original question: you now say that *all* ABNF 
productions define the syntax in terms of Unicode code points. It that's 
the case all is well; but I didn't want to propose that because I don't 
have sufficient knowledge of the contexts where these protocol elements 
are used.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 9 Jul 2012 15:36:17 +0000

What's the syntax for defining UNICODENOCTRLCHAR in a better way?  I'd be eager to incorporate that.  I failed to find that part from your link.

				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 8:02 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Preliminary OAuth Core draft -29

> HTML5 is not cited because it's a working draft - not an approved standard.  In what way is "the definition of the media type in HTML4 is known to be insufficient"?  People have been successfully i…

For instance, the HTML4 "definition" doesn't even mention what to do with non-ASCII characters.

I understand that it's not particularly attractive, but citing HTML4 just because it's a "standard" isn't really helpful for people who actually follow the link and try to understand what needs to be implemented.

where you had asked for a better way to define it, and that's also in the link I sent.

With respect to the original question: you now say that *all* ABNF productions define the syntax in terms of Unicode code points. It that's the case all is well; but I didn't want to propose that because I don't have sufficient knowledge of the contexts where these protocol elements are used.

Best regards, Julian

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Jul 2012 11:44:56 -0400

Given we are making the changes to the public client code flow.

I would change the name of the security consideration to:
> Misuse of Access Token to Impersonate Resource Owner in Implicit Flow

Sorry I forgot to change that when I sent it.

John B.

On 2012-07-09, at 3:08 AM, Mike Jones wrote:

> A preliminary version of OAuth core draft -29 is attached for the working group’s consideration and discussion on today’s call.  I believe that this addresses all issues that have been raised, including Julian’s issues about the ABNF, character sets, and form encoding.  Changes are:
>  
> Added "MUST" to "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" and added text explaining why this must be so.
> Added that the authorization server MUST "ensure the authorization code was issued to the authenticated confidential client or to the public client identified by the client_id in the request".
> Added Security Considerations section "Misuse of Access Token to Impersonate Resource Owner at Public Client".
> Deleted ";charset=UTF-8" from examples formerly using "Content-Type: application/x-www-form-urlencoded;charset=UTF-8".
> Added the phrase "and a character encoding of UTF-8" when describing how to send requests using the HTTP request entity-body, per Julian Reschke's suggestion.
> Added "The ABNF below is defined in terms of Unicode code points [UNICODE5]; these characters are typically encoded in UTF-8".
> For symmetry when using HTTP Basic authentication, also apply the application/x-www-form-urlencoded encoding to the client password, just as was already done for the client identifier.
> Reduced multiple blank lines around artwork elements to single blank lines.
> Removed Eran Hammer's name from the author list, at his request. Dick Hardt is now listed as the editor.
>  
>                                                             Best wishes,
>                                                             -- Mike
>  
> <draft-ietf-oauth-v2-29 preliminary.txt><draft-ietf-oauth-v2-29 preliminary.html><draft-ietf-oauth-v2-29 preliminary.pdf><draft-ietf-oauth-v2-29 preliminary.xml>_______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jul 2012 17:50:26 +0200

> What's the syntax for defining UNICODENOCTRLCHAR in a better way?  I'd be eager to incorporate that.  I failed to find that part from your link.

Just change

   UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>

to

   UNICODENOCTRLCHAR = %x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF

(inspired by <http://www.w3.org/TR/REC-xml/#charsets>).

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 9 Jul 2012 16:15:43 +0000

OK - will do

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 8:50 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Preliminary OAuth Core draft -29

Just change

to

Best regards, Julian

---

From: Dick Hardt <[email-masked]>
Date: Mon, 9 Jul 2012 10:31:49 -0700

Hi Mike

Reading over the spec, I think some more color in 4.2 on the risks of the Implicit Grant and where it makes sense and where it does not is in order. 
Also, this should be in Section 9.

Thoughts?

-- Dick

---

From: Justin Richer <[email-masked]>
Date: Mon, 9 Jul 2012 16:21:09 -0400

Implicit grant makes perfect sense when the user agent and client are 
collapsed into a single entity. In other words, if your client is inside 
the user agent then doing a code flow doesn't actually buy you any extra 
security. This is the driving design decision behind having it in there, 
and from my perspective that's clear from the current text.

In a similar manner, the client credentials flow came about from 
collapsing the client with the resource owner, effectively putting the 
resource owner inside the client. In this case the authorization step 
doesn't make any sense and doing a code flow doesn't buy you any greater 
security, either.

  -- Justin

On 07/09/2012 01:31 PM, Dick Hardt wrote:
> Hi Mike
>
> Reading over the spec, I think some more color in 4.2 on the risks of 
> the Implicit Grant and where it makes sense and where it does not is 
> in order.
>>     password MUST use theclient_idrequest parameter to identify
>>     itself when sending requests to the token endpoint" and added
>>     text explaining why this must be so.
>>   * Added that the authorization server MUST "ensure the
>>     authorization code was issued to the authenticated confidential
>>     client or to the public client identified by theclient_idin the
>>     request".
>>   * Deleted ";charset=UTF-8" from examples formerly using
>>     "Content-Type: application/x-www-form-urlencoded;charset=UTF-8".
>>   * Added the phrase "and a character encoding of UTF-8" when
>>     describing how to send requests using the HTTP request
>>     entity-body, per Julian Reschke's suggestion.
>>   * For symmetry when using HTTP Basic authentication, also apply
>>     theapplication/x-www-form-urlencodedencoding to the client
>>     password, just as was already done for the client identifier.
>> <draft-ietf-oauth-v2-29 preliminary.txt><draft-ietf-oauth-v2-29 
>> preliminary.html><draft-ietf-oauth-v2-29 
>> preliminary.pdf><draft-ietf-oauth-v2-29 
>> preliminary.xml>_______________________________________________
>> OAuth mailing list
>> [email-masked] <mailto:[email-masked]>
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Mon, 9 Jul 2012 13:31:02 -0700

On Jul 9, 2012, at 1:21 PM, Justin Richer wrote:

> Implicit grant makes perfect sense when the user agent and client are collapsed into a single entity. In other words, if your client is inside the user agent then doing a code flow doesn't actually buy you any extra security.

It protects the client from an attacker replacing the access token.

> This is the driving design decision behind having it in there, and from my perspective that's clear from the current text.

I think the reasons for implicit flow are captured in 1.3.2, and it would be useful to point to them in 4.2 

> 
> In a similar manner, the client credentials flow came about from collapsing the client with the resource owner, effectively putting the resource owner inside the client.

It can be thought of like that, but that is not where it came from.

> In this case the authorization step doesn't make any sense and doing a code flow doesn't buy you any greater security, either.

One can think of the client credential flow as the client already having the code and that the authorization happened out of band. No need to change any copy.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jul 2012 10:31:18 +0200

On 2012-07-09 17:01, Julian Reschke wrote:
>> HTML5 is not cited because it's a working draft - not an approved
>> standard.  In what way is "the definition of the media type in HTML4
>> is known to be insufficient"?  People have been successfully
>> implementing form-urlencoding with it for quite some time. :-)  Is
>> there a specific wording change that you'd suggest that we make that
>> doesn't involve citing a working draft, rather than an approved standard?
>

Here's an attempt to describe the encoding in terms of HTML4, plus 
additional instruction. This would need to be referenced anyway where 
the spec currently refers to the HTML4 media type definition:

-- snip --
Appendix X. Use of the application/x-www-form-urlencoded Media Type

At the time of publication of this specification, the 
"application/x-www-form-urlencoded" media type was defined in Section 
17.13.4 of [HTML4], but not registered in the IANA media types registry 
(<http://www.iana.org/assignments/media-types/index.html>). Furthermore, 
the definition is incomplete as it does not consider non-US-ASCII 
characters.

To address this shortcoming, when generating payloads using this media 
type, names and values MUST be encoded using the "UTF-8" character 
encoding scheme ([RFC3629]) first; the resulting octet sequence then 
needs to be further encoded using the escaping rules defined in [HTML4].

When parsing data from a payload using this media type, the names and 
values resulting from reversing the name/value encoding consequently 
need to be treated as octet sequences, to be decoded using the "UTF-8" 
character encoding scheme.

Example: A value consisting of the six Unicode code points (1) U+0020 
(SPACE), (2) U+0025 (PERCENT SIGN), (3) U+0026 (AMPERSAND), (4) U+002B 
(PLUS SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would 
be encoded into the octet sequence below (using hexadecimal notation):

   20 25 26 2B C2 A3 E2 82 AC

and then represented in the payload as:

   +%25%26%2B%C2%A3%E2%82%AC

-- snip --

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Jul 2012 14:46:13 +0000

Thanks, Julian.  Dick and I will integrate this into the draft.

				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Thursday, July 12, 2012 1:31 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Preliminary OAuth Core draft -29

> actually follow the link and try to understand what needs to be 

Here's an attempt to describe the encoding in terms of HTML4, plus additional instruction. This would need to be referenced anyway where the spec currently refers to the HTML4 media type definition:

-- snip --

At the time of publication of this specification, the "application/x-www-form-urlencoded" media type was defined in Section
17.13.4 of [HTML4], but not registered in the IANA media types registry (<http://www.iana.org/assignments/media-types/index.html>). Furthermore, the definition is incomplete as it does not consider non-US-ASCII characters.

To address this shortcoming, when generating payloads using this media type, names and values MUST be encoded using the "UTF-8" character encoding scheme ([RFC3629]) first; the resulting octet sequence then needs to be further encoded using the escaping rules defined in [HTML4].

When parsing data from a payload using this media type, the names and values resulting from reversing the name/value encoding consequently need to be treated as octet sequences, to be decoded using the "UTF-8" 
character encoding scheme.

Example: A value consisting of the six Unicode code points (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN), (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded into the octet sequence below (using hexadecimal notation):

-- snip --

Best regards, Julian

---

From: Dick Hardt <[email-masked]>
Date: Thu, 12 Jul 2012 09:17:00 -0700

Much appreciated Julian!

On Jul 12, 2012, at 1:31 AM, Julian Reschke wrote:

> At the time of publication of this specification, the "application/x-www-form-urlencoded" media type was defined in Section 17.13.4 of [HTML4], but not registered in the IANA media types registry (<http://www.iana.org/assignments/media-types/index.html>). Furthermore, the definition is incomplete as it does not consider non-US-ASCII characters.
> 
> When parsing data from a payload using this media type, the names and values resulting from reversing the name/value encoding consequently need to be treated as octet sequences, to be decoded using the "UTF-8" character encoding scheme.
>