What to include on an OAuth permissions page

The OAuth flow, which involves a redirect between 2 parties, is really a new UX pattern for users. Yahoo did some usability studies to find out how to best explain the process to regular users. The goal of the session was to encourage more consistent / similar experience across SPs. Showed several existing OAuth type permission UIs: Learnings from user studies: Other Questions / Comments selective ask/request. - Vince Wu (vwu@google.com)
 * MS Live - has invite duration, allows users to select specific items to share
 * Yahoo bbauth - lots of text, lawyers like it
 * Yahoo Flickr - Good: warning text "only authorize if you trust", includes description of service
 * Google - comments: the AuthSub image looks like user is sending Flickr content to Google
 * 1) tell users 3rd party is not affiliated with SP --> because users blindly trust SP to do the right thing. e.g. "this app is not made by yahoo". Someone commented that the Apps Engine openid IDP was confusing. It felt like Google is a openid provider
 * 2) tell users that if they don't trust app, don't allow access! --> denying access isn't a bad thing.
 * 3) range of data and type of access is useful to communicate. Users think "delete" and "write" are different things when they see read vs write access. Some examples: "Yahoo Profile to read your public profile data and your connections", "Yahoo mail to read, write, and delete your email"
 * 4) explain duration of access
 * 5) describe how to revoke
 * 6) showing application name and short description are useful
 * 7) tell user that 3rd party does not have access to password
 * 8) maybe: "don't enter your password on the next page"
 * 9) maybe: do something useful on finished page for client apps. "You've already authorized these applications"
 * How do you protect against phishing
 * Stats --> after these changes to Yahoo. interesting to check stats on if more people decline.
 * What about UX on consumer side, so users know it's using oauth and doesn't require passwords
 * OAuth only about auth, not about common data formats
 * Why revoke all tokens when user changes password?
 * Fine grained tokens: Uploading photos, and sending contacts back are two very different use cases.