Subject: [OAUTH-WG] Looking for a compromise on signatures and other open issues

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 27 Sep 2010 23:25:58 -0700

(Please take a break from the other threads and read this with an open mind. I have tried to make this both informative and balanced.)

--- IETF Process

For those unfamiliar with the IETF process, we operate using rough consensus. This means most people agree and no one strongly objects. If someone strongly objects, it takes a very unified group to ignore that person, with full documentation of why the group chose to do so. That person can raise the issue again during working group last call, area director review, and IETF last call - each has the potential to trigger another round of discussions with a wider audience. That person can also appeal the working group decision before it is approved as an RFC.

The process is managed by the working group chairs. The chairs elect the editor and make consensus calls. So far this working group had only a few consensus calls (breaking the 1.0a RFC into two parts and dropping these in favor of a unified WRAP + 1.0a draft). From my experience and understanding of the process, this working group does not have rough consensus on any of the open items to make consensus calls and close the issues. Simply dismissing the few objections raised will not accomplish finishing the document sooner, but will only add more rounds of debates now and at a later time.

One of the problems we have is that we work without a charter. Usually, the charter is the most useful tool chairs have when limiting scope and closing debates. For example, had we fixed the charter last year to explicitly say that we will publish one document with both bearer tokens and signatures, the chairs could have ended this argument by pointing to the charter. Since we have no charter, the chairs have little to offer in terms of ending these disagreements. We never officially agreed what we are here to solve.

The reality of this working group is that we need to find a way to make everyone happy. That includes every one of those expressing strong opinions. Any attempt to push people around, dismiss their views, or reject reasonable compromises will just keep the issues open. If this small group cannot reach agreement, the specification will surely fall apart during working group last call, area director review, IETF last call, application area review, security area review, general area review, IANA review, and IESG review.

It's a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change).

--- Open Issues

This working group has failed to reach consensus on a long list of items, among them are the inclusion of signatures, signatures format, use of HTTP authentication headers, restrictions on bearer tokens, support for specific profiles, etc. While many of these items faded away, I would not be surprise to see them all come back.

The current argument over signatures ignores compromises and agreements reached over the past two years. This working group explicitly rejected WRAP as the replacement for OAuth 1.0 and the whole point of combining 1.0a with WRAP was the inclusion of signatures. We reached another agreement to keep signatures at the Anaheim meeting. The current draft is a version of WRAP alone.

There are currently three separate threads going on:

1. OAuth 1.0a style signatures vs. JSON proposals
2. Including a signature mechanism in core
3. Concerns about bearer tokens and HTTPS

The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide.
The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can't agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus.

The third item has also been debated and blogged for a long time and is not going to be resolved in consensus. Instead, we will need to find the right language to balance security concerns with the reality that many providers are going to deploy bearer tokens no matter what the IETF says. The OAuth 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTPS, and I would expect the same issue to come up with the current draft.
--- Proposal

1. Add a parameter to the token response to include an extensible token scheme.

The default (if omitted) will be whatever the bearer token scheme is called. This will allow the authorization server to return any token type it deems appropriate, and for other specifications to define additional parameters such as token_secret. Others can extend the token request endpoint by allow the client to request a specific token scheme.

2. Break the core specification into multiple parts.

Go back to the original working group consensus to break the document into two parts: getting a token and using a token. Getting a token will include everything from core expect for section 5. Section 5 will become a new specification which will describe how to use a bearer token (replacing the generic 'OAuth' scheme with something more descriptive like).

3. Introduce two signature proposals in one or more documents, for the JSON token and 1.0a-like method.

One, both, or none can become working group item.

--- Benefits

1. Remove the HTTP binding from the core specification, leaving it transport agnostic for using access tokens.

2. Solve a few open issues:

* Concerns over bearer tokens as the preferred/promoted/default token method.
* The use of one or more HTTP authentication schemes, and the general architecture of using tokens.
* Issues around scheme names.
* Concerns over requiring HTTPS will be limited to only one part of the protocol.
* The need to pick one signature format.
* The need to finish signatures before the core ('how to get an access token').
* The need to decide on discovery for the entire protocol (moves it to each scheme).

3. Allow moving the core specification to last call within a few weeks (and maybe also the bearer token part).

--- Downside

The only downside of this approach is that people will need to read at least two documents. It will not take any more effort or time, just some guidance.

--- Request for feedback

This proposal represents a purely editorial compromise. I believe it gives everyone enough to move forward. It has no impact on implementations. By breaking the problem into pieces, we allow those who strongly disagree to simply disengage that work and focus on the parts that matter to them.

EHL

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 28 Sep 2010 17:35:30 +1000

Sounds great Eran,

> 1. Add a parameter to the token response to include an extensible token scheme.

