authorization-panel
authorization-panel copied to clipboard
solid
Compelling Use Cases for User-Focused Client Constraining Access Control
We've heard multiple use cases for User-Focused Client Constraining Access Control (ie Client Constraining Access Control that is not controlled by the resource controller, but by the app user). I'd like to use this issue to collect them.
from gitter per @jaxoncreed 's request:
i thought that one of the fundamental principles of Solid was that the user should be able to use whatever app she wants to access whatever data. it's not reasonable for a resource controller/owner to have to maintain a whitelist of all the different apps all the different consuming users want to use. i thought we-all had decided that a long time ago. however, the minutes from monday's meeting sound like people had gone back to the controller/owner explicitly specifying what apps users can use. that or "user uses a proxy". i'm very -1 on both of those antipatterns.
~note that the meeting minutes from 2020-04-20 is in a file named 2019-04-20, so if that gets fixed the link above will break. :)~ (edit: minutes renamed, link updated)
One compelling use case revolves around multiple communities. These communities are relatively tight-knit and each member trusts the other members. In order to avoid the friction of asking to use an application, the access control in the community accepts any application that one of its members uses.
A concrete example of this could be an open-source project where all members of the project trust each-other.
A concrete example of this could be an open-source project where all members of the project trust each-other.
I think we can take @solid as an example. While CG has more open entry, github org has higher requirements for membership. If we consider @solid members as invited experts, who in addition only have access to relevant repositories, I think we don't we need to restrict which applications they can use to participate in issues, project boards, chatrooms (gitter) etc.
W3C Working Groups which have even higher level of entry possibly can leave it up to experts participating in them, which applications/clients they want to use.
This is a highly perplexing issue, and conversation to be having. What you're asking is the exact logical equivalent of Apple asking "Let's come up with some compelling use cases for allowing users to pick the app they're accessing our music with." That's not a metaphor, that's not an exaggeration, it is the exact functional equivalence / definition.
User-Focused Client Constraining access control == an "ok" (not perfect) protection from phishing, and is a genuine innovation Solid can bring to the world. Oh, and, most importantly, is technically possible.
Resource Controller Focused Client Constraining access control == is literally DRM. Not technically possible for the vast majority of Solid apps. And does not bring any benefit or added security.
I think appending Linked Data Notifications makes interesting example:
Alice doesn't want to restrict which applications other users can use to append Linked Data Notifications to her inbox. Other users want to restrict which applications can append LDN to Alice's (and other) inboxes
Currently we have following use cases documented:
All of those use cases illustrate scenario where Alice wants to constrain client when accessing data which she doesn't have resource controller access rights.