On 4/6/10 5:24 PM, Evan Gilbert uid...@google.com wrote:
Proposal:
In 2.4.1 2.4.2, add the following OPTIONAL parameter
username
The resource owner's username. The authorization server MUST only send back
refresh tokens or access tokens for the user identified by username.
What are
On 04/06/2010 11:50 PM, Eran Hammer-Lahav wrote:
That's only when you need to trust the client. If your requirements demand
registration, discovery is mostly pointless (other than dynamic configuration).
At the risk of comparing apples and pears - many large-scale SAML
deployments rely on
While odd, this is a perfectly legal GET request with a form-encoded body.
EHL
On 4/7/10 3:33 AM, Greg Beech g...@blinkbox.com wrote:
Hi
I noticed that there is an error in the example for section 3.4.1.1 in
the latest OAuth draft. The example of building a signature base string
uses the
To re-iterate and clarify Leif's second point, I would be in favor of
making TLS:
-- REQUIRED for implementations to support (== MUST)
-- RECOMMENDED for deployments to use (== SHOULD)
This a pretty universal pattern in IETF protocols.
--Richard
On Apr 7, 2010, at 7:20 AM, Leif Johansson
Right now most of the flows return the same parameters (access token,
expiration, refresh token). A few do not return a refresh token. When we add
signatures, we will need to add token secret and algorithm type.
I know there are good reasons why certain flows do not return a refresh
token but
We are looking at this all wrong.
There are two kinds of protected resources OAuth supports:
* http://
* https://
OAuth provides two kinds of token authentication modes:
* bearer token
* token + signature
I don't know how to translate your statement below into text I can put in
the draft to
You guys are both right: The recommendation I made before is basically
saying that you SHOULD only use tokens without signing on HTTPS
resources.
--Richard
On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:
Eran
Richard and Lief are describing the same point we had in the past
where Peter
I think it depends on which profiles we end up with. If we have the web and
rich client profiles from Dick's WRAP draft plus the JS profile from David's
draft, I would want to return the refresh token with the first two profiles
but not with the third. Since our refresh tokens are going to be very
On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote:
I'm assuming that tokens need not be bound to a specific user (typically
they are, but imagine a secretary granting an app access to his boss's
calendar and then leaving the company and therefore being removed from the
