Subgroup membership implies group membership

[jjensenral]

This issue applies to

1. attribute authorities (AAs) - how group membership is communicated for users who are members of subgroups of groups - and
2. relying parties (RPs) - how the same group information is parsed.

For a user who is member of a subgroup of a group, the implication is that they are also member of the parent group. Thus, it should not be necessary to assert

{
  "groups":["urn:example:foo:group:snap","urn:example:foo:group:snap:yup","urn:example:foo:group:snap:yup:flap"]
}

Instead, the statement

{
  "groups":"urn:example:foo:group:snap:yup:flap"
}

asserts the same information. The implication is that implementations MUST NOT use full string comparison alone to check whether the user is a member of snap (additionally, this example makes use of the rule that allows a list of one element to be replaced with that element)

The corollary is that RPs MUST do a prefix string match. E.g. in C,

#include <stdio.h>
#include <string.h>
int main()
{
    char const *authorised_group = "urn:group:foo", *user_group = "urn:group:foo:bar";
    if(strncmp(authorised_group, user_group, strlen(authorised_group))==0)
        printf("user is authorised\n");
    return 0;
}

or in python 3.11,

authorised_group="urn:group:foo"
user_group="urn:group:foo:baz"
if user_group.startswith(authorised_group):
    print("user is authorised\n")

In contrast, we would not suggest requiring regexp matching, as the configuration then becomes more complicated.

See also #10 and #24

[NicolasLiampotis]

See also https://github.com/WLCG-AuthZ-WG/common-jwt-profile/blob/master/profile.md#group-based-authorization-wlcggroups

[marcvs]

How about explicitly defining it, maybe in a practical way?
From using mqtt quite a bit, this one seems to be solving the same thing (if you replace / with :) : https://mosquitto.org/man/mqtt-7.html

[msalle]

Not sure how you mean "explicitly defining it" ? You mean no implicit membership, or defining a schema/set of rules?

[marcvs]

Examples of my suggestion:

Suppose we have groups:

• <namespace>:group:a
• <namespace>:group:a/b
• <namespace>:group:a/x
• <namespace>:group:a/c
• <namespace>:group:a/b/c
• <namespace>:group:a/b/d
• <namespace>:group:a/b/d/e
• <namespace>:group:a/x/c

entitlement	groups you're a member of
<namespace>:group:a/b/c	a/b/c	Exact group
<namespace>:group:a/+/c	a/x/c, a/b/c	Any group, where a is 1st level and c is 3rd level
<namespace>:group:a/b/#	a/b, a/b/c, a/b/d, a/b/c/d	Any group starting with a/b/
<namespace>:group:#/c	a/b/c, a/x/c, a/c	Any group ending with /c

This IS complicated, but it allows expressing all cases and it does work well in mqtt.