+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 <[email protected]>
wrote:
Glad to see this thread. :)
On Thu, Feb 18, 2010 at 9:14 AM, Eran Hammer-Lahav <[email protected]
> 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
.
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
