On 4/26/09 1:48 AM, Eran Hammer-Lahav wrote: > 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).
Requiring SP to authenticate user _before_ the request token request, returnin an identity token to the consumer which is then required as part of the request token request. This way, an attacker can't generate a request token that can be authorized by another user. > 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 I vote for "authorization token", which invalidates the previously issued request token and is used by the consumer to prove it has been authorized by the user. The consumer would then use the authorization token with the original request secret to receive an authorized access token. > 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? It should replace the value of the oauth_token. There's no reason to use a value that an attacker can already know. -- Dossy Shiobara | [email protected] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
