You're correct that I misspoke. The Authorization Server and the Resource
Server must agree on the format of the token. Yes, it's opaque to the client.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul
Madsen
Sent: Wednesday, May 25, 2011 6:50 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] bearer token authorization header
Mike/George, can you clarify in what sense must a client and RS agree on the
format of a bearer token? Are they not opaque to the client, and so their
internal format irrelevant to it?
paul
On 5/24/11 4:04 PM, Mike Jones wrote:
> George, you are correct that resources and clients must agree upon the format
> of the bearer token to achieve interoperability. The means for achieving
> this agreement is out of the scope of this document.
>
> -- Mike
>
> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurte...@google.com]
> Sent: Tuesday, May 24, 2011 11:28 AM
> To: George Fletcher
> Cc: Mike Jones; OAuth WG
> Subject: Re: [OAUTH-WG] bearer token authorization header
>
> The "printable non-whitespace ASCII characters" represents the access token,
> which is supposed to be opaque. I don't think this affects libraries.
>
> Marius
>
>
>
> On Tue, May 24, 2011 at 10:24 AM, George Fletcher<gffle...@aol.com> wrote:
>> Do I understand this correctly that each resource owner can define
>> it's own format for the "printable non-whitespace ASCII characters"?
>> It seems like that would make it difficult for clients to use
>> standard libraries because the Authorization header format could be
>> different on a per resource/host basis.
>>
>> Thanks,
>> George
>>
>> On 5/23/11 3:10 PM, Mike Jones wrote:
>>
>> [snip]
>>
>>
>>
>> The fact that there is no escaping mechanism can potentially create
>> problems. The list of allowed characters is spelled out, but what if
>> some implementation uses other characters? Using a name value pair
>> and proper escaping is much safer IMO. For example:
>>
>> Bearer token=dfgh76dfghdfg
>>
>> or
>>
>> Bearer token="dfgh76dfghdfg"
>>
>>
>>
>> The value above can be either a token or a quoted string. HTTP header
>> parsers know how to parse tokens and quoted strings so an implementor
>> has a better chance of doing it right.
>>
>>
>>
>> Mark Lentczner started a thread on this regard a few moths ago, James
>> Manger replied and suggested something similar:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
>>
>>
>>
>> If it is too late to switch to a name/value pair, then I think we
>> should at least clean up the references.
>>
>> The definition allows the access token to be any string of one or
>> more printable non-whitespace ASCII characters. Thus, legal access
>> token strings include ones like the ones you are asking for, such as:
>>
>> param="value"
>>
>>
>>
>> -- Mike
>>
>>
>>
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Monday, May 09, 2011 10:32 AM
>> To: OAuth WG; Mike Jones
>> Cc: Mark Lentczner; Manger, James H
>> Subject: bearer token authorization header
>>
>>
>>
>> I am working through version 04 of the Bearer Token draft:
>>
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04
>>
>>
>>
>> Not sure how to interpret the authorization header grammar described
>> in section 2.1. The intent seems to be for something like:
>>
>> Bearer dfgh76dfghdfg
>>
>>
>>
>> After the scheme name, "Bearer", there is a required whitespace
>> followed by the actual token. The token is represented by a sequence
>> of printable characters, no escaping. No spaces or other elements are
>> allowed after the token. Is that correct?
>>
>>
>>
>> RWS is not defined, I assume it is the "required whitespace" from
>> section
>> 1.2.2 of:
>>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13
>>
>>
>>
>> There is a reference to RFC2617, but not sure why. That seems to
>> imply that a list of values can be specified, which is not the case.
>>
>>
>>
>> The fact that there is no escaping mechanism can potentially create
>> problems. The list of allowed characters is spelled out, but what if
>> some implementation uses other characters? Using a name value pair
>> and proper escaping is much safer IMO. For example:
>>
>> Bearer token=dfgh76dfghdfg
>>
>> or
>>
>> Bearer token="dfgh76dfghdfg"
>>
>>
>>
>> The value above can be either a token or a quoted string. HTTP header
>> parsers know how to parse tokens and quoted strings so an implementor
>> has a better chance of doing it right.
>>
>>
>>
>> Mark Lentczner started a thread on this regard a few moths ago, James
>> Manger replied and suggested something similar:
>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg04671.html
>>
>>
>>
>> If it is too late to switch to a name/value pair, then I think we
>> should at least clean up the references.
>>
>>
>>
>> Marius
>>
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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
