Access needs for pod browser apps

[lem-onade]

Pod browser applications (think Penny or Inrupt's pod browser) will request access to all of your data. What would the access need look like for apps like these?

[laurensdeb]

I think there's two things we should consider here:

• Should we have a way to define access needs that matches "any" registered ShapeTree for this purpose? If so, what does that look like? Or is a Pod Browser application rather something that operates at the same privilege level as an Authorization Agent?
• If we assume a Pod Browser is yet another application that has to use the Authorization Agent, how do its access needs materialize in terms of data grants? (e.g. if I use my PodBrowser to plant a new ShapeTree, does it need to make a round-trip to the Authorization Agent to retrieve a data grant for this new ShapeTree)

On a side note: It might be useful to elaborate on how a Pod Browser would work in the presence of Shape Trees and Interop support. I think better, more interpretable UX patterns should emerge from it than the "File Explorer" that is now so ubiquitous.

[woutermont]

Or is a Pod Browser application rather something that operates at the same privilege level as an Authorization Agent?

This is not a desirable way to enable pod browser apps, i.m.o. It fails to address a very probable use case, i.e. that the user would want to browse their data without giving the browser privileged access. E.g. the user might have some initial AA that does not provide browser functionality, which they want to keep using, while adding a non-privileged browser app to their applications.

So the core question indeed remains: what do the Access Needs of a pod browser look like?

[elf-pavlik]

E.g. the user might have some initial AA that does not provide browser functionality, which they want to keep using while adding a non-privileged browser app to their applications.

Every AA would need to provide minimal browsing functionality, at least showing human-readable labels for selecting data instances on the authorization screen.

AA would also have exclusive responsibility of sharing access to data, I must admit not using mentioned pod browsers that much but they probably also try to handle that responsibility. In that sense giving them AA level of access would be a bad practice.

Given that such browser app would not get access to share (also delegate) access. As well as AA would have minimal browsing capability. It would be good to document what that browser app is expected exactly to do. Given that users would use dedicated domain-specific apps to work with data falling under specific shape trees, what generic functionality do current browser apps provide?

BTW it might be good to distinguish how we expect this browser app to operate on storage instances that the user owns and how on storage instances that the user doesn't own but still can access some data on them.

---

Given we clarify the expectations we may end up needing some kind of GenericDataGrant and GenericDataConsent which would not specify a shape tree. Just brainstorming here!

[woutermont]

Thanks @elf-pavlik!

Every AA would need to provide minimal browsing functionality, at least showing human-readable labels for selecting data instances on the authorization screen.

It would be good to document what that browser app is expected exactly to do. Given that users would use dedicated domain-specific apps to work with data falling under specific shape trees, what generic functionality do current browser apps provide?

I do not see the need for minimal browsing functionality in AAs. Their purpose is to enable the user to grant access: it suffices to list the needs in the needs group, and to list a very minimal rendering (name, label, thumbnail...) for every specific need (i.e. a single shapetree) if the user wants to select specific instances.

From a browser, on the other hand, I expect the ability to give smart overviews of all data I have access to (e.g. per shapetree, per registry ...), and to view that data in a much more elaborate rendering (e.g. list metadata, download/open documents in new tab, edit rdf data, call AA to initiate sharing ...). All these last functionalities are i.m.o. no concern of the AA; yet AA level access is no requisite of a browser (it is just an app with a very broad need).

[justinwb]

Generally there is a class of Agents (Applications and Social Agents) that can be deemed as "Trusted". This is one of the few remaining items left on the spec draft (see https://github.com/solid/data-interoperability-panel/issues/187). In the simplest sense, a fully trusted agent would have a similar access rights as an authorization agent to manage data on another social agent's behalf. An authorization agent is itself a trusted agent. Still up for discussion are what degrees of trust should we allow in the middle. I could argue that this use case (a file browser) would necessitate access across data registries, but wouldn't require access to other registries like access consents or agents.

[jeff-zucker]

I would like to mention SolidOS (aka mashlib, aka the databrowser, aka the frontend for NSS) here. It is far more than a pod browser. It must be able to discover everything. It might eventually function as an AA but it might not.