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

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 01:34:14 -0700

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 word 'oauth' in it), as well as a matching HTTP authentication scheme if a new one is being defined.

Benefits:

- works cleanly with the HTTP authentication framework by simply defining new methods or reusing existing ones.
- schemes can be used outside the OAuth authorization flow (e.g. 2-legged OAuth 1.0 use cases).
- all schemes are presented equally without giving any a preferred treatment.
- built-in discovery using 401 challenge header for which schemes are supported (with their respective information).

Downsides:

- potential creation of many new HTTP authentication schemes which has been stable for a long time.

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.

Downsides:

- requires a new registry for authentication header parameters.
- schemes are not easily reusable outside OAuth.
- existing frameworks usually switch on scheme name, not on sub scheme, which will cause difficulty in some deployments.
- potential to produce a very complicated scheme once many sub schemes are added.
- requires its own discovery method for which schemes are supported.

3. Name prefix (e.g. oauth2_bearer)

Benefits:

- makes the protocol a bit easier to newbies since it will look all inclusive (authorization and authentication).

Downsides:

- makes reuse outside OAuth awkward without any technical benefit.

4. OAuth2 for bearer, MAC for mac

Name the bearer token 'OAuth2' and everything else gets a different name (with or without OAuth in it).

Benefits:

- Matches current draft.

Downsides:

- Elevates bearer token to the preferred token type, instead of promoting comparison of the various token types available.
- Creates a very odd usage where the authorization server issues an access token of type 'OAuth2' which is non-descriptive and very confusing (since there are other token types).
- Uses the name OAuth2 which stands for authorization in an authentication flow, continuing the confusion about what OAuth is (an authorization protocol).

---

Please reply with your preference by 2/10. As always, please provide feedback on the options and analysis.

EHL

---

From: Mike Jones <[email-masked]>
Date: Thu, 3 Feb 2011 16:19:35 +0000

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 the spec, and that don't have substantial support within the working group.

Given that we're trying to bring the specs to working group last call, I would personally vote no to introducing any further any breaking changes.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, February 03, 2011 12:34 AM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: William Mills <[email-masked]>
Date: Thu, 3 Feb 2011 08:42:11 -0800

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?

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 10:13:31 -0700

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 new option (with full analysis), or don't vote.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, February 03, 2011 8:20 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)

                                                            -- Mike

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: Mike Jones <[email-masked]>
Date: Thu, 3 Feb 2011 17:19:33 +0000

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

I already did vote below -- for option 4.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, February 03, 2011 9:14 AM
To: Mike Jones; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)

EHL

                                                            -- Mike

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 10:20:06 -0700

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 all clients to migrate. This is trivial to support.

The usage with the WWW-Authenticate header is being debated on another thread.

That's everywhere OAuth2 is used.

This is no different from the work Facebook has done to support parameter names we changed during the process to a live (and heavily used) production system. Probably the largest OAuth 2.0 deployment to date.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Thursday, February 03, 2011 8:42 AM
To: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 10:23:21 -0700

#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, especially with regard to the extensive security review this scheme is getting.

Calling the two current scheme and types 'Mac' and 'Bearer' is clean, simply, descriptive, and forward looking.

EHL

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 10:30:24 -0700

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 take it you fully agree with my analysis of the various options.

And I'm actually implementing the specification thank-you-very-much.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, February 03, 2011 9:20 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Bearer token type and scheme name (deadline: 2/10)

EHL

                                                            -- Mike

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: "Franklin Tse" <[email-masked]>
Date: Fri, 4 Feb 2011 01:40:07 +0800

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 scheme name, and most importantly, it preserves the fairness to other current (and future) schemes by not promoting a specific scheme.

Regards,
Franklin
  
--------------------------------------------------
From: "Mike Jones" <[email-masked]>
Date: Friday, 04 February, 2011 01:19
To: "Eran Hammer-Lahav" <[email-masked]>; "OAuth WG" <[email-masked]>
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Recordon <[email-masked]>
Date: Thu, 3 Feb 2011 09:41:32 -0800

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 at 8:42 AM, William Mills <[email-masked]> wrote:
> 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?
>
>
>
> Each token type gets its own name (which does not include the word ‘oauth’
> in it), as well as a matching HTTP authentication scheme if a new one is
> being defined.
>
>
>
> Benefits:
>
>
>
> - built-in discovery using 401 challenge header for which schemes are
> supported (with their respective information).
>
>
>
> Downsides:
>
>
>
> Define a single authentication scheme for all token types with some
> attribute used to detect which scheme is actually being used.
>
>
>
> Benefits:
>
>
>
> - existing frameworks usually switch on scheme name, not on sub scheme,
> which will cause difficulty in some deployments.
>
> - makes the protocol a bit easier to newbies since it will look all
> inclusive (authorization and authentication).
>
>
>
> Downsides:
>
>
>
> Name the bearer token ‘OAuth2’ and everything else gets a different name
> (with or without OAuth in it).
>
>
>
> Benefits:
>
>
>
> - Matches current draft.
>
>
>
> Downsides:
>
>
>
> - Elevates bearer token to the preferred token type, instead of promoting
> comparison of the various token types available.
>
> - Creates a very odd usage where the authorization server issues an access
> token of type ‘OAuth2’ which is non-descriptive and very confusing (since
> there are other token types).
>
> - Uses the name OAuth2 which stands for authorization in an authentication
> flow, continuing the confusion about what OAuth is (an authorization
> protocol).
>
>
>
> ---
>
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Feb 2011 19:10:32 +0100

With my individual contributor hat on, I too prefer #1 -- it's just a
lot cleaner to my mind.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Feb 2011 10:12:46 -0800

OPTION 1.

Phil
[email-masked]

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 doesn’t make it any less pertinent – the “technical” argument is that breaking changes break implementations.
>  
> Pick an option, provide a new option (with full analysis), or don’t vote.
>  
> EHL
>  
>  
> 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 the spec, and that don’t have substantial support within the working group.
>  
> Given that we’re trying to bring the specs to working group last call, I would personally vote no to introducing any further any breaking changes.
>  
>                                                             -- Mike
>  
> Each token type gets its own name (which does not include the word ‘oauth’ in it), as well as a matching HTTP authentication scheme if a new one is being defined.
>  
> Benefits:
>  
> Name the bearer token ‘OAuth2’ and everything else gets a different name (with or without OAuth in it).
>  
> Benefits:
>  
> - Matches current draft.
>  
> Downsides:
>  
> - Creates a very odd usage where the authorization server issues an access token of type ‘OAuth2’ which is non-descriptive and very confusing (since there are other token types).

---

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Feb 2011 10:14:37 -0800

BTW, if you vote for #1, OAUTH2 could be reserved for legacy behaviour.

Phil
[email-masked]

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 3 Feb 2011 19:17:53 +0100

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 value, I see no need limit these ambitions by choice of scheme name.

I'm also assuming that if the larger HTTP or IETF community would have issue with how Auth scheme names are allocated (short vs. long, general vs. specific) there would be some regulatory measure in place to address that.

As to the issue of backwards compatibility that William raises, my earlier proposal is in line with what Eran just proposed.

Moreover, the value of a working group would seem to be that the community can work to consensus for the best possible design without (and particularly so) the burden of supporting pre-standard systems.

