On 4/15/10 6:09 PM, "James Manger" <james.h.man...@team.telstra.com> wrote:
>> I would like to proposal that the spec remains mute on the allowed parameter
>> values
>
> The spec isn't mute.
Yep, but we are not there yet. The ABNF was just copied over from another
draft and not updated yet. We will need to choose an encoding method for the
header values and percent-encoding seems to make the most sense (though
unlike OAuth 1.0, we will not detail the encoding function). Base64-ed
values are hard to debug.
EHL
> Currently, the draft spec uses HTTP's 'token' production for the value of an
> access token. Perhaps not surprising given the names.
> The ABNF for HTTP's 'token' allows only 89 characters. It excludes '=' for
> instance. It is designed NOT to need quoting in an HTTP header.
> Contradicting this, the draft spec requires double quotes around the access
> token value when in an HTTP header. It also uses a base64-encoding as an
> example that ends with '=' -- a disallowed character.
>
> Something needs to change.
>
> Either use 'quoted-string' for access tokens. That allows another ~20 ASCII
> chars, and \c escaping for other ASCII chars. I don't think there is any
> defined escaping for Unicode of bytes. Seemingly ad hoc choices such as %xx
> appeared in earlier OAuth example values, but I don't think it was ever
> defined.
>
> Or stick with 'token'; remove the quoting as unnecessary and hence misleading;
> change the example not to have '='; note that "normal" base64 cannot be used
> (need to exclude '=' and '/').
>
> Or restrict access tokens to a restricted set that never needs escaping
> anywhere (HTTP headers, URIs, query params, XML...). Recommend base64-url-safe
> without terminators whenever a byte array, or (UTF-8 encoded) unicode needs to
> be represented.
> I favour this approach.
>
> The client app and user browser that are just passing these opaque values
> around don't have to do any escaping. They should just do input validation
> (reject values with any disallowed chars).
>
>
>
> P.S. 'token' may be changing in the revision of HTTP currently being written.
>
>
>
> --
> James Manger
>
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
> Hammer-Lahav
> Sent: Friday, 16 April 2010 3:57 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Issue: restriction on values characters
>
> Given the current proposal for signatures (no parsing of the request URI or
> body, or any encoding), I would like to proposal that the spec remains mute
> on the allowed parameter values.
>
> While it is best to issue values that do not require any encoding (or
> decoding when receiving a token response), encoding and decoding
> form-encoded parameter is trivial and provided automatically by every
> platform.
>
> The only issues with encoding in 1.0a related to signatures and the
> production of the base string. This is no longer an issue.
>
> Proposal: close issue without further action.
>
> EHL
>
> _______________________________________________
> 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