Yes. I suggest a parameter named "scheme". The value can be an HTTP authentication scheme name (eg "scheme":"BASIC") for which the response is providing credentials. Not all possibilities are HTTP authentication schemes but they can be assigned pseudo-HTTP-auth-scheme-names (eg "scheme":"TLS-PSK").

> The default (if omitted) will be whatever the bearer token scheme is called.

May as well include the bearer token scheme name (ie don't bother with a default). Might even be convenient to use the scheme name as a JSON key in a token response.

  "credentials":{

    "bearer":{"token":"54er"},

    "basic":{"userid":"jim","password":"beer2"} }

> 2. Break the core specification into multiple parts.

Yes. Hopefully the "using a token" parts don't have to be OAuth-specific. They might not even use the term "token". A signature spec could use an "id" and "key", without caring whether or not those items came from a "getting a token" response or from a config file.

> 3. Introduce two signature proposals in one or more documents, for the JSON token and 1.0a-like method.

Yes. Separate docs for each signature proposal sounds best to me.

> * The need to decide on discovery for the entire protocol (moves it to each scheme).

I don't think it removes much of the need for discovery.

Apps still need to discover that OAuth delegation can be used to access a resource (and where to send the user). I suspect the token response performs some of the discovery related to specific schemes (eg the response says "here is a token to use with the 'BEARER' scheme", or "here is an id for this delegation and a secret to used in signature scheme XYZ".

--

James Manger

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Sep 2010 10:05:14 -0400

+1 on the split. I think it's an elegant approach, and it won't be any
harder to follow than a monolithic spec with multiple optional sections.
Especially if we put together the right guidance as a gateway to the
spec.

OAuth 1.0 (and -a) really talk about three different things: how to get
a token, how to use a token, and how to sign an HTTP request so that you
know who it came from without using full two-way TLS. Much of the
confusion that I've seen on "What is OAuth" surrounding 1.0 came from
this conflation of three things. The fact that "two-legged OAuth" still
gets to be called "OAuth" at all, even when it doesn't touch a token,
speaks to this discontinuity, and it remains to me the most shining
example of why we do need signatures but that they shouldn't be tied to
OAuth tokens.

Spec 1 can provide common ways (profiles) to get tokens and provide
mechanisms for extending the methods of getting tokens (the grant-type
parameter) along with mechanisms for extending what goes with the token
(token secrets, for example).

Spec 2 can provide ways to use bearer-style OAuth tokens with a PR. This
will be a short an simple spec, and mostly concerned with making sure
everybody names the parameter the right thing.

Spec 3/4 can provide ways to use signed tokens with a PR, through signed
HTTP requests (oauth 1.0a, magic signatures) or signed tokens (JWT), or
both. These can in turn provide mechanisms for extending the signature
algorithms, key management, etc. 

I've long been in favor of factoring out signing, and I don't see any
downsides to this approach right now.

 -- Justin

On Tue, 2010-09-28 at 02:25 -0400, Eran Hammer-Lahav wrote:
> (Please take a break from the other threads and read this with an open
> mind. I have tried to make this both informative and balanced.)
> 
>  
> 
> --- IETF Process
> 
>  
> 
> For those unfamiliar with the IETF process, we operate using rough
> consensus. This means most people agree and no one strongly objects.
> If someone strongly objects, it takes a very unified group to ignore
> that person, with full documentation of why the group chose to do so.
> That person can raise the issue again during working group last call,
> area director review, and IETF last call - each has the potential to
> trigger another round of discussions with a wider audience. That
> person can also appeal the working group decision before it is
> approved as an RFC.
> 
>  
> 
> The process is managed by the working group chairs. The chairs elect
> the editor and make consensus calls. So far this working group had
> only a few consensus calls (breaking the 1.0a RFC into two parts and
> dropping these in favor of a unified WRAP + 1.0a draft). From my
> experience and understanding of the process, this working group does
> not have rough consensus on any of the open items to make consensus
> calls and close the issues. Simply dismissing the few objections
> raised will not accomplish finishing the document sooner, but will
> only add more rounds of debates now and at a later time.
> 
>  
> 
> One of the problems we have is that we work without a charter.
> Usually, the charter is the most useful tool chairs have when limiting
> scope and closing debates. For example, had we fixed the charter last
> year to explicitly say that we will publish one document with both
> bearer tokens and signatures, the chairs could have ended this
> argument by pointing to the charter. Since we have no charter, the
> chairs have little to offer in terms of ending these disagreements. We
> never officially agreed what we are here to solve.
> 
>  
> 
> The reality of this working group is that we need to find a way to
> make everyone happy. That includes every one of those expressing
> strong opinions. Any attempt to push people around, dismiss their
> views, or reject reasonable compromises will just keep the issues
> open. If this small group cannot reach agreement, the specification
> will surely fall apart during working group last call, area director
> review, IETF last call, application area review, security area review,
> general area review, IANA review, and IESG review.
> 
>  
> 
> It’s a long process, and at each step, anyone can raise their hand and
> object. A united working group is the most important tool to end
> discussions over objections and concerns raised at each step. It also
> give people the confidence to implement a working group final draft
> before it is published as an RFC (because it is much less likely to
> change).
> 
>  
> 
> --- Open Issues
> 
>  
> 
> This working group has failed to reach consensus on a long list of
> items, among them are the inclusion of signatures, signatures format,
> use of HTTP authentication headers, restrictions on bearer tokens,
> support for specific profiles, etc. While many of these items faded
> away, I would not be surprise to see them all come back.
> 
>  
> 
> The current argument over signatures ignores compromises and
> agreements reached over the past two years. This working group
> explicitly rejected WRAP as the replacement for OAuth 1.0 and the
> whole point of combining 1.0a with WRAP was the inclusion of
> signatures. We reached another agreement to keep signatures at the
> Anaheim meeting. The current draft is a version of WRAP alone.
> 
>  
> 
> The first item will not be resolved because we are not going to reach
> industry consensus over a single signature algorithm (this is a
> general comment, not specific to these two proposals). The only thing
> we can do is let those who care about each solution publish their own
> specification and let the market decide.
> 
> The second item, while it was part of the very first compromise this
> working group made (when we combined the two specifications), cannot
> be resolved because of #1. We can’t agree on which signature method to
> include, and including all is not practical. For these reasons,
> including a signature algorithm in core is not likely to happen. I
> have made some proposals but they received instant negative feedback
> which means we have no consensus.
> 
>  
> 
> The third item has also been debated and blogged for a long time and
> is not going to be resolved in consensus. Instead, we will need to
> find the right language to balance security concerns with the reality
> that many providers are going to deploy bearer tokens no matter what
> the IETF says. The OAuth 1.0a RFC was blocked by the IESG until the
> PLAINTEXT method required HTTPS, and I would expect the same issue to
> come up with the current draft.
> 
> --- Proposal
> 
>  
> 
> The default (if omitted) will be whatever the bearer token scheme is
> called. This will allow the authorization server to return any token
> type it deems appropriate, and for other specifications to define
> additional parameters such as token_secret. Others can extend the
> token request endpoint by allow the client to request a specific token
> scheme.
> 
>  
> 
> Go back to the original working group consensus to break the document
> into two parts: getting a token and using a token. Getting a token
> will include everything from core expect for section 5. Section 5 will
> become a new specification which will describe how to use a bearer
> token (replacing the generic ‘OAuth’ scheme with something more
> descriptive like). 
> 
>  
> 
> 1. Remove the HTTP binding from the core specification, leaving it
> transport agnostic for using access tokens.
> 
>  
> 
> * The need to finish signatures before the core (‘how to get an access
> token’).
> 
> The only downside of this approach is that people will need to read at
> least two documents. It will not take any more effort or time, just
> some guidance.
> 
>  
> 
> --- Request for feedback
> 
>  
> 
> This proposal represents a purely editorial compromise. I believe it
> gives everyone enough to move forward. It has no impact on
> implementations. By breaking the problem into pieces, we allow those
> who strongly disagree to simply disengage that work and focus on the
> parts that matter to them.
> 
>  
> 
> EHL
> 
>  
> 
>  
> 
>

---

From: Stefanie Dronia <[email-masked]>
Date: Tue, 28 Sep 2010 17:55:23 +0200

+1 to split the spec into multiple parts

Am 28.09.2010 08:25, schrieb Eran Hammer-Lahav:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Tue, 28 Sep 2010 12:05:37 -0400

+1 I think this is a great path forward

On 9/28/10 2:25 AM, Eran Hammer-Lahav wrote:
> It's a long process, and at each step, anyone can raise their hand and 
> be resolved because of #1. We can't agree on which signature method to 
> token (replacing the generic 'OAuth' scheme with something more 
> descriptive like).
>
> =

---

From: Luke Shepard <[email-masked]>
Date: Tue, 28 Sep 2010 16:16:21 +0000

Eran-

Thanks for writing a great explanation of where we are so far. I agree that it makes sense to logically separate "getting a token" from "using a token", and we should structure it so that there can be extension specs about how to use a token. It also seems clear that we should do some more work to build consensus on signature method. Both great points.

As far as the charter: this workgroup has had a focus on building an interoperable, easy-to-use, developer-friendly standard that is actually used. With the goal of market adoption, we should strive to codify those practices that will people will use. Bearer tokens are already widely adopted - Facebook, Twitter, Google, Microsoft, and others are already using this. While I understand that there are some security considerations, on balance, these companies have chosen that it's an acceptable tradeoff. In the interest of interoperability, doesn't it make sense to include the way that many people are going to use it in the spec?

Anyway, by defining a default parameter, aren't we already admitting that the spec isn't complete without bearer tokens anyway?

On Sep 27, 2010, at 11:25 PM, Eran Hammer-Lahav wrote:

--- IETF Process

It’s a long process, and at each step, anyone can raise their hand and object. A united working group is the most important tool to end discussions over objections and concerns raised at each step. It also give people the confidence to implement a working group final draft before it is published as an RFC (because it is much less likely to change).

--- Open Issues

The first item will not be resolved because we are not going to reach industry consensus over a single signature algorithm (this is a general comment, not specific to these two proposals). The only thing we can do is let those who care about each solution publish their own specification and let the market decide.
The second item, while it was part of the very first compromise this working group made (when we combined the two specifications), cannot be resolved because of #1. We can’t agree on which signature method to include, and including all is not practical. For these reasons, including a signature algorithm in core is not likely to happen. I have made some proposals but they received instant negative feedback which means we have no consensus.

Go back to the original working group consensus to break the document into two parts: getting a token and using a token. Getting a token will include everything from core expect for section 5. Section 5 will become a new specification which will describe how to use a bearer token (replacing the generic ‘OAuth’ scheme with something more descriptive like).

--- Benefits

* The need to finish signatures before the core (‘how to get an access token’).

--- Downside

--- Request for feedback

EHL

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 28 Sep 2010 10:08:30 -0700

> -----Original Message-----
> From: Luke Shepard [mailto:[email-masked]]
> Sent: Tuesday, September 28, 2010 9:16 AM

> As far as the charter: this workgroup has had a focus on building an
> interoperable, easy-to-use, developer-friendly standard that is actually used.
> With the goal of market adoption, we should strive to codify those practices
> that will people will use. Bearer tokens are already widely adopted -
> Facebook, Twitter, Google, Microsoft, and others are already using this.

Sure. I have no disagreement with this. However, while these companies have many resources to make educated decisions about their security architecture, this is not the case for most startups and smaller companies. The challenge is always finding the right balance between interop, security, and usability. We don't want to scare people away from using the protocol, but we do want to make sure they really understand the security tradeoff proposed. I am willing to bet less than 10% of those who read the 1.0a specification read the security consideration section.

> While I understand that there are some security considerations, on balance,
> these companies have chosen that it's an acceptable tradeoff.

And that's clearly their decision to make. I disagree with these tradeoffs and have expressed that. I am not trying to make them change their mind. But while you are focused solely on building a product today, I am focused on the future. I cannot put my name on a specification that I strongly believe will promote a practice I am opposed to, even if it is widely deployed today. By offering an equally accessible alternative, I hope some will make a different choice.

> In the interest
> of interoperability, doesn't it make sense to include the way that many
> people are going to use it in the spec?

Yes, but nothing is lost by breaking it into two documents. We can keep debating this until we reach consensus (which is likely never), or we can 'agree to disagree' by putting everything we agree on in one document, and everything we don't in another. By employing a modular approach, you get what you need, and I get the ability to offer an alternative - both presented equally. It is this equality that I care most about.
 
> Anyway, by defining a default parameter, aren't we already admitting that
> the spec isn't complete without bearer tokens anyway?

The specification describing how to obtain a token is clearly incomplete without another document telling you how to use the token you obtained. I would rather not have a default value at all, and require the parameter present with every token response. I am willing to define a default scheme value to keep this proposal at zero implementation impact. From a protocol architecture perspective, it would be much better not to have a default value. This is another compromise, and if it becomes an argument for not splitting the documents, I will drop my support for a default value.

At the end, I doubt most Facebook, Google, Microsoft, or Salesforce developers will bother to ever read the RFC. They will read the API documentation provided by each company. Some library developers will read it, but I hope they will read all the parts to provide a comprehensive support for bearer tokens, signed tokens, signed requests, common assertions, etc.

I think splitting the current spec into two documents is a reasonable compromise with some useful side benefits. This is a carefully balanced proposal which I hope will get us moving forward quickly. The time for trying to come up with a plan for a single document has passed. We are not going to agree on what such a single document includes.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 28 Sep 2010 11:44:17 -0700

> +1 I think this is a great path forward

+1

Marius

---

From: Brian Campbell <[email-masked]>
Date: Tue, 28 Sep 2010 13:14:01 -0600

+1 seems like a pragmatic compromise

---

From: John Panzer <[email-masked]>
Date: Tue, 28 Sep 2010 12:18:36 -0700

+1.
--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Mon, Sep 27, 2010 at 11:25 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> consensus. This means most people agree and no one strongly objects. If
> someone strongly objects, it takes a very unified group to ignore that
> person, with full documentation of why the group chose to do so. That person
> can raise the issue again during working group last call, area director
> review, and IETF last call - each has the potential to trigger another round
> of discussions with a wider audience. That person can also appeal the
> working group decision before it is approved as an RFC.
>
>
>
> The process is managed by the working group chairs. The chairs elect the
> editor and make consensus calls. So far this working group had only a few
> consensus calls (breaking the 1.0a RFC into two parts and dropping these in
> favor of a unified WRAP + 1.0a draft). From my experience and understanding
> of the process, this working group does not have rough consensus on any of
> the open items to make consensus calls and close the issues. Simply
> dismissing the few objections raised will not accomplish finishing the
> document sooner, but will only add more rounds of debates now and at a later
> time.
>
>
>
> One of the problems we have is that we work without a charter. Usually, the
> charter is the most useful tool chairs have when limiting scope and closing
> debates. For example, had we fixed the charter last year to explicitly say
> that we will publish one document with both bearer tokens and signatures,
> the chairs could have ended this argument by pointing to the charter. Since
> we have no charter, the chairs have little to offer in terms of ending these
> disagreements. We never officially agreed what we are here to solve.
>
>
>
> The reality of this working group is that we need to find a way to make
> everyone happy. That includes every one of those expressing strong opinions.
> Any attempt to push people around, dismiss their views, or reject reasonable
> compromises will just keep the issues open. If this small group cannot reach
> agreement, the specification will surely fall apart during working group
> last call, area director review, IETF last call, application area review,
> security area review, general area review, IANA review, and IESG review.
>
>
>
> object. A united working group is the most important tool to end discussions
> over objections and concerns raised at each step. It also give people the
> confidence to implement a working group final draft before it is published
> as an RFC (because it is much less likely to change).
>
>
>
> --- Open Issues
>
>
>
> This working group has failed to reach consensus on a long list of items,
> among them are the inclusion of signatures, signatures format, use of HTTP
> authentication headers, restrictions on bearer tokens, support for specific
> profiles, etc. While many of these items faded away, I would not be surprise
> to see them all come back.
>
>
>
> The current argument over signatures ignores compromises and agreements
> reached over the past two years. This working group explicitly rejected WRAP
> as the replacement for OAuth 1.0 and the whole point of combining 1.0a with
> WRAP was the inclusion of signatures. We reached another agreement to keep
> signatures at the Anaheim meeting. The current draft is a version of WRAP
> alone.
>
>
>
> industry consensus over a single signature algorithm (this is a general
> comment, not specific to these two proposals). The only thing we can do is
> let those who care about each solution publish their own specification and
> let the market decide.
>
> working group made (when we combined the two specifications), cannot be
> resolved because of #1. We can’t agree on which signature method to include,
> and including all is not practical. For these reasons, including a signature
> algorithm in core is not likely to happen. I have made some proposals but
> they received instant negative feedback which means we have no consensus.
>
>
>
> The third item has also been debated and blogged for a long time and is not
> going to be resolved in consensus. Instead, we will need to find the right
> language to balance security concerns with the reality that many providers
> are going to deploy bearer tokens no matter what the IETF says. The OAuth
> 1.0a RFC was blocked by the IESG until the PLAINTEXT method required HTTPS,
> and I would expect the same issue to come up with the current draft.
>
> --- Proposal
>
>
>
> called. This will allow the authorization server to return any token type it
> deems appropriate, and for other specifications to define additional
> parameters such as token_secret. Others can extend the token request
> endpoint by allow the client to request a specific token scheme.
>
>
>
> Go back to the original working group consensus to break the document into
> two parts: getting a token and using a token. Getting a token will include
> everything from core expect for section 5. Section 5 will become a new
> specification which will describe how to use a bearer token (replacing the
> generic ‘OAuth’ scheme with something more descriptive like).
>
>
>
> least two documents. It will not take any more effort or time, just some
> guidance.
>
>
>
> --- Request for feedback
>
>
>
> This proposal represents a purely editorial compromise. I believe it gives
> everyone enough to move forward. It has no impact on implementations. By
> breaking the problem into pieces, we allow those who strongly disagree to
> simply disengage that work and focus on the parts that matter to them.
>
>
>
> EHL
>
>
>
>
>

---

From: "Keenan, Bill" <[email-masked]>
Date: Tue, 28 Sep 2010 12:23:28 -0700

+1

Eran, thanks for framing this up...

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Sep 2010 13:58:30 -0600

On 9/28/10 12:25 AM, Eran Hammer-Lahav wrote:
> person, with full documentation of why the group chose to do so. That
> person can raise the issue again during working group last call, area
> director review, and IETF last call - each has the potential to trigger
> another round of discussions with a wider audience. That person can also
> appeal the working group decision before it is approved as an RFC.

To clarify, "rough consensus" does not mean "unanimity" and it does not
mean "one vocal person can launch their own personal DoS against the
WG". The chairs (and if necessary the sponsoring AD) do have tools at
their disposal for declaring consensus.

That said, I think your proposal is a reasonable compromise for how to
move this WG forward.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Tue, 28 Sep 2010 15:12:32 -0500

+1

The proposal makes sense. I particularly like the side effect that the use of access tokens is no longer bound to HTTP.

Hui-Lan Lu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, September 28, 2010 2:26 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] Looking for a compromise on signatures and other open issues

--- IETF Process

--- Open Issues

--- Proposal

--- Benefits

--- Downside

--- Request for feedback

EHL

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Tue, 28 Sep 2010 15:03:45 -0500

+1

The proposal makes sense. I particularly like the good side effect that the use of access tokens is no longer bound to HTTP.

Hui-Lan Lu

--- IETF Process

--- Open Issues

--- Proposal

--- Benefits

--- Downside

--- Request for feedback

EHL

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Sep 2010 17:08:50 -0700

I am mildly concerned that breaking the spec into multiple parts makes it harder for the spec reader to understand what is going on. Where does a complete example of getting and using a token? Imagine how confusing HTTP would be if the request and response were in separate specs.

I'm not sure that this compromise is a compromising. Seems like it enables people that think bearer tokens are bad can pretend to ignore them because they are in a different document.

My argument for having the signature mechanism in a different document was so that it could be used by other specs. This proposal breaks the spec at a different level, and I don't see the benefit. What am I missing?

I am supportive of having signatures be part of OAuth. I was hoping that if a signing mechanism was agreed on, that it would be in a format that would be reusable by others and would be able to have general libraries developed for it.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 28 Sep 2010 22:42:46 -0700

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Tuesday, September 28, 2010 5:09 PM

> I am mildly concerned that breaking the spec into multiple parts makes it
> harder for the spec reader to understand what is going on. Where does a
> complete example of getting and using a token? Imagine how confusing
> HTTP would be if the request and response were in separate specs.

You mean like break the HTTP specification into, say, 7 parts? Maybe something like this:

1: URIs, Connections, and Message Parsing
2: Message Semantics
3: Message Payload and Content Negotiation
4: Conditional Requests
5: Range Requests and Partial Responses
6: Caching
7: Authentication

This is exactly what the original HTTP authors are doing these days [1]. You should have probably chose another example to make your point :-).

