Re: [OAUTH-WG] OAuth WRAP

Chris Messina <chris.messina@gmail.com> Thu, 12 November 2009 02:50 UTC

Return-Path: <chris.messina@gmail.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 ECBE128C18E for <oauth@core3.amsl.com>; Wed, 11 Nov 2009 18:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[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 Yb74r5Z82K35 for <oauth@core3.amsl.com>; Wed, 11 Nov 2009 18:50:19 -0800 (PST)
Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id CD01428C17B for <oauth@ietf.org>; Wed, 11 Nov 2009 18:50:18 -0800 (PST)
Received: by yxe4 with SMTP id 4so1578429yxe.32 for <oauth@ietf.org>; Wed, 11 Nov 2009 18:50:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=b7sKpzlDs8suK23MEttZmRvR0Wr0gWsfVUI0arfi/NM=; b=Pxn0UKHMy8ynlXUWsf8rw+jBlwaU3U8oXVvW+ATNK8KPWOdl8IsPgqGAxnD6jTcayr uqIzrPkB+FX7776DzRsdzzXKe6yYwEPrtIaxa6vm3yKRMySh/Tex7vrPkB156xhIaCZy EowX5/Ssxx9yzjVoe8OR/dkce3n01LEQiD9jI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NDfoLSUF3lJ1/vEnLj1BIuyM18JbxCqQV0iDo6XUvBiEqAsnz1K9FFGwsmegC245BQ 246qWaDCenk/h9JvPRbxqsgkb1r+mLd1azQCN88f3bTSI1mL5YKdR2xbjHM0vbCiSSIg U9Ndt6igHuRX3eX5rw8Ulk6WuUmzeLWzrYK4E=
MIME-Version: 1.0
Received: by 10.150.174.9 with SMTP id w9mr4246241ybe.24.1257994241708; Wed, 11 Nov 2009 18:50:41 -0800 (PST)
In-Reply-To: <1257889230.10242.53.camel@localhost>
References: <C71F1827.28808%eran@hueniverse.com> <1257889230.10242.53.camel@localhost>
Date: Wed, 11 Nov 2009 18:50:41 -0800
Message-ID: <1bc4603e0911111850h3f8006efrd7835ca7b4d660b2@mail.gmail.com>
From: Chris Messina <chris.messina@gmail.com>
To: "Paul C. Bryan" <email@pbryan.net>
Content-Type: multipart/alternative; boundary="000e0cd573d2e8120a0478239bcf"
Cc: oauth@googlegroups.com, Dick Hardt <Dick.Hardt@microsoft.com>, oauth-wrap-wg@googlegroups.com, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] 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 02:50:22 -0000

On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan <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
Follow me on Twitter: http://twitter.com/chrismessina

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

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