To refocus the discussion on OAuth (no superprotect and copyright issues
here please :), the field with legal relevance is the privacy policy of the
application (and maybe its terms of service if we add such a thing in the
future). Any time you use, say, CropTool, the tool operator has access
to checkuser-type information. The tool operator publishes a privacy policy
(which is legally binding for them), and the OAuth admins approve or reject
the tool based on that policy (for example if it contains that the operator
can pass private data to any third party, that tool application is going to
get rejected). If the tool operator can change the privacy policy without
any oversight, that can be problematic. On the other hand, if they can't
change it at all, that's also problematic, and we probably won't have the
resources to build some kind of complicated change review system anytime
soon.
As for attack vectors, some of the information (such as the application's
icon and short description) is presented on the authorization dialog and
users will have to decide based on that dialog whether they trust that
application to, say, delete pages in their name. An attacker could create
an innocent description, get the tool approved, and then change the
description to pretend it is some other, widely trusted tool, and trick
users into authorizing it.