Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread George Fletcher
...@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

Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread Marius Scurtescu
Subject: Re: [OAUTH-WG] bearer token authorization header On May 24, 2011, at 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

Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread Mike Jones
You got it right. :-) -Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] Sent: Thursday, May 26, 2011 9:16 AM To: George Fletcher Cc: Mike Jones; John Kemp; OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header Maybe I created some confusion. Earlier

Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread William J. Mills
From: Marius Scurtescu mscurte...@google.com To: George Fletcher gffle...@aol.com Cc: OAuth WG oauth@ietf.org Sent: Thursday, May 26, 2011 9:15 AM Subject: Re: [OAUTH-WG] bearer token authorization header Maybe I created some confusion. Earlier in the thread I

Re: [OAUTH-WG] bearer token authorization header

2011-05-25 Thread Paul Madsen
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

Re: [OAUTH-WG] bearer token authorization header

2011-05-25 Thread John Kemp
] 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

Re: [OAUTH-WG] bearer token authorization header

2011-05-25 Thread Mike Jones
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

Re: [OAUTH-WG] bearer token authorization header

2011-05-25 Thread Mike Jones
, May 25, 2011 10:11 AM To: Mike Jones Cc: Marius Scurtescu; George Fletcher; OAuth WG Subject: Re: [OAUTH-WG] bearer token authorization header On May 24, 2011, at 4:04 PM, Mike Jones wrote: George, you are correct that resources and clients must agree upon the format of the bearer token

Re: [OAUTH-WG] bearer token authorization header

2011-05-24 Thread George Fletcher
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

Re: [OAUTH-WG] bearer token authorization header

2011-05-23 Thread Mike Jones
Answers inline: 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

[OAUTH-WG] bearer token authorization header

2011-05-09 Thread Marius Scurtescu
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,