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

[Mike Jones <[e-mail]>]

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:[e-mail]] 
Sent: Monday, July 09, 2012 6:55 AM
To: Mike Jones
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Preliminary OAuth Core draft -29

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