Regarding
The access control proposed for future versions of Solid is being redesigned to use Access Control Policies instead of Web Access Control, but its still based on who you are or things about you, as opposed to what you possess, like a key.
This is worrying from the perspective of human rights and should be approached with skepticism.
See also
I donāt know anything about ACP. I do really like Capability based access and impression is that it satisfies your concern, as well as being functionally superior to ACP.
Have you voiced your concerns in https://github.com/solid/authorization-panel? Sounds like it would be good to discuss with the panel.
Thats a good idea but the problem for me is that Iām mostly an armchair developer and my implementation experience is sketchy.
That and I probably I would be standing in front of a freight train which loses its appeal the closer the train gets.
Thatās fair, I understand it can be intimidating (and time consuming) to start these interactions.
But Iām guessing the panel would be interested in your concerns, especially if youāre able to phrase some use cases thatās not handled well by the current access control systems. Let me know if you want help 
Regarding Capabilities this was raised with the panel Solid, ACL's and the future but AFAIK quickly put aside.
Imho, the panel should really reach out to @cwebber who is expert on this, and can explain pros and cons very well. Alignment in general with other initiatives is a good thing. In the past the fediverse community has tried multiple times to do this, and Solid was agenda point on multiple SocialCG meetups, but without success. This while there are great combinations with both technologies, and a couple of community projects are (or were) investigating these.
Thanks Arnold.
I donāt feel that I have what it takes in terms of time and energy and skills to do a decent job of even asking the right questions.
There is something about ACP/WAC in social terms that seems too oversimplified. The whole world of the web canāt possibly fit into a Unix like permissions model with read, write, control and user, groups, and root, can it?
My concerns are not so much with security flaws but with justice and freedom, as it should be with any citizen.
Justice is ultimately better than charity, if there will be any charity at all forthcoming from the oligarchs who think they own the web and will use this stuff their way, no matter what good intentions it was conceived with.
I think problems may arise when people start using authorization groups that are shared widely, so they donāt personally know the people in the groups.
For example, there is a use case, https://solid.github.io/authorization-panel/wac-ucr/#basic-group, where someone, Alice, starts a group to review her resume. Alice personally forms that group.
But what if a person in that group insists that Alice include another group, one circulated by email, say all-good-and-charitable-resume-reviewers-who-are-only-interested-in-facts.com, in the resume review group.
Alice may feel pressured to agree because the person suggesting it is an important advisor and reference. Several members of that group are affiliated with the Culinary Institute of America, who disapprove of Alice because she is from Iceland, and according to Wikipedia āDue to the islandās climate, fruits and vegetables are not generally a component of traditional dishes (there)ā. So they do not recommend her resume. This may be unbeknownst to Alice or the advisor. Or maybe the group has evolved into something inappropriate since it was last reviewed.
Well, that is the question indeed. This is the same reasoning I saw on Gitter by the auth panel, when they seemed to dismiss the concept after a quick Google search. But @cwebber, co-author of the W3C-recommended ActivityPub spec which has a Fediverse with 4 million users running on top of it, sees this as the growing fediverseās future and currently its a different one than where Solid is trending towards (at least for now, I think).
If you drilldown on the Spritely project, thereās tons of background research. One thing that @cwebber values is finding old technology gems that work great, but are passed by in the tech world - that often goes for the latest fad - reinventing the wheel. Object capabilities is one such gem, in his opinion.
(Note also - as a similar such example - that as this moment the Top 1 submission on Hacker News is āHow io_uring and eBPF Will Revolutionize Programming in Linuxā, and is about technology that existed in the Amiga computer in 1985 (!)ā¦)
And it is not only Object capabilities where @timbl Solid team might find an interesting discussion with @cwebber. In Spritely thereās also Porta & Bella: Portable Encrypted Storage. Looks like a Solid without Solid in it to my untrained eyes. Will it be successful? Will it be compatible? Idkā¦ but letās not pass the opportunity to get timely informed 
Edit: @anon36056958 maybe you were not referring to Ocap in the comment, but that too is an old Unix technology. That was one of the remarks on Gitter, and the basis for my response.
Hi all,
Firstly thank you for looking at Access Control Policies.
Iāll try to address the questions in this thread.
ACP includes Policies and Rules. At the moment Rules can specify agents, groups, clients (apps), public, the resource creator and finally any authenticated user. However Rues are effectively the extension point for ACP. The intent to to include things like verified credentials, time constraints, etc.
So ACP will not have to be about who you are, it can be about what you posses or indeed many other things.
Hope this helps but Iām happy to answer questions if it is unclear.
Thank you for clarifying that @emmettownsend!