OAuth 2.0 is far from being published as an RFC. I estimate it is at least 6 months away from reaching final IESG approval, if not a year. This is mostly due to a significant effort needed in writing and reviewing the security considerations section which so far has received no attention. We can easily lock down the bearer token portions and continue working on the spec. The argument that it needs to be published as an RFC for companies to deploy is both irrelevant and untrue. Facebook and Salesforce are two examples.
If your entire argument is that waiting for a signature will delay core, I am happy to promise that if the rest of the specification is done, and signatures are the only thing holding it back from publication, that we can take them out and publish. My main issue with a separate specification is that is sends a clear (and misguided) message that signatures are some advance and complex thing most developers should ignore. It promoted bearer tokens to be the preferred implementation (in practice, an implied MUST) which will render any signature work pointless (an afterthought MAY). By putting it in the same specification (and I have clearly demonstrated that this can be done in under 4 pages) we give developers a complete picture and let them choose. We also get to call out the shortcomings of using bearer tokens and directly point to one possible alternative. It is ridiculous how much time those opposed to signatures have wasted by demanding justification, proposing complex replacements, or just intentionally derailed any effort to come up with a simple signature solution. If we can't quickly agree on a new signature, I am going to take 1.0a and paste it into the specification. That will be sad and pathetic, and will ignore our responsibility to move the web forward, but its light years better than a specification with only bearer tokens. We have to find a quick way to compromise, or we will find ourselves with plenty more issues to resolve. I know a few people (myself included) who dropped their opposition to bearer tokens (especially without requiring HTTPS) that will be inclined to bring this up again and reopen the topic. It seems those who promote bearer tokens as the core 2.0 protocol got everything they wanted but have not given an inch so far. EHL On 9/24/10 4:26 PM, "John Panzer" <[email protected]> wrote: -1 on requiring it to be part of core OAuth2. Reasoning: It won't be a MUST or even SHOULD requirement for either client or server, so adding it later does not affect interop. The actual schedule to finalize the signature mechanism should not be affected either way -- it's fine for a WG to produce 2 or more RFCs if that's the right thing to do. (If there were consensus today on what exactly the signing mechanism should be I'd think differently, but I don't believe there is.) Caveat: If there were consensus that OAuth 2 should simply adopt the OAuth 1.0a signature mechanism today, I'd be okay with that, just because there is some proven code out there. This is of course a trade-off. My bias: I really want us to stabilize what has been spec'd so far and move forward with that while additional work happens. There are already multiple mutually implementations of "OAuth2" floating around and I'd rather resolve that quickly. -- John Panzer / Google [email protected] / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav <[email protected]> wrote: Since much of this recent debate was done off list, I'd like to ask people to simply express their support or objection to including a basic signature feature in the core spec, in line with the 1.0a signature approach. This is not a vote, just taking the temperature of the group. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