---

From: William Mills <[email-masked]>
Date: Thu, 3 Feb 2011 10:21:00 -0800

+1 for reserving the legacy behavior as well.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Phil Hunt
> Sent: Thursday, February 03, 2011 10:15 AM
> To: Mike Jones
> Cc: [email-masked]
> >>> I'm coming around to #1, I'll put my vote there.    I do agree that
> we have
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> >>> Eran Hammer-Lahav
> >>> After a long back-and-forth, I think it is time to present a few
> options and
> >>> have people express their preferences.
> >>>
> >>>
> >>>
> >>> Each token type gets its own name (which does not include the word
> 'oauth'
> >>> - works cleanly with the HTTP authentication framework by simply
> defining
> >>> new methods or reusing existing ones.
> >>>
> >>> - schemes can be used outside the OAuth authorization flow (e.g. 2-
> legged
> >>> OAuth 1.0 use cases).
> >>>
> >>> - potential creation of many new HTTP authentication schemes which
> has been
> >>> stable for a long time.
> >>>
> >>>
> >>>
> >>> - potential to produce a very complicated scheme once many sub
> schemes are
> >>> added.
> >>>
> >>> Name the bearer token 'OAuth2' and everything else gets a different
> name
> >>> token of type 'OAuth2' which is non-descriptive and very confusing
> (since
> >>> Please reply with your preference by 2/10. As always, please
> provide
> >>> feedback on the options and analysis.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >

---

From: Michael D Adams <[email-masked]>
Date: Thu, 3 Feb 2011 10:30:00 -0800

> 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 compatibily, but, supposing #1
"wins", I don't see a need to support "legacy" #4 in the spec.  I feel
it can be addressed by implementors without loss of full compliance.

Phil's note about reserving OAUTH2 as a scheme name makes more sense
to me than supporting it.

I do not disagree with any of Eran's analysis, though #4, which I am
voting against, has a couple of the same benefits as #1:

- works cleanly with the HTTP authentication framework by simply
defining new methods or reusing existing ones.
- built-in discovery using 401 challenge header for which schemes are
supported (with their respective information).

Mike Adams

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 03 Feb 2011 13:32:13 -0500

(How pleasant it is to agree with everyone!)

+1

Igor

William Mills wrote:
>>>> On Thu, Feb 3, 2011 at 8:42 AM, William Mills <[email-masked]>
>>>>         
>> wrote:
>>     
>>>>> usage out there of the OAuth2 scheme and we need not to break that,
>>>>>           
>> how do
>>     
>>>>> we solve that?
>>>>>
>>>>>
>>>>>
>>>>> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline:
>>>>>           
>> 2/10)
>>     
>>>>>
>>>>> in it), as well as a matching HTTP authentication scheme if a new
>>>>>           
>> one is
>>     
>>>>> being defined.
>>>>>
>>>>>
>>>>>
>>>>> Benefits:
>>>>>
>>>>>
>>>>>
>>>>> - built-in discovery using 401 challenge header for which schemes
>>>>>           
>> are
>>     
>>>>> - existing frameworks usually switch on scheme name, not on sub
>>>>>           
>> scheme,
>>     
>>>>> - requires its own discovery method for which schemes are
>>>>>           
>> supported.
>>     
>>>>>
>>>>> - Elevates bearer token to the preferred token type, instead of
>>>>>           
>> promoting
>>     
>>>>> - Creates a very odd usage where the authorization server issues an
>>>>>           
>> access
>>     
>>>>> - Uses the name OAuth2 which stands for authorization in an
>>>>>           
>> authentication
>>     
>>>>> flow, continuing the confusion about what OAuth is (an
>>>>>           
>> authorization
>>     
>>>>> protocol).
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>>
>>>>>
>>>>>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 3 Feb 2011 10:35:31 -0800

> - requires a new registry for authentication header parameters.

How is this different from option 1? Wouldn't that need some registry?

> - schemes are not easily reusable outside OAuth.

Sure. But I really don't see this group trying to create generic
authentication schemes.

> which will cause difficulty in some deployments.

I can see this as a potential problem. But considering that there
wasn't much objection to use "OAuth" as a scheme name before (total
overlap with OAuth 1, and the suggested solution was to look for the
signature parameter) I don't see how this is suddenly an issue.

Do we have a concrete problem here or this is just theoretical?

> - potential to produce a very complicated scheme once many sub schemes are

Why? I would argue that this option actually produces more uniform
schemes because it forces all of them to be name/value pairs. Beyond
token_type everything is scheme specific. I really don't see what is
very complicate here.

> - requires its own discovery method for which schemes are supported.

Why is this a downside only for this option?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Feb 2011 12:39:07 -0700

Hey Marius,

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Thursday, February 03, 2011 10:36 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG

#1 relies on the existing practice of creating HTTP scheme names (no current registry but httpbis might be creating one), as well as the -12 token type registry. Using a sub-scheme means you also need a registry for the header attributes that each token type will need (unless you just don't care about using the same attribute name for different needs).

> Sure. But I really don't see this group trying to create generic authentication
> schemes.

MAC is exactly that.
 
> > scheme, which will cause difficulty in some deployments.
> 
> I can see this as a potential problem. But considering that there wasn't much
> objection to use "OAuth" as a scheme name before (total overlap with
> OAuth 1, and the suggested solution was to look for the signature
> parameter) I don't see how this is suddenly an issue.

There was pretty strong objection to reusing OAuth.

> Do we have a concrete problem here or this is just theoretical?

This came up during the review of draft-hammer-http-token-auth [1]. There was a long thread about it where people posted actual framework issues.
 
> token_type everything is scheme specific. I really don't see what is very
> complicate here.

It is still a single scheme with many different sub-schemes, each with different key-value pairs that may have conflicting meaning. The way I look at it is that if I try to fully implement this mega scheme (which means all its sub-schemes), it will likely be a complicated task. On the other hand, if you split it across scheme name, we already have a well-established system in place to pick and choose HTTP authentication schemes.
 
> Why is this a downside only for this option?

Because the other options get this for free by using the WWW-Authenticate header (since each scheme has a unique name). You can list multiple headers in the 401 response.

Should I record your vote for #2?

EHL

[1] http://tools.ietf.org/html/draft-hammer-http-token-auth-01

---

From: Justin Hart <[email-masked]>
Date: Thu, 3 Feb 2011 12:47:00 -0800

#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
-- [email-masked]<mailto:[email-masked]>

On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

<ATT00001..txt>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 3 Feb 2011 16:21:06 -0700

Also #1

On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart <[email-masked]> 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
> -- [email-masked]
>
>
>
>
>

---

From: Luke Shepard <[email-masked]>
Date: Fri, 4 Feb 2011 00:17:00 +0000

+1 #1

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 4 Feb 2011 15:24:02 +1100

+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 trying to get their heads around this complex space.

--

James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, 3 February 2011 7:34 PM
To: OAuth WG
Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

...

...

...

...

---

From: Brian Eaton <[email-masked]>
Date: Thu, 3 Feb 2011 23:57:51 -0800

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
exactly the same reasons that all of the above examples have specific,
different validation logic.  The normal way code that needs to deal
with multiple authentication types gets written is to look at the
scheme name, and then switch out library support based on the scheme.

