Hey everyone, Thank you for all the feedback on the list, email and through Tweets. We've been responding throughout the day to many of the Tweets but wanted to group the questions together and respond here as well.
> Two weeks is not enough time to implement a web OAuth flow and have the app > approved. We need an extension. We’ve heard your feedback on this list, privately and through Tweets about this. Based on this feedback we are going to extend the enforcement deadline by two weeks. **** This means we'll enforce the new permission the week beginning the 14th June 2011. **** This should provide enough time for you to make the change and have your application approved by your chosen platform’s app store. > Will Twitter's own applications also go through the OAuth web flow? We’re taking this step to give more clarity and control to users about the access a third-party application has to their account. The way users interact with Twitter’s clients is not expected to change. Applications who wish to access a user’s DMs will need to update their application permission and incorporate the OAuth web flow if they don’t already. If an application does not need access to DMs it will not need to make any changes. > Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. > What if the client using xAuth has no browser and therefore cannot go through > OAuth? For single user applications and scripts we provide the 'My Access Token' page of the application details. To ensure the 'My Access Token' is correct it is important the app owner revokes their access before change the permission level of the app. If you do not do this, the 'My Access Token' will not be regenerated with the new permission. This revoke action is only needed by you, the owner of the application. Remember Read/Write applications can still send direct messages. > When you activate the new permission, will all Read and Read/Write > user_tokens issued to third-party applications lose their ability to read > direct messages? Existing tokens are unaffected by any change to the application permission level. If you change your application to R/W/DM all future authorizations will be for that permission. When a user re-authorizes, their existing token will be updated to the current application permission level. Access to DMs will be enforced on 14th June 2011 if the user_token wasn't authorised as for R/W/DM. > What if I want to request a different level of access for my application > instead of the one my application is registered with? You can do this now by using the x_auth_access_type parameter during the request_token phase. Using this parameter you can request a read or a read/write token even if your application is registered for read/ write/direct messages. More information on this method is in our developer documentation: http://dev.twitter.com/doc/post/oauth/request_token > Why are permissions attached to the user token? Permissions are attached to the user token to ensure an application only has the access a user has authorised. If permissions were not attached to the user token an application would be able to change the level of access they have without the user’s knowledge. If you tie the permissions to the application each user token would need to be invalidated whenever an application’s permissions are changed. > Users already gave their permission for apps to access private messages, why > are you making us, and them, reauthorize? The purpose of the re-authorization is to ensure both users and developers know the level of access requested. Re-authorization allows a user to make a more informed decision about the access an application has requested. We hope these responses answer your questions. Please continue to send us your feedback about the permission model and what you would like to see it offer. Best, @themattharris -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk