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 <[email protected]> Date: Thu, Dec 17, 2009 at 10:22 AM Subject: [WRAP] Proposed OAuth WRAP Client Only Profile To: "[email protected]" <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
