But now we have a similar situation with “remote services”, that is, applications running on servers that login as users. How do I grant such services access to my data?
Yes, the server-side apps can use some credentials to sign in as normal WebID users … but I do not want to hand over my login credentials to some random server on the web. And even if I did it could easily spoof the “Origin” header in any way it wanted (unlike apps running inside the browser), making it impossible to restrict its access to parts of my data.
That problem is normaly solved using good old OAuth2 where I grant access to the (server-side) application using the Authorization Code grant with a couple of redirects.
So there is actually a (future idea) way to protect against mailicious web apps, by including the value of the “Origin” header in the access control list.
No, that is how it works now. NOW, webapps are blocked by default.
No you never do that. The remote service has it own secret key/password you never get to see. it logs in with ITS credentials. It has webid. You only give it the read/write/append access you want to explicitly give it, using the ACL system as it stands right now.
It is really important to distinguish the different cases. The origin header is only used with web apps. Web apps are not trusted. Now. In Solid. right now. The browser always restricts the script as to what it can do, and alerts the server. For a web app, the browser forces the origin header, and the app can’t turn it off. For any other case it is unused and irrelevant. You wouldn’t bother spoofing it, you would remove it, and then be a trusted app.
Yes, that is typical in a lot of systems. We could add this workflow. We would have to design it so that the remote service has a webid, as we would need to put that into the ACL system to grant it access to things.
(Down the road, it may be used to have a form of profile for an app, logging in as an agent, where it can declare itself as a (say) corporate agent rather than a human agent. (It could also down the road put digitally signed certificates that he service has been vetted as being benevolent, and thing like that.))
FYI this has sparked a parallel discussion on the SAFE Network forum where we have the similar concerns about privacy and security, while enabling the switch to user ownership of data, and allowing apps access on a permissive basis.
However, it lead me to see how much better the situation would be, both in security and user experience, if we could allow apps free reign to access our data, but have the ability to monitor and control where they are able to send it (other than writing to our own user storage).
I’m not sure if that’s feasible, but if it is I think we could fully realise the vision of users owning their data, and App developers competing on the basis of features and functionality, instead of on the ability to manipulate users and exploit our data. More in this post.
we’re working on mechanisms/models that enriches this approach.
So, how and by whom is this being addressed? Is there a working group? Should there be one? I’d like to follow the progress, and perhaps contribute. I would certainly like to contribute my use cases outlined above. I find it helps to have a consistent set of examples to center discussion around, in order to save time, and ensure everyone is on the same page.
We are working on the process of how we should be public about our work and how to let the community contribute to work on cases like this. We should have something ready soon.
I’ll note the new thread you’ve created, and try to link to whatever public resource we make available as soon as it is matured to that point. Hopefully it’s not long until we can do that.
Thanks for the clarification. I can see that my test web-app is incapable of reading my private data (the inbox) unless I (1) give access to “everyone” - or (2) retry the same request outside the webbrowser without the Origin header. My assumptions so far was obviously wrong and only tested in the public part of my data (which anyone can read anyway).
The next problem is more of usability of the databrowser (which has one of the most obscure interfaces I have seen so far): how do I grant access to a web-app (adding my test web-app’s Origin value)? I can drag that globe to the intended access panel (how do you expect users to figure out that?) - but where is the “Enter WebID here” kind of input for granting access? Maybe I am just supposed to enter the ACL tripplets myself at this point?
This is where the OAuth2 kind-of mechanism comes in - it would be very useful to let the web-app ask permissions for a specific folder through something like OAuth2.
If you run a web app in a web page, the browser does severely limit its access to anything on the web […]. In solid, if you try to get at data from a web app, then the web app AND you must BOTH have the access required in the Access control system. You do this with the ACL by making an Authorization which has an origin property.
But if I’m logged in to Solid Chess then that chess app has unrestricted read/write/delete access to all data on my pod, right? Isn’t that very dangerous?
The App by its very nature is operating on your behalf i.e., your credentials are used to authenticate read-write operations to your pod.
The cool thing here is that your profile doc (not the apps) controls read-write operations. Thus, you are always the one writing to your pod, when you login under your WebID. Naturally, others can only write to your pod if you expressly grant access to their WebIDs via an ACL.
For the chess app, each player writes to their own pod using their respective credentials.
{webid}:Origin == writesTo ==> Pod, subject to ACLs (that include an acl:origin relation) set on Pod.
Is there a way to login with WebID in an app and give it reduced access as default?
Right now, if I were to log in using WebID on a webapp, I would not be able to stop malicious applications (or hacked applications) from cryptolocking all my data. OR deleting everything.
Reduced defaults would shield the user from malicious applications, or apps that leave litter around the filesystem, or even bugs of the “I’m writing over existing files” type.
I’m not saying that I destroyed my card while building a prototype, but I’m also not not saying that.
With NSS 5 you have to grant explicit permission to each origin in the ACL files, otherwise the apps cannot change / access any private data even if you are logged in.
Is there any documentation or example for Origin-based ACLs in NSS5? (edit: beyond “Web Access Control spec” above)
Also, are solid.community and inrupt.net running NSS5?
@timbl linked to the Web Access Control spec in his first reply of this topic (first link) … (see “Referring to Origins, i.e. Web Apps” from the Table of Contents)
