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? 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 [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 -~----------~----~----~----~------~----~------~--~---
