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
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
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
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
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
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,
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