Re: [OAUTH-WG] [WRAP] Re: OAuth WRAP

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 12 November 2009 08:09 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB05C3A698E for <oauth@core3.amsl.com>; Thu, 12 Nov 2009 00:09:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level:
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_WEOFFER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHtnLVEhmtTX for <oauth@core3.amsl.com>; Thu, 12 Nov 2009 00:09:00 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 948873A69FF for <oauth@ietf.org>; Thu, 12 Nov 2009 00:09:00 -0800 (PST)
Received: (qmail 1143 invoked from network); 12 Nov 2009 08:09:26 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Nov 2009 08:09:25 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 12 Nov 2009 01:09:25 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 12 Nov 2009 01:09:13 -0700
Thread-Topic: [WRAP] Re: [OAUTH-WG] OAuth WRAP
Thread-Index: AcpjQvAN396n9PrZSk6B2wCeKl2yqwAKIDVw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102B46@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <C71F1827.28808%eran@hueniverse.com> <1257889230.10242.53.camel@localhost> <1bc4603e0911111850h3f8006efrd7835ca7b4d660b2@mail.gmail.com>
In-Reply-To: <1bc4603e0911111850h3f8006efrd7835ca7b4d660b2@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785102B46P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] [WRAP] Re: OAuth WRAP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2009 08:09:18 -0000

I don't think it was a good idea to associate WRAP with OAuth (beyond the obvious technical similarities). I also don't think the decision was appropriately made.

WRAP is in no way a profile of OAuth no matter how you look at it - it is a completely separate protocol developed by different people.

WRAP and OAuth are competing protocols and this conflict can only be resolved by a new protocol replacing both. OAuth will need to change to accommodate the use cases driving WRAP's development. While this is certainly my intention, the IETF process does not guarantee that. Meanwhile, at least some of WRAP's three corporate sponsors are going to ship running code using it, and it is actively being promoted as a viable alternative. This is not criticism (at least not in this context), just  a matter of fact.

The IETF WG is going to review and consider the many new (good) ideas contained in WRAP as soon as it is submitted as input into the WG in the form of an I-D. I am grateful to the authors for making it available in this manner. It certainly makes my life easier.

I am hoping that the IETF WG can produce stable implementers drafts soon which will provide developers a better alternative than both OAuth 1.0 and WRAP. The next few months will tell if this move has hurt the OAuth brand and how it will impact what we end up calling the new WG protocol.

All of this is nothing but the usual tension between the needs of corporations to deliver products on their own timeline and the slow speed of standards development, especially for something with a high profile like OAuth. But it would have moved much faster if the energy spent on WRAP was instead invested here.

EHL







From: oauth-wrap-wg@googlegroups.com [mailto:oauth-wrap-wg@googlegroups.com] On Behalf Of Chris Messina
Sent: Wednesday, November 11, 2009 6:51 PM
To: Paul C. Bryan
Cc: oauth@ietf.org; oauth@googlegroups.com; oauth-wrap-wg@googlegroups.com; John Panzer; Dick Hardt; Brian Eaton; Eric Sachs
Subject: [WRAP] Re: [OAUTH-WG] OAuth WRAP

On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan <email@pbryan.net<mailto:email@pbryan.net>> wrote:

It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be related in some way to OAuth, at the expense of community confusion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise?


Hi Paul,

This is an important point and one that drove the move to rename WRAP to OAuth WRAP.

Let me explain how this decision was made, with an eye to what it means for other projects calling themselves "OAuth".

Dick Hardt originally reached out to various members of the OAuth community in August and explained what he, Brian Eaton, and Allen Tom were working on (perhaps there were others, but they seem like the core group). At the time, they called the initiative "Simple OAuth" - "simple" because of its reliance on HTTPS for handling the crypto. While moving the crypto to SSL simplified the protocol and removed the need for signing (the biggest problem for developers implementing OAuth) it created a new burden, which was obtaining a certificate.

Now, the point was made to me that anyone serious about security will have to obtain an SSL cert anyway, so that wasn't such a big deal. However, from the perspective of the individual or independent developer, I felt like this was a fairly serious change in OAuth, and a challenge to the promise of the OAuth protocol (namely one protocol for authorization, regardless of the size of your organization). I want people who run their own WordPress installs on a shared host to be able to use OAuth just as large providers like Google and Yahoo do.

