extra constraints

[bblfish]

In the 14 August 2019 meeting Michael Thornburgh seemed to be working with a number of constraints that should be made explicit so that they can be addressed. The ones I remember were:

1. not all ACLs should be public: If I want to tell the server to limit which apps of mine can access a server I may not want everyone to know about which apps I am using. So that part of the acl should be protected
2. One may want access control to work across pods. I don't quite understand the use case here, but perhaps it has to do with my wanting to limit what apps I can use on other servers?
3. There is the question that one may or may not want to reveal to an app where the resources of a certain type are that it is requesting access to.

If any other extra constraints pop up please add them here. We should find a place to place these to make it explicit.

[RubenVerborgh]

Note that the granularity of Solid access control is a resource. So “part of the ACL” is not a thing yet, since the entire ACL document is one resource.

We could do more granular, but then that is a dependency.

[bblfish]

yes, I was just trying to express the property that Michael was expressing, not how to do it.

The OAuth method that some people have in mind for 1) and 2) (guessing from some discussions) is that the Authorization server can give tokens only to clients that fit the bill. If the server only delivers tokens for 1) a limited number of apps then the list of apps will only be known to the OAuth server, and it will function across all servers.

There may be other ways to do that too...

[zenomt]

@bblfish some clarifications:

1. not all ACLs should be public

WAC currently says that ACL resources should only be accessible by someone with acl:Control access. however, i was talking specifically about the acl:trustedApp thing recently added to WAC and NSS, where my profile (publicly) lists the origins i trust/use. i think acl:trustedApp is a huge privacy and security problem.

2. One may want access control to work across pods [...] perhaps it has to do with my wanting to limit what apps I can use on other servers?

a user might want to limit what an app they are using can do, even on other servers. as in all cases, it's ultimately up to the resource server to honor the user's preference.

your (3) i think has to do generally with how apps figure out where to get & put stuff. i don't think i was the one who raised this point. if it's a concern, then perhaps that kind of information can itself be subjected to granular access control somehow.

[zenomt]

1. it should not be possible for third parties to read a list of apps i use (without my consent). i'm not counting being able to discover or deduce my apps by reading my resource(s) where the app leaves an indication of its identity (such as a direct claim or by fingerprinting the resources) -- that's a different but also important problem.

2. it should not be possible for a resource server to know about any apps i use other than ones i've actually used to access that resource server.

3. it should not be possible for an app i'm currently using to know what other apps i use.