Troubles with Solid Groups

# It is a Group and it has a member!
<#us>
  a vcard:Group;
  vcard:hasMember <https://example.me/profile/card#me>.

# Group members can read my data!
<#Read>
  a acl:Authorization;
  acl:accessTo <my-data-url>;
  acl:mode acl:Read;
  acl:agentGroup <https://group.example.us/group#us>.

Praise

I love Solid Groups. In fact, I love them so much that I chose them as the main access control method for data sharing in decentralized hospitality exchange.

They're great. They allow you to share data with the community without having to list all its members in your Access Control List (ACL). When a new member joins the community, they can already read what you've shared without waiting for your explicit personal approval. And unlike verifiable credentials, they don't depend on a credential-providing authority.

Troubles

But there are issues with groups in Solid:

  1. Groups have to be public.
  2. Large groups slow down the response or crash the server that serves the protected data.

Why does this happen?

There are conversations, and those conversations break down. Let's listen to them.

Who talks:

  • Group Server (G) - Solid server hosting the group
  • Data Server (D) - Bella shares data with the group here
  • Person's Server (P) - Alice is the group member and wants to read data that Bella shared with the group

First conversation: Groups have to be public

  • P to D: Hey! I want to see the data!
  • D (thinking): Let me check permissions. P is not allowed to read the data directly, but there is a group. Maybe P is a member.
  • D to G: Hey, I want to see the group!
  • G (thinking): The group is not public.
  • G to D: Sorry! You're nobody. I won't share the group.
  • D to P: Sorry! I won't serve the data.

Second conversation: Large groups slow down or crash the server

  • P to D: Hey! I want to see the data!
  • D (thinking): Let me check permissions. P is not allowed to read the data directly, but there is a group. Maybe P is a member.
  • D to G: Hey, I want to see the group!
  • G (thinking): Ok, the group is public.
  • G to D: Here you go! (serves a 500MB file)
  • D: Tries to fetch the file, parse it, and find P's membership.
  • In the worst case, D crashes.
  • D to P after several minutes: Here's the data you asked for!

Solutions?

As we have seen, there are friction points in the conversation. If only the partners could have more conversation options!

Let's see how the conversations could continue successfully. Please be aware that they are not currently specified in the Solid Specification.

First conversation

Group can be accessed by its members

  • P to D: Hey! I want to see the data!
  • D (thinking): Let me check permissions. P is not allowed to read the data directly, but there is a group. Maybe P is a member.
  • D to P: Hey, I may need to show that you allowed me to read that group!
  • P to D: That makes sense. Here you go. (Provides some proof)
  • D to G on behalf of P: Hey, I want to see the group! P says that I can!
  • G (thinking): The group is not public, let's see if P can read it. Well, P is not directly listed, but the group's access control list says that its own members can. Let's peek in, because I can. Ok! P is in the group!
  • G to D: Sure! Here's the group!
  • D to P: (sees that P is a member) Hey! Here is the data you requested!

Groups aren't public, but everybody can test if someone is a member

  • P to D: Hey! I want to see the data!
  • D (thinking): Let me check permissions. P is not allowed to read the data directly, but there is a group. Maybe P is a member.
  • D to G: Hey, I want to see if P is a member of the group!
  • G to D: (checks the group) Yes, they are!
  • D to P: Hey! Here is the data you requested!

Second conversation

D can ask if P is a member of the group, and G is able to answer quickly

  • P to D: Hey! I want to see the data!
  • D (thinking): Let me check permissions. P is not allowed to read the data directly, but there is a group. Maybe P is a member.
  • D to G: Hey, is P a member of the group?
  • G (thinking): Ok, D is allowed to ask that (for some reason). I have the group indexed, let's see if P is a member.
  • G to D: (finds P in index) Yes, they are!
  • D to P: Hey! Here is the data you requested!

Conclusion

Groups have the potential to make Social Linked Data really social. We want them to be safe and scalable. That may be possible if:

  1. Servers can ask questions to other servers on behalf of the person (delegation).

  2. Servers can index their data and answer more specific questions (search and indexing).

    Linked Data Fragments would be perfect for answering the membership question that we need in order to make groups scalable.

Different Solid project folks have been saying that Solid servers shouldn't be queryable. But why? Even the dumb Nostr relays are indexed and queryable, why can't Solid servers be?

WIP: I want to open issues in relevant repositories regarding the troubles described here, with reproducible examples, etc.

Last but not least, Access Control Policies (ACP) do not support group permissions.

Thank you for reading!

2024-07-14