Comment 2 for bug 1356682

So the situation you describe is by design (which we could decide to change, of course). The rationale is that if, in the case of only using SQL with multiple domains, you want to prevent such leakage, then setting the appropriate rules in the policy file will prevent the leakage of user data across domains. The example policy.v3cloudsample.json shows how to do this - it basically requires (unless you are cloud admin) that you specify a domain filter on the query - and will return "Not Authorized" if you do not.

I guess my comments over the proposal here would be:

1) We'd have to do this for users, groups and projects - make it consistent
2) We'd have to still allow, I think, some "admin way" of bypassing this, if that's what the cloud provider wanted.
3) If we do go to a project hierarchy, where domains are just (effectively) an attribute of a given project node where you can attach users, would the idea of restricting this API via its domain token scope still be implementable (I think, actually, the answer is yes)