role of server side clients

[elf-pavlik]

This relates to: https://forum.solidproject.org/t/push-notifications-push-api/1079

I can see use for all kinds of clients which run 'in the cloud' rather than on local devices in web browsers. In example below Alice and Bob use two different applications running on their devices and to my understanding acting as Presenters. But each of those application has companion client running on some server 'in the cloud' which in this case sends Push notifications to the applications running on local devices. For the sake of discussing it I just call them bots on diagram below.

Few things I see need to clarify

• which OIDC roles do they play
• how do those bots authenticate using WebID-OIDC
• how do those bots fit acl:trustedApp and Origin restrictions

In illustration above Alice and Bob might want to get notifications caused by writes of the other one to the acme RS/RP. We can't really rely on Solid Websockets API since mobile OS will not keep all the applications active. Push Notifications and Service Workers already address this issue we just need a clear way to integrate that solution. Each application (running on the device) might provide their own bot that could subscribe to Websockets API and send customized push notifications to the app it accompanies.

[elf-pavlik]

from @dmitrizagidulin on a call

• Authorization Code flow
• Hybrid flow - both components share token (servers side component and app in the browser)

[jaxoncreed]

Noting what Demitri said in the community meeting: such an app would use oidc hybrid flow:

Where Presenter X and Presenter Y are the Relying Party. Bot X and Bot Y are the resource server/api provider.

Given we're going to implement client ids to distinguish web apps (#12), acl:trustedApp will reference the token just like any other flow.

[elf-pavlik]

Just to clarify few things and match names used in diagram to terminology from Decentralized Authentication Glossary

Presenter X and Presenter Y act as:

• Public client
• Presenter
• ???Relying Party???

Bot X and Bot Y act as:

• Confidential client
• ???Presenter???
• ???Relying Party???

RS/RP Alice's, Bob's and ACME's act as

• Resource Server
• Relying Party

Presenter
A public client app that is trying to present a user's credentials from their home POD to some other POD. For example, Bob is trying to access, via a client app, a shared file on Alice's alice.com POD, logging in using his own bob.com POD/provider. In this example, bob.com is a Provider, alice.com is a Relying Party, and the client app (say, a browser-based HTML editor) is a Presenter.

I don't know if we can also consider confidential client (Alice's Bot X) as presenter but it will use credentials from Alice's OP to access ACME's RS/RP

Relying Party (RP)
A Relying Party is a POD or a client app that has to rely on an ID Token that's issued by a Provider.

If all the clients (Presenter X & Y, Bot X & Y) use PoPToken they also seem to act as RP. In my diagram only OPs don't act as RPs

[michielbdejong]

cc @sylvainlb about server-side clients