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.

[josephguillaume]

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 want to try to answer this question by continuing from my more technical question & observation at https://github.com/solid/data-interoperability-panel/issues/324#issuecomment-2423380766

Given the principle of least privilege, an application that is following its nose will likely come upon a uri that it does not have access to. It will not make an access request because it doesn't even know what the access need is for the uri, let alone whether it actually supports it.

Instead, if an app is given a uri it can't access or handle, it hands it over to a launcher app that can 1) offer apps to open with, 2) automatically redirect to a preferred app, or 3) show the resource internally. As I understand it, I agree that the launcher app needs to be trusted - it needs to have complete knowledge of all apps the user wants to consider and be able to dereference any uri the user has access to, regardless of what pod it is on.

As far as I know at the moment launcher apps that offer (1) and (2) simply don't exist. The dominant solution is to have a trusted browser app that has a combination of specific and generic panes to handle any uri that is thrown at them.

SolidOS (and other alternatives) have the superpower and privilege that they achieve the launcher app effect at the uri. Even if the user follows their nose by copy pasting the uri into a new browser window (after authentication) they will still be provided with a user interface for the resource. This is achieved through content negotiation via the "data browser hack" https://github.com/SolidOS/mashlib?tab=readme-ov-file#the-databrowser-hack-upgrading-your-browser

[elf-pavlik]

SolidOS (and other alternatives) have the superpower and privilege that they achieve the launcher app effect at the uri. Even if the user follows their nose by copy pasting the uri into a new browser window (after authentication) they will still be provided with a user interface for the resource. This is achieved through content negotiation via the "data browser hack" https://github.com/SolidOS/mashlib?tab=readme-ov-file#the-databrowser-hack-upgrading-your-browser

This can lead to a security nightmare unless done cautiously. Probably, those restrictions would need to be in place:

• Storage serving a default app, like a data browser, would need to have it as an exception for client-based constraints. So if Alice visits that pod but she didn't authorize that data browser to access resources on her behalf, the access would still be granted based on that exception on the pod providing that data browser app.
• Since Alice hasn't authorize that data browser to access resources on her behalf, that data browser would be limited to only access resource on the pod that serves her and handles that data browser as an exception in authorization system. That data browser should (must?) not ask Alice to be authorized to access resources on other storages, since that would lead to an antipatern and result in mentioned security nightmare.

[josephguillaume]

Sorry, I mixed three things in my comment: 1) providing an answer about what generic functionality do current browser apps provide, 2) describing some of their existing implementation, 3) speculating about how it might connect with SAI.

• if Alice visits that pod but she didn't authorize that data browser to access resources on her behalf, the access would still be granted based on that exception on the pod providing that data browser app.

I agree we can't just trust all data browser apps, as also noted above. I think we need to distinguish between Alice visiting Alice's storage's browser app vs Bob's storage's browser app. In the former, the browser app can safely operate as a launcher app (or might already be the AA), but in the latter, Bob's storage's browser app should be treated as just another app.

• That data browser should (must?) not ask Alice to be authorized to access resources on other storages

This would hobble the data browser - the whole point is that it is a browser for the web, including resources on other pods. If Alice's storage's data browser is also a launcher app then it absolutely does need access to everything Alice has access to, including on other storages.

It sounds like the browser app should indeed not be "trusted", but rather it needs a specific access grant that covers everything on Alice's storage + any access grants from Bob's storage's and elsewhere?

[josephguillaume]

This train of thought surprisingly also suggests that in contrast to bblfish's launcher app concept, this type of launcher functionality might have at least two different implementation paths, at least one of which would need to be spec-ed to allow apps to be able to follow their nose to unsupported URIs:

1) Alice MUST have a launcher app that has the ability to dereference arbitrary URIs. This could be the AA but could also be something like a data browser. An application discovers the user's launcher app in order to handle unsupported URIs.

2) Resources on Solid storages MUST offer a default view for the user. If Alice follows her nose in an application to an unsupported uri on Bob's storage that she has access to, we definitely don't want to just show 401 error, but if Bob's storage's data browser is authorised by Alice then this solution already meets requirements for transitioning out of one application into another.

The way I've described this could probably be clearer but hopefully a starting point for further discussion.

[elf-pavlik]

Resources on Solid storages MUST offer a default view for the user. If Alice follows her nose in an application to an unsupported uri on Bob's storage that she has access to, we definitely don't want to just show 401 error, but if Bob's storage's data browser is authorised by Alice then this solution already meets requirements for transitioning out of one application into another.

I disagree with this requirement. If Alice follows her nose from a Solid app, that app will hand it off to AA if it can't open resources of that type. If Alice follows her nose from non-Solid app, there are a few options; one would be to use AA via Web Share Target as I showcase in this video, even that here it specifically does it to accept an invitation: https://www.youtube.com/watch?v=dH4BAOmjCAs&list=PLXBho_YohPB09B_ecOsABoI8Dc67v1H4O&index=3

Finally, when Alice ends up navigating her browser directly to a protected resource, I think 401 is acceptable. But there could also be a minimal login, e.g., via FedCM, which requires zero input. That minimal app would just discover the authorization agent from the user's WebID and hand it off to the user's AA, so it wouldn't need to display any data generically.

[josephguillaume]

Thanks for the reaction and suggestions. While I think there are still implications for pod browser apps, this seems to have opened up a broader topic, so I've taken the liberty of opening a new issue https://github.com/solid/data-interoperability-panel/issues/325

I agree that the "default view" for a resource could indeed be a minimal login - the key point is that a spec could require more than just 401, and the result could be something very similar in behaviour to the existing "data browser hack".