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