@Clay (#16) Just user_id is fine to identify a unique user, and that is supported in the ACL with the wildcard syntax *:userID.
The syntax ACL 'tenantX:userY' does not mean 'allow userY who is contained within tenantX'. Users and tenants are independent of each other (its possibly easier to comprehend in terms of users and projects rather than 'tenants'). So tenant_id:name is not sufficient as an ACL because the tenant_id does not disambiguate the user name.
Rather, the tenantX:userY syntax specifies two conditions for container access: 1) the user is userY and 2) the user's token is scoped for tenantX. (Either condition can be forced true with a wildcard.) Since we can have more than one tenant *named* 'acme' we need to tighten up that part of the syntax to require an tenant ID. And since we can have more than one user named 'bob' we need to tighten up the other part of the syntax to require a user ID.
@Clay (#16) Just user_id is fine to identify a unique user, and that is supported in the ACL with the wildcard syntax *:userID.
The syntax ACL 'tenantX:userY' does not mean 'allow userY who is contained within tenantX'. Users and tenants are independent of each other (its possibly easier to comprehend in terms of users and projects rather than 'tenants'). So tenant_id:name is not sufficient as an ACL because the tenant_id does not disambiguate the user name.
Rather, the tenantX:userY syntax specifies two conditions for container access: 1) the user is userY and 2) the user's token is scoped for tenantX. (Either condition can be forced true with a wildcard.) Since we can have more than one tenant *named* 'acme' we need to tighten up that part of the syntax to require an tenant ID. And since we can have more than one user named 'bob' we need to tighten up the other part of the syntax to require a user ID.
HTH.