I gave a presentation on Dynamic Policy for Access Control at the Summit. https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dynamic-policy-for-access-control My slides are here: http://adam.younglogic.com/presentations/dynamic_policy.pp.pdf My original blog post attempted to lay out the direction: http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ And the Overview spec is here: https://review.openstack.org/#/c/147651/ This references multiple smaller specs: A unified policy file: https://review.openstack.org/134656 Hierarchical Roles: https://review.openstack.org/125704 Managing the Rules from a database as opposed to flat files: https://review.openstack.org/184926 Fetching the policy file from the server https://review.openstack.org/134655 Enforcing the policy via common logic in keystonemiddleware. https://review.openstack.org/133480 I've been pleased to get such a positive response; I think most people agree that we need to improve the policy management in OpenStack. This is not, by any means, set in stone, and all of this is still subject to the same review process that covers all of OpenStack. The more I discuss and design, the more I've learned. One recent discussion has driven home the fact that our policy can be Fragile. We want to make it easy for people to customize policy, but only in certain ways. There are parts that should be managed as part of the code review/engineering process, such as determining where the project_id exists for matching the scope of a resource. Contrast this with a deployer tweaking the role assignment required in order for user to call that API. Neutron uses Policy in innovative ways, and I would not want to remove that power. Let's figure out what the real requirements are here, beyond what policy does today. Policy is something about halfway between config and code, and figuring out how to manage it properly is the next step.