Re: [OAUTH-WG] OAuth WRAP

[John Panzer]

To clarify the distinctions between OAuth WRAP and OAuth 1.0a, the OAuth WRAP doc[1] Appendix C states the following:

"OAuth WRAP    requires        the     Authorization   Server  to      support HTTPS,  OAuth   1.0A    does    not."

This is an important distinction, though I assume it applies only to the profile(s) supplied as part of WRAP and not to extension profile(s) that may be created.  E.g., one could create a fourth profile which did not require HTTPs -- it just would not be as interoperable as the others, and servers and clients are not required to support it, but it would be otherwise compatible with WRAP if I understand correctly.)

"The   Access  Token   in      OAuth   WRAP    is      opaque  to      the     Client. The     Client  does    not     need    to      perform any     cryptography    except  for     calling HTTPS."

This is also important, but what is the difference between WRAP and OAuth 1.0A PLAINTEXT mode?  They seem to be pretty much identical to me, if there is a difference it should be called out.

"The   Access  Token   in      OAuth   WRAP    can     contain authorization   information,    or      claims, enabling        the     Protected     Resource        to      determine       the     Client's        authorization   without querying        any     other   resource."

I don't understand this distinction; this sounds exactly like the OAuth 1.0a token.  What am I missing?

Best,

John

PS:  Sorry for the munged text, that's what I get when I copy and paste from the PDF to ASCII, any chance of getting a plain text or HTML version of the spec?

[1] http://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf

On Tue, Nov 10, 2009 at 9:52 AM, Dick Hardt <Dick....@microsoft.com> 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
OA...@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--
--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Chris Messina]

On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan <em...@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" <em...@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"
>         <em...@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
>         > >> OA...@ietf.org
>         > >> https://www.ietf.org/mailman/listinfo/oauth
>         > >
>         > > _______________________________________________
>         > > OAuth mailing list
>         > > OA...@ietf.org
>         > > https://www.ietf.org/mailman/listinfo/oauth
>         > >

]]>

>         _______________________________________________
>         OAuth mailing list
>         OA...@ietf.org
>         https://www.ietf.org/mailman/listinfo/oauth

]]>

_______________________________________________
OAuth mailing list
OA...@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

[Peter Saint-Andre]

On 11/11/09 7:38 AM, John Panzer wrote:
> To clarify the distinctions between OAuth WRAP and OAuth 1.0a, the OAuth
> WRAP doc[1] Appendix C states the following:
>
> "OAuth WRAP requires the Authorization Server to
> support HTTPS, OAuth 1.0A does not."

It's not clear to me that this distinction would force someone to define
or label a new protocol. For instance in XMPP the protocol requires
support for TLS in *implementations*, but leaves the use of TLS by any
one *deployment* up to local service policy.

> This is an important distinction, though I assume it applies only to the
> profile(s) supplied as part of WRAP and not to extension profile(s) that
> may be created. E.g., one could create a fourth profile which did not
> require HTTPs -- it just would not be as interoperable as the others,
> and servers and clients are not required to support it, but it would be
> otherwise compatible with WRAP if I understand correctly.)
>
> "The Access Token in OAuth WRAP is opaque to
> the Client.

Isn't the token always opaque to the client? What semantic information
should we expect a client to clean from an access token?

> The Client does not need to perform
> any cryptography except for calling HTTPS."

A security review would tell us if that assumption is warranted. And,
again, this seems to be more of a deployment choice (the client and
server require SSL/TLS and therefore feel safe in using PLAINTEXT) than
a protocol change.

> This is also important, but what is the difference between WRAP and
> OAuth 1.0A PLAINTEXT mode? They seem to be pretty much identical to me,
> if there is a difference it should be called out.

Agreed.

> "The Access Token in OAuth WRAP can contain
> authorization information, or claims, enabling the
> Protected Resource to determine the Client's
> authorization without querying any other resource."
>
> I don't understand this distinction; this sounds exactly like the OAuth
> 1.0a token. What am I missing?

Yes, this sounds very similar.

/psa

[Monica Keller]

Hi guys
Pardon my newbie questions here I am just finally sitting down with
the spec. I found this thread quite helpful to get some background.
I was wondering what are the convergeance plans for oAuth and WRAP ?
Any meetups planned ?

I feel that this is a great initiative but may dilute the efforts of
the core oAuth protocol if kept as a separate spec and in general
having the two parallel specs may dillute the influence of each one of
them.

Thoughts? The last thing we would want to do is confuse adopters

>  smime.p7s
> 9KViewDownload

[David Recordon]

I'm hoping that WRAP is a large piece of input to OAuth 2.0, but I imagine that WRAP will be deployed faster than the IETF can have 2.0 approved.  Eran's written up more context in a comment at http://www.scripting.com/stories/2010/01/01/oauthIsBecomingACautionary.html#comment-27873402.

Another meetup would be good this month.  Maybe to focus on finalizing the various profiles and continuing to simplify the spec itself.

--David

--

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-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Dick Hardt]

While I don't agree with all of Eran's points -- we all seem aligned that OAuth 2.0 will have the capabilities in OAuth WRAP.

-- Dick