I didn't want this new effort to use the name OAuth for exactly the reasons that you specified. This seemed like a fork of the project and a dilution of the brand. It also seemed to conflict with Eran's work here at the IETF and I encouraged Dick to seek a more transparent process to developing the protocol.

Several weeks went by and progress was made - including the eventual renaming of the protocol to WRAP. This seemed like a fairly satisfactory development.

At IIW, Dick presented a joint session with Brian Eaton (Google) on WRAP. There was considerable interest and many suggestions and improvements were proposed.

Following the session, I reconsidered my position. My original concern with WRAP (when it was called "Simple OAuth") was that it would fragment the efforts of the community. If a new protocol came out calling itself "Simple OAuth", people would gravitate to it and potentially abandon work on improving the core spec. Now with WRAP clearly taking cycles from the people at Yahoo, Google, and Microsoft who would otherwise be working on OAuth Core, we had a decision to make: refuse them the ability to use the brand or find a middle ground that might pave the way for similar implementation-driven projects to find a foothold in the OAuth community.

On top of that, the OAuth community must confront the simplicity and elegance of Facebook Connect. Although not everyone is paying attention to Facebook, theirs is a significant enough distraction from standards-based work that we must keep in mind that OAuth does not exist in a vacuum. From a competitive perspective, we must constantly work to improve our technology, and make it easier to adopt the "open" and "universal" solution - to the point where Facebook could adopt it.

In that light, it's also important to remember where OAuth came from.

The original contributors to OAuth were a small, tight knit group of folks solving a problem that each of them shared. They looked to the work that had come before them - for patterns and solutions that had been established by the Googles, Yahoos, Flickrs, Microsofts, and AOLs of the web. What they came up with was, unexpectedly, adopted by most of the companies that were the inspiration for the universal solution.

That said, looking back, OAuth itself was largely developed in semi-secrecy, with a closed mailing list and a private spec that didn't see the light of day until months into the process. I know this because I was the one that made the decision to keep our work private. Whether we like it or not, the best work doesn't always come from completely transparent processes and so I'd be a hypocrite if I didn't evaluate WRAP in the same light that lead to the original success of OAuth.

Now, when it came to deciding what to call WRAP, well... that was more of a political calculation than a technical one. Dick had done the right thing in coming to us early and telling us what he was working on. I wish it had happened on the public list, but that was his decision to make and the fact of the matter is: they're damned near a 1.0 spec and are now ready for feedback.

This is a perfectly valid way to develop specs and standards - especially since they're leading with an implementation. OAuth Core 1.0 captured the best thinking around del-auth when it was produced - and represented the beginning of a collaborative conversation about how to move away from password confetti.

In the time since OAuth was launched, we've seen a multifold increase in the number of sites that no longer collect user passwords and instead use some form of the OAuth pattern. From my perspective, that's a massive improvement over the previous status quo. The OAuth project has raised awareness of the problem of user authentication credentials being passed to parties that shouldn't have them, and it's lead to the development of a viable and more powerful alternative. But that work isn't finished - and when it comes to deploying this alternative in a widespread way, it turns out that what works for one kind of developer or provider doesn't work for all of them.

Therefore, I see WRAP as an experimental branch of OAuth - and one that's closer in spirit, goals, and intention to OAuth than different from it.

The work that Eran is doing now on OAuth 2.0 will invariably have to consider it - and even he accepts that there are some good ideas built into it. We also know now that signing is not trivial and is one central element of OAuth that is inhibiting its adoption, probably more than any other. Therefore, there is a need to improve the usability of OAuth, and WRAP seems to be squarely aimed at offering a solution to that problem - while also offering a more deployable solution for larger, distributed providers.

Given all this, it seemed to me that WRAP was more "in the family of OAuth" than a distant cousin - or one that should necessarily have to develop its own, independent community. We're all trying to solve similar and related problems, and we need cohesion and consistency in the message that we offer to the world. Forking OAuth at this stage in its development is not, in my estimation, an option, and is why I changed my mind and decided that WRAP should be renamed to OAuth WRAP.

Of course it's up to the OAuth WRAP maintainers to make their case and answer the community's questions and criticisms - but I'd much rather have them do that within the existing community infrastructure than separately.