Something like "Bearer" seems overly generic.  Why do we think we are
qualified to claim "Bearer" for our own?

On Thu, Feb 3, 2011 at 8:24 PM, Manger, James H
<[email-masked]> wrote:
> +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 trying to get their heads
> around this complex space.
>
>
>
> --
>
> James Manger
>
>
>
> …
> …
> …
> …

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Feb 2011 01:07:03 -0700

> Of Brian Eaton
> Sent: Thursday, February 03, 2011 11:58 PM
> To: Manger, James H
> Cc: OAuth WG
> "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?

Basic and Digest use the same credentials, only in different ways.
 
> qualified to claim "Bearer" for our own?

We can use any name we want as long as it is not taken, and is not misleading. 'Bearer' passes this test. This is not a sexy namespace like link relations or HTML tags where everyone wants to claim a name. You define a scheme and name it.
 
EHL

> > #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
> > trying to get their heads around this complex space.
> >
> >
> >
> > --
> >
> > James Manger
> >
> >
> >
> > Of Eran Hammer-Lahav
> > options and have people express their preferences.
> >
> >
> >

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 4 Feb 2011 08:31:40 -0800

FWIW, I agree with Brian - it should say OAuth somewhere, because it's an
OAuth token. My vote would be for OAuth2 for bearer tokens, and OAuth2Signed
for MAC tokens, for all the backward-compatibility issues with oauth_bearer,
etc.

Dirk.

On Fri, Feb 4, 2011 at 12:07 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> We can use any name we want as long as it is not taken, and is not
> misleading. 'Bearer' passes this test. This is not a sexy namespace like
> link relations or HTML tags where everyone wants to claim a name. You define
> a scheme and name it.
>
> EHL
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 4 Feb 2011 09:39:20 -0800

> #1 relies on the existing practice of creating HTTP scheme names (no current registry but httpbis might be creating one), as well as the -12 token type registry. Using a sub-scheme means you also n…

Sure, there is no registry for schemes yet, but we would still need
some coordination. The fact that a sub-scheme needs a registry that we
control is a benefit not a downside IMO.

>> Sure. But I really don't see this group trying to create generic authentication

May or may not be. My point is that this group is not focused on
creating generic authentication schemes. Are you aware of any other
protocols that might use MAC or BEARER? Are we willing to put in the
effort to create generic schemes? Is it our charter?

> There was pretty strong objection to reusing OAuth.

Yes, because there was no sub-scheme nor version (and the grammar was
totally broken). Even so, lots of implementations went ahead and did
it. Were there any scheme switching issues we are aware of?

> It is still a single scheme with many different sub-schemes, each with different key-value pairs that may have conflicting meaning. The way I look at it is that if I try to fully implement this meg…

No one has to implement a mega scheme. All schemes must use name/value
pairs and that's where the common part stops.

> Because the other options get this for free by using the WWW-Authenticate header (since each scheme has a unique name). You can list multiple headers in the 401 response.

I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate
work for sub-schemes as well?

> Should I record your vote for #2?

#2 or #3

Thanks,
Marius

---

From: Phil Hunt <[email-masked]>
Date: Fri, 4 Feb 2011 09:42:00 -0800

OAuth should be able to support other token schemes.  

Or conversely you don't have to have OAuth to use MAC, JWT, or whatever.

Phil
[email-masked]

---

From: "Minoo Hamilton" <[email-masked]>
Date: Fri, 4 Feb 2011 12:24:14 -0600

I vote for #1.  I really do not like the downsides of #4 (promoting
bearer to preferred token type).

Minoo

After a long back-and-forth, I think it is time to present a few options
and have people express their preferences.

Each token type gets its own name (which does not include the word
'oauth' in it), as well as a matching HTTP authentication scheme if a
new one is being defined.

Benefits:

- schemes can be used outside the OAuth authorization flow (e.g.
2-legged OAuth 1.0 use cases).

- all schemes are presented equally without giving any a preferred
treatment.

Downsides:

- potential creation of many new HTTP authentication schemes which has
been stable for a long time.

Benefits:

Downsides:

- potential to produce a very complicated scheme once many sub schemes
are added.

Benefits:

Downsides:

Name the bearer token 'OAuth2' and everything else gets a different name
(with or without OAuth in it).

Benefits:

- Matches current draft.

Downsides:

- Elevates bearer token to the preferred token type, instead of
promoting comparison of the various token types available.

- Creates a very odd usage where the authorization server issues an
access token of type 'OAuth2' which is non-descriptive and very
confusing (since there are other token types).

- Uses the name OAuth2 which stands for authorization in an
authentication flow, continuing the confusion about what OAuth is (an
authorization protocol).

---

Please reply with your preference by 2/10. As always, please provide
feedback on the options and analysis.

EHL

---

From: William Mills <[email-masked]>
Date: Fri, 4 Feb 2011 11:29:49 -0800

The only challenge is to know what scheme to use and what the nuances are of how to present the credential.

> Sent: Friday, February 04, 2011 9:42 AM
> To: Marius Scurtescu
> Cc: OAuth WG
> >>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name
> (deadline:
> >>> 2/10)
> >>>
> >> #1 relies on the existing practice of creating HTTP scheme names (no
> current registry but httpbis might be creating one), as well as the -12
> token type registry. Using a sub-scheme means you also need a registry
> for the header attributes that each token type will need (unless you
> just don't care about using the same attribute name for different
> needs).
> >
> wasn't much
> >> This came up during the review of draft-hammer-http-token-auth [1].
> There was a long thread about it where people posted actual framework
> issues.
> >>
> schemes
> >> It is still a single scheme with many different sub-schemes, each
> with different key-value pairs that may have conflicting meaning. The
> way I look at it is that if I try to fully implement this mega scheme
> (which means all its sub-schemes), it will likely be a complicated
> task. On the other hand, if you split it across scheme name, we already
> have a well-established system in place to pick and choose HTTP
> authentication schemes.
> >
> >> Because the other options get this for free by using the WWW-
> Authenticate header (since each scheme has a unique name). You can list
> multiple headers in the 401 response.
> >

---

From: Phil Hunt <[email-masked]>
Date: Fri, 4 Feb 2011 11:37:15 -0800

Yes. This should be defined in each token type specification.

Phil
[email-masked]

---

From: William Mills <[email-masked]>
Date: Fri, 4 Feb 2011 11:44:38 -0800

I was thinking more about how the client knows what to use.  The ubiquitous "service documentation" may come in to play here.  Some form of serv ice discovery/webfinger thing could also be used.

> From: Phil Hunt [mailto:[email-masked]]
> Sent: Friday, February 04, 2011 11:37 AM
> To: William Mills
> Cc: Marius Scurtescu; OAuth WG
> Behalf

---

From: Phil Hunt <[email-masked]>
Date: Fri, 4 Feb 2011 13:13:46 -0800

I agree, that is still to be defined. There seems to be some push back on discovery, but this is likely warranted.  If only because web sites may have both browser clients and app clients.

In a previous message, I did suggest the web site return HTTP 401 as below...
>> 401 Unauthorized
>> WWW-Authenticate: Basic realm="tokenSvc"
>> WWW-Authenticate: Digest realm="tokenSvc"
>> WWW-Authenticate: Form url="/clientAuthenticate.jsp",realm="tokenSvc"

