search

solid / webid-oidc-spec

WebID-OIDC Authentication Spec v0.1.0
MIT License
56 stars 18 forks source link

role of server side clients #9

Open elf-pavlik opened 5 years ago

elf-pavlik commented 5 years ago

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.

webid-oidc

Few things I see need to clarify

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 commented 5 years ago

from @dmitrizagidulin on a call

jaxoncreed commented 5 years ago

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

image

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 (https://github.com/solid/webid-oidc-spec/issues/12), acl:trustedApp will reference the token just like any other flow.

elf-pavlik commented 5 years ago

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

Presenter X and Presenter Y act as:

Bot X and Bot Y act as:

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

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 commented 5 years ago

cc @sylvainlb about server-side clients