Subject: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

From: Mike Jones <[email-masked]>
Date: Thu, 2 Dec 2010 07:35:39 +0000

Draft -01 of the OAuth 2.0 Bearer Token specification is now available.  This version is intended to accompany OAuth 2.0 draft -11<http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-11.txt>.  This draft is based upon the September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, with input from David Recordon and several others.  It includes an extensive Security Considerations section, for which Hannes Tschofenig gets significant credit.

The draft is available at these locations:

http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-01.xml
http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.html
http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.txt
http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-01.xml
http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)

If any of you believe that you should be added to the Acknowledgments in Appendix A, please drop me a note and I'll be glad to add you.

                                                            -- Mike

---

From: Andrea Reginato <[email-masked]>
Date: Thu, 2 Dec 2010 10:43:27 +0100

I was reading the specifications, mainly the new related to the security
issues.

One thing is pointed out in the security summary is related to the fact that
the
token should not be in the URL. So, here come some of my doubts on the the
user agent flow, where it is set on the URL fragment. Even more, if working
only on the client side, I suppose I should save the token somewhere and the
cookie, secure one, should be the option. There should also be the
possibility
to save it on a JavaScript variable, but this means I'll only use AJAX style
web
page definition (no reloads).

If possible, I would love to have some clarifications on the the user agent
flow
security definition. As far I've searched on the web several project do not
use it
because they think "its not secure", so I would love to understand more
about.

On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones <[email-masked]>wrote:

>  Draft -01 of the OAuth 2.0 Bearer Token specification is now available.
>  This version is intended to accompany OAuth 2.0 draft -11<http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-11.txt>.
> This draft is based upon the September 3rd preliminary OAuth 2.0 draft by
> Eran Hammer-Lahav, with input from David Recordon and several others.  It
> includes an extensive Security Considerations section, for which Hannes
> Tschofenig gets significant credit.
>
>
>
> http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion
> repository, with html, txt, and html versions available)
>
>
>
> If any of you believe that you should be added to the Acknowledgments in
> Appendix A, please drop me a note and I’ll be glad to add you.
>
>
>
>                                                             -- Mike
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Andrea Reginato

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Dec 2010 08:24:33 -0700

Fragments are not allowed in the HTTP request URI and are not transmitted. They are allowed in the Location header which is not an issue.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrea Reginato
Sent: Thursday, December 02, 2010 1:43 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

I was reading the specifications, mainly the new related to the security issues.

One thing is pointed out in the security summary is related to the fact that the
token should not be in the URL. So, here come some of my doubts on the the
user agent flow, where it is set on the URL fragment. Even more, if working
only on the client side, I suppose I should save the token somewhere and the
cookie, secure one, should be the option. There should also be the possibility
to save it on a JavaScript variable, but this means I'll only use AJAX style web
page definition (no reloads).

If possible, I would love to have some clarifications on the the user agent flow
security definition. As far I've searched on the web several project do not use it
because they think "its not secure", so I would love to understand more about.

On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Draft -01 of the OAuth 2.0 Bearer Token specification is now available.  This version is intended to accompany OAuth 2.0 draft -11<http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-11.txt>.  This draft is based upon the September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, with input from David Recordon and several others.  It includes an extensive Security Considerations section, for which Hannes Tschofenig gets significant credit.

                                                            -- Mike

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

--
Andrea Reginato

---

From: Kris Selden <[email-masked]>
Date: Thu, 2 Dec 2010 08:16:29 -0800

Also, when a browser follows the Location header it strips the fragment from the URL. Fragments are visible to the client but not sent to the server.

On Dec 2, 2010, at 7:24 AM, Eran Hammer-Lahav <[email-masked]> wrote:

> On Thu, Dec 2, 2010 at 8:35 AM, Mike Jones <[email-masked]> wrote:
> 
> Draft -01 of the OAuth 2.0 Bearer Token specification is now available.  This version is intended to accompany OAuth 2.0 draft -11.  This draft is based upon the September 3rd preliminary OAuth 2.0 draft by Eran Hammer-Lahav, with input from David Recordon and several others.  It includes an extensive Security Considerations section, for which Hannes Tschofenig gets significant credit.
> 
>  
> 
> If any of you believe that you should be added to the Acknowledgments in Appendix A, please drop me a note and I’ll be glad to add you.
> 
>  
> 
>                                                             -- Mike
> 
>  
> 
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 2 Dec 2010 12:19:03 -0800

