Does this mean we will no longer use pkidbuser, at least for key operations in KRA?

The "tag" terminology is a little bit too generic/confusing. It might be better to use "project" like originally proposed. However, instead of defining just the permission, a "project" should define the following:
* a set of users (including admins, agents, users)
* a set of secrets (including owners, members)
The permission to the secrets can be determined by static ACIs and attributes defined in the secret itself.

There should be a REST interface to manage "projects" too. Basically a "project" can be considered as "light-weight KRA".

In IPA a vault can be owned by multiple owners.

This project-specific ACI should be added automatically when a project is created.

A project can optionally have a default escrow officer.

We can also add an "escrowOfficers" attribute to store non-default escrow officers (e.g. department-specific officers).

The IPA tag/project should be created automatically when KRA is installed in IPA. The IPA admin later can add a global escrow officer for all IPA secrets. Alternatively, the IPA admin can add an escrow officer to a specific group to manage secrets belonging to the group.

Defining a new ACL is too low-level and error-prone. Permissions can be defined using static/global ACLs and other attributes as described in line #134 & #182.

Since tag is global in KRA, the user might pick a wrong tag and accidentally exposes the secret to people in a different project:

$ ipa vault-add test --tag sales_secrets (whose sales dept?)

IPA should create all vaults with "ipa" project automatically. This should automatically grant IPA default escrow officer access to all IPA secrets.

To create group-specific escrow officer, IPA might need to provide new commands, for example:

$ ipa vault-group-add sales --escrow-officer-group "cn=Escrow Officers"

$ ipa vault-add test --group sales

The vault group only exists in IPA so it's not possible to incorrectly pick a group from another project.

We can also add a "groups" attribute to store the groups this vault belongs to as described in line #193.

The "groups" attribute will automatically grant group-specific escrow officers access to this secret.

Similar to line #182, Barbican should create all vaults with "barbican" project.

Not sure if we should add this. Constructing a correct ACI is not trivial, so ideally ACIs should be static and few so it can be reviewed easily. Allowing dynamic ACI, even if it's limited to KRA admins, is risky.

The above comment applies to DS ACI. PKI ACI is fine if we want to provide a REST interface for it.