Joking aside, I don't buy this argument for two reasons. First, most developer are not going to read the actual specification - they will read API documentations, books, and tutorials. Very few people actually read RFC 2616 in whole (most just use it as a reference for status codes). Second, you are exaggerating the complexity of following a link to another part.

Would it be better to have everything in one document? Sure! But is it worth delaying this work by another year or so? That's the point of this compromise. It gives everyone the technical details they care about, treats competing views equally, at the small cost of having to read one more document (but same number of pages) if you only care about bearer tokens. That's the compromise.

I am confident that I can write easy to follow prose that will explain that this specification shows how to obtain a token, while other specifications show how to use it (and discuss the specific properties of different token types).
 
I believe my detailed proposal addresses all the points raised in your feedback.

EHL

[1] http://tools.ietf.org/wg/httpbis/

---

From: Mark Mcgloin <[email-masked]>
Date: Wed, 29 Sep 2010 08:55:26 +0100

I echo Dick's sentiment, mildly

-1 to splitting acquiring and using a token. It may not confuse people
actively engaged in the WG but what about everyone else?

Also, as Torsten and I look at security considerations, I wonder if there
are some examples that link the threat model for acquiring a token and
using a token.  So:

1) Will the decisions a service provider make when granting a token depend
on, or affect, the use case for using that token?
2) Will the use case, grant type or other flow parameters a client selects
for acquiring a token, depend on how they will use that token?

