Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread William J. Mills
Yes, in fact one could get annoyingly confusing with tokens here and have... Authorization: bearer token="asfd2353fasdfa235q54rdasf",plaintext="JSON_GOES_HERE",oauth_signature="mysig" and the token would be token="asfd2353fasdfa235q54rdasf",plaintext="JSON_GOES_HERE",oauth_signature="my

Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1 subsection on assertions

2011-05-26 Thread Brian Campbell
A new document describing client authentication using assertions via HTTP parameters that *does not* expand to encompass all assertion related business, I believe, will also produce a useful document structure. At the same time it introduces fewer changes, while still arriving at the same function

Re: [OAUTH-WG] Redirect Issues

2011-05-26 Thread Igor Faynberg
Actually, I would go even further: Provide a list of different ways of redirecting and address each of them, or at least each class of redirects with the same characteristics. Igor Anthony Nadalin wrote: The OAuth spec is somewhat silent about how a resource provider should perform a redire

[OAUTH-WG] Redirect Issues

2011-05-26 Thread Anthony Nadalin
The OAuth spec is somewhat silent about how a resource provider should perform a redirect as there are many ways to accomplish the redirect. We also discovered that since the HTTP specifications were somewhat vague on fragments that some HTTP client implementations strip the fragment, we have th

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 in

Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread Marius Scurtescu
Maybe I created some confusion. Earlier in the thread I was wondering why isn't the part after the scheme name a list of name/value pairs. If it was, then the authorization header would look like: Bearer token=asfd2353fasdfa235q54rdasf and the actual token would be just asfd2353fasdfa235q54rdasf,

Re: [OAUTH-WG] bearer token authorization header

2011-05-26 Thread George Fletcher
So just to make sure that I'm clear... The following is ok... The AS and RO decide that the token will be comprised of both a name and value part. So the whole token looks like 'token=asfd2353fasdfa235q54rdasf'. From the protocol perspective, the access token is the entire string, eve