Proposal: Replace Trusted Apps with combined authorization

jaxoncreed commented 5 years ago

I believe there's already been a proposal to move trusted apps from the profile to the individual .acl files. Though, I think "trusted apps" are too use-case specific.

It should be possible for any entity (app, human, or bot) to share the same kind of control flow.

A .acl should include an ontology to represent the following cases

The resource can be accessed if a specific person (or group) is authorized (represented by the #owner triple in the example below)
The resource can be accessed only if all people (or groups) from a list combined are authorized (represented by the #app triple in the example below)

This case will allow for flexible application access control. For example, if I wanted an app to have read access to my private folder, the .acl would look like this:

# ACL resource for the private folder
@prefix acl: <http://www.w3.org/ns/auth/acl#>.

# The owner has all permissions
<#owner>
    a acl:Authorization;
    acl:agent <https://jackson.localhost:8443/profile/card#me>;
    acl:accessTo <./>;
    acl:defaultForNew <./>;
    acl:mode acl:Read, acl:Write, acl:Control.

<#app>
    a acl:Authorization;
    acl:combinedAgent [
       acl:agent <https://jackson.localhost:8443/profile/card#me>;
       acl:agent <https://coolapp.example/profile#me>
    ];
    acl:accessTo <./>;
    acl:defaultForNew <./>;
    acl:mode acl:Read, acl:Write.

Notice the acl:combinedAgent predicate. This refers to a list of agents (it could also be a list of lists of agents). This authorization would only qualify if a request was made with a token that represents both jackson.localhost:8443/profile/card#me (my webid) AND coolapp.example/profile#me (the app's webID)

The main benefit of this over PoP tokens is it is not simply constrained to apps and can be applied to anything with a WebID

It should be noted that this would also require a new kind of token that can represent consent from any number of parties.

dmitrizagidulin commented 5 years ago

The main problem that the Trusted App mechanism was intended to solve (and it's far from an ideal solution), is not that there wasn't a notion of a combined agent. There is (although this proposal is even better than the current implicit acl:agent + acl:origin combined authorization). The main problem is - the UI/UX complexity of having to track per-app authorization in every .acl file. (The Trusted App mechanism gets around that by having a global whitelist, which means that each .acl file does not have to have an individual app whitelist.)

So, this combinedAgent proposal, although I really like it, still has the same UI/UX problem of maintaining multiple app permissions over many .acls.

RubenVerborgh commented 5 years ago

I don't think the notion of a "combined agent" is what we are looking for, but rather an "on behalf of".

We can find a lot of inspiration in PROV-O: https://www.w3.org/TR/prov-o/

the UI/UX complexity of having to track per-app authorization in every .acl file

So that would definitely not be the way to go. But rather something like "I allow Alice to access R", and—independently—"I trust apps with qualifications X, Y, X to act on behalf of others". And only if needed "I trust app Q acting on behalf of Alice".

dmitrizagidulin commented 5 years ago

@RubenVerborgh

"I trust apps with qualifications X, Y, X to act on behalf of others".

That's a little more manageable than a global list of trusted apps, but not much more. Because that still gives those apps access to the whole data space. The thing we also need, I think, is a way to specifically restrict which data an app can access, but without the UI complexity of managing every .acl file in every container. I suspect we can do something with collections/shapes, and some sort of type index or app index. To say (in one place, rather than many .acls) "this app can have access to all my vCards, but not other stuff".

RubenVerborgh commented 5 years ago

That's a little more manageable than a global list of trusted apps, but not much more. Because that still gives those apps access to the whole data space. The thing we also need, I think, is a way to specifically restrict which data an app can access, but without the UI complexity of managing every .acl file in every container.

Yeah, one doesn't exclude the other. My plea was for separating "this is what people can do" from "this is what apps acting on behalf of people can do". To avoid exhaustively listing apps, see my proposal. To limit those apps to certain folders, see yours. But those constraint sets are orthogonal.

dmitrizagidulin commented 5 years ago

@RubenVerborgh

"this is what apps acting on behalf of people can do"

Ah, ok, I didn't catch that we were talking about apps on behalf of other users, not your own apps. So there, I think the question is first - should we be able to restrict the apps of other users (we're sharing data with) at all. And if yes, what mechanism. I don't think that should be a possible restriction, though. Your own apps - yes. (Because otherwise they have the run of your data space). Other people's apps? Not really (since we tend to limit other people's access anyways).

solid / authorization-panel

Proposal: Replace Trusted Apps with combined authorization #21