I don't have concrete examples to back this up but possibilities include:
automatic granting of access token, refresh tokens, non-secure channels, ??

Regards
Mark McGloin

Dick Hardt wrote on 29/09/2010 01:08

harder for the spec reader to understand what is going on. Where does a
complete example of > getting and using a token? Imagine how confusing HTTP
would be if the request and response were in separate specs.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 29 Sep 2010 07:50:33 -0700

> From: Mark Mcgloin [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2010 12:55 AM

> -1 to splitting acquiring and using a token. It may not confuse people actively
> engaged in the WG but what about everyone else?

We are already splitting it, by putting signatures elsewhere. Just because you might think bearer tokens are the 'obvious choice' and signatures are the 'optional more advance choice', you are still splitting the protocol over multiple parts. It is just that your preferred way of splitting it is optimized to what you care most about. I have made the same argument about the readability of the specification without signatures in core and was shut down because it will delay the work too much and other reasons.

> Also, as Torsten and I look at security considerations, I wonder if there are
> some examples that link the threat model for acquiring a token and using a
> token.  So:
> 
> 2) Will the use case, grant type or other flow parameters a client selects for
> acquiring a token, depend on how they will use that token?
> 

This is possible, but there is absolutely no benefit from the way the draft is structured today. If you strive to offer a complete and comprehensive solution and security review, you clearly have to include signatures in the same document. How would you discuss these examples and dependencies without the full picture? IOW, how is including bearer token but not other alternatives make answering these questions in the core specification any easier? Why is it any less useful to discuss these questions in each of the token authentication schemes? After all, it is the nature of the scheme that dictates everything else.

