I wasn’t able to make the meetings yet, but have been following along and wanted to put in some of my thoughts.
I’m +1 to “group” terminology for this generic functionality. I think this will end up a bit branded and at least power-user-visible (eg, like Standard Site). I am still thinking over what full name (and NSID domain) I this is best.
For transparency, we (Bluesky) registered this domain and we could use/donate it for this project if that is what the consensus ends up being.
My current thinking is that there should be a “group host” service which hosts space authority accounts for community groups, and fills all the roles of: PDS host, authorization server, space host, and open social API server. These would be generic protocol servers, separate from app services, but app operators might run one for ease of setup (similar to some app devs running PDS instances for easy creation). Group members with appropriate roles could log in to the group host to manage the account (within their permission) using OAuth. And also approve OAuth sessions on behalf of the group to app servers. This would resolve how permission delegation works: entirely within the group host, not needing any new auth or protocol features. Apps end up with OAuth sessions directly authorized to the group account; there aren’t “on behalf of” permissions. This is basically what dholms proposed, but phrased/framed a bit differently.
I think that role permissions should probably be NSIDs, and probably be permission-set lexicon schemas. I think they can have additional semantics beyond just the permission-set permissions if needed. Eg, could have two differently named permission sets with the same rpc or space permissions, but the group host could enforce them differently.