Limitations: Limiting access to trusted applications

[bblfish]

Use Case §2.5.1 Limiting access to trusted applications is part of §2.5 Permission applications, which is listed in §4 Limitations of Web Access Control.

The use case is quite complicated. I want to here show how WAC is compatible with limiting access to applications.

Comparing to WAC

The WAC spec has a § Trusted Web Apps section which allows trusted apps to be listed in the WebID Profile.

This has the advantage that it can be used not just on the user Oscar's pod but also be used by other Pods to limit access. It also leaves the choice of apps to the user so that remote resources don't need to keep up-to-date with compabible apps when setting the Access Control Rules.

But it has the disadvantage that

• it requires potentially remote resource controllers (Guards) to take into account remote user preferences
• it leaks information about what apps an agent is using
• it does not show how to specify certain types of resources which the App can access, such as in the use case which wants to limit an app to all resources contained in a collection (eg a health App to data in a health collection)
• The remote resource can then limit access to a user on sets of resources rather than go indirectly via Apps, which would mean it would need to keep track of every compatible app that could be used.

The Self Sovereign Identity Way

In Self Sovereign Identity philosophy is to put the user at the center. (The book Self Sovereign Identity makes this very clear). SSI has the user control the Wallet containing the credentials, and an Agent (call it WAgent) that can decide which credentials can be given out for a particular request on a resource, by checking a user-policy or asking the user. (see @msporny's Wallet demo) Self Sovereign Identity thus ties in very well with how we interact with credentials in every day life: we hold our wallet in our hand and check give out credentials, deciding on which to use depending on the situation: the drivers license when confronting a policeman, a credit card when buying from a trusted merchant (trusted not to leak the number), cash on a flea market, birth certificate when submitting for an H1B visa, ...

This way of doing things would allow the trusted WAgent to consult protected information on the user's POD on what types of resources any App can access and look at (call it a policy) the to-be-authenticated-to resource to determine its type, before giving out a credential to an App. So such an Agent could consult the ACLs on the resource, and the restrictions given out by the user.

An initial method to do this was explored in the Launcher App proposal. But one could also tie it in with Web Monetization's strategy of deploying browser plugins, allowing for a lot more sophisticated behaviors that way. There may be many other technical possibilities to consider here.

This has the advantage of

• working across Pods, as Solid applications should
• requiring no changes to WAC on the deployed Solid servers, since the WAgent won't give credentials/tokens to the App if it is not allowed access
• not leaking out preferred App information to each origin
• not requiring a remote resource to find user-preference information to decide on access

Conclusion

This use case does not reveal a limitation of WAC as deployed, but rather points to extending the way the client interacts with resources protected by WAC.