OAuth 2 Protocol Framework v11 introduces a new required parameter: token_type.

Should the Bearer Token spec define the value for this parameter for
bearer tokens?

Are we blocked by the missing section 6.1. (Access Token Types) of the
Framework spec?

Marius

On Wed, Dec 1, 2010 at 11:35 PM, Mike Jones <[email-masked]> wrote:
>  This version is intended to accompany OAuth 2.0 draft -11.  This draft is
> based upon the September 3rd preliminary OAuth 2.0 draft by Eran
> Hammer-Lahav, with input from David Recordon and several others.  It

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Dec 2010 13:22:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Thursday, December 02, 2010 12:19 PM
> To: Mike Jones
> Cc: [email-masked]
> Should the Bearer Token spec define the value for this parameter for bearer
> tokens?

Yes. 'bearer' seems sensible, but I don't really care. I am going to define 'mac' in my own extension.
 
> Are we blocked by the missing section 6.1. (Access Token Types) of the

No. It will simply describe the general flow and how to define (register) token types and authentication methods for those types. IOW, all spec-talk. You can decide how it works and implement and deal with the extension paperwork later.

EHL
 
> >  This version is intended to accompany OAuth 2.0 draft -11.  This
> > draft is based upon the September 3rd preliminary OAuth 2.0 draft by
> > Eran Hammer-Lahav, with input from David Recordon and several others.
> > It includes an extensive Security Considerations section, for which
> > Hannes Tschofenig gets significant credit.
> >
> >
> >
> > If any of you believe that you should be added to the Acknowledgments
> > in Appendix A, please drop me a note and I'll be glad to add you.
> >
> >
> >
> >                                                             -- Mike
> >
> >
> >

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 2 Dec 2010 12:29:45 -0800

"bearer" sounds good. Thanks for clarifying 6.1.

Both specs look great!

Thanks,
Marius

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 3 Dec 2010 09:41:55 +1000

token_type should be an HTTP authentication scheme name (eg "BASIC" or "BEARER" or "MAC"...).
The core spec (draft-ietf-oauth-v2) should explicitly state this rule.
>From the token_type, the client app knows which auth scheme to use.
[renaming the parameter from "token_type" to "scheme" would help.]

Defining token_type to be an HTTP authentication scheme name effectively defines how OAuth2 can deliver credentials for auth schemes that are independent of OAuth2, eg schemes specified before OAuth2 existed. It eliminates the need for additional specs just to provide a link from OAuth2 to every authentication mechanism.

Some auth mechanisms for which OAuth2 could deliver credentials are not actually HTTP authentication schemes. Eg OAuth2 delivering an id/secret to use in TLS-PSK (pre-shared key). For that you will need a small additional spec to define a token_type value -- ie define a pseudo-HTTP-auth-scheme-name.

P.S. Related to this, the bearer spec (draft-ietf-oauth-v2-bearer) must not use the "OAuth2" scheme name. It needs its own scheme name, eg "BEARER".

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 3 Dec 2010 11:54:40 +1100

Mike Jones,

Thanks for writing draft-ietf-oauth-v2-bearer-01.

I feel there are some major problems with this draft, though.

Primarily, it is bound so tightly to OAuth2 core that it misses the point (& benefit) of separating the specs.

This draft re-uses the "OAuth2" HTTP authentication scheme name. It uses it to transmit a bearer token from a client app to a web server. This scheme name is already used by the core spec (draft-ietf-oauth-v2). The core spec uses it to indicate when a client needs to do a delegation/get-a-token/swap-longterm-cred-for-shortterm-cred flow (and hopefully in the future it will indicate the URIs for doing those flows). These core & bearer uses are quite different. They are different enough that different scheme names need to be used.

The reason the bearer draft almost gets away with re-using OAuth2 is that is only defines an "Authorization: OAuth2 ..." header, while the core spec only defines an "WWW-Authenticate: OAuth2 ..." header so the clash isn't obvious. However, the bearer draft could (and should) usefully define a WWW-Authenticate response header. For instance, such a header could indicate whether or not the server supports bearer tokens in URI query parameters, and/or in the body. At the moment a server MAY support these, with no nice way for a client app to tell.

Splitting the OAuth2 document recognised that OAuth2 delegation flows can deliver credentials for different authentication schemes - so one such authentication scheme should not hijack the OAuth2 name.

--

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 3 Dec 2010 14:59:04 +1100

Eran,

> What does scheme=basic mean [in a token response]?