It could also include other items for "MAC", etc.

The only other issue would be determining whether the token is obtained via an OAuth profile or via some default profile.  That could be handled with something like:

WWW-Authenticate: Basic realm="somerealm"
WWW-Authenticate: MAC realm="somerealm"
WWW-Authenticate: OAuth token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy"

The above would suggest that MAC tokens could be used alone as described in some specification for "MAC".  However, the presence of the OAuth header indicates that MAC and BEARER tokens can be used in the OAuth pattern.

I think this allows both de-coupling of tokens from OAuth but also informs clients what tokens can be used with OAuth.

There may be other ways to do this. But it does help with the decoupling.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 4 Feb 2011 14:15:28 -0700

> Sent: Friday, February 04, 2011 9:39 AM

> May or may not be. My point is that this group is not focused on creating
> generic authentication schemes. Are you aware of any other protocols that
> might use MAC or BEARER? Are we willing to put in the effort to create
> generic schemes? Is it our charter?

We are chartered to produce one such generic HTTP authentication scheme:

"The Working Group will also define a generally applicable
  HTTP authentication mechanism (i.e., browser-based "2-leg"
  scenario)."

My team is using MAC outside of OAuth. Also keep in mind that MAC is not a working group item or document. It is an individual submission aimed at producing an HTTP authentication scheme that is useful on its own but with OAuth binding.
 
> >> signature
> totally broken). Even so, lots of implementations went ahead and did it.
> Were there any scheme switching issues we are aware of?

There was a wide range of reasons. At the end, we are talking about a literal string. Code doesn't care what humans make of it.
 
> work for sub-schemes as well?

It can. But it is not as trivial. With different schemes, the existing 2617 framework does everything for you. You just include multiple headers. With sub-schemes, it is awkward to repeat the same scheme multiple times (but probably allowed), so you need to define some key="value, value, value" format for specifying multiple sub-schemes. And then if each sub-scheme has other parameters, it gets tricky.

IOW, you are moving functionality provided to you by HTTP into one you are making up. What's the point? Where is the value? I think the core difference here is you are more concerned about the HTTP scheme namespace and I am more concerned about inventing new authentication framework facilities.

EHL

---

From: William Mills <[email-masked]>
Date: Fri, 4 Feb 2011 13:39:45 -0800

I was thinking along the lines of simply returning the HTTP Authorization header schemes that are supported.  In the OAuth 2 context that would be 

	WWW-Authenticate: 401 error="blah blah blah"  auth_types="Bearer MAC Basic"

The client has to be aware of the authentication scheme names. 

-bill

> Sent: Friday, February 04, 2011 1:14 PM
> To: William Mills
> I agree, that is still to be defined. There seems to be some push back
> on discovery, but this is likely warranted.  If only because web sites
> may have both browser clients and app clients.
> 
> >> WWW-Authenticate: Form
> url="/clientAuthenticate.jsp",realm="tokenSvc"
> 
> The only other issue would be determining whether the token is obtained
> via an OAuth profile or via some default profile.  That could be
> handled with something like:
> 
> WWW-Authenticate: OAuth
> token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy"
> 
> The above would suggest that MAC tokens could be used alone as
> described in some specification for "MAC".  However, the presence of
> the OAuth header indicates that MAC and BEARER tokens can be used in
> the OAuth pattern.
> 
> I think this allows both de-coupling of tokens from OAuth but also
> informs clients what tokens can be used with OAuth.
> 
> > I was thinking more about how the client knows what to use.  The
> ubiquitous "service documentation" may come in to play here.  Some form
> of serv ice discovery/webfinger thing could also be used.
> >
> >>> The only challenge is to know what scheme to use and what the
> nuances
> >> are of how to present the credential.
> >>>
> >>>> current registry but httpbis might be creating one), as well as
> the
> >> -12
> >>>>> some coordination. The fact that a sub-scheme needs a registry
> that
> >>>> we
> >>>>>>> token_type everything is scheme specific. I really don't see
> what
> >>>> is very
> >>>>>>> complicate here.
> >>>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 05 Feb 2011 19:03:37 +0100

+1 for option 3, but would be fine with option 1, too

Both are quite similar, except 3 keeps the link between the OAuth 
authorization server API (how to get a token) and the HTTP schemes used 
to send the tokens to the resource servers. Since OAuth is becoming, in 
my perception, the synonym for token-based authorization of REST service 
calls this link might be important.

regards,
Torsten.
Am 03.02.2011 19:12, schrieb Phil Hunt:
> OPTION 1.
>
> Phil
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>> 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 implementations.
>> *From:*Eran Hammer-Lahav [mailto:[email-masked]]
>> *Sent:*Thursday, February 03, 2011 9:14 AM
>> *To:*Mike Jones; OAuth WG
>> *Subject:*RE: 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.
>> *From:*Mike Jones [mailto:[email-masked]]
>> *Sent:*Thursday, February 03, 2011 8:20 AM
>> *To:*Eran Hammer-Lahav; OAuth WG
>> *Subject:*RE: 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 the spec, and that 
>> don’t have substantial support within the working group.
>> Given that we’re trying to bring the specs to working group last 
>> call, I would personally vote no to introducing any further any 
>> breaking changes.
>>                                                             -- Mike
>> *From:[email-masked] 
>> <mailto:[email-masked]>[mailto:[email-masked]]*On 
>> Behalf Of*Eran Hammer-Lahav
>> *Sent:*Thursday, February 03, 2011 12:34 AM
>> *To:*OAuth WG
>> *Subject:*[OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)
>> ‘oauth’ in it), as well as a matching HTTP authentication scheme if a 
>> has been stable for a long time.
>> schemes are added.
>> access token of type ‘OAuth2’ which is non-descriptive and very 
>> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 05 Feb 2011 19:21:08 +0100

that's not the way WWW-Authenticate headers are used today. Instead the 
resource server should return a single WWW-Authenticate header _per_ 
supported authentication scheme, such as

WWW-Authenticate: MAC realm="somerealm"
WWW-Authenticate: BEARER realm="somerealm"

furthermore, I think interdependencies among WWW-Authenticate headers as suggested by Phil

WWW-Authenticate: OAuth
token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyy

could be rather fragile.

I would expect the WWW-Authenticate header to return all the data required to obtain the credentials/tokens, such as

WWW-Authenticate: MAC realm="somerealm", tokenUrl="yyyyy&token_secret=yes"
WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy"

Which raises the question whether the coupling between authentication schemes and the OAuth2 core protocol is stronger than assumed.

please als see http://www.ietf.org/mail-archive/web/oauth/current/msg04988.html

regards,
Torsten.

---

From: Phil Hunt <[email-masked]>
Date: Sat, 5 Feb 2011 11:00:31 -0800

I think you are correct - there should be only one scheme per header.

However, there is an issue that a particular token type may be used outside of OAuth and then it may also be used within OAuth at the same time. So you do have to list protocols twice.  I believe Eran had mentioned an approach of sub-categorization that could also work...

WWW-Authenticate: BEARER ...
WWW-Authenticate: OAUTH2_MAC ...
WWW-Authenticate: OAUTH2_BEARER ...

