search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

Launcher App: Is there too much implementation overhead? #57

Open jaxoncreed opened 4 years ago

jaxoncreed commented 4 years ago

As I currently understand it, the launcher app would require me to have a compatible application for every device I use (browser, desktop, android, ios, smart TV etc). Is this true? Is that too much implementation overhead?

bblfish commented 4 years ago

Thinking about it from first principles, what does the Launcher App do?

  1. It has rights to write to a part of the user's Pod allowing it to:
    • create an AppId where it can link to the App Manifest (which issue 32 calls the App WebID), so that it knows how to launch it, and so also have an identity for the App that is verifiable, since it launches it.
    • give the App space (an LDPC probably) where the it can save information to run, by setting the wACLs for it.
    • It can also place on the Pod a Description of limitations the user wished to impose on an App (can it access all servers, or only some?)
    • It can Link the WebID Document to public keys so that signatures can be tied to the App.
  2. It knows how to read wACLs and choose the right credential for an App to use, according to the user's privacy policies,
  3. It has access to the private keys so that it can sign tokens and credentials for the App when it accesses a resource.

The question of implementation overhead needs to take into account the problem of multiple platforms. This is already an implementation overhead. If a lot of apps are expected to be built for each of these platforms, then one launcher app or equivalent (whatever can do the above for each platform) is a one time cost.

Presumably the question assumes that the OAuth/OpenId method is satisfactory. This means that a redirect to a service that authenticates the user is good enough.

But does the Launcher App preclude a Pod service that does the same thing? I don't think so. Furthermore the Launcher App could also be implementable via a web proxy on the user's Pod as suggested in issue 35: new role: User's Proxy. Abstractly considered each of these if they have the same role could be considered a Launcher App. Details would need to be worked out of course.

elf-pavlik commented 4 years ago

It has access to the private keys so that it can sign tokens and credentials for the App when it accesses a resource.

So the app directly accesses resources or it makes requests via the Launcher app using it as proxy?

bblfish commented 4 years ago

So the app directly accesses resources or it makes requests via the Launcher app using it as proxy?

My first proposal for the Launcher App has it return some signed header to the Relying App (the less secure one) so that this one can make the request. This can happen after the Launcher App has followed the rel=acl link to determine what identity should be used.

One would need to research if it is possible in the browser for one JS App to act as a proxy for all requests for apps from other origins. This used to be possible with Cross-Origin Service Workers, are there other ways to get this to work?

elf-pavlik commented 4 years ago

One would need to research if it is possible in the browser for one JS App to act as a proxy for all requests for apps from other origins. This used to be possible with Cross-Origin Service Workers, are there other ways to get this to work?

Given #56 one may want to run 'launcher app' on remote server anyways, in that case we don't have limitation of doing only what web browsers allow.