Identify primary group

[marcvs]

man use-cases use the group information for accounting. Whith mutliple groups / entitlements being conveyed to RPs, one needs to be identified the primary one. The trouble with json is that its lists are not sorted.

I suggest adding one literal in G027: primary-group, which may only be there once.

[marcvs]

And I'd love to tag this G027, but for some reason, I'm still not allowed to do that.

[NicolasLiampotis]

Hi @marcvs. I've added the following tags:

• G069: Guidelines for group and role information
• G027: Guidelines for resource capabilities

However, I think that identifying the primary group is mostly related to G069.

[c00kiemon5ter]

I think that this is not the correct approach. From the short description, I feel that there are hidden assumptions that are not directly visible.

My guess is that at some point some-system made a decision to model the accounting information as group membership. Now there is this implicit assumption that this is how everything works. This causes confusion when talking about groups and having to separate some of those groups.
Having modeled the accounting information as membership in a group does not justify putting labels on groups that one would like to highlight but for reasons unrelated to the membership.

If there is a need to provide information about accounting then we need a separate attribute to convey that information, instead of implying it indirectly with a label like "primary". By using primary-group as an attribute to convey accounting information we will be binding "primary" to be about accounting, and accounting to be a "group". I think that neither is correct.

To say this differently,

• why must the accounting information be a group?
• why should "primary" be used for the group(s) that are about accounting and not for group(s) that are about the user's-favourite-project-or-something-else?

[marcvs]

Ok; let's turn the use case around, so it's described properly (sorry for the confusion)

• People use federated identities to access unix-systems.
• On unix-systems users need to have have one primary group (which is in some cases uses for accounting; Yes: This is implicit. It was meant as an example)

There are (in my view) two ways to support primary groups. Maybe we can
iterate the pros and cons here (feel free to edit my list):

1. New attribute
   • pros:
     • Should not break existing implementations
   • cons:
     • It's a new attribute
2. Enhance an existing attribute
   • pros:
     • We already have the entitlements specified, maybe we find a
       reasonably backward compatible way to identify primary groups
   • cons:
     • If we miss one piece, existing implementations could break

[msalle]

This links also to a discussion we had last week in the GUT profile meeting, see Running notes, meeting 9 May

I think mapping to a posix account is one use case that could make use of group-like information, accounting is another, authorization is a third one, and knowing in which context capabilities are valid a fourth. For accounting and "context" we had some thoughts in the GUT profile meeting which will be/are being captured in the google doc linked from aforementioned notes.