I would focus on users for now (instead of users + providers), since groups of providers remains an imagined need and, in most cases, providers will also be (or could be) users of the system.
Instead of hardcoding a single owner, what about allowing
VIEW relationship to user and to user group? That would allow multiple owners (e.g., who could delete the group).
How would we handle publicly accessible (viewable) groups without having to grant view access to all users?
We may not need to add groups of groups now, but I could easily see it becoming a requirement if user groups are used widely, so – even if we don’t build it now – I’d like to at least consider how it would affect the API. More specifically, could it be introduced in a backwards-compatible way that doesn’t require all consumers to be refactored. For example, an API call like “Who are the users in this group?” could returns all users whether direct members or members of subgroups. And if “What groups is this user in?” only returned direct memberships, the responses wouldn’t change. But “Remove user from a group” might behave differently (e.g., after groups of groups was introduced, it might fail if the user belongs to a subgroup and isn’t a direct member of the group). That’s probably fine.
Groups of groups gets a little more complicated when you consider permissions (e.g. what happens if a user has
VIEW access to a group but doesn’t have access to one of its subgroups? Maybe that’s more reasons to defer groups of groups for now.