A good library should hide the request token from the developer. They should
simply call a function to generate the authorization URL (ex.
get_auth_url()) and
display that to the user. This way they never get the token and can't really
bind it (library should also state this in its docs).

I agree this is a consumer implementation problem. This should be fixed in
the libraries and not the protocol its self. It's up to library implementers
to properly document their libraries and educate its users. The process of
implementing a consumer should be trivial to the developer.

On Thu, Apr 30, 2009 at 12:29 PM, Mike Malone <mjmal...@gmail.com> wrote:

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

Reply via email to