Subject: [OAUTH-WG] Issue: restriction on values characters

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 10:56:33 -0700

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

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 11:01:07 -0700

I trust your experience here, so +1.

On Thu, Apr 15, 2010 at 10:56 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Apr 2010 11:09:10 +1000

> I would like to proposal that the spec remains mute on the allowed parameter values

The spec isn't mute.
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: [email-masked] [mailto:[email-masked]] 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

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 07:51:01 -0700

>> I would like to proposal that the spec remains mute on the allowed parameter

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

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 01:14:03 +1000

> We will need to choose an encoding method for the header values

Not if we restrict the allowed chars in tokens to a very safe set of ~64 chars.

> and percent-encoding seems to make the most sense

It makes sense in URIs. In HTTP headers, however, I think it is more novel. There are quoted strings, \-escapes for a few chars, and some strange beast that does use %-encoding but not in double quotes and with a charset label.

> (though unlike OAuth 1.0, we will not detail the encoding function).

> Base64-ed values are hard to debug.

Debugging pesky %-escapes in base64 is annoying.
That can be avoided by specifying the base64-url encoding without '=' terminators.

If a party wants to represent an arbitrary byte array...
that's easy: apply the base64-url encoding without '=' terminators to the bytes

If a party wants to represent an arbitrary Unicode string...
that's easy: apply the base64-url encoding without '=' terminators to the UTF-8 encoding

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 08:27:24 -0700

By definition the header ABNF is going to limit the allowed characters. There is no way around that. As of right now, the only problem is with the token value because the other fit well with the 'token' ABNF. The signature is already base64 encoded and included as a quoted string.

So the question is, do we define an encoding scheme for tokens containing other characters not allowed, or not, leaving each server to figure out how to encode their tokens to fit the allowed set?

EHL

--
James Manger