This argument is valid but has nothing to do with moving section 5 out.

This leaves readability as the only potential argument against splitting. Why not try it out? What's the worse that will happen? We have to put it back in and look for a different compromise?

And last, if you are going to opposed this proposal, then the burden is on you to offer an alternative that is going to address the concerns and parameters presented in my original post. By definition, a compromise means you don't get everything you want, so what are you willing to give up to help resolve these otherwise blocking issues? I am not trying to tease anyone, but asking an sincere question. Every other proposal has been rejected with sufficient resistance to suggest it will not last through the multiple review stages.

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 29 Sep 2010 15:14:44 +0000

I agree bearer tokens are already in wide usage, I think it makes sense to have a default interoperable token type, much like a token format and signature. The security considerations section can point/cover any issues.

I'm not seeing what the splitting of the document is achieving except side stepping.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luke Shepard
Sent: Tuesday, September 28, 2010 9:16 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

Eran-

--- IETF Process

--- Open Issues

--- Benefits

--- Downside

--- Request for feedback

EHL

---

From: Mark Mcgloin <[email-masked]>
Date: Wed, 29 Sep 2010 16:27:59 +0100

Eran Hammer-Lahav <[email-masked]> wrote on 29/09/2010 15:50:33:

> We are already splitting it, by putting signatures elsewhere. Just
> because you might think bearer tokens are the 'obvious choice' and
> signatures are the 'optional more advance choice', you are still
> splitting the protocol over multiple parts. It is just that your
> preferred way of splitting it is optimized to what you care most
> about. I have made the same argument about the readability of the
> specification without signatures in core and was shut down because
> it will delay the work too much and other reasons.
>