It means this token response contains credentials that can be used with the HTTP BASIC authentication scheme. Don't try to use the credentials with any other scheme. The access_token value would be used as the user-id, and the token_secret value as the password.

> I think tying type and scheme together is less intuitive then
> letting the type definition provide the right scheme(s).

Keeping them separate offers an additional degree of indirection.
Indirection is sometimes useful, but I don't think it adds any value here.
It just means we need another registry (of token_types, with associated procedures); and we need an extra spec for each authentication mechanism to define the linkage to OAuth2.

A lot of authentication mechanisms take similar inputs (an id and a secret) so they shouldn't each need a separate spec to define their binding to OAuth2.

> I am using 'MAC' for my draft.

As the token_type? As the HTTP authentication scheme? I hope both.

> But its still an OAuth2 extension, not a completely generic HTTP scheme.

I guess it is an OAuth2 extension in as much as it defines how to get MAC credentials from an OAuth2 token response: check token_type=MAC; access_token is the id; token_secret is the MAC key; mac_algorithm is the MAC algorithm.

> It can be used independent of OAuth2 if you somehow got
> a token, secret, and mac algorithm name.

Hopefully you define a "WWW-Authenticate: MAC ..." response header that can list acceptable MAC algorithms.
I think an OAuth2 token response for a MAC scheme should contain the same information as the WWW-Authenticate response header for the MAC scheme, plus the credentials to use (id & secret) and the OAuth2-specific lifetime management bits (eg how/when to refresh). We should explicitly define (in core) how to put a WWW-Authenticate header into a token response.

--
James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 3 Dec 2010 16:27:21 -0800

How about:
- keeping the scheme "OAuth2", for both WWW-Authenticate and Authorization
- define both as name/value pairs (WWW-Authenticate is already)
- require that one of the pairs be "type=<token-type>"

For example:
WWW-Authenticate: OAuth2 type=bearer
Authorization: OAuth2 token=vF9dft4qmT, type=bearer

Marius

---

From: Mike Jones <[email-masked]>
Date: Sat, 4 Dec 2010 01:07:55 +0000

My assumption about the new token_type parameter is that it would be used to communicate the data type of the token -- not the class of the token.  I was imagining token_type values like:
	SWT
	JWT
	urn:oasis:names:tc:SAML:1.0:assertion
	urn:oasis:names:tc:SAML:2.0:assertion

Or Eran, did you mean for the token_type to be more like the WS-Trust 1.3 wst:KeyType parameter, where values defined by that spec are:
	http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey
	http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey
	http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer

I hope you meant the former, as this information would be generally useful (and something I know that our developers have asked for, based upon their deployment experiences).

				Thanks,
				-- Mike

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Thursday, December 02, 2010 12:23 PM
To: Marius Scurtescu; Mike Jones
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

 

EHL
 
> > If any of you believe that you should be added to the 
> > Acknowledgments in Appendix A, please drop me a note and I'll be glad to add you.
> >
> >
> >
> >                                                             -- Mike
> >
> >
> >

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 6 Dec 2010 10:27:44 +1100

Marius,

> Authorization: OAuth2 token=vF9dft4qmT, type=bearer

What is the benefit of trying to couple one form of bearer token so strongly to the OAuth2 delegation flows?
You have now complicated the Authorization header (extra type=bearer param), and the WWW-Authentication header (now indicates that delegation is available, swapping-permanent-cred-for-temp-token is available, and bearer authentication is required -- I hope a client can work out which is relevant in any response).
Should Eran's MAC mechanim also use the same scheme, just with type=mac and adding its own parameters? I hope not.

We end up with multiple specs (core, bearer, MAC, any other auth mechanism...) all adding bits to the same HTTP scheme -- and not just registering their own "type" value, but also all their own parameters (eg alg, nonce?, token...). This causes unnecessary complications, because it is unnecessary tight coupling.

> WWW-Authenticate: OAuth2 type=bearer

What does this mean to a client app?
Does it mean that if the client app already has a bearer token it should repeat the request with that token.
Does it mean the client app should do an OAuth2 flow (which?) and expect a bearer token? Does this type value override any type information in a subsequent token response? That could be dangerous. Should a server include multiple "WWW-Authenticate: OAuth2" headers if it can issue tokens for different authentication mechanisms depending on resources/scopes/client-app-preferences?

"Authorization: BEARER ..." avoids a lot of confusion.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 5 Dec 2010 23:33:27 -0700