This may have some advantages. E.g. different parameters for each OAuth sub category. The big difference would be that this sub-category approach would end up requiring more registrations.

I'm neutral on the approach here, but I think the key is that tokens need to be usable both inside and outside of OAuth and that servers may need both at the same time.

Phil
[email-masked]

On 2011-02-05, at 10:21 AM, Torsten Lodderstedt wrote:

> that's not the way WWW-Authenticate headers are used today. Instead the resource server should return a single WWW-Authenticate header _per_ supported authentication scheme, such as
>

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 6 Feb 2011 22:39:05 +1100

> using the "Bearer" scheme as well?

"Basic" & "NTLM" are password schemes; "Negotiate" can be a password or Kerberos or other scheme (I think); "GoogleLogin" is a password scheme with an optional CAPTCHA.
These aren't bearer token schemes so they should not (and cannot) switch to the "Bearer" scheme.

...

> Something like "Bearer" seems overly generic.
> Why do we think we are qualified to claim "Bearer" for our own?

By not defining it to be just our own, ie don't make the definition OAuth-specific.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 6 Feb 2011 23:26:10 +1100

Dirk said:

> FWIW, I agree with Brian - it [the "Bearer" scheme] should say OAuth somewhere, because it's an OAuth token.

OAuth can deliver any variety of bearer token: SAML, JWT, SWT, opaque id, anything else.

Conversely, any of these tokens can come from a variety of sources: a user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do with OAuth, a device interaction, manual configuration....

A server receives a bearer token in a request.

Dirk, are you saying the contents of the token (at that it is a bearer token) is not enough for the server? Does the server also need to know that it came from an OAuth flow? If so, I suspect the server actually needs to know more than that: such as which OAuth flow was used (eg user-delegation, client-only, assertion, future device flow etc), or from which authorization server it came. I don't think a scheme name saying "OAuth" helps.

--

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 7 Feb 2011 00:07:33 +1100

Phil Hunt said:
> The only other issue would be determining whether the token is obtained via an OAuth profile or > via some default profile.  That could be handled with something like:
>
> The above would suggest that MAC tokens could be used alone as described in some specification > for "MAC".  However, the presence of the OAuth header indicates that MAC and BEARER tokens can > be used in the OAuth pattern.
>
> I think this allows both de-coupling of tokens from OAuth but also informs clients what tokens > can be used with OAuth.
>

I agree that this is a good approach. A separate WWW-Authenticate header indicating that an OAuth delegation flow can be used to get access. I am not sure that you need to token="MAC;BEARER" at this point -- you can get that detail from the token response.

> WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy"

I don't really like this approach.
Existing WWW-Auth headers do NOT "return all the data required to obtain the credentials". They assume the client already has the credentials -- perhaps from a config file, perhaps from prompting a user.
I don't think we can add tokenUrl etc to existing (non-OAuth-specific) auth schemes -- the existing specs and existing implementations just don't support it. That shouldn't mean those schemes cannot be used for the authentication part of an OAuth authorization flow, though.

I would expect a 401 HTTP error response to return all the data required (except any client credentials (if required)) for the client to make a successful request. Or at least the data required for the next step towards making a successful request (eg an authorization URI).

--
James Manger

---

From: Dirk Balfanz <[email-masked]>
Date: Sun, 6 Feb 2011 23:16:28 -0800

On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H <
[email-masked]> wrote:

>  Dirk said:
>
> > FWIW, I agree with Brian - it [the “Bearer” scheme] should say OAuth
> somewhere, because it's an OAuth token.
>
>
>
> Conversely, any of these tokens can come from a variety of sources: a
> user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing to
> do with OAuth, a device interaction, manual configuration….
>
Yes - they're all still all OAuth tokens, though. As opposed to passwords,
basic auth tokens, etc., (which are also bearer tokens, but not OAuth
tokens).

> Dirk, are you saying the contents of the token (at that it is a bearer
> token) is not enough for the server?
>
No - I'm sure the server can look at the token and figure out that it's on
OAuth token. All I'm saying is that if it's an OAuth token, we should call
it an OAuth token.

Dirk.

> Does the server also need to know that it came from an OAuth flow? If so, I
> suspect the server actually needs to know more than that: such as which
> OAuth flow was used (eg user-delegation, client-only, assertion, future
> device flow etc), or from which authorization server it came. I don’t think
> a scheme name saying “OAuth” helps.
>
>
>
> --
>
> James Manger
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 01:02:51 -0700

Yes, any token issued via OAuth by an authorization server is an OAuth token by definition. Which makes 'token_type=oauth2' an silly and confusing statement, given that any token issued via this method is also an OAuth 2.0 token... but for some reason only one is labeled oauth2.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Sunday, February 06, 2011 11:16 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H <[email-masked]<mailto:[email-masked]>> wrote:

Conversely, any of these tokens can come from a variety of sources: a user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do with OAuth, a device interaction, manual configuration....
Yes - they're all still all OAuth tokens, though. As opposed to passwords, basic auth tokens, etc., (which are also bearer tokens, but not OAuth tokens).

Dirk, are you saying the contents of the token (at that it is a bearer token) is not enough for the server?
No - I'm sure the server can look at the token and figure out that it's on OAuth token. All I'm saying is that if it's an OAuth token, we should call it an OAuth token.

Dirk.

Does the server also need to know that it came from an OAuth flow? If so, I suspect the server actually needs to know more than that: such as which OAuth flow was used (eg user-delegation, client-only, assertion, future device flow etc), or from which authorization server it came. I don't think a scheme name saying "OAuth" helps.

--

James Manger

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 7 Feb 2011 08:28:52 -0800

-1

I don't agree fully here. 

Phil

Sent from my phone. 

On 2011-02-07, at 0:02, Eran Hammer-Lahav <[email-masked]> wrote:

> Yes, any token issued via OAuth by an authorization server is an OAuth token by definition. Which makes ‘token_type=oauth2’ an silly and confusing statement, given that any token issued via this method is also an OAuth 2.0 token… but for some reason only one is labeled oauth2.
> 
>  
> 
> EHL
> 
>  
> 
> On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H <[email-masked]> wrote:
> 
> Dirk said:
> 
> > FWIW, I agree with Brian - it [the “Bearer” scheme] should say OAuth somewhere, because it's an OAuth token.
> 
>  
> 
> Conversely, any of these tokens can come from a variety of sources: a user-delegation OAuth flow, a client-only OAuth flow, a flow with nothing to do with OAuth, a device interaction, manual configuration….
> 
> Does the server also need to know that it came from an OAuth flow? If so, I suspect the server actually needs to know more than that: such as which OAuth flow was used (eg user-delegation, client-only, assertion, future device flow etc), or from which authorization server it came. I don’t think a scheme name saying “OAuth” helps.
> 
>  
> 
> --
> 
> James Manger
> 
>  
> 
>  
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 10:54:47 -0700

What don’t you agree with?

EHL

From: Phillip Hunt [mailto:[email-masked]]
Sent: Monday, February 07, 2011 8:29 AM
To: Eran Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

-1

Phil

Sent from my phone.