If other projects wish to call themselves "OAuth", I hope that they'll have to run through a similar gauntlet of proving how they relate to this broader initiative, and how they're improving the overall stack of best practices and patterns that make up the OAuth technology. Stagnant technology is dead technology, and I'm happy to see at least a vibrant conversation about what does and doesn't fit into OAuth.

That was probably more than you wanted to know, but I felt it was worth explaining the WRAP -> OAuth WRAP lineage.

Chris

On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote:
> My 2c:
]]>
> WRAP was developed out of necessity due to limitations in OAuth and
> product release schedule. Without going into too much detail about
> whether a whole new protocol was really necessary, the WRAP authors
> felt that it was, and that their timeline could not accommodate
> waiting for the OAUTH WG to accommodate their use cases in the new
> version of the spec. We now have a new and separate spec in the space.
]]>
> I have encouraged the authors to submit their spec as input for the WG
> and to collaborate to make the upcoming WG spec cover their use case.
> The goal would be to render the separate WRAP spec unnecessary. How
> they or others would choose to apply this to their implementation is
> beyond my control or (TBH) interest.
]]>
> Most of the innovative ideas in WRAP are around the delegation flow
> (and there are some good ideas in there). I plan to use some of that
> as the basis for the new delegation spec. On the authentication side,
> WRAP uses bearer token with no crypto which will be supported by the
> PLAIN flavor.
]]>
> As for how to manage community expectations, the OAuth brand, etc.: I
> was opposed to putting WRAP under the OAuth brand (the entire effort
> started as "Simple OAuth"). Others felt that pretending WRAP was an
> OAuth profile (it is not) and naming it as such would be less
> confusing or less damaging to the OAuth brand (if you call it the same
> thing, there is no competition). I didn't care enough to (continue)
> that argument given my view that by the time WRAP will get the wide
> attention OAuth has, this WG will produce stable drafts of the new
> OAuth and will make this irrelevant.
]]>
> EHL
]]>
]]>
]]>
]]>
> On 11/10/09 11:56 AM, "Paul C. Bryan" <email@pbryan.net> wrote:
]]>
>         I guess I must admit I'm a bit surprised that the general
>         consensus
>         would be to merge with/profile WRAP as OAuth, as the deltas
>         between the
>         two protocols as defined seems quite substantial. Does this
>         mean that
>         for all intents and purposes I should consider the existing
>         OAuth IETF
>         drafts to date to be deprecated in favour of WRAP?
]]>
>         Paul
]]>
>         On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote:
>         > Good question. Given the positive reception WRAP received at
>         IIW and
>         > that capabilities in WRAP are expected to come out of the
>         work in the
>         > IETF OAuth WG, there was consensus from the OAuth community
>         to include
>         > WRAP as OAuth profiles.
>         >
>         > -- Dick
>         >
>         > On 2009-11-10, at 10:06 AM, "Paul C. Bryan"
>         <email@pbryan.net> wrote:
>         >
>         > > Hi Dick:
>         > >
>         > > Given that WRAP is so different from OAuth (as I know it),
>         other than
>         > > the fact that OAuth could be used to negotiate the
>         issuance of a WRAP
>         > > refresh token, I'm curious why you chose to associate this
>         with
>         > > OAuth by
>         > > giving it an "OAuth" prefix. It seems to me that it would
>         only create
>         > > confusion in this space.
>         > >
>         > > Paul
>         > >
>         > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote:
>         > >> At IIW last week, myself, Biran Eaton from Google and
>         Allen Tom from
>         > >> Yahoo! presented what is now called OAuth WRAP
>         > >>
>         > >> The specs and discussion specific to those documents is
>         at:
>         > >>
>         > >>    http://groups.google.com/group/oauth-wrap-wg
>         > >>
>         > >> We plan to submit the document as an I-D next week when
>         I-D
>         > >> submission
>         > >> is open again, and for further work to occur in the IETF
>         OAuth WG.
>         > >>
>         > >> -- Dick
>         > >> _______________________________________________
>         > >> 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
>         > >
]]>
>         _______________________________________________
>         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


--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com<http://factoryjoe.com/>
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com<http://citizenagency.com/>
Diso Project: http://diso-project.org<http://diso-project.org/>
OpenID Foundation: http://openid.net<http://openid.net/>

This email is:   [ ] shareable    [X] ask first   [ ] private

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-wrap-wg@googlegroups.com
To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en
-~----------~----~----~----~------~----~------~--~---