Supporting material: Applications and access control with strict origin checking

This is a document that inrupt has been working on to get an overview on the work being done on how NSS handles strict origin checking with the release of v5.

NSS v5 introduces a reimplementation of the Web Access Control (WAC) specification. A central aspect of this is the handling of agent origins, and a result of this is stricter access control for web applications on untrusted domains (‘untrusted’ being any other domain than the PODs domain). If left unchecked on the release of v5, this will “break” a lot of applications currently relying on the access system in v4.

This document tries to summarize the conversation being had on this, where the focus is on how we want to advance a solution for this in the long run, and how we can mitigate this in the short-term.

In the end the community leader needs to make a decision on how we want to proceed on this, so it’s vital that Tim Berners-Lee is included in the conversation. We also need to decide how we want to communicate these decisions to the broader community, so that developers and users know what they can expect going forward.

Short term alternatives

Some suggestions on short-term options. Regardless of which solution we go for, we need good documentation for the choice taken.

1. Leave it as is (i.e. postpone the release of v5 until we have a “proper” solution)

We could choose to not mitigate this in the short-term, and wait until we have a proper long-term solution.

If we choose to release v5 without a good long term solution for this, we will most likely get a lot of heat from application developers and their users who can no longer access non-public resources without having their domain listed as a trusted domain.

2. Add a given set of trusted domains

We could have an ongoing discussion with the community about URLs that should be trusted by default. When it comes down to it, this is up to the POD providers to configure for their various servers. (It is also counter-intuitive to the decentralized nature of Solid to rely on a list of trusted domains for all applications, but again - this is merely a short-term solution.)

If we do want to go for this approach, we think that the W3C Solid CG should advice POD providers on which origins should be listed as trusted.

A URL that we might want to include by default is localhost:3000, to give developers an easy way of testing their own applications in their local development environment. (This is also the default URL for the Solid React SDK.)

3. Turn off the use of trusted domains

The use of trusted domains is already a configurable option, and we could set this to false by default.

This is probably the easiest solution, as it doesn’t break with what people have grown to accept from NSS v4. It could be combined with a clear communication that we intend to implement a proper solution for this in the next minor release, v5.1.

4. Allow users to grant access to a list of trusted apps

In the WAC spec there is a section describing how web applications can be added to a list of trusted origins in a user’s profile. We could implement this mechanism to allow users the ability to add which origins they trust themselves.

This also needs to be coupled with good tutorials that explains how people can do this themselves. We may also want add a feature to [the profile pane](https://github.com/solid/solid-panes/blob/master/profile/profilePane.js) to give an UI to do this.

Long-term options

Suggestions on how to solve this in the long run.

1. Implement an access system using OIDC to enable OAuth-based access tokens

Right now this is probably how we want to go about this in the long-term. The question is how we go about doing this. We probably want a specification on how this should be handled by Solid servers in general.

The following sub options are not exclusive, we can choose to implement all of them if we want to.

1a. Coordinate the creation of the specification with W3C Solid Community Group

This is probably a given, but we list it as an option in case there are better ways to go about this.

1b. Implement the system for NSS v5

The current codebase is quite convoluted, and we might want drop implementing a proper system for NSS v5. But we need to discuss this further.

1c. Implement the system for NSS v.next

With a new architecture this should hopefully be much easier to do.

Meetings

This section lists the relevant meetings on this topic.

February 27, 2019

Meeting with Kjetil Kjernsmo, Justin Bingham, Pat McBennett, Mitzi László, and Arne Hassel.
Arne held an introduction explaining the issue that prompted the conversation, and how this leads into a larger discussion.
- To be clear: This is a discussion that has been going on for a while, but the issue made it clear that this is something some decisions should be made for the upcoming release of v5
Kjetil goes into more details, and how this complicates the release of v5.
Justin explains how this could work in the long term, by making use of OpenID Connect to grant access to applications.
Mitzi suggests proposing coming up with some alternatives and present this to the W3C Community Group, to get input on how to proceed with this.
Action points to follow up:
- Arne commits to writing up a summary of the meeting (this document).
- Arne coordinates with Kevin and Kelly to set up a meeting ASAP to continue this conversation:
  - It is very important to have Tim part of that discussion, as he is the one that needs to make the final decision on how we want to proceed on this, both short-term and long-term.

February 28, 2019

Meeting with Kevin Howard, Arne Hassel, Pat McBennett, Kelly O’Brien, John Bruce, Tim Berners-Lee
Justin and Arne presents the problem
- NSS v4 is not doing strict origin checking by default
- The reimplementation of WAC in NSS v5 is setting strict origin checking on by default, and it will probably cause a lot of confusion for users and developers using web applications
- A way of going about this is to add a lot of URLs to the list of trusted origins on the server, but that is not really the philosophy of Solid
Tim points out that strict origin checking should be on by default
It does put web applications in a disadvantage over desktop or native applications, as the latter aren’t affected by strict origin checks (but that’s just the way it currently is)
- We don’t want to centralize around a small number of domains
Justin presents the idea of a system that grants access to applications as agents (instead of relying on the current model where applications acts as the user)
Tim points out that this becomes a problem of authentication, not authorization
- Tim proposes a solution that is described in the WAC spec, under the title “Possible future”
- Allows user to list which origins they trust, and which modes these origins should have to all resources in the POD (ie this is a global solution for a given POD)
- Pat points out that this is not implemented yet, and there’s no UI to help users doing this
- This could take a lot of time to implement, and could delay the release of v5
Arne points out that we need a short-term solution for the release of NSS v5 to continue a good developer experience
- it looks like the use of acl:trustedApp is implemented in acl-check in a function called publishedTrustedApp, but it’s uncertain how to use it (and it is not used in NSS v5 currently)
- Implementing the use of acl:trustedApp could work as a short-term solution (Arne will do some research on this)
Tim points out that we must have strict origin on by default in the release of v5
- In the long term a user will just say they trust a particular app
Justin: We need a way to automate the addition of trusted apps/origins in a POD; i.e. as part of an oauth authorization flow, or through a trusted third party app registry where users could say they trust applications from that source
- We also need to provide a good way for users to manage this trust / list of applications that have access to the POD

Pat points out that people will probably need a UI for managing trusted applications

Arne comments that he thinks people will be happy if they can add their local app to a list of trusted apps, and not rely on POD providers

Related resources

This list is not exhaustive, but gives insight into some of the previous conversations regarding this topic.