On 2011-02-07, at 0:02, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Yes, any token issued via OAuth by an authorization server is an OAuth token by definition. Which makes ‘token_type=oauth2’ an silly and confusing statement, given that any token issued via this method is also an OAuth 2.0 token… but for some reason only one is labeled oauth2.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Sunday, February 06, 2011 11:16 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Dirk.

--

James Manger

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 7 Feb 2011 10:15:47 -0800

I don't agree that at token issued by an OAuth server is by definition an OAuth token.

OAuth describes a flow pattern around how tokens may be obtained, etc. There are many types of tokens that could be employed.

OAuth does not describe how SP's interpret and use tokens.  It only suggests how tokens are presented.

Phil
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 11:39:44 -0700

Given the loose definition of tokens, any token issued as part of the OAuth flow is an OAuth token. It doesn't mean that an OAuth token cannot be (internally or in practice) using a token format from another protocol. The idea that an OAuth token request may issue something other than an OAuth token is not compatible with the specification language, but this is just terminology and has little to no practical implications.

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, February 07, 2011 10:16 AM
To: Eran Hammer-Lahav
Cc: Dirk Balfanz; Manger, James H; OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Phil
[email-masked]<mailto:[email-masked]>

What don't you agree with?

EHL

-1

Phil

Sent from my phone.

EHL

Dirk.

--

James Manger

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 7 Feb 2011 11:23:38 -0800

What in oauth other than method of issue makes a token an oauth token?

Is money obtained from an ATM suddenly ATM money?

What if the tokens are Kerberos tokens. What makes them suddenly oauth tokens?

Phil

Sent from my phone. 

On 2011-02-07, at 10:39, Eran Hammer-Lahav <[email-masked]> wrote:

> Given the loose definition of tokens, any token issued as part of the OAuth flow is an OAuth token. It doesn’t mean that an OAuth token cannot be (internally or in practice) using a token format from another protocol. The idea that an OAuth token request may issue something other than an OAuth token is not compatible with the specification language, but this is just terminology and has little to no practical implications.
> 
>  
> 
> EHL
> 
>  
>

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 7 Feb 2011 12:10:01 -0800

> Is money obtained from an ATM suddenly ATM money?

It would be if some vendors would only accept money which came out of ATMs.
Which is the situation we're in with OAuth.

> What if the tokens are Kerberos tokens. What makes them suddenly oauth

What makes them OAuth tokens is that they came out of an OAuth flow. What
makes them OAuth token is that the resource server, upon receiving such a
token, will contact the local AS (not the kerberos server) and say "hey, I
received this OAuth token, can you please verify it for me". (If the AS
chooses to hand out kerberos tokens as OAuth tokens, that's its business).

Dirk.

> Given the loose definition of tokens, any token issued as part of the OAuth
> flow is an OAuth token. It doesn’t mean that an OAuth token cannot be
> (internally or in practice) using a token format from another protocol. The
> idea that an OAuth token request may issue something other than an OAuth
> token is not compatible with the specification language, but this is just
> terminology and has little to no practical implications.
>
>
>
> EHL
>
>
>
> *From:* Phil Hunt [mailto:[email-masked]]
> *Sent:* Monday, February 07, 2011 10:16 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Dirk Balfanz; Manger, James H; OAuth WG
> *Subject:* Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
> 2/10)
>
>
>
> OAuth describes a flow pattern around how tokens may be obtained, etc.
> There are many types of tokens that could be employed.
>
>
>
> <[email-masked]>[email-masked]
>
>
>
>
>
>
>
> *From:* Phillip Hunt [mailto:[email-masked]]
> *Sent:* Monday, February 07, 2011 8:29 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Dirk Balfanz; Manger, James H; OAuth WG
> *Subject:* Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
> 2/10)
>
>
>
> -1
>
>
>
> On 2011-02-07, at 0:02, Eran Hammer-Lahav < <[email-masked]>
> [email-masked]> wrote:
>
> Yes, any token issued via OAuth by an authorization server is an OAuth
> token by definition. Which makes ‘token_type=oauth2’ an silly and confusing
> statement, given that any token issued via this method is also an OAuth 2.0
> token… but for some reason only one is labeled oauth2.
>
>
>
> EHL
>
>
>
> *From:*  <[email-masked]>[email-masked] [mailto:
> [email-masked]] *On Behalf Of *Dirk Balfanz
> *Sent:* Sunday, February 06, 2011 11:16 PM
> *To:* Manger, James H
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
> 2/10)
>
>
>
>
>
> On Sun, Feb 6, 2011 at 4:26 AM, Manger, James H <<[email-masked]>
> <[email-masked]>[email-masked]
> <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Feb 2011 21:43:54 +0100

Hi James,

Am 06.02.2011 14:07, schrieb Manger, James H:
> Phil Hunt said:
>> The only other issue would be determining whether the token is obtained via an OAuth profile or>  via some default profile.  That could be handled with something like:
>>
>> The above would suggest that MAC tokens could be used alone as described in some specification>  for "MAC".  However, the presence of the OAuth header indicates that MAC and BEARER tokens can>  be used in the OAuth pattern.
>>
>> I think this allows both de-coupling of tokens from OAuth but also informs clients what tokens>  can be used with OAuth.
>>

I don't think a WWW-Authenticate header is the right way to transmit 
supplementary data to other WWW-Authenticate headers, such as hints how 
to obtain credentials (e.g. OAuth). If such data belong to a 
authentication scheme, then it should be provided with the respective 
WWW-Authentication header. Alternatively, some other discovery 
mechanismus could be used, such as host-meta on the resource server.

> I would expect a 401 HTTP error response to return all the data required (except any client credentials (if required)) for the client to make a successful request. Or at least the data required for…

What the difference to my proposal? authorizationURL instead of tokenURL?

regards,
Torsten.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 7 Feb 2011 14:02:51 -0800

Phil
[email-masked]

On 2011-02-07, at 12:10 PM, Dirk Balfanz wrote:

> It would be if some vendors would only accept money which came out of ATMs. Which is the situation we're in with OAuth.

My analogy was more of the form that you can go anywhere in the world and use an ATM to obtain 'local currency'. All ATMs work more or less the same.  The vendors around that ATM accept local currency. The same is true here. Tokens are issued for a particular security domain. The domain dictates the token types they want to use. Those tokens may turn out to be proprietary, or based entirely on another standard (e.g. Kerberos).
 
