Open Stack

> Not allowing impersonation is probably the right thing the abstract, but due
> to the way Swift in particular manages ownership, which is at the per user
> level, the attribute that needs to be delegated is, unfortunately, the user_id
> of the owner of the object.  Systems are currently built around users
> surrendering control of their password just as you state above.
> Impersonation is a step in the right direction.  I would be happy to remove
> the impersonation aspect of trusts once it is no longer needed.

I nearly pointed out the root of this problem in my first reply, but decided to leave it out. OpenStack as a whole needs to establish its intentions with respect to ownership (my user, your user, shared in a tenant, shared across a tenant, public, admin-level access, etc.) and until we do that these problems are largely intractable. End users (not deployers or security experts) have really quite obvious expectations around ownership, and we need to empower those while maintaining a proper security stance.

It's probably worth spending time on this at the next summit.

But all-in-all, once we as a community agree on our model of ownership the projects need to fall in line. We can't have each project deciding on its own interpretation of such a fundamental concept (though individual projects may disagree). It's simply dreadful for the community and people trying to write cross-functional code like this.

In practical terms, I suggest that the Swift team (and any other project teams that have this problem) work together  with the Keystone team early on in H so that we can remove this hack as soon as possible. 

All the best,

    - Gabriel