Token type is as simple as informing the client how to use the token issued. If you tell it 'bearer' is means 'present it as is without having to do anything else'. If you tell it 'mac' is means 'construct a very specific signature base string and hmac it with the provided secret'. For JWT it means figure out what the token internals mean and use it as needed.

It is pretty straight forward. You give the client a token and tell it exactly what to do with it.

EHL

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, December 03, 2010 5:08 PM
To: Eran Hammer-Lahav; Marius Scurtescu
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

				Thanks,
				-- Mike

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Thursday, December 02, 2010 12:23 PM
To: Marius Scurtescu; Mike Jones
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

 

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 5 Dec 2010 23:34:49 -0700

This is not how most HTTP authentication frameworks work (that was the conclusion from my HTTP Token scheme proposal a year ago). Most frameworks rather switch on the scheme name, not on a parameter inside the header.

EHL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Friday, December 03, 2010 4:27 PM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01

How about:

For example:

Marius

On Thu, Dec 2, 2010 at 7:59 PM, Manger, James H <[email-masked]> wrote:
>> I think tying type and scheme together is less intuitive then letting 
>> the type definition provide the right scheme(s).
>
>> It can be used independent of OAuth2 if you somehow got a token, 
>> secret, and mac algorithm name.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 6 Dec 2010 00:11:50 -0700

> Of Manger, James H
> Sent: Thursday, December 02, 2010 7:59 PM

> It means this token response contains credentials that can be used with the
> HTTP BASIC authentication scheme. Don't try to use the credentials with any
> other scheme. The access_token value would be used as the user-id, and the
> token_secret value as the password.

But that has the same security properties as bearer.

> It just means we need another registry (of token_types, with associated
> procedures); and we need an extra spec for each authentication mechanism
> to define the linkage to OAuth2.

Yeah. But I'm not expecting a flood. We'll have a handful and probably 2 will survive the deployment test. OAuth 1.0a had three signature methods and only one really got any significant traction.
 
> A lot of authentication mechanisms take similar inputs (an id and a secret) so
> they shouldn't each need a separate spec to define their binding to OAuth2.

I don't see a way around it. OAuth returns tokens using form-encoded URI and JSON body replies. If your token is not self describing, you need extra parameters so binding is required anyway.
 
> As the token_type? As the HTTP authentication scheme? I hope both.

In my case both, but I don't care about it as a generic HTTP authentication scheme. It can be used that way but it is defined in clear OAuth context.
 
> I guess it is an OAuth2 extension in as much as it defines how to get MAC
> credentials from an OAuth2 token response: check token_type=MAC;
> access_token is the id; token_secret is the MAC key; mac_algorithm is the
> MAC algorithm.
> 

Nope. You are told what to use when you are issued the token. That's as far as my requirements go (and this spec is based directly on my current project).

EHL

> I think an OAuth2 token response for a MAC scheme should contain the
> same information as the WWW-Authenticate response header for the MAC
> scheme, plus the credentials to use (id & secret) and the OAuth2-specific
> lifetime management bits (eg how/when to refresh). We should explicitly
> define (in core) how to put a WWW-Authenticate header into a token
> response.
> 
> --
> James Manger

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 6 Dec 2010 11:56:31 -0800

> This is not how most HTTP authentication frameworks work (that was the conclusion from my HTTP Token scheme proposal a year ago). Most frameworks rather switch on the scheme name, not on a paramete…

The alternative, as suggested by James, requires a new scheme for each
token type. My guess is that we will have quite a few types pretty
soon:
- bearer opaque
- bearer transparent (JSON, signed by authz server)
- JWT signed
- MAC
- etc.

Who controls the auth header scheme names? Aren't we asking for a
collision here?

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 6 Dec 2010 12:01:18 -0800

