Allow non-owners to access a shared resource with a web app of their own choice

[michielbdejong]

Suppose Alice has a resource on her pod, and gives Bob read access to it. Bob wants to use a web app to view the resource. This is currently allowed if:

• there is an ACL rule granting read access for that path, Bob's webid, and the app's origin, or:
• with https://github.com/solid/web-access-control-spec#possible-future, Alice (who has control access to the resource has listed the app's origin as an acl:trustedApp in her profile
• Bob gets acl:control access to the resource, meaning the acl:trustedApps in his profile also get whitelisted (but this option doesn't really count, since the premise was that Bob was only getting read access)

This means that Alice can only whitelist specific app origins for Bob to use, and she does not have a way to give Bob read access to the resource without making any restrictions on web app origin.

One possible way to service this use case would be to allow ACL rules to have acl:origin "*", meaning that Bob is free to choose which web app he prefers, even if it's one that Alice has never heard of yet.

Another option might be to also check Bob's profile for trusted apps when a web app tries to read the resource on Bob's behalf.

Without this feature, sharing a resource could feel like how sharing an office document worked in the 90's: you could only view the documents you receive if you used the same app as the sender, if you used a different app, you had to email back and forth asking them to export/convert the document.

[michielbdejong]

@elf-pavlik does this more or less capture what you described during today's community call?

[elf-pavlik]

Thank you @michielbdejong I does indeed! In general I think that ACL should only stay responsible for giving permissions to agents. Agents need to stay responsible for managing their trust for apps. I will also follow up with you in https://github.com/solid/web-access-control-spec/issues/34

[michielbdejong]

cc @zenomt

[elf-pavlik]

Can we transfer this issue to app-authorization-panel repo?

[RubenVerborgh]

Without this feature, sharing a resource could feel like how sharing an office document worked in the 90's: you could only view the documents you receive if you used the same app as the sender, if you used a different app, you had to email back and forth asking them to export/convert the document.

I cannot emphasize this strongly enough.

Solid promises app/data independence. Being too strict with app restrictions breaks that promise.

We need better mechanisms for specifying which apps can access data. For instance, things like:

• I trust all apps that have received a certification from parties A, B, or C

Suggestion: can we turn this issue into a PR with a set of use cases?

[elf-pavlik]

I'll make PR with one or two use cases where person gives some global trust to specific app. Maybe you can make PR with use case for that:

I trust all apps that have received a certification from parties A, B, or C

?