Yes I know and I realise there are conflicting opinions and you want a
compromise. I do not want to block that, hence my mild -1, but want to
raise these 2 points now before the split in case others feel they are
important points.

> > token.
> This is possible, but there is absolutely no benefit from the way
> the draft is structured today. If you strive to offer a complete and
> comprehensive solution and security review, you clearly have to
> include signatures in the same document. How would you discuss these
> examples and dependencies without the full picture? IOW, how is
> including bearer token but not other alternatives make answering
> these questions in the core specification any easier? Why is it any
> less useful to discuss these questions in each of the token
> authentication schemes? After all, it is the nature of the scheme
> that dictates everything else.
>

I think acquiring and using a token can be considered core as you always
need both. I don't have valid security consideration linkage between
acquiring and using the token to back up my assertion that it may confuse
developers if we separate them (yet)

> This leaves readability as the only potential argument against
> splitting. Why not try it out? What's the worse that will happen? We
> have to put it back in and look for a different compromise?
>
> And last, if you are going to opposed this proposal, then the burden
> is on you to offer an alternative that is going to address the
> concerns and parameters presented in my original post. By
> definition, a compromise means you don't get everything you want, so
> what are you willing to give up to help resolve these otherwise
> blocking issues? I am not trying to tease anyone, but asking an
> sincere question. Every other proposal has been rejected with
> sufficient resistance to suggest it will not last through the
> multiple review stages.
>

I am fine with breaking the spec if it means progress towards review stages

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 29 Sep 2010 08:37:17 -0700

Thanks Mark.

> Sent: Wednesday, September 29, 2010 8:28 AM

> developers if we separate them (yet)

Just to be clear, the 'core' designation is completely virtual. No specification will say 'core' in it or position itself as more authoritative than others. OAuth is already a modular protocol with its different profiles and use cases. We have been using this term to talk about the primary document, but with this proposal it is no longer a useful term.

I think that positioning the OAuth name as the 'protocol for exchanging one set of credentials for an access token via HTTP' is useful. What happens next is not always strictly OAuth. This is especially true when the token is used with new or existing schemes that are outside the scope of this working group.

EHL

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 29 Sep 2010 11:39:58 -0400

+1

I think this is a reasonable & practical proposal.

/thomas/

--- IETF Process

--- Open Issues

--- Proposal

--- Benefits

--- Downside

--- Request for feedback

EHL

---

From: Luke Shepard <[email-masked]>
Date: Wed, 29 Sep 2010 16:27:22 +0000

Okay, I'm fine with proceeding down this path. My takeaway is that I don't care really where signatures live, but we definitely need a threat analysis and security considerations document dealing with how and in what contexts to use bearer tokens.

On Sep 28, 2010, at 10:08 AM, Eran Hammer-Lahav wrote:
From: Luke Shepard [mailto:[email-masked]]

