Hey all,
the work on version -12 of the OAuth specification has generated a lot
of discussion.
-12 certainly contains a number of changes; some editorial but also
normative changes.
I went through the mailing list to see what the level of support we have
for various design decisions.
I
Hi all,
Eran suggested to remove the 'OAuth2' HTTP Authentication Scheme
functionality from the specification in his mail from last month:
http://www.ietf.org/mail-archive/web/oauth/current/msg05026.html
The discussion got off topic pretty quickly with the discussion about
OAuth usage for
Hi all,
Eran suggested to remove the Client Assertion functionality from the
draft-ietf-oauth-v2 specification in his mail from last month:
http://www.ietf.org/mail-archive/web/oauth/current/msg05027.html
This lead to a heated discussion.
Going through the discussions I got the following
Hi all,
Eran suggested to remove the HTTP Basic Authentication functionality
from the specification in his mail from last month:
http://www.ietf.org/mail-archive/web/oauth/current/msg05028.html
Essentially, there are two ways to accomplish the same functionality,
namely (1) Request
After a long back-and-forth, I think it is time to present a few options and
have people express their preferences.
These are the options mentioned so far and their +/-:
1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
Each token type gets its own name (which does not include the
Yes. I think automatic registration and other mechanisms for discovery and
obtaining credentials are going to be extremely useful. We're just not there
yet.
EHL
-Original Message-
From: Tschofenig, Hannes (NSN - FI/Espoo)
[mailto:hannes.tschofe...@nsn.com]
Sent: Thursday, February
There have been several of us that have objected and several of that have
implemented this feature, it's late in the cycle to remove, so I raise the
objection.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Thursday,
Hey Tony,
thanks for the feedback. I might have missed the objection. Could you be
more specific about who did not want this functionality to be removed?
Ciao
Hannes
On 2/3/2011 5:19 PM, Anthony Nadalin wrote:
There have been several of us that have objected and several of that have
On 2/3/2011 5:00 PM, Eran Hammer-Lahav wrote:
Yes. I think automatic registration and other mechanisms for discovery and
obtaining credentials are going to be extremely useful. We're just not there
yet.
This issue does not only need to be related to automatic registration.
With respect to
Here's one objection, per my note sent on January 18th:
'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like a
huge step away from interoperability. As one data point, Microsoft implements
this in our WIF OAuth2 protected resource code. All up, clients need a way to
Hi all,
while we are hopefully coming to an end with the main specification (and
the two other WG items) I need to put text for re-chartering together.
The entire process typically takes a little while because
* I need your feedback (hence this mail) of what you guys want to work on
* I have
This seems like an overly complex characterization - especially because you're
including hypothetical choices such as schemes and sub-schemes that don't
provide substantial benefits over the straightforward schemes we have now and
would complicate implementations and people's understanding of
Perhaps it can be left in for compatibility purposes but declared to be
deprecated for new implementations?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Thursday, February 03, 2011 8:06 AM
To: Hannes Tschofenig; Anthony Nadalin
Cc: oauth@ietf.org
I'm coming around to #1, I'll put my vote there.I do agree that we have
usage out there of the OAuth2 scheme and we need not to break that, how do we
solve that?
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, February 03, 2011
The problem with your entire statement below is that it doesn't explain how all
those important goals listed are actually accomplished by this header as
currently defined. Asking again...
- Can you please explain how this header helps interoperability?
- How does a client use this header to
All these suggestions were posted to the list by members (Marius, William,
James, Justin). Nothing here is new. If you disagree with my analysis of any of
the points, please raise your *technical* concerns. Trying to use process
arguments is simply not going to fly.
Pick an option, provide a
I realize that spec stability doesn't matter to you, but that doesn't mean that
it's not important to others, including those actually using the specs. Call
that a process argument if you want, but that doesn't make it any less
pertinent - the technical argument is that breaking changes break
Thanks Bill,
It would be useful to know where it is deployed and how it is being used.
If an existing deployment already uses the header to authenticate (via
Authorization request header field), the resource server should continue to
accept such request alongside the new name until it can get
#1
I suggest simply using 'Bearer' as the scheme name. It is descriptive and
provide reusability in other protocols with similar needs. I know this is being
dismissed but bearer tokens are not unique to OAuth and it would be helpful to
allow other protocols to use a well-defined scheme,
Stability comes second to proper definition and building a forward looking
framework. The OAuth2 scheme is the least implemented part of the
specification, and using a different name (i.e. changing 6 characters in an
opaque string) a trivial change to support on the server.
From your reply I
Hello Mike,
Given the spec is still a draft and most existing implementations are not in
production stage, it seems that changing the name of the bearer scheme from
OAuth2 to Bearer is not going to have a big impact.
With a small change, we are going to have a clearer and more descriptive
Also #1. While I feel for existing implementations of OAuth2 by
itself, it's not the best name for this specific piece of
functionality and Facebook too has a final migration server side to
make for other features in the spec which weren't finalized when we
implemented them.
On Thu, Feb 3, 2011
With my individual contributor hat on, I too prefer #1 -- it's just a
lot cleaner to my mind.
On 2/3/11 6:41 PM, David Recordon wrote:
Also #1. While I feel for existing implementations of OAuth2 by
itself, it's not the best name for this specific piece of
functionality and Facebook too has a
OPTION 1.
Phil
phil.h...@oracle.com
On 2011-02-03, at 9:19 AM, Mike Jones wrote:
I realize that spec stability doesn’t matter to you, but that doesn’t mean
that it’s not important to others, including those actually using the specs.
Call that a “process” argument if you want, but that
BTW, if you vote for #1, OAUTH2 could be reserved for legacy behaviour.
Phil
phil.h...@oracle.com
On 2011-02-03, at 10:10 AM, Peter Saint-Andre wrote:
With my individual contributor hat on, I too prefer #1 -- it's just a
lot cleaner to my mind.
On 2/3/11 6:41 PM, David Recordon wrote:
While I'm mostly indifferent between #1 and #3, I cast my vote for #1 for the
sake of garnering consensus.
Also, it seems important to some that the current specs be usable outside of
OAuth. While I'm not convinced there are sufficient other use cases being
examined to deliver the extra-OAuth
+1 for reserving the legacy behavior as well.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, February 03, 2011 10:15 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Bearer token type and scheme
On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC)
I vote #1.
In addition to the pros/cons Eran mentioned, it seems the simplest and
cleanest so will cause the least confusion.
William and others brought
(How pleasant it is to agree with everyone!)
+1
Igor
William Mills wrote:
+1 for reserving the legacy behavior as well.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, February 03, 2011 10:15 AM
To: Mike Jones
On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
2. Single OAuth2 scheme with sub-schemes
Define a single authentication scheme for all token types with some
attribute used to detect which scheme is actually being used.
Benefits:
- single scheme, reuse of the
Hey Marius,
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, February 03, 2011 10:36 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
On Thu, Feb 3, 2011 at 12:34 AM, Eran
In 5.1 (draft 12), if a refresh_token is returned with an access_token, what
does expires_in refer to? Strict reading of the spec says it refers to the
access_token, but isn't lifetime of the refresh token as important? Should
there be a similar refresh_expires_in?
Apologies if this was
The general use case for refresh tokens is that they don't have a lifetime,
although they can be invalidated by various things.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, February 03, 2011 12:27 PM
To: OAuth
#1, which is nice to support the OAuth2 scheme as previously discussed (Hunt,
etc) as a legacy type (can be specified in a migration spec).
-- Justin Hart
-- jh...@photobucket.commailto:jh...@photobucket.com
On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote:
After a long
Thanks. This makes sense. I'm wondering if there should be some explanative
text under refresh_token. Yet, it doesn't make all that much sense to define
why something isn't there. Never-the-less, it just seem like an awkward
omission after reading it.
I do note, that section 6 (Refreshing an
Also #1
On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart jh...@photobucket.com wrote:
#1, which is nice to support the OAuth2 scheme as previously discussed
(Hunt, etc) as a legacy type (can be specified in a migration spec).
-- Justin Hart
-- jh...@photobucket.com
On Feb 3, 2011, at
+1 #1
On Feb 3, 2011, at 3:21 PM, Brian Campbell wrote:
Also #1
On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart jh...@photobucket.com wrote:
#1, which is nice to support the OAuth2 scheme as previously discussed
(Hunt, etc) as a legacy type (can be specified in a migration spec).
--
Mixi, one of the biggest Japanese social network service, supports OAuth2 with
refresh_token.
The lifetime of refresh_token is 6 hours ~ 3 months depends on user's decision
on authorization.
In that case, how can Mixi tell the lifetime of refresh_token?
Currently they just documented it in
I think this is a matter of frequency. Since an access token might expire
frequently (e.g. in seconds rather than days or months), it is worth having the
client calculate to see if a token has expired (by returning expires_in). It
has the effect of saving the client/server a failed
since it expires in 3 to 6 months
No, 6 hours or 3 months.
3 months when user approved long-time access, 6 hours when not.
(Mixi has a checkbox on authorization page for that, so an client can have both
kind of refresh_tokens)
The only way to know the refresh_token lifetime is try to refresh
Correct. So the request would fail and you then re-authorize. You get a wasted
request/response. But it doesn't cost as much as for an expired access_token.
Phil
phil.h...@oracle.com
On 2011-02-03, at 4:42 PM, matake@gmail wrote:
since it expires in 3 to 6 months
No, 6 hours or 3
Seems a bit odd to issue a refresh token for 6 hours. Why not just issue an
access token for 6 hours without any refresh token.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of matake@gmail
Sent: Thursday, February 03, 2011 4:43 PM
Yeah, your way is much better, especially for client developers.
All mixi access_tokens expire in 15 mins, I'm not sure the details of their
security policy though.
And there are no way to know the lifetime of refresh_token when client get an
access_token.
On 2011/02/04, at 9:45, Eran
+1 for #1
#2 is awful; #3 is unnecessary; #4 OAuth2 just has less meaning than, say,
Bearer.
#1 offers the cleanest separation between using-a-token to authenticated a
request and a delegation flow to authorize a client which is likely to be
helpful for lots of people now and in the future
14. Explicitly state in section 3.3.2 (and 3.3.3) that SHA-1 (and SHA-256)
are
used to calculate the body hash when using the hmac-sha-1 (and hmac-sha-
256) algorithm.
Why isn't 3.2 enough? That's where body hash is discussed.
3.2 says the body hash algorithm is determined by the access
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Hannes Tschofenig
Sent: Thursday, February 03, 2011 8:19 AM
A) Simple Web Discovery (SWD)
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt
This has no business in this
In no place in the OAuth 2.0 Bearer Token Specification does it actually say
what the token_type parameter value should be in the access token response.
The only way anyone is able to pick this up is gleaning it from the example in
the OAuth 2.0 specification itself. And the only way a reader
How do we reconcile Bearer with Negotiate, NTLM, Basic, and
GoogleLogin? All of those examples are widely deployed and use
bearer tokens in Authorization headers. Should all of those switch to
using the Bearer scheme as well?
Tokens issued via OAuth will require specific validation logic, for
48 matches
Mail list logo
