How to escape the Authorization header's access_token value?

[Andrew Arnott]

In the likely even that the access_token has characters like " in them, the Client and Protected Data had better be prepared to escape/unescape the access token within the quotes that bound it.  What are the rules for this? Are they the standard for HTTP?  Should this be brought up in the spec to avoid people forgetting that detail and finding it as a bug later?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Marius Scurtescu]

I assume the token value should be represented as a quoted string,
which also means that it is not always necessary to enclose in double
quotes. But I agree, it would be good if the spec made that explicit.

Marius

> --
> You received this message because you are subscribed to the Google Groups
> "OAuth WRAP WG" group.
> To post to this group, send email to oauth-...@googlegroups.com.
> To unsubscribe from this group, send email to
> oauth-wrap-w...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>

[Dick Hardt]

Per RFC 2617 the Access Token is either a token or quoted string.

I had clarified this in 4.3 in draft-hardt-oauth-wrap-01/draft-hardt-oauth-wrap-01 in (attached)
What could I do to make that more clear?

-- Dick

[Marius Scurtescu]

Sorry, missed that in the latest draft.

Marius

[Andrew Arnott]

I think the reference to the RFC is clear.  But I can't find in that RFC any reference to escaping the value.  I'm not familiar with this RFC though, and so maybe I'm missing something. 

In particular, if the access token may be either a token or quoted-string as in the RFC, how will you discern:

Authorization: WRAP access_token="abc"

from

Authorization: WRAP access_token="abc"

?

They're exactly the same, except that in the first, the token is literally "abc", whereas in the second one it is merely abc.  If tokens are a base64 encoded string, as they certainly could be, then quotes, and commas, and other "reserved" characters will be present in these strings.  In some cases the base64 string could itself just happen to have a leading and trailing quote character, but that if trimmed off would lead to an invalid base64 sequence and a decoding error.

So, how can the two examples above be discerned? And how do we escape these special characters?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Mon, Feb 8, 2010 at 9:02 AM, Dick Hardt <dick....@gmail.com> wrote:

On 2010-02-08, at 8:46 AM, Marius Scurtescu wrote:

[Dick Hardt]

On 2010-02-08, at 7:37 PM, Andrew Arnott wrote:

> I think the reference to the RFC is clear. But I can't find in that RFC any reference to escaping the value. I'm not familiar with this RFC though, and so maybe I'm missing something.
>
> In particular, if the access token may be either a token or quoted-string as in the RFC, how will you discern:
> Authorization: WRAP access_token="abc"
> from
> Authorization: WRAP access_token="abc"
> ?
> They're exactly the same, except that in the first, the token is literally "abc", whereas in the second one it is merely abc. If tokens are a base64 encoded string, as they certainly could be, then quotes, and commas, and other "reserved" characters will be present in these strings.

> In some cases the base64 string could itself just happen to have a leading and trailing quote character, but that if trimmed off would lead to an invalid base64 sequence and a decoding error.

FYI: See RFC 4648

Base 64 only has '+'', /' and '='

URL safe Base 64 use '-', '_' and '=' for padding (which would not be needed in a token)

>

>
> So, how can the two examples above be discerned? And how do we escape these special characters

an Access Token must be able to be a valid quoted string or token in the HTTP header, so the restriction on what chars are valid are placed on the token generator.

[Andrew Arnott]

Doh!  I was sure the quote and comma characters showed up in base64, but I can see I was totally off base on that.  So nothing to see here.  Thanks, Dick.  Sorry for the noise.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--