Comment 11 for bug 1437407

So I think we need to think long and hard about this one. The original concept of a domain token was NOT that it gave you magical powers over all projects in your domain....rather it would be used to do domain-level management tasks (e.g. create users, groups...and create projects). It was not intended that you could use a domain token to access all projects in your domain. Likewise the original v3policysample I wrote clearly separated domain_admin from project_admin and being domain_admin did NOT mean you were automatically you had the rights to be a project_admin for all projects in your domain. I think others may have modified the sample subsequently to try and make this true....which means we fall into traps like this one.

Having said all the above, I understand the desire here. We faced a related problem with list_users() in fact when we implemented domain specific drivers - where we didn't want to allow people to list all uses across all backend drivers....so we require you to either specify a domain_id filter or we use the domain_id of the domain scoped token you are using as a query filter.

The big difference here is that in this case the thing you want to restrict the output on (domain_id) is not being returned as part of the collection....in all other filtering cases this is true...our filters apply to attributes being returned (the scope: domain_id part of the filter means it is looking for assignments on the domain...not that you should return all project assignments for projects in that domain).

So, first off, we need to decide on the conceptual model we wish to present, then we can decide how to implement it. Let's discuss!