> What makes them OAuth tokens is that they came out of an OAuth flow. What makes them OAuth token is that the resource server, upon receiving such a token, will contact the local AS (not the kerberos server) and say "hey, I received this OAuth token, can you please verify it for me". (If the AS chooses to hand out kerberos tokens as OAuth tokens, that's its business).

I don't see how the method of issue defines what something is.  To do so implies that there must be a specification that defines an OAuth token.  Method of verification and use of a token should be defined within the definition of the token.

It sounds to me like people are after a universal token. Is that the case?

I would prefer a scheme where the right type of token can be used for the job at hand. This means artifacts, bearer, MAC, etc can all be used. Even potentially Kerberos. It all depends on security requirements of the use case.

---

From: William Mills <[email-masked]>
Date: Mon, 7 Feb 2011 14:49:50 -0800

OK.

So then the question is the right way to communicate token endpoints.  Is it cleaner/preferred to have everything in the WWW-Authenticate header, or to break things out so we're not stuffing a lot into those headers and repeating outselves?  So, all in one would be:

    WWW-Authenticate: MAC realm="somerealm" token_url="http://login.example.com/token" auth_url="http://login.example.com/webauth"

Broken out might be:

    WWW-Authenticate: MAC realm="OAuth2"
    Link: <http://login.example.com/token?grant_type=MAC> rel="oath2-token"
    Link: <http://login.example.com/auth?.done=http://foo.service.come/blahblahblah> rel="oath2-auth"

-bill

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Saturday, February 05, 2011 10:21 AM
> To: William Mills
> Cc: Phil Hunt; OAuth WG
> I would expect the WWW-Authenticate header to return all the data
> required to obtain the credentials/tokens, such as
> 
> Which raises the question whether the coupling between authentication
> schemes and the OAuth2 core protocol is stronger than assumed.
> 
> > I was thinking along the lines of simply returning the HTTP
> Authorization header schemes that are supported.  In the OAuth 2
> context that would be
> >
> >>>>>>>>>> Define a single authentication scheme for all token types
> with
> >>>>>> some
> >>>>>>>> #1 relies on the existing practice of creating HTTP scheme
> names
> >>>> (no
> >>>>>>> protocols that might use MAC or BEARER? Are we willing to put
> in
> >>>> the
> >>>>>>>>> objection to use "OAuth" as a scheme name before (total
> overlap
> >>>>>> with
> >>>>>>> Yes, because there was no sub-scheme nor version (and the
> grammar
> >>>> was
> >>>>>>> totally broken). Even so, lots of implementations went ahead
> and
> >>>> did
> >>>>>> with different key-value pairs that may have conflicting
> meaning.
> >>>> The
> >>>>>> Authenticate header (since each scheme has a unique name). You
> can
> >>>> list

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 16:06:52 -0700

I'm a strong advocate of the Link approach, given that authorization information does not belong on the authentication headers.

EHL

> Of William Mills
> Sent: Monday, February 07, 2011 2:50 PM
> To: Torsten Lodderstedt
> Cc: OAuth WG
> Subject: [OAUTH-WG] Discovery RE: Bearer token type and scheme name
> (deadline: 2/10)
> 
> OK.
> 
> So then the question is the right way to communicate token endpoints.  Is it
> cleaner/preferred to have everything in the WWW-Authenticate header, or
> to break things out so we're not stuffing a lot into those headers and
> repeating outselves?  So, all in one would be:
> 
> token_url="http://login.example.com/token"
> auth_url="http://login.example.com/webauth"
> 
> Broken out might be:
> 
>     Link:
> <http://login.example.com/auth?.done=http://foo.service.come/blahblahbl
> ah> rel="oath2-auth"
> 
> -bill
> 
> > that's not the way WWW-Authenticate headers are used today. Instead
> > the resource server should return a single WWW-Authenticate header
> > _per_ supported authentication scheme, such as
> >
> > furthermore, I think interdependencies among WWW-Authenticate
> headers
> > as suggested by Phil
> >
> > WWW-Authenticate: OAuth
> > >> described in some specification for "MAC".  However, the presence
> > >> of the OAuth header indicates that MAC and BEARER tokens can be
> > >> used in the OAuth pattern.
> > >>
> > >>>>>> for the header attributes that each token type will need
> > >>>>>> (unless
> > >> you
> > >>>>>>>> This came up during the review of
> > >>>>>>>> draft-hammer-http-token-auth
> > >>>> [1].

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 7 Feb 2011 22:59:12 -0700

This is where we stand so far:

Option 1  -- 14 votes

William Mills
Eran Hammer-Lahav
Franklin Tse
David Recordon
Peter Saint-Andre
Phil Hunt
Skylar Woodward
Michael Adams
Igor Faynberg
Justin Hart
Brian Campbell
Luke Shepard
James Manger
Minoo Hamilton

Option 2 -- 1 vote

Marius Scurtescu (or #3)

Option 3  -- 1 vote

Torsten Lodderstedt (or #1)

Option 4 -- 3 votes

Mike Jones
Brian Eaton (??)
Dirk Balfanz

Option #1 has clear support.

However, given my strong feeling on the subject, it is only fair that those voting for other options get to decide if they are willing to let #1 stand as the working group consensus, or would like to continue this debate in hope of a different result.

Mike, Brian, Dirk, and Marius - can you live with #1?

EHL

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

Downsides:

Benefits:

- Matches current draft.

Downsides:

---

EHL

---

From: Allen Tom <[email-masked]>
Date: Mon, 7 Feb 2011 22:37:59 -0800

Hi All,

I vote for #1 - the proposal is simple and straightforward.

However, as one of the authors of WRAP - I am rather fond of bearer tokens.
 Replacing OAuth 1.0 tokens with bearer tokens was one of the primary goals
of WRAP, so #4 makes a lot of sense to me too.

That being said, #1 is simple and straightforward, and has the advantage
that choice #1 can move the process forward.

Allen

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 8 Feb 2011 18:31:02 +1100

I see 4 suggestions for discovery (getting details about the OAuth endpoints etc to client apps):

1. Include it as extra params when advertising authentication mechanisms.
   WWW-Authenticate: MAC realm="...", <any MAC-specific params>, auth_url="http..."

I don't like this as it changes WWW-Auth headers for other auth schemes,
which might be theoretically feasible for new schemes this WG defines,
but is not really possible for other schemes.
It unnecessarily binds the delegation flow to a specific auth mechanism up front.
There is nowhere to put the info if a server support delegation, but doesn't use an HTTP auth scheme to exchange the resulting state from the authz server to resource servers.
When we specify a new parameter it affects all other auth schemes as well.
Do we really want a discovery spec adding params to the WWW-Auth header defined in the MAC spec?
If you updated the discovery spec you would need to check every other auth scheme (past & future) for param name clashes.

2. Define a WWW-Auth scheme specifically for announcing support for delegation flows.
   WWW-Authenticate: OAuth2 realm="..." token_url="http..." auth_url="http..."

This is my preference.
The only downside is that there is no matching Authorization header (and it is more about authz than auth) so some feel it not how WWW-Auth is supposed to be used.
I see WWW-Auth as accompanying responses when a better response is possible with more authentication -- and providing details about how to "improve" the authentication.
Providing the info required to perform an OAuth delegation flow is a close enough fit in my mind.
When a client app gets a 401, it looks at WWW-Auth headers to decide if it can continue. Orchestrating an OAuth delegation flow is a way to continue.

3. Define link relations.
   Link: <http://login.example.com/auth?> rel="oauth2-auth"

This feels possible, but not ideal.
Details about how to delegate is not quite a "relationship".
There is probably more than a single URI that you want to specify, and a handful of other parameters.

4. Something else entirely, such a host-meta.

I would prefer to offer discovery inline -- in the 401 response.

--
James Manger

----------
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 8 February 2011 10:07 AM

> ----------

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 8 Feb 2011 01:19:21 -0700

> Of Manger, James H
> Sent: Monday, February 07, 2011 11:31 PM

> Details about how to delegate is not quite a "relationship".

Sure it is. "My authorization server".

> handful of other parameters.

Link allows defining addition extension attributes if needed, which can include other URIs, but I would just include multiple links as needed. For example, one link per client profile.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 8 Feb 2011 09:23:38 -0800

On Mon, Feb 7, 2011 at 9:59 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Mike, Brian, Dirk, and Marius – can you live with #1?

Works for me.

Marius

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Feb 2011 17:45:48 +0000

I'm likewise OK with #1.  As I'd written previously, I wasn't religious about the name "OAuth2"; I was for it for to be consistent with past drafts and so as not to introduce a breaking change.  Given that there appears to be consensus to make a change, I'll plan on publishing a draft later this week that contains it unless discussion in the next few days convinces us that we should follow a different course.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Tuesday, February 08, 2011 9:24 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Works for me.

Marius

---

From: William Mills <[email-masked]>
Date: Tue, 8 Feb 2011 14:39:57 -0800

So, if we go with the Link approach and we are thinking in the context of the MAC token draft, how is realm used in some sane way?  Am I right that a server might know of multiple ways to obtain a MAC token?  Should we define the realm "oauth2" and then have that imply the link relationship names?  This would mean we can support:

  WWW-Authenticate: MAC realm="oauth2"
  WWW-Authenticate: MAC realm="x-newspec"
  Link: <http://login.example.com/token?grant_type=MAC> rel="oath2-token"
  Link: <http://login.example.com/auth> rel="oath2-auth"
  Link: <http://login.example.com/newauth/MAC> rel="x-newspec"

If we do define the realm this way, should this go into the core spec?

-bill

> Sent: Monday, February 07, 2011 3:07 PM
> To: William Mills; Torsten Lodderstedt
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme name
> (deadline: 2/10)
>
> I'm a strong advocate of the Link approach, given that authorization
> information does not belong on the authentication headers.
>
> EHL
>
> > > >         WWW-Authenticate: 401 error="blah blah blah"
> auth_types="Bearer
> > > MAC Basic"
> > > >
> > > >> I agree, that is still to be defined. There seems to be some
> push
> > > back
> > > >> In a previous message, I did suggest the web site return HTTP
> 401
> > > >> as below...
> > > >>>> 401 Unauthorized
> > > >> ubiquitous "service documentation" may come in to play here.
> Some
> > > form
> > > >>>>>> Or conversely you don't have to have OAuth to use MAC, JWT,
> or
> > > >>>>>> whatever.
> > > >>>>>>
> > > >>>>>> Phil
> > > >>>>>> [email-masked]
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>>> How is this different from option 1? Wouldn't that need
> some
> > > >>>>>> registry?
> > > >>>>>> token type registry. Using a sub-scheme means you also need
> a
> > > >>>> registry
> > > >>>>>>> Sure, there is no registry for schemes yet, but we would
> still
> > > >> need
> > > >>>>>>> May or may not be. My point is that this group is not
> focused
> > > on
> > > >>>>>>> creating generic authentication schemes. Are you aware of
> any
> > > >> other
> > > >>>>>>>>>> - existing frameworks usually switch on scheme name, not
> on
> > > >> sub
> > > >>>>>>>>> I can see this as a potential problem. But considering
> that
> > > >> there
> > > >>>>>> wasn't much
> > > >>>>>>>>>> - potential to produce a very complicated scheme once
> many
> > > sub
> > > >>>>>> schemes
> > > >>>>>>>>>> are added.
> > > >>>>>>>>> Why? I would argue that this option actually produces
> more
> > > >>>> uniform
> > > >>>>>>>>> schemes because it forces all of them to be name/value
> pairs.
> > > >>>>>> Beyond
> > > >>>>>>>> It is still a single scheme with many different sub-
> schemes,
> > > >> each
> > > >>>>>> way I look at it is that if I try to fully implement this
> mega
> > > >>>> scheme
> > > >>>>>> task. On the other hand, if you split it across scheme name,
> we
> > > >>>> already

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 8 Feb 2011 15:46:53 -0700

Realm is really only useful when MAC is used outside of OAuth like Basic or Digest and informs the client when it should try and reuse the same credentials. But with OAuth, presumably, the server will tell the client (using a parameter or documentation) where to use the token, making realm pointless.

EHL

> From: William Mills [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2011 2:40 PM
> To: Eran Hammer-Lahav; Torsten Lodderstedt
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme
> name (deadline: 2/10)
>
> So, if we go with the Link approach and we are thinking in the context of the
> MAC token draft, how is realm used in some sane way?  Am I right that a
> server might know of multiple ways to obtain a MAC token?  Should we
> define the realm "oauth2" and then have that imply the link relationship
> names?  This would mean we can support:
>
> > >     Link: <http://login.example.com/token?grant_type=MAC>
> > > rel="oath2- token"
> > >     Link:
> > >
> >
> > > > that's not the way WWW-Authenticate headers are used today.
> > > > Instead the resource server should return a single
> > > > WWW-Authenticate header _per_ supported authentication scheme,
> > > > such as
> > > >
> > > > >> on discovery, but this is likely warranted.  If only because
> > > > >> web
> > > > sites
> > > > >> via an OAuth profile or via some default profile.  That could
> > > > >> be handled with something like:
> > > > >>
> > > > >>>>>> From: [email-masked]
> > > > >>>>>> [mailto:[email-masked]]
> > > On
> > > > >>>> Behalf
> > > > >>>>>> Of Phil Hunt
> > > > >>>>>> current registry but httpbis might be creating one), as
> > > > >>>>>> well
> > as
> > > > >> the
> > > > >>>> -12
> > > > >>>>>>> No one has to implement a mega scheme. All schemes must
> > > > >>>>>>> use
> > > > >>>>>> name/value
> > > > >>>>>>> I thought we dropped WWW-Authenticate. Why cannot
> WWW-
> > > > >> Authenticate

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 8 Feb 2011 15:48:04 -0700

Thanks Mike.

How are you going to show the scheme name? bearer, Bearer, BEARER, ...? It is case-insensitive but want to be consistent.

EHL

> Sent: Tuesday, February 08, 2011 9:46 AM
> To: Marius Scurtescu; Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline:
> 2/10)
> 
> I'm likewise OK with #1.  As I'd written previously, I wasn't religious about the
> name "OAuth2"; I was for it for to be consistent with past drafts and so as not
> to introduce a breaking change.  Given that there appears to be consensus to
> make a change, I'll plan on publishing a draft later this week that contains it
> unless discussion in the next few days convinces us that we should follow a
> different course.
> 
> 				-- Mike
> 
> Of Marius Scurtescu

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Feb 2011 23:06:51 +0000

It will be either OAuth2Bearer or Bearer, depending upon the outcome of the vote just sent to the list.

				-- Mike

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Tuesday, February 08, 2011 2:48 PM
To: Mike Jones; Marius Scurtescu
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10)

Thanks Mike.

EHL

> I'm likewise OK with #1.  As I'd written previously, I wasn't 
> religious about the name "OAuth2"; I was for it for to be consistent 
> with past drafts and so as not to introduce a breaking change.  Given 
> that there appears to be consensus to make a change, I'll plan on 
> publishing a draft later this week that contains it unless discussion 
> in the next few days convinces us that we should follow a different course.
> 
> 				-- Mike
>