On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers <jesse.my...@gmail.com> wrote:
> > I can't say that I agree. What do you disagree with? Eran said early binding would be addressed in the security considerations section. The fact of the matter is that a lot of developers are going to > encounter OAuth for the first time when they first need to integrate > with an SP. Most developers will immediately download an OAuth library > from somewhere and start to work with it. They probably won't read the > OAuth spec and internalize it. If they do read the spec, they may just > gloss over whatever disclaimer warns them off of early binding or not > have any idea what early binding is. > Early binding is also harder. Why would you try to maintain state (user/request token binding) between requests when you don't have to? The path of least resistance is the right one in this case, which should be enough to keep most "bad developers" from screwing things up. I can't think of any way you'd be able to enforce this constraint in the OAuth libraries short of not providing access to the request token. And that's not really an option since the consumer app needs to persist the request token somewhere, and the library has no way of knowing where that somewhere is. Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
