Something important to keep in mind with permissions is that by default granting 'edit' should not carry the rights to edit the user's .js page.
With this consideration and other fine grained rights that may be missing from the api-oriented method the other idea of basing OAuth permissions based on our actual rights system is probably the better way to go about this.
There are some rights like the ability to edit a user's permissions which we'll want to create some dummy rights for so that we can deny them by default to OAuth.
However something else we do have to be careful of is how we display to the user the list of rights that the application asked them to authorize. If we don't display these in a combined, grouped, clean, and intuitive way we risk overloading the user with so much information that the user starts ignoring the list of rights and will grant permissions to apps which they shouldn't allow it to have.
Firstly we should probably add a $wg which we add information on what category rights are in based what area they effect. For example edit, createpage, and upload would be grouped together as rights that affect content on the page. While rights like protect and delete would be grouped together as rights that do administrative things on the wiki. And rights like 'watch' and 'permissions' would be grouped together as rights that affect the user's own account.
If we don't group things like that we risk sysops not noticing when an application randomly requests their delete right.
Secondly we should find some way to group multiple requested rights into a single line in the display. For example for [edit] we would display "Edit existing pages on the wiki" while for [edit, createpage, createtalk] we would display "Create and edit pages on the wiki". If we don't do it this way we'll end up outputting things like "Edit pages. / Create pages. / Create talkpages." and overloading the user with a huge pile of rights lines.