Dear David Recordon, I think it could make easier for developers to create OAuth consumer sites because WRAP is simpler than OAuth. I reviewed the part of WRAP spec v0.9.7.2, and I have questions.
Concerning Bret Taylor's blog, though it mentioned the consumer sites could be stateless, coud you explain the reason ? 'wrap_client_state' WRAP spec defines seems to mean stateful. And concerning Access Token Refresh, why is Refresh Token needed in refreshing request ? On 12月22日, 午前9:30, David Recordon <[email protected]> wrote: > 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/cfa... > ) , 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.
