Launcher App: How does it work with Bots?

[jaxoncreed]

Given the launcher app must be on the same devices as the application, how would it be offload an identity to a bot on a server? I would like to be able to get some kind of constrained credential that could be used by some code on a device I don't trust.

[bblfish]

In today's teleconf - 11 Dec 2019- (on the subject of issue 31) @justinwb mentioned that this was a very important use case. Can you develop a bit? Just to help me think about it.

[jaxoncreed]

Let's say I have an app that will take my photos and build cool slideshows for each day of my vacation.

The app runs a cron job every night when I'm asleep to get photos from myself and friends and turn the into a slideshow.

How does the app's server get the proper credentials to do that if all my devices are off when I'm asleep?

[bblfish]

One possible answer is to think of the user's Pod Proxy as a launcher App, following my answer in issue 57.

What is the answer from the OAuth side?

[elf-pavlik]

What is the answer from the OAuth side?

In most recent discussions, we consider giving OIDC Provider (OP) broader responsibility to issue capability credentials to clients, based on what user have delegated to that client on consent screen. Putting aside how client requests fresh credentials (refresh token, client secret, dpop proof), as long as client can communicate with OP it can get verifiable credentials (id & capability) to make requests to RS.

One possible answer is to think of the user's Pod Proxy as a launcher App

Does it mean that launcher apps run on each user's device as well as some remote server? I think we could compare it to OIDC with OP running on remote server as well as OIDC self-issuers solid/solid-oidc#91

@bblfish user has 'launcher app' running on remote server, why would they run additional instances on their local devices? If person uses 'launcher app' running on remote server, it becomes to look very much like using standard OIDC Provider.

[bblfish]

@bblfish user has 'launcher app' running on remote server, why would they run additional instances on their local devices?

Speed and efficiency come to mind: it is faster to calculate something locally and store data locally than remotely. This is made very clear if you consider Computer Latency in Human Time.

If person uses 'launcher app' running on remote server, it becomes to look very much like using standard OIDC Provider.

So that's a good thing, since you are for OIDC :-) What we are doing then is proposing a way to make OIDC flexible so as to be taken on locally or remotely as well as connecting it to the linked data world.

There is a difference in that as opposed to traditional OIDC providers the concept of a LauncherApp would allow apps to use multiple credentials from multiple providers for different resources on the web (a topic of issue 59)