Launcher App proposal

[bblfish]

This is a full (but initial) description of a Launcher App, that plays the role of an Admin App and a KeyChain for all the other apps as discussed in #45 .

It comes with three sections to address the Problems Solved, the Use Cases and the Success Criteria set by the Panel.

A lot of pieces relating to ontologies and other parts of the acl ecosystem would need then to be worked on for it to be able to address all issues the panel wanted to address.

Much more could be done if COWL were developed further in browsers and if it were to taking into account this use case.

[jaxoncreed]

Put in proposals folder

[michielbdejong]

Nice! Could the launcher app also just edit the ACL files? So then there would basically be no spec changes needed, right?

[bblfish]

The Launcher App could edit the ACL files, though it could also delegate the task to a wACL editor app.
The most important thing is that it needs to be able to read the ACLs, reason about them and make decisions as to which credential an App should use for accessing a particular resource, as it has to give the credentials to the apps that want to access protected resources.

But I am not sure why the Launcher App being or not able to edit files would mean that there would be no spec changes. I suppose it depends which spec changes :-)

There are quite a few things that would need to be spec-ed out, such as defining AppIds, vocabularies to tell the app where it should or not authenticate which apps too, where to publish AppKeys (if needed), etc....

[michielbdejong]

why the Launcher App being or not able to edit files would mean that there would be no spec changes. I suppose it depends which spec changes

I was referring to how your proposal seems to rely on the app launcher keeps keys and issues or signs tokens. If the goal is purely that to decide which access a launched or "installed" app gets, then why not just store that information in acl:origin triples in the appropriate ACL docs on the server, as the current spec already allows?

[bblfish]

There are a number of advantages of having the launcher app over relying on the Origin that the panel identified as being important.

1. The Origin method is too vague a method to individuate Apps. A Company could be providing a number of apps from the same Origin. The LauncherApp allows individuation of apps in a more fine grained way: it can use something like a Manifest URL to identify a type of App, or using the AppId which identifies an instance of an App used by an individual. This would allow one to request access for a given AppId, say if one wants to allow access to medical data only to a certain specific App.
2. The Launcher App can control on the user's behalf which set of resources the App can authenticate to. This would allow a user to start with conservative restrictions on the App while testing it, and later change the policy to be more liberal once his confidence in the App has grown, without needing to change all the ACLs.
3. If the JS from the Origin were in charge of making keys for an App, the private key could be leaked to the Origin and to other servers, and so the resource server on seeing an Authentication request for an App could not tell if it was the individual App instance belonging to a user, or any other instance used by other users that was authenticating. The Launcher App allows individuation of a User/App instance pair.

Having said that the Origin can still be an important way to individuate organisations that create Apps, and block or allow all the apps from an Origin if needed.

The Launcher App then can provide many additional services for the user.

1. It can create space for each App on the user's Pod, as it is a good candidate to have administrator rights to do this.
2. It can maintain policies for the user as to when he should be asked to authenticate, something that is quite important in the Solid context to avoid the user being overwhelmed by authentication requests. (This is actually a problem for TLS client authentication, though it could be solved in the same way if browsers wanted it to, and if enhancements to TLS client cert auth were to see the day to make it function well with HTTP2.0).
3. It can be a central place to keep the quite complicated authentication and access control logic which otherwise may need to be contained in each individual App, thereby making it easier for people to write Apps, and for progress to be made in authentication logic without this affecting them.
4. It can of course present all the Apps the user like to use in one place and help her find the metadata for each app, provide feedback on them, etc...

[michielbdejong]

Re your first point 3 (individuation of a User/App instance pair), that sounds promising, nice! That may be a reason to change how our bearer tokens work, yes. But to make that work, the launcher app would need some sort of server-side secret, right? Otherwise the first person to use the launcher app would get access to whatever secret the launcher app uses to produce those signatures?

And yes, our existing acl:origin system is not ideal for native (mobile) apps, but I think that might turn out to be a perpendicular issue to the one a launcher app would solve.

So until then I think it would also be interesting to explore how we can build a launcher app that works with the current spec (i.e., one that just edits the acl:origin triples in the ACL docs).

[bblfish]

The Launcher App can securely create public/private keys and store the private key in the browser storage using JS Crypto API. I implemented that 4 years ago or so to test it. It can be done in a way that it is impossible to ever see the private key.

But yes, one should try to first get the Launcher App to work with some simple code (trying that now) and then with existing protocols, to see how far one can go with it.