[Openid-specs-ab] nested groups (was: Review of OpenID Provider Commands (draft 00))

[Dick Hardt]

broke out nested groups discussion

On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <andrii.deinega at gmail.com>
wrote:

> On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <andrii.deinega at gmail.com>
>> wrote:
>>
> <snip>

>
>>> 3. I suggested enabling nested groups in section "6.1 Metadata Command".
>>> Are there particular reasons for having and allowing only a plain
>>> structure? That shouldn't be a big issue to remove this limitation in the
>>> way I see it. Nested groups offer convenience and simplify their and
>>> permission management.
>>>
>>
>> Would you elaborate on how this would work? What would it mean if a group
>> was in a group for a user? While groups can be made up of groups when
>> defining a group, the account either belongs to a group or not.
>>
>
> First of all, RPs can make use of the structure of groups (how they are
> nested in each other) alone, I'd even say that in some cases, it's very
> desirable to have this piece of information. Secondly, you don't need to
> indicate in OP Commands such as "activate" that user1 is a member of
> group1.1 when this group is included in group1.
>

To clarify your suggested, nesting groups would then only be allowed in the
metadata command? Something like:

"groups": [
    {
        "id": "983764",
        "display": "staff",
        "groups": [
            {
                "id": "983765",
                "display": "engineering",
                "groups": [
                    {
                        "id": "983766",
                        "display": "backend"
                    }
                ]
            }
        ]
    },
    {
        "id": "983767",
        "display": "management",
        "groups": [
            {
                "id": "983768",
                "display": "executive"
            }
        ]
    }
]

And the value would be that an OP would then be able to send just the claim

"groups":"983766" // id for backend

in an id_token or an activate or maintain command, and the RP would know
the user is the backend, engineering, and staff groups?

An interesting idea.

My pushback would be if the added complexity required by all RPs to
understand and model nested groups is worth the benefits.

My philosophy for OP Commands (and standards in general) is minimize the
required functionality for interop.

The RP can choose which commands it wants to implement, but if it wants to
use groups, it could not just support a flat list of groups, it would need
to support nested groups in your proposal.

/Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250313/b3da2e69/attachment-0001.htm>