[Ecosystem] strongly identifiable clients can also act on behalf of a user and be piloted as well

[elf-pavlik]

3.2. Limiting access by client application states

In the case of a strongly identifiable server-side application, the authenticated agent and the client application are the same. The client application has its own identity that can be strongly authenticated. Alice chooses which data that client application’s identity can access, in the same way that she chooses which data Bob can access.

I see it describing only one of possible cases. Strongly identifiable server-side client can just as well act on behalf of user who delegated access to it in the same way as they would do it for weakly identifiable client.

When it comes to piloting, strongly identifiable server-side client would use solid client as part of that server-side application, it can still provide custom client-server api (eg. using actor pattern) for the interface used to pilot it by the user. That means that user can pilot strongly identifiable server-side clients just as they can pilot weakly identifiable clients.

[joshdcollins]

Totally agree, @elf-pavlik

In the next iteration of changes, you should expect to see an update to https://solid.github.io/data-interoperability-panel/ecosystem/#nevernote-profile that will introduce a triple to indicate whether the application should be authorized using its appId or the end user's.

We're thinking that will likely be manifest itself as multiple, but linked application profile documents. We are envisioning use cases whereas application acting autonomously (on behalf of itself) could request different levels of access from as compared to the access it needs when it is piloted.

[elf-pavlik]

To be honest I don't see a case where client application would have fully autonomous agency. Even if user (person or organization) doesn't 'pilot' the client as it makes request. Some user 'automated' the client to make requests on its behalf. I really don't see case where client application would not act on behalf of some user (person or organization). I do see cases of conflating identity of user and client application, for example if ACME provides one specific online service hosted on acme.example, people would commonly tend to conflate ACME organization with their flagship service.

EDIT: If client usage causes violation of some ToS, I think some person or organization would be held responsible not the client application itself.

[joshdcollins]

@elf-pavlik I agree with you that ultimately there is no sentience here. How would you like to refer to these bots that take action on a Pod without direct user control. Non-piloted?

[dmitrizagidulin]

@joshdcollins "Non-piloted" is a good option. We can also call them "services" or "service apps" (which would match the Google Compute and AWS terminology for non-piloted apps).

[elf-pavlik]

We had some related conversation already in https://github.com/solid/authorization-and-access-control-panel/issues/38

I made argument there that with Web Background Synchronization it becomes even less clear to distinguish when user pilots / attends client and when client makes request based on some automation.

I think we should clarify requirements that depend on distinction between piloted and automated clients. Once we have it I would make sure we also consider clients with offline capabilities which use background sync.

Can we agree for now that when it comes to server-side clients, considered strongly identifiable, they can be used as user piloted (attended) just as well as automated (unattended)?

[joshdcollins]

Yes, I agree that server-side clients can operate in both modes.

[elf-pavlik]

I've just noticed that some time ago I also included comments about client always acting on behalf of some user in https://github.com/solid/authentication-panel/pull/44#pullrequestreview-379436019