Policy ontology to allow automated access control decisions

[bblfish]

Solid apps are build to follow links from one server to another to fetch data. As an example see the wiki page showing what connections would be needed to write a friend of a friend address book starting from Tim Berners-Lee's WebID, and illustrated below:

There is thus a danger that in a short time the user be bombarded with 100s of popups asking her what identity she wishes to use on each web site - potentially even on each resource requested. This would quickly lead to apps being unusable, or to popup fatigue, training the user to always click yes, and so for those popups to become essentially meaningless. (This is a criticism of GDPR induced popups).

The user should be able to choose and edit reasonable policies for when to be asked for an authentication decision, and when to allow the Authentication Agent to make that decision on its behalf. This could be very useful initially for a Launcher App, and indeed longer term for browsers themselves.

Are there ontologies that we can already use to do this?

[jaxoncreed]

Tons of pop-ups would only be a problem if the resource server required a user's permission to continue with an application. As of now, there is no such mechanism. Even @zenomt 's proposal (https://github.com/zenomt/webid-auth-protocol) for resource server authorization would be automated.

[bblfish]

I suppose this issue should be tied together with the issue Consider the advantages of wACLs being readable by apps, as both answers are needed to help both reduce credential leakage and popup fatigue. So I'll work them together here.

If you follow a friend of a friend network (see diagram I added above), and if these profiles are protected as they may be by an wACL returning a 401 Unauthorized with one or more WWW-Authenticate headers specifying the methods the server accepts for authentication, how is the App to know what credential it is to use to authenticate and if the user agrees to that being used there?

If the policy at present is to always use one ID anywhere then this is an implicit policy in current apps. Future Apps would certainly like to give the user a choice, as some users may not want to leak credentials to any server in this way.

Asking the user for permission for each origin would give the user the most control but lead to the popup fatigue. Especially if many of the uses of an id are often unsuccessful, as they will be if the App has to then use an Id to authenticate without being able to tell if the authentication will be successful.

If the user has many ids, as most of us already have (I have Twitter, Github, Facebook and Google Ids to mention a few), how would the App know which one to choose to authenticate? Without seeing the wACLs, the Identity controller (eg. the Launcher App) would have to randomly try each one, which would be both time consuming and leak credential details, allowing a server to potentially link identities that the user may have wanted to keep separate, without that process even being guaranteed to be successful.

The above is a still a simplified use case. We should work on the assumption that different resources on a web server have different wACLs, some allowing members of some groups access, others of other groups. So one single server may require many different proofs of identity.

Furthermore, the multiplicity of identities will grow with the work of the Verifiable Credentials WG at the W3C.

From previous discussions with members of the wider security community the criticism of credentials leakage is one they take very seriously (over seriously at times). The proposal here is to make it possible to respond to that criticism.

By making it possible to have readable acls, the client can use the right credentials. By having a policy file the user can choose when it makes sense to be asked whether a credential should be used.

[zenomt]

If the user has many ids, as most of us already have (I have Twitter, Github, Facebook and Google Ids to mention a few), how would the App know which one to choose to authenticate?

the model of almost all apps everywhere that use something like OAuth2/OpenID Connect is that you log in to the app, and that's the identity you use when using that app. it's probably undesirable from a privacy point of view for one app to be able to correlate that two different webids are the same person.

from a general security point of view, it's an anti-pattern to tell an adversary what identity they need to steal or impersonate in order to access a restricted resource, so at the very least an ACL should not be world-readable. WAC currently specifies that only controllers should have access to an ACL. i've relaxed that a little in my own implementation (though i'm not sure it's a good idea) to allow someone to read an ACL if the ACL grants read access to its resource.

[TallTed]

ls -l on any Unix-like system lets you read an ACL, albeit a primitive one. I supposed it's debatable whether that was a good idea.

Still -- Unix filesystems being a substantial piece, if not the whole, of the base model behind Solid, it suggests that some degree of ACL exposure is at least OK.

[bblfish]

@zenomt wrote in response to @bblfish's setence:

If the user has many ids, as most of us already have (I have Twitter, Github, Facebook and Google Ids to mention a few), how would the App know which one to choose to authenticate?

the model of almost all apps everywhere that use something like OAuth2/OpenID Connect is that you log in to the app, and that's the identity you use when using that app.

Most current Apps are not the type of apps that Solid is aiming to build (I call those HyperApps in my second year report to distinguish them from normal Apps that we have now and for which OpenID Connect was designed). @RubenVerborgh made a similar point recently.

Having said that I agree with you here:

it's probably undesirable from a privacy point of view for one app to be able to correlate that two different webids are the same person.

Indeed it would be nice to be able to solve this issue too. We would ideally like neither the App nor the servers connected to to be able to correlate identifiers. This is not an easy task, but one can aim for it

It may be that the Launcher App can help here. The Launcher App as the user's most trusted app, playing the role of a keychain, can know all the identifiers of a user without this information needing to leak to an App.

If it were possible for the Launcher App to make the HTTP requests itself and give the content to the App, then this could reduce the visibility of the identifiers used to the App (who would have no way of knowing if the content were received directly or through a third party for example). So we could both have flexible authentication with multiple ids, policies for client authentication, and perhaps even reduction of id correlation.

Also, the aim of providing un-linkability of ids needs to be balanced with the current problem of single ids designed for massively centralised systems, where all information is visible to the owner of the system. The Panopticon architecture of current systems has set a very low barrier for privacy. If we can improve by redecentralising networks, then we will have solved a major privacy problem. A further aim of providing unlinkability would make it even better.

[csarven]

https://github.com/solid/authorization-and-access-control-panel/issues/55