Can i use a non-public group to define access to my resources?

Build a Solid App Solid App Development FAQs
1

aka App Permission Design and its limits.

Hello, for the Solid Hospitality Exchange Network we’ve tried to design data as follows:

A Hospex Community keeps a list of its members (“vcard:Group vcard:hasMember foaf:Person”). Only members of that community can read that list and find each other that way. (this works.)

This way of access is specified here:
http://solid.github.io/web-access-control-spec/#acl-agentgroup

A User keeps their hosting offers and memberships in a solid pod in one or more turtle documents. Currently these hospex data are public, but ideally would be shared only with Other members of User’s communities.

However, even though these Other members have theoretically all the permissions they need to read this User’s hospex data, practically they can’t read it. Such requests from Other members fail with 403 User Unauthorized. So when i’m Other member and i try to access User’s hospex data, i can’t. As if the Pod of User is unable to fetch the list of group members on my behalf and so verify my permissions. (I’ve tried this with different NSS providers, haven’t tried with CSS or ESS)

Can we use non-public groups to define access to our resources?

Is it documented somewhere, how group access works in detail? How the communication between different Pods goes?

Can i hope for this private-group permission to work in the future, or is it a hard technology limit?

Has defining access to resources by groups a future, or is it gonna be deprecated or something? With the different access control mechanisms and mentions about WAC not suitable for production, i’m insecure about this. Practically, access for groups is very useful (for social networks that help people discover each other), but the access control discussion is confusing to me.

I hope this issue is not an instance of Use an app to access data of other user: 403 User Unauthorized which i asked a couple days ago. If it is, i apologize. :slight_smile:

2

403 is not a user unauthorized error, it is an app unauthorized error so I suspect that this may be related to your earlier issue.

Groups are NOT going away. They will be very important for a number of purposes in Solid. The exact mechanisms to refer to, discover members of, and authorize groups are in flux. Keeping the members of the group secret would seem to be an essential ability but I’m not sure it can be done in an interoperable way right now. A months from now, probably. I recommend you get involved with the interop panel to explore these use cases and issues.

1 Like
3

P.S. I think we all find the access control discussion confusing :-). You might pop into solid/specification - Gitter and ask some questions and keep asking until you understand. This will actually help the spec writers because they need to (and want to) be aware of what parts of the spec are confusing to others.

2 Likes
4

@jeffz Thank you for the replies. This is interesting and hopeful, that this should work in principle.

However, i’m still consistently getting 403 when trying to access a document that has Read permissions bound to a private group (group accessible to its group members) i’m member of. I’ll explore it more and i may post details here in the future. It’s an edge case and i can see why some or all solid server implementations are failing here.

I’ve looked at documentation of @inrupt/solid-client, and i see that setGroupAccess and getGroupAccess work both for WAC and ACP (Getting hopeful!)
But then i look at the bottom of the methods and i see

deprecated Access Control Policies will no longer support vcard:Group. Use the mechanism-specific access API’s if you want to define access for groups of people.

(Getting disappointed)

So i don’t know; how do we define Group access with ACP then… :roll_eyes:

I’m not much into getting involved with interop or other panels (tried it, but personally it didn’t feel very satisfying; i prefer building stuff), but dropping into the gitter channel you @jeffz suggest sounds like a good idea. I may then report here what i will have learned there. And if it helps the spec writers to enhance their ideas and test them with real-world use cases, even better.

5

Groups are a headache with a couple of open questions that are still to be resolved (e.g. what if they’re defined on a different Pod? What if they’re private too?), and the different access mechanisms exacerbate that.

That said, although Groups were removed from ACPs, an equivalent effect can be achieved by creating a Rule (I thought they were getting renamed to Matchers, but I don’t see that reflected in the docs yet - so be aware that breaking changes may be afoot) that specifies the members of the Group. However, that being a different concept does mean that there’s no universal abstraction that can cover both, so you’d have to write custom code if you wanted to support both current access mechanisms.

3 Likes