acl:trustedApp limits usefulness of decentralized social apps

[mrkvon]

As was already pointed out in #1672 (comment), when somebody has shared their data hosted on NSS with me, I can't access those data with a web app of my choice, I have to use the same web app they used.

This limits usefulness of otherwise interoperable apps that work on top of any kind of social non-public data.

In comparison, CSS doesn't use acl:trustedApp, and I can use an app of my choice to access the data shared with me.

Has this been discussed already? Is this a desired behaviour? It looks to me like it's an unfortunate side effect, since it limits one of goals of Solid Project¹: People can choose which app they want to use.

Footnotes

1. as I understand it ↩

[zg009]

Is it not used to address the open issue with the ACL model is the fact it doesn't explicitly take into account client apps, because once a client has an access token it can make use of it maliciously to craft requests, even if it uses DPoP-bound JWTs? So the trustedApp predicate is to provide a guard against an unauthorized application from executing an arbitrary request with any access token. Or am I completely wrong?

[mrkvon]

Is it not used to address the open issue with the ACL model is the fact it doesn't explicitly take into account client apps, because once a client has an access token it can make use of it maliciously to craft requests, even if it uses DPoP-bound JWTs? So the trustedApp predicate is to provide a guard against an unauthorized application from executing an arbitrary request with any access token. Or am I completely wrong?

I suppose that's correct. However, the feature still limits the choice of apps for other users.

A simple resolution would be to apply trustedApp only to requests from the pod owner, as their misused access has the most potential for harm. This doesn’t need to apply to other users, who have only limited read, write, or append access.

[zg009]

I suppose that's correct. However, the feature still limits the choice of apps for other users.

Being right about something for once is nice, but I agree. Though this may be by design - I think acl:trustedApp should be applied on a per-resource basis and not a per-pod basis, though. For instance, I may have a datashape/resource that I only want a specific app to use. Is that a use case that makes sense?

A simple resolution would be to apply trustedApp only to requests from the pod owner, as their misused access has the most potential for harm. This doesn’t need to apply to other users, who have only limited read, write, or append access.

I agree here and could possibly make a branch for this because I think I rewrote the acl-checker which uses this recently, but I would have to check.

I think another instance where you would want to use acl:trustedApp would be if a user has Control permissions, for instance I don't want any app where a user with control permissions is using it then able to make authn/authz changes arbitrarily. Do you have any thoughts on that?

[mrkvon]

I think acl:trustedApp should be applied on a per-resource basis and not a per-pod basis, though. For instance, I may have a datashape/resource that I only want a specific app to use. Is that a use case that makes sense?

👍🏼 Yes! It seems shape/resource-based app authorization is the long-term vision for many in the Solid community (e.g., SAI). Personally, I'm a fan of shape-based app authorization.

I think another instance where you would want to use acl:trustedApp would be if a user has Control permissions, for instance I don't want any app where a user with control permissions is using it then able to make authn/authz changes arbitrarily. Do you have any thoughts on that?

Agreed. Control is too much to share arbitrarily. 🙂

In the long term, it would make sense for each user with access to grant that access to their chosen app, though I'm not sure how that would be implemented.

For now, since acl:trustedApp isn’t specified in WAC afaics, I'd be happy with an imperfect solution that makes the most sense until something better is available.

For now, it would be great if non-owner people with resource access could use the app of their choice, at least for Read and Append permissions granted to them:

• Read: For displaying shared data from another person.
• Append: For sending (ActivityStreams) notifications to another person's inbox.

However, we would need to be a bit more restrictive with profile document itself, since Append allows apps to give themselves Write and Control by editing it.

[zg009]

In the long term, it would make sense for each user with access to grant that access to their chosen app, though I'm not sure how that would be implemented.

I keep seeing mentions of decentralized/self-sovereign identities to handle this with the app possibly being tied to who owns it(?).

For now, since acl:trustedApp isn’t specified in WAC afaics, I'd be happy with an imperfect solution that makes the most sense until something better is available.

For now, it would be great if non-owner people with resource access could use the app of their choice, at least for Read and Append permissions granted to them:

Read: For displaying shared data from another person.
Append: For sending (ActivityStreams) notifications to another person's inbox.
However, we would need to be a bit more restrictive with profile document itself, since Append allows apps to give themselves Write and Control by editing it.

I'll take a look into it when I can. I am busy with writing my thesis this term which is why I have been rather inactive. I don't think it should be too big of a hassle to remove, but maintaining/updating these packages is on the low priority list right now

[mrkvon]

Thank you for the responses, @zg009!

Best of luck with your thesis!

I might be able to make a PR, but it would be great to get approval from the NSS maintainers/community first.