1. I don't have really any other alternatives to suggest.
2. I am for the signed callback URL solution.
3. First to decide if it's a token or a secrete. This value should not be
shared so I'm leaning toward secrete.
The name of the secrete should symbolize its purpose. We are using the
secrete to verify this is the same user
who authorized the consumer, or put another way we are trying to
establish ownership of the request token.
So I suggest the name "request secrete" which is used to establish
ownership of the authorized request token.
4. I think it is best to send back both request token and the request
secrete. This way the consumer can link the authorization with the initial
request.
This would also help block brute force attacks trying to guess the
request secrete. If we receive a callback with a request secrete that
results in a failed exchange with the
provider, we can now invalidate the request token and alert the admins
of an attack.
On Sun, Apr 26, 2009 at 12:48 AM, 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?
>
> 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
-~----------~----~----~----~------~----~------~--~---
