Groups and Group Membership information in oc-id

In chef/oc-id#36, @leftathome said:

Consider this scenario:

Of all the users who are supposed to have access to Organization A, I only want a subgroup of them to be able to upload cookbooks.

I install Supermarket. I'd like that same subgroup of people to be able to manage a set of cookbooks owned by an Organization in Supermarket.

Currently, I would create a Group (within an Organization) on the Chef Server, add users into that group and set the appropriate ACLs on the Group. Then I'd have to go to Supermarket, where there is no equivalent concept, and add all of those users as Collaborators on each cookbook managed by that team.

If I start installing other Chef components, or even want to write my own service that ties into Chef somehow, this process would get annoying pretty quickly.

But if oc-id understood the concept of user groups, I'd only have to set ACLs on the oc-id-provided groups in each application, which changes much more rarely. Meanwhile, the group membership information could be provided (or at least synced) by oc-id to other Chef services, reducing the number of times I'd have to ask someone to "log in first" to something before I can set their permissions and group memberships properly.

Start by reading the referenced chef/oc-id#36 discussion and mapping how oc-id currently represents users. Then investigate how Chef Server and Supermarket handle groups, membership, and ACLs; the work is done when a concrete, shared group-membership design and its integration scope are defined.