http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1
The expired_token error code doesn't scale well and won't be
implemented reliably. It should be merged with invalid_token.
Suggested language:
invalid_token
The access token provided is invalid. Resource servers
SHOULD
On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
I think the way to solve it is to make them more detailed and normative.
This will retain the general framework as current specified, but will
provide a reference-able description of useful profiles. This will also
Minor language change request. We have seen much more demand for use of the
user-agent flow in mobile apps than in desktop apps in the past month. I think
that the spec should address that.
Instead of this:
1.4.3. Native Application
Native application are clients running as native code
On 7/12/10 11:22 PM, Brian Eaton bea...@google.com wrote:
On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
I think the way to solve it is to make them more detailed and normative.
This will retain the general framework as current specified, but will
provide a
+1
On Sun, Jul 11, 2010 at 12:15 AM, Brian Eaton bea...@google.com wrote:
I think it would be a good idea to return to the draft 6 organization.
Draft 6: normative language for each flow was called out separately,
and was described from start to finish, in chronological order, with
no
I tend to agree with Eran, although it should be qualified that a token
is BASED on a shared secret, rather than is a shared secret itself. (By
the way, I think the word symmetric is redundant here.).
I also think that the text in the Security Considerations must contain
the last paragraph of
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly
like passwords. I added that text to make that stand out.
When
I am ok replacing it with 'acts as a password'.
EHL
On 7/13/10 8:55 AM, Dirk Balfanz balf...@google.com wrote:
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them
On 22/07/28164 13:59, Eran Hammer-Lahav wrote:
The following was submitted via the shared-copy page but does not
belong with editorial feedback. This needs to be discussed and
supported on the list before added the specification. I think it
belongs where 'immediate' is specified.
EHL
As defined in section 4.2 of RFC 2616 the only characters legally allowed in a
HTTP header are a fairly small subset of ASCII. So if we want to shove in
Unicode characters they will have to be encoded in a form that only uses
characters that are legal in the subset of ASCII supported by HTTP.
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Tuesday, July 13, 2010 7:21 AM
To: Brian Eaton; OAuth WG; b...@google.com
Subject: Re: [OAUTH-WG] expired_token error code
The question is if we have consensus to force providers to support it.
It seems to overstep the boundaries we set over the years and it makes
assumptions about how services authenticate users and obtain approvals.
EHL
On Jul 13, 2010, at 13:05, William Mills
I agree it changes the boundaries. I think this one needs moving. As I said
we hit a significant problem with this, which we solved by virtue of the fact
that the target we were working with has an un-crumbed logout, so we could XSRF
the logout.
It's something people get wrong and we should
I can live with SHOULD.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, July 13, 2010 10:30 AM
To: Colin Snover; David Recordon
Cc: OAuth WG
Subject: Re: [OAUTH-WG] ' force_auth' request parameter
On 7/13/10 10:25 AM, John Kemp j...@jkemp.net wrote:
On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
I am ok replacing it with Oacts as a password¹.
An access token is something used by the server to decide whether a request is
authorized. Although it may also be used for
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon record...@gmail.com wrote:
That strikes me as very odd - returning some params in the query, and
others in the fragment is just weird.
I actually think that you want this – albiet odd – combination when
requesting both a code and token. The code
Isn't that better overall than requiring the browser to make another HTTP
request to pass the code over?
EHL
On 7/13/10 11:17 AM, Brian Eaton bea...@google.com wrote:
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon record...@gmail.com wrote:
That strikes me as very odd - returning some
Hi Eran,
On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote:
On 7/13/10 10:25 AM, John Kemp j...@jkemp.net wrote:
On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
I am ok replacing it with Oacts as a password¹.
An access token is something used by the server to decide whether
I would be very unhappy if we equated access tokens with passwords.
I agree with Dirk that capability is a more expressive phrase than either
shared secret or password.
Expressive to you and people well-versed in security theory. It means
nothing to a casual reader. The token definition
I don't claim to fully grok what the current state of the various
proposals are regarding the user agent flow, but fundamentally,
shouldn't we be aiming to replicate what Twitter and Facebook are
already doing?
We've already moved towards JSON as a standard format, why not go all
the way and
On Jul 13, 2010, at 2:46 PM, Richer, Justin P. wrote:
I would be very unhappy if we equated access tokens with passwords.
I agree with Dirk that capability is a more expressive phrase than either
shared secret or password.
Expressive to you and people well-versed in security theory. It
On Tue, Jul 13, 2010 at 11:53 AM, Blaine Cook rom...@gmail.com wrote:
I don't claim to fully grok what the current state of the various
proposals are regarding the user agent flow, but fundamentally,
shouldn't we be aiming to replicate what Twitter and Facebook are
already doing?
Yes. They
+1 on like a password, or something similar-and-meaningful because
that's exactly how it's being used here. Pre-shared key, shared
secret, etc, would be fine. Keep in mind that authentication *will be
done* using the bearer token, and the bearer token alone.
An OAuth token is unlike capabilities
I think the spec should address this. I don't think it needs to go back to -06
format. There is a middle ground.
Also, keep in mind that the current format is much easier for those
implementing multiple flows or servers.
The important part is to make the spec instructive, not to optimize
On Tue, Jul 13, 2010 at 11:17 AM, Brian Eaton bea...@google.com wrote:
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon record...@gmail.com
wrote:
That strikes me as very odd - returning some params in the query, and
others in the fragment is just weird.
I actually think that you want
On Mon, Jul 12, 2010 at 10:36 PM, Brian Eaton bea...@google.com wrote:
Draft 10 has the following sentence in section 4.1.4:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4
The authorization server MAY issue a new refresh token.
That carries a surprising amount of baggage.
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook rom...@gmail.com wrote:
Don't leak it, and treat it as though it were a
password, then we avoid having to explain (embarrassingly) that the
capability actually meant something like password.
For the initiated, that's what capability means.
How
On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott andrewarn...@gmail.com wrote:
I'm pretty sure anyone issuing cryptographic refresh tokens is crazy,
these pretty much have to be backed by server-side state or there is
no way to run your system.
Brian, can you tell me what you mean by
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
In this case, the term capability MUST be defined up front. The word
capability seems to carry a much broader meaning than password...
It has a standard definition we can reference. From
I'll work with this text.
EHL
On 7/13/10 1:35 PM, Brian Eaton bea...@google.com wrote:
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook rom...@gmail.com wrote:
Don't leak it, and treat it as though it were a
password, then we avoid having to explain (embarrassingly) that the
capability actually
On Jul 13, 2010, at 4:06 PM, Blaine Cook wrote:
On 13 July 2010 20:31, John Kemp j...@jkemp.net wrote:
Where is that specified? Is that required for all implementations?
It's not specified - I was referring to your earlier comments:
In the bearer token case (and even over SSL unless
YES!!!
Brian, could you please add this?
Igor
Brian Eaton wrote:
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
In this case, the term capability MUST be defined up front. The word
capability seems to carry a much broader meaning than password...
On Tue, Jul 13, 2010 at 1:56 PM, Brian Eaton bea...@google.com wrote:
On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott andrewarn...@gmail.com
wrote:
Ah, got it. Yes, we're on the same page.
I happen to store the authorization tuple (mentioned in another thread)
rather than the refresh
This is how OAuth works: The client wants to access a protected resource. The
resource requires authentication (that's the definition of protected). The
client presents the access token to authenticate (using an HTTP authentication
header). The access token has all the security characteristics
On Tue, Jul 13, 2010 at 9:46 AM, Yaron Goland yar...@microsoft.com wrote:
As defined in section 4.2 of RFC 2616 the only characters legally allowed in
a HTTP header are a fairly small subset of ASCII.
I don't think that is correct. The definition of the TEXT rule in
section 2.2 allows most
I'm only using 2828 definition of capability, not password.
EHL
On 7/13/10 3:20 PM, Zachary Zeltsan zachary.zelt...@alcatel-lucent.com
wrote:
According to the RFC 2828 an access token is rather a capability than a
password. The passwords are usually associated with the matching identifiers,
I agree with the below.
To be clear, the case where we had a problem with this is a 3 legged flow,
where we as the 3rd party direct a user through an auth flow to be redir3ected
back to us. In this case it's nto the browser specifying, it's the
partner/integrator with a service.
Kris -
Thanks for pointing back to where this started!
I more or less agree with what Allen said in response to Torsten's
proposal: http://www.ietf.org/mail-archive/web/oauth/current/msg02295.html.
The devil is in the details.
I'd be interested in tackling client secret rotation at the same
How about:
Authorization codes SHOULD expire shortly after they are issued to
minimize the risk of leaks. Clients MUST NOT reuse authorization
codes. If an authorization code is used more than once, the authorization
server SHOULD revoke all tokens previously issued based on that authorization
I'd suggest authorization server MAY revoke all tokens.
Revoking an access token that was just issued is surprisingly tricky.
Fast to verify, easy to revoke, scalable: pick two.
On Tue, Jul 13, 2010 at 9:26 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
How about:
Authorization codes SHOULD
That's even worse I think, it's a harder problem. Why do we want to
revoke previously issued tokens here? It closes one door but opens a
DOS attack.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
We plan to issue new refresh tokens for certain clients only (mobile, desktop),
it's part of the client-related policy. So the behavior for a particular client
is predictable.
Regards,
Torsten.
Am 14.07.2010 um 03:07 schrieb Brian Eaton bea...@google.com:
Kris -
Thanks for pointing back
Thanks! That sounds great.
On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
This is clearly a third flow - hybrid (of user-agent and web-server) - and
not just a variant of the user-agent flow. It should be presented with its
own flow diagram and description. I
43 matches
Mail list logo
