Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing app authorization step, in suggested discovery via pim:storage #51

Open
elf-pavlik opened this issue Sep 22, 2022 · 1 comment

Comments

@elf-pavlik
Copy link
Member

elf-pavlik commented Sep 22, 2022

The current, draft, assuming #46, will include:

The pim:storage predicate is used to indicate where
a WebID owner stores their data. An app wanting to access the
WebID owner's Pod should find its location using the
pim:storage predicate.

This suggested path of discovery is missing the step where the user authorizes the app to access (or even discover the existence) any data.

Solid Application Interoprability doesn't even use pim:storage.

  • User's Authorization Agent uses interop:hasRegistrySet which only AA can access
  • Any other app uses interop:hasAuthorizationAgent to discover where they get authorization from the user to add or even discover anything. Once authorized the app gets a dedicated entry point that allows it to discover all the data it was authorized to access.
@jeff-zucker
Copy link
Member

You're right that the passage you quoted should say "attempt to find its location" and should mention that there are valid reasons why a given user or a given app may not have access to that information about a user's storage(s).

The authorization of apps is out of scope for this specification. We will not cover trustedApps, the Inrupt client registration process, or the interoperability spec. There will be a consideration section mentioning some of the issues.

It is not relevant here that the interoperability spec doesn't use pim:storage. That spec is orthogonal to this one. If you find things we say that would prevent anyone from conforming to the interoperability spec, please bring them up as that is not our intention. That is not the case here. If some apps follow this spec and use pim:storage, that doesn't prevent any other app from following the interoperability spec and ignoring pim:storage.

The fact that the interoperability spec presents a robust system for authorization suitable for banking and medical apps does not negate the need to a) support existing apps and libraries and b) provide a simple method for apps not needing the level of security that the interoperability spec deals with.

If you are concerned about the security of the pim:storage predicate, you might ask the server providers why they expose the location of a user's storage without the user's permission. If you have any thoughts on how to prevent that, please suggest them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants