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

Reply via email to