In the interest

EHL

---

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 30 Sep 2010 11:23:00 +0200

+1

While it's good to have one document, it's better to have two good documents
instead of one that we're unhappy with.

There'll be "Implementer's Guides" and "Tutorials" later who will do the job
of explaining how to make sense of the two (which of course doesn't mean I'm
advocating specifications which are hard to understand without other
material).

2010/9/28 Eran Hammer-Lahav <[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Sep 2010 07:45:29 -0700

Note there will be three documents not two.

The suggested change does not address the issue that myself and others had raised with having signatures be in the core. The suggestion was that having signatures be a different spec made them reusable by other groups and enabled a more comprehensive signature specification. Having them in core made them OAuth specific.

I think there was consensus with those that had seen the advantage of a different signature spec that including the OAuth 1.0A signature mechanism in core and having a clear extension mechanism was a satisfactory direction. This enables alternative algorithms to be specified

From what I have gathered, the only advantage to breaking it up is participants can "ignore" bearer tokens or signatures if they don't "value" one of those mechanisms. Personally, I think it is important that we all respect the various use cases rather than push one mechanism under the rug because it is not important to us. From what I understand of IETF process, we are striving for rough consensus. If there is not consensus that both bearer tokens and signatures are important, then the I think we need to have a break through in that issue rather than breaking up the document.

As I have reflected on this proposal, I am now a strong -1 for the following reason:

Deep understanding of the full flow and security implications of the full flow is critical to a successful implementation and deployment. As Eran keeps pointing out, understanding the security implications of bearer tokens (and conversely, of using signatures) is a critical security decision. Breaking the document up implies to the reader that not all sections need to be read. If they are not all read, then the reader will not have a complete understanding of the protocol, and hence not a complete understanding of the security implications.

-- Dick

On 2010-09-30, at 2:23 AM, Lukas Rosenstock wrote:

> +1
> 
> While it's good to have one document, it's better to have two good documents instead of one that we're unhappy with.
> 
> There'll be "Implementer's Guides" and "Tutorials" later who will do the job of explaining how to make sense of the two (which of course doesn't mean I'm advocating specifications which are hard to understand without other material).
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 30 Sep 2010 11:33:35 -0700

> Sent: Thursday, September 30, 2010 7:45 AM

> The suggested change does not address the issue that myself and others had
> raised with having signatures be in the core. The suggestion was that having
> signatures be a different spec made them reusable by other groups and
> enabled a more comprehensive signature specification. Having them in core
> made them OAuth specific.

Of course it does! It addresses it by keeping signature proposals as separate documents. This is exactly what you have been asking for! Now it is up to those working on each signature proposal to decided how generic they want to keep it.
 
> I think there was consensus with those that had seen the advantage of a
> different signature spec that including the OAuth 1.0A signature mechanism
> in core and having a clear extension mechanism was a satisfactory direction.
> This enables alternative algorithms to be specified

There was no consensus! Mike Jones and Marius Scurtescu outright objected, Anthony Nadalin was not supportive, you and Lukas Rosenstock raised concerns, John Panzer suggested he might be ok with it, and Mark McGloin said it is worth trying. That's it.

On the other hand, the proposal to break the specification has an overwhelming support: 13 people support it unconditionally, 2 raised concerns but are happy to give it a try, and 1 didn't see the point (but did not object). You are the only one with an actual objection (so far), and one which is pretty easy to test, and much faster than anything else suggested.

Breaking the specification will take a few days and will let us judge these assertions in practice. I suggest we move forward with this proposal and revisit your objection later when we have actual documents to discuss. If the result will prove to be unreadable, we can always go revisit, and the IETF process will give you plenty of opportunities to voice your concerns.

EHL

[1] http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Sep 2010 12:08:16 -0700

On 2010-09-30, at 11:33 AM, Eran Hammer-Lahav wrote:

> Of course it does! It addresses it by keeping signature proposals as separate documents. This is exactly what you have been asking for!

No, that is not what I was asking for. You are breaking it on "using a token". Your proposal does not create an independent signing spec. As stated, I don't have a concern with signatures being part of OAuth,

> Now it is up to those working on each signature proposal to decided how generic they want to keep it.
> 

If the WG is happy spending time on yet another experiment on moving around the content, please proceed.

You have not addressed my core point which is that the WG needs to come to agreement on which use cases are in scope, which I think is the underlying issue here. I think breaking the spec into 3 parts is just moving around deck chairs.

-- Dick