Comment 15 for bug 1324592

Suggestions for the code:

It looks like the code mitigates the privilege escalation, it feels like the code should go a bit further (yes this could all be controlled via policy, but I get the feeling that most deployments would not limit in this way).

Suggestion #1:
- While it is useful to include all the OAuth information and Trust information in the credentials (common/authorization) it would be easier for both cases to set a 'is_delegated_auth' flag and we can universally check for that instead of having to check trust, and oauth, and oauth, and trust, and if anything else crops up.

Suggestion #2:
If you cannot create new trusts/OAuth request tokens (authorize in the case of Oauth), the user should not be able to delete them. Likely, the user shouldn't be able to list them either. Once we get to chaining of trusts / whatever else is out there that allows delegation of smaller scope that is current, we can allow those smaller-scope delegations to be managed by the user with delegated auth. At this point, it seems that it would be unexpected for a user to be able to delete a trust or OAuth related stuff because they authed as the via a delegated role.

This assessment comes from the sample policy allowing a lot of various things to occur as admin (all oauth related actions request token etc, require admin) - lets prevent people from screwing up other people's access if they were (for some reason) delegated admin on their project.