On Sat, Apr 25, 2009 at 10:48 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > Let's see if we can take a quick break from the discussion and get a sense of > where we are. Please answer the questions to follow. > > --- > > We have identified 2 solutions listed here: > > https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory > > > * Signed Approval URLs > > This proposal breaks the protocol into two separate flows, one for Consumers > capable of launching a browser and accepting callbacks, and another for those > who can't. It requires a significant rewrite of the specification because of > the way the flow and signature are mixed together in the current Core 1.0 > specification. > > > * Signed Callback URLs > > This proposal makes the callback URL part of the signed request for Request > Token (which does not allow an attacker to manipulate it), and adds some > unpredictable value to the callback redirection that is needed to get an > Access Token. > > The spec changes include (see quick reference at the bottom): > > - Move the oauth_callback parameter from 6.2.1 to 6.1.1 > - Add a new parameter to 6.2.3 which is needed to make 6.3.1 > > --- > > Open questions: > > 1. Am I missing a completely different alternative? If yes, please create a > new wiki page and point to it (if you don't have access ask or email it to > someone who does). > > 2. Given the simplicity of the Signed Callback URLs *specification change*, I > would like to instead of asking people which solution they prefer, to ask > people if they have a strong objection to using the Signed Callback URLs > solution, and if so, to explain why? > > 3. For the Signed Callback URLs solution, what to call the new parameter > returned in 6.2.3? Suggestions so far included: > > - pin > - verifier > - chaperon > - callback token > - callback secret > > 4. And, should the new parameter be added to 6.3.1 (oauth_token + > oauth_something) or replace the value of the oauth_token parameter?
Should be *added*. It can be much shorter - and thus potentially could be typed by a human - if it is added instead of replacing oauth_token. > > The second option basically returns an authorized token which is used with > the existing secret from 6.1.2. The benefit of a new parameter is it is > easier to follow the protocol. The benefit of reusing oauth_token to make > 6.3.1 is that is keeps the signed request consistent with all other signed > requests (no new parameters). > > EHL > > --- > > Quick Reference > > 6.1.1. Consumer Obtains a Request Token > 6.1.2. Service Provider Issues an Unauthorized Request Token > 6.2.1. Consumer Directs the User to the Service Provider > 6.2.2. Service Provider Authenticates the User and Obtains Consent > 6.2.3. Service Provider Directs the User Back to the Consumer > 6.3.1. Consumer Requests an Access Token > 6.3.2. Service Provider Grants an Access Token > > > > > --~--~---------~--~----~------------~-------~--~----~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
