<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>broke out nested groups discussion</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 10:53 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com">andrii.deinega@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Mar 12, 2025 at 2:25 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 8:47 PM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com" target="_blank">andrii.deinega@gmail.com</a>> wrote:<br></div></div></div></blockquote></div></div></blockquote><div><snip><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>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.<br></div></div></blockquote><div><br>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. <br></div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>To clarify your suggested, nesting groups would then only be allowed in the metadata command? Something like:<br><br><div><font face="monospace">"groups": [</font></div><div><font face="monospace">    {</font></div><div><font face="monospace">        "id": "983764",</font></div><div><font face="monospace">        "display": "staff",</font></div><div><font face="monospace">        "groups": [</font></div><div><font face="monospace">            {</font></div><div><font face="monospace">                "id": "983765",</font></div><div><font face="monospace">                "display": "engineering",</font></div><div><font face="monospace">                "groups": [</font></div><div><font face="monospace">                    {</font></div><div><font face="monospace">                        "id": "983766",</font></div><div><font face="monospace">                        "display": "backend"</font></div><div><font face="monospace">                    }</font></div><div><font face="monospace">                ]</font></div><div><font face="monospace">            }</font></div><div><font face="monospace">        ]</font></div><div><font face="monospace">    },</font></div><div><font face="monospace">    {</font></div><div><font face="monospace">        "id": "983767",</font></div><div><font face="monospace">        "display": "management",</font></div><div><font face="monospace">        "groups": [</font></div><div><font face="monospace">            {</font></div><div><font face="monospace">                "id": "983768",</font></div><div><font face="monospace">                "display": "executive"</font></div><div><font face="monospace">            }</font></div><div><font face="monospace">        ]</font></div><div><font face="monospace">    }</font></div><div><font face="monospace">]</font></div></div><div><br>And the value would be that an OP would then be able to send just the claim </div><div><br></div><div>"groups":"983766" // id for backend<br></div><div><br></div><div>in an id_token or an activate or maintain command, and the RP would know the user is the backend, engineering, and staff groups? </div><div><br></div><div></div>An interesting idea. <br><br>My pushback would be if the added complexity required by all RPs to understand and model nested groups is worth the benefits.<br><br>My philosophy for OP Commands (and standards in general) is minimize the required functionality for interop. </div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">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.<br><br>/Dick</div></div></div></div></div>