On Mon, 10 Aug 2009 08:02:33 -0700 (PDT) sasha <[email protected]> wrote:
> All in all, I agree with Chris - ideally, access and authentication > should be very distinct. Twitter Oauth is still a step in the right > direction vs. basic HTTP auth, but would be nice to have a strictly > authentication-based call that wouldn't require user to grant the > consumer any kind of access to personal data. > > It would be nice to have someone from the team to weigh in here to > understand their rationale for this kind of implementation of > authentication - is it an issue of resource constraints or is it > something else? Twitter is only implementing the OAuth spec. It just happens that the OAuth folks decided that OAuth authentication would be allowing the Consumer (app) to authenticate *as* the user rather than simply authenticating to the consumer that s/he *is* the user. I'll fall back to asking for the user to click on a link in a DM to demonstrate the ownership of a Twitter account. Coincidentally, a decision "not to fix" regarding upgrading read tokens to read/write tokens makes sense in this context. There's no sense burning LOCs on a corner case when there's a work around. If your application changes from read to read/write then see if a change from authorize tokens to authenticate tokens works. Chris Babcock
