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

[Breno]

I support breaking the document into two parts.

Methods to access APIs are not going to be many -- there are currently
two proposals on the table, OAuth1.0-like signatures and signed JSON
tokens -- but the existing proposals are fundamentally different.
There's probably little to gain in writing them together. In
particular, they require completely different security considerations
treatment.

On the other hand, the methods to obtain tokens are already many, and
I suspect that future use cases will appear that will lead to new ways
to obtain tokens [1]. However varied these methods may be, they seem
to share enough context that reading them together is not confusing.

[1] For e.g., There is a variety of mechanisms to authenticate users
that do not involve HTTP but need to provide a bridge to authenticate
users to web-based APIs. Even for HTTP-based authentication, there is
precedent established by OAuth1.0(a) -- one example of a flow not
covered in the protocol spec would be the OpenID+OAuth extension.


On Fri, Oct 1, 2010 at 9:07 PM, Eran Hammer-Lahav  wrote:
> Given the overwhelming support for this proposal, I am officially asking the
> chairs to make a consensus call to break the current document into two
> parts. This will be done with the understanding that the result will be
> reviewed by the working group again once the parts are stable to determine
> if it compromises the overall readability and security analysis of the
> protocol.
>
>
>
> I am also requesting that the chairs assign a new editor for the bearer
> token part of the specification. I will continue as editor on the ‘how to
> obtain a token’ part, and will also publish an individual submission I-D for
> an alternative signature proposal based on my proposal in the -05 draft.
>
>
>
> EHL
>
>
>
>
>
> From: Eran Hammer-Lahav
> Sent: Monday, September 27, 2010 11:26 PM
>
> To: OAuth WG (oauth@ietf.org)
> Subject: Looking for a compromise on signatures and other open issues
>
>
>
> (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
> authenticati

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

[Eran Hammer-Lahav]

Given the overwhelming support for this proposal, I am officially asking the 
chairs to make a consensus call to break the current document into two parts. 
This will be done with the understanding that the result will be reviewed by 
the working group again once the parts are stable to determine if it 
compromises the overall readability and security analysis of the protocol.

I am also requesting that the chairs assign a new editor for the bearer token 
part of the specification. I will continue as editor on the 'how to obtain a 
token' part, and will also publish an individual submission I-D for an 
alternative signature proposal based on my proposal in the -05 draft.

EHL


From: Eran Hammer-Lahav
Sent: Monday, September 27, 2010 11:26 PM
To: OAuth WG (oauth@ietf.org)
Subject: Looking for a compromise on signatures and other open issues

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

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

[Pelle Wessman]

+1, I think this sounds like a sensible path forward

On Tue, Sep 28, 2010 at 8:25 AM, 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.
>
>
>
> 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

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

[Dick Hardt]

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

>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> 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!

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

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


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> 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/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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).
> 
> 2010/9/28 Eran Hammer-Lahav 
> 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.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Lukas Rosenstock]

+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 

> 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.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Luke Shepard]

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:lshep...@facebook.com]

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




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Thomas Hardjono]

+1

I think this is a reasonable & practical proposal.

/thomas/

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

(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

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

[Eran Hammer-Lahav]

Thanks Mark.

> -Original Message-
> From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
> Sent: Wednesday, September 29, 2010 8:28 AM

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

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mark Mcgloin]

Eran Hammer-Lahav  wrote on 29/09/2010 15:50:33:

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

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.

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

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

> EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Luke 
Shepard
Sent: Tuesday, September 28, 2010 9:16 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open 
issues

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:


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

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com]
> Sent: Wednesday, September 29, 2010 12:55 AM

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

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:
> 
> 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, ??

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mark Mcgloin]

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

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> 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/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

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

On 2010-09-27, at 11:25 PM, 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.
>  
> 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 pr

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

[Lu, Hui-Lan (Huilan)]

+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


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

(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

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

[Lu, Hui-Lan (Huilan)]

+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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran 
Hammer-Lahav
Sent: Tuesday, September 28, 2010 2:26 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Looking for a compromise on signatures and other open issues

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

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

[Peter Saint-Andre]

On 9/28/10 12:25 AM, 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.

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/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Keenan, Bill]

+1

Eran, thanks for framing this up...

On Sep 28, 2010, at 12:14 PM, Brian Campbell wrote:

> +1 seems like a pragmatic compromise
> 
> On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu
>  wrote:
>> On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher  wrote:
>>> +1 I think this is a great path forward
>> 
>> +1
>> 
>> 
>> Marius
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Panzer]

+1.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org  /
@jpanzer



On Mon, Sep 27, 2010 at 11:25 PM, 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.
>
>
>
> 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 provide

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

[Brian Campbell]

+1 seems like a pragmatic compromise

On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu
 wrote:
> On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher  wrote:
>> +1 I think this is a great path forward
>
> +1
>
>
> Marius
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Marius Scurtescu]

On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher  wrote:
> +1 I think this is a great path forward

+1


Marius
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

> -Original Message-
> From: Luke Shepard [mailto:lshep...@facebook.com]
> 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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Luke Shepard]

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:

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

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

[George Fletcher]

 +1 I think this is a great path forward

On 9/28/10 2:25 AM, 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.


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

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

[Stefanie Dronia]

 +1 to split the spec into multiple parts

Am 28.09.2010 08:25, schrieb Eran Hammer-Lahav:


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

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

[Justin Richer]

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

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

[Manger, James H]

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.



> --- Benefits

>

> 2. Solve a few open issues:

>

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



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Eran Hammer-Lahav]

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