> You have now complicated the Authorization header (extra type=bearer param), and the WWW-Authentication header (now indicates that delegation is available, swapping-permanent-cred-for-temp-token is…

Not sure the Authorization header is that more complicated. Name/value
pairs are pretty straight forward and any client or server must be
able to handle them. If anything, the Basic scheme type seems the odd
one to me.

> Should Eran's MAC mechanim also use the same scheme, just with type=mac and adding its own parameters? I hope not.

That's what I was suggesting. Why not?

> We end up with multiple specs (core, bearer, MAC, any other auth mechanism...) all adding bits to the same HTTP scheme -- and not just registering their own "type" value, but also all their own par…

I don't see where the complication is coming from. They all share the
scheme and a 'type' parameter, the rest is type specific.

> "Authorization: BEARER ..." avoids a lot of confusion.

Maybe, but how many schemes are we going to generate? Who controls
these scheme names?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 6 Dec 2010 13:43:38 -0700

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Monday, December 06, 2010 11:57 AM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; [email-masked]
> > This is not how most HTTP authentication frameworks work (that was the
> conclusion from my HTTP Token scheme proposal a year ago). Most
> frameworks rather switch on the scheme name, not on a parameter inside
> the header.
> 

Nah. It's a proposed registry and has never been very active.

EHL

> >> It means this token response contains credentials that can be used with
> the HTTP BASIC authentication scheme. Don't try to use the credentials with
> any other scheme. The access_token value would be used as the user-id,
> and the token_secret value as the password.
> >>
> >>
> >> A lot of authentication mechanisms take similar inputs (an id and a secret)
> so they shouldn't each need a separate spec to define their binding to
> OAuth2.
> >>
> >>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 6 Dec 2010 12:47:03 -0800

> Nah. It's a proposed registry and has never been very active.

Doesn't that mean that we should be even more cautious with creating
lots of schemes?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 6 Dec 2010 14:11:44 -0700

Each scheme will have an RFC and will get proper review. If there is consensus for a new scheme, the rest doesn't matter. And being able to reuse these schemes without having to use a confusing OAuth2 scheme is a big benefit.

EHL

> Sent: Monday, December 06, 2010 12:47 PM
> To: Eran Hammer-Lahav
> >> frameworks rather switch on the scheme name, not on a parameter
> >> inside the header.
> >>
> >> The alternative, as suggested by James, requires a new scheme for
> >> each token type. My guess is that we will have quite a few types
> >> pretty
> >> soon:
> >> - bearer opaque
> Doesn't that mean that we should be even more cautious with creating lots
> of schemes?
> 
> Marius

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 7 Dec 2010 10:00:43 +1100

When a client app gets an OAuth2 token response it needs to know what to do next. In particular, which authentication *protocol* it should use with the received credential. I thought this was what token_type was designed for, hence my suggestion that it hold an HTTP authentication scheme name.

A totally separate piece of information is what is the internal format of a token. Is it a random index to server-side state, or a JWT, or a base64-encoded SAML message? This information could be helpful for protected resource servers if they trust multiple authorization servers. It might be helpful to some client apps, though most should be able to treat a token as an opaque blob. Mike Jones though this was what token_type was designed for.

These two uses are quite separate.
A bearer token could use a JWT, SWT, SAML, or random-string syntax.
Similarly, an "id" in a MAC scheme (or the user-id in the BASIC scheme) could be a JWT, SWT, SAML, or random-string.
Conversely, knowing a token is in JWT format doesn't tell a client app if it should sent the token in a "Authorization: BEARER ..." header, or a oauth_token=.. query-string/body parameter, or in a "Authorization: MAC ..." header along with a signature.

Marius,
I certainly do NOT want new HTTP schemes to be invented every time an authorization server comes up with a new internal structure for its tokens/ids. If we need to indicate the internal structure of a token/id (and assuming self-describing syntaxes are insufficient), then we need a parameter that is *separate* from the indication of the authentication protocol.

Looks like we need two parameters:
* scheme
* token_format

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 7 Dec 2010 10:44:51 +1100

Eran,

> But that has the same security properties as bearer.

True.

>> Keeping [type and scheme] separate...

> Yeah. But I'm not expecting a flood. We'll have a handful and probably 2 will survive the deployment test. OAuth 1.0a had three signature methods and only one really got any significant traction.

Its not a flood of schemes I am concerned about, but providing a clear mental model. It is less obvious how delegation and HTTP auth go together when one uses "type" and the other uses "scheme", with any connection between the two left to a case-by-case description.

>I don't see a way around it. OAuth returns tokens using form-encoded URI and JSON body replies. If your token is not self describing, you need extra parameters so binding is required anyway.

It is a pity the form-encoding isn't a base64url-encoded version of the JSON body reply isn't it :-(

> In my case both, but I don't care about it as a generic HTTP authentication scheme. It can be used that way but it is defined in clear OAuth context.

My guess is that it would be easier to understand a standalone MAC HTTP auth scheme, than have to understand it amongst the complexities of delegation/swapping-perm-cred-for-temp-cred/swapping-assertion-for-temp-cred/etc.

I am looking forward (with some trepidation) to seeing the MAC scheme in your current project.

--
James Manger