W3C home > Mailing lists > Public > public-xg-socialweb@w3.org > December 2009

Fwd: [oauth] Fwd: Prototyping OAuth WRAP on FriendFeed

From: Dan Brickley <danbri@danbri.org>
Date: Tue, 22 Dec 2009 10:46:36 +0100
Message-ID: <eb19f3360912220146i5a162617k3d8aa7842c18805f@mail.gmail.com>
To: public-xg-socialweb@w3.org
Some updates from the Facebook team (David and Luke, our visiting
speakers a few weeks ago) on their WRAP explorations.

Also worth noting
http://hueniverse.com/2009/11/wrap-and-the-demise-of-the-oauth-community/
from Eran Hammer-Lahav - the WRAP proposals can be seen either as a
competing technology being offered as a successor within the OAuth
'brand', or as as in improvement of OAuth, depending on perspective.
I've not dug enough into the details to judge.

In http://www.techcrunch.com/2009/12/21/facebook-friendfeed-oauth-wrap/
and http://bret.appspot.com/entry/oauth-wrap
I read  "The main difference between OAuth and OAuth WRAP is that WRAP
does not have elaborate token exchanges or signature schemes. Instead,
all server-to-server WRAP calls happen via SSL. The "access token,"
which grants your client the ability to make API calls on a user's
behalf, is protected by SSL rather than by a shared secret and
signature scheme." .... this might be interesting therefore for the
FOAF+SSL folk to take a look at?

cheers,

Dan

---------- Forwarded message ----------
From: David Recordon <recordond@gmail.com>
Date: Tue, Dec 22, 2009 at 1:30 AM
Subject: [oauth] Fwd: Prototyping OAuth WRAP on FriendFeed
To: oauth@googlegroups.com


We wrote a bit more about what we've been doing with WRAP today on
both the Facebook Developers blog
(http://developers.facebook.com/news.php?blog=1&story=350) and Bret
Taylor's blog (http://bret.appspot.com/entry/oauth-wrap).  Let me know
if you have any questions and we'd love some more feedback before
rolling WRAP out on Facebook next year.

Thanks,
--David

---------- Forwarded message ----------
From: Luke Shepard <lshepard@facebook.com>
Date: Thu, Dec 17, 2009 at 10:22 AM
Subject: [WRAP] Proposed OAuth WRAP Client Only Profile
To: "oauth-wrap-wg@googlegroups.com" <oauth-wrap-wg@googlegroups.com>


Last Tuesday, we had an OAuth WRAP community meeting at Facebook. The
main purpose of the discussion was to answer the question of how
applications written primarily in JavaScript would interact with OAuth
WRAP – specifically, we’d like to figure out how to make products like
Facebook Connect work without requiring server code.

The outcome of the meeting was that we would create a new profile that
doesn’t require the Client Secret in order to make calls. We’ve
focused mostly on applications written entirely in Javascript, but it
should also extend to other client-only apps such as desktop and
mobile. The proposed addition to the spec is attached. It’s the same
as the Web App profile with the main difference that the Access Token
is returned directly on the callback URL without requiring an extra
round trip.

Examples

Thanks to Bret Taylor and the Friendfeed team for providing a great
playground to illustrate the profiles with working code.

- FriendFeed has an OAuth WRAP provider prototype, with the following endpoints:
Authorize URL: https://friendfeed.com/account/wrap/authorize
Access Token URL: https://friendfeed.com/account/wrap/access_token
(no Refresh Token URL yet)

- Web App profile demo:
http://friendfeed-wrap.appspot.com/
(source: http://github.com/finiteloop/friendfeed-wrap-example )

- Client Only (Javascript) profile demo:
http://open.lukeshepard.com/oauth-wrap/console/
(source: http://github.com/lshepard/oauth-wrap-demo )

Both of these examples do the same thing – get an access token and
then fetch and render your Friendfeed news feed. The first does it on
the server, the second entirely in JavaScript.

Discussion

In contrast to the Web Gadget Profile proposed earlier (
http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/cfafaa4acb5cf1e1?hl=en
) , this profile leaves all JavaScript specifics out of the spec.
Sure, we need to use things like postMessage and whatever, but those
can be handled in libraries and reference implementations.

I also chose not to add a “wrap_profile” parameter. I’m a little
worried that if we start identifying a bag of behavior by
“wrap_profile” then the spec will be less able to handle new profiles
in the future, since each server will have to know about each profile
name. I’d love to hear ideas on how we can customize behavior between
profiles while supporting future extensibility.

Looking forward to all your feedback!

- Luke

--

You received this message because you are subscribed to the Google
Groups "OAuth" group.
To post to this group, send email to oauth@googlegroups.com.
To unsubscribe from this group, send email to
oauth+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/oauth?hl=en.
Received on Tuesday, 22 December 2009 09:47:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:08 UTC