You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
The current, draft, assuming #46, will include:
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
.interop:hasRegistrySet
which only AA can accessinterop: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.The text was updated successfully, but these errors were encountered: