Subject: [OAUTH-WG] Fwd: [WRAP] Proposed OAuth WRAP Client Only Profile

From: David Recordon <[email-masked]>
Date: Thu, 17 Dec 2009 10:30:19 -0800

We'll be discussing this on the WRAP list, but wanted to share where
we're thinking with the working group as well.

--David

---------- Forwarded message ----------
From: Luke Shepard <[email-masked]>
Date: Thu, Dec 17, 2009 at 10:22 AM
Subject: [WRAP] Proposed OAuth WRAP Client Only Profile
To: "[email-masked]" <[email-masked]>

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 WRAP WG" group.
To post to this group, send email to [email-masked].
To unsubscribe from this group, send email to
[email-masked].
For more options, visit this group at
http://groups.google.com/group/oauth-wrap-wg?hl=en.