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

  +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 draft.
>
> --- Proposal
>
> 1. Add a parameter to the token response to include an extensible 
> token scheme.
>
> The default (if omitted) will be whatever the bearer token scheme is 
> called. This will allow the authorization server to return any token 
> type it deems appropriate, and for other specifications to define 
> additional parameters such as token_secret. Others can extend the 
> token request endpoint by allow the client to request a specific token 
> scheme.
>
> 2. Break the core specification into multiple parts.
>
> Go back to the original working group consensus to break the document 
> into two parts: getting a token and using a token. Getting a token 
> will include everything from core expect for section 5. Section 5 will 
> become a new specification which will describe how to use a bearer 
> token (replacing the generic ‘OAuth’ scheme with something more 
> descriptive like).
>
> 3. Introduce two signature proposals in one or more documents, for the 
> JSON token and 1.0a-like method.
>
> One, both, or none can become working group item.
>
> --- Benefits
>
> 1. Remove the HTTP binding from the core specification, leaving it 
> transport agnostic for using access tokens.
>
> 2. Solve a few open issues:
>
> * Concerns over bearer tokens as the preferred/promoted/default token 
> method.
>
> * The use of one or more HTTP authentication schemes, and the general 
> architecture of using tokens.
>
> * Issues around scheme names.
>
> * Concerns over requiring HTTPS will be limited to only one part of 
> the protocol.
>
> * The need to pick one signature format.
>
> * The need to finish signatures before the core (‘how to get an access 
> token’).
>
> * The need to decide on discovery for the entire protocol (moves it to 
> each scheme).
>
> 3. Allow moving the core specification to last call within a few weeks 
> (and maybe also the bearer token part).
>
> --- Downside
>
> The only downside of this approach is that people will need to read at 
> least two documents. It will not take any more effort or time, just 
> some guidance.
>
> --- Request for feedback
>
> This proposal represents a purely editorial compromise. I believe it 
> gives everyone enough to move forward. It has no impact on 
> implementations. By breaking the problem into pieces, we allow those 
> who strongly disagree to simply disengage that work and focus on the 
> parts that matter to them.
>
> EHL
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth