Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 l

[OAUTH-WG] token_type parameter value

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

Re: [OAUTH-WG] New Working Group Items?

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

Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02

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

Re: [OAUTH-WG] more comments on draft-hammer-oauth-v2-mac-token-02

Thanks James. > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, February 03, 2011 9:23 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2- > mac-token-02 > > Comments

[OAUTH-WG] MAC: more comments on draft-hammer-oauth-v2-mac-token-02

Comments on draft-hammer-oauth-v2-mac-token-02 This draft is a good improvement. (continuing numbering from my previous comments) 11. The "access token" field would be better labelled "id". The MAC scheme only needs this field to id

Re: [OAUTH-WG] New Working Group Items?

Hannes, I would like one more item in the list: * OAuth2 discovery from the response to any HTTP request, probably via a WWW-Authenticate response header. I am keen to contribute, and perhaps co-author such a spec. > B) HTTP Authentication: MAC Authentication > http://datatracker.ietf.org/doc/

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

+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

Re: [OAUTH-WG] Refresh Token and Expires_in

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 Hammer-La

Re: [OAUTH-WG] Refresh Token and Expires_in

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

Re: [OAUTH-WG] Refresh Token and Expires_in

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 mo

Re: [OAUTH-WG] Refresh Token and Expires_in

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

Re: [OAUTH-WG] Refresh Token and Expires_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 request/respo

Re: [OAUTH-WG] Refresh Token and Expires_in

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 their

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Also #1 On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart 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:34 AM, Era

Re: [OAUTH-WG] Refresh Token and Expires_in

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

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

#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:34 AM, Eran Hammer-Lahav wrote: After a long back-and-f

Re: [OAUTH-WG] Refresh Token and Expires_in

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: O

[OAUTH-WG] Refresh Token and Expires_in

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 disc

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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,

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav 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 1.0 pattern.

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

(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

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav 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 up backward compatib

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

+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 sche

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 v

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 tha

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 ha

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 schem

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 t

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 a

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 bre

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 ne

Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'

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 acce

Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

This is more about pragmatism than proper standards process. A large number of providers today use client password credentials. This is the common practice in almost every non-enterprise use case (which was the original driver behind OAuth and is still the lion share of the work and deployment).

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 12:

Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'

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 Sub

Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 th

[OAUTH-WG] New Working Group Items?

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

Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'

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 auth

Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

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 st

Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'

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 impleme

Re: [OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'

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,

Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

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

Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

> > The main question for me is: "What is mandatory to implement?" > > Nothing. The authorization server can support whatever client > authentication methods it deems appropriate. *IF* client > password credentials are supported, then the spec offers one > way to provide them using parameters.

[OAUTH-WG] JSON Cryptographic Syntax and Processing: BOF Status and Next Steps

Hi all, as mentioned earlier I have requested a BOF about the JSON signature topic and the IESG discussed the various BOF proposals this Tuesday. FYI, here are all the BOF proposals: http://trac.tools.ietf.org/bof/trac/ The BOF was not approved because the IESG felt we need more time for pre

Re: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Thursday, February 03, 2011 12:16 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for > Client Credentials' > > Hi all,

[OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

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 w

[OAUTH-WG] Hum about 'Removal: HTTP Basic Authentication for Client Credentials'

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 parameters

[OAUTH-WG] Hum about 'Removal: Client Assertion Credentials'

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 impr

[OAUTH-WG] Hum about 'Removal: OAuth2 HTTP Authentication Scheme'

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 SAS

[OAUTH-WG] OAuth version -12 specification

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 n