1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)
I'm here because we have a huge opportunity, right now, to move authentication down the "stack" a level. Just as developers don't have to worry about HTTP anymore - it just sorta happens effortlessly - likewise, I want to build a spec that has enough widespread adoption so that the entire tools ecosystem supports it. If we are successful, then developers won't have to think about auth - they can worry about building their applications. One thing that I haven't seen mentioned much is the relationship between OpenID and OAuth. A primary goal of mine in OAuth 2.0 is to see a path to smooth interop with OpenID. The current OpenID/OAuth Hybrid protocol is awkward and overly complex; it would be nice if the two protocols stacked on top of each other really nicely. For a service like Facebook to truly adopt OAuth as our one standard way of logging in, it must be able to support identity as well as authorization. To me, this is one of the elephants in the room that we need to address. 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else? Dave summed this up nicely - I'd like to see what he comes up with. Personally, I have a preference towards starting with WRAP, because it better reflects the Facebook Connect use cases than does OAuth 1.0a. On Feb 19, 2010, at 10:59 AM, Chris Messina wrote: +1 to what Dave said. I almost wrote the same thing (though admittedly with less technical insight). To me, the needs are: 1. Consolidate the needs for OAuth 2.0 2. Merge the documents as necessary; rinse, wash, repeat until we have a satisfactorially readable and comprehensible document (2.0 should be one of Eran's "editor's drafts"). 3. We need more flow diagrams methinks (I'll volunteer to prettify any ASCII drawings). 4. This document needs to tell the marketplace that OAuth is: evolving, stable, secure, and getting easier to implement in more diverse (and realistic) environments. And that 2.0 isn't abandoning 1.0a, but improving on that foundation to solve the problems that have become clearer to us in the past several years since 1.0 was released. 5. I would volunteer to write a context-setting document to help people who aren't active in these lists understand the goals, context, and purpose behind revving OAuth. Managing the transition and outreach for the next rev of OAuth will be nearly as important as getting to a final document in my mind. Chris Sent from my iPhone 2G On Feb 18, 2010, at 10:24 PM, David Recordon <record...@gmail.com<mailto:record...@gmail.com>> wrote: Glad to see this thread. :) On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <<mailto:e...@hueniverse.com>e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: A few questions we should answer before moving forward. Considering *your* use cases and reasons for being here: 1. Why are you here? What are you trying to solve that is not already addressed by existing specifications (OAuth 1.0a, WRAP, etc)? OAuth has been insanely successful the past few years in terms of almost eliminating new password-based APIs. That said, developers both large and small have found it to be complex and not as simple to implement as possible. We now have the opportunity to develop OAuth 2.0 based on what we've learned and new methodologies in APIs that weren't prevalent two years ago. Overall, I want to modernize OAuth so that it's not just "FooCo supports OAuth" but rather "FooCo has a million developers using OAuth". 2. Should the WG start by taking WRAP or OAuth 1.0a as its starting point? Something else? I think that WRAP has a lot of the right ideas (multiple ways to get tokens and relies on SSL), but ultimately wasn't created in an open process and was shaped by small number of implementors. I also think that there are lessons to be learned from OAuth 1.0 which haven't made their way into the current WRAP draft. If I were to write a draft, I'd start with an empty document and merge in appropriate sections from draft-hammer-oauth, draft-hammer-http-token-auth, and WRAP. I'd then probably rewrite half of the text as it gets merged together. 3. If we start from draft-hammer-oauth, what needs to change to turn it into OAuth 2.0? Eran had a good answer here. 4. If we start from draft-hardt-oauth, what needs to change to turn it into OAuth 2.0? Eran had a good answer here. 5. Do you think the approach of working first on 'how to use a token' and then on 'how to get a token' is right? I think it's hard to compare text from this split approach to the WRAP draft spec. 6. Should we go back to working on a single specification? Yes. We can split it apart later, but should optimize for a single easy to understand document. 7. Do you think the protocol should include a signature-based authentication scheme? Yes. See <http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html> http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html. EHL _______________________________________________ OAuth mailing list <mailto:OAuth@ietf.org>OAuth@ietf.org<mailto:OAuth@ietf.org> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
