elf-pavlik
commented
1 year ago Great points @woutermont !
I will work on https://github.com/solid/data-interoperability-panel/issues/302 as part of my current project with NLnet. This will update the work in the invitation draft to take advantage of pre-established channels when creating social agent registration for peers in one's social graph.
Regarding applications, in sai-js I'm currently adding displayable app info to application registration at the step of creating it. We probably want to add something about it to the spec.
There is also https://github.com/solid/solid-oidc/issues/207 which could take advantage of OIDC Federation. Possibly equivalents of app stores could act as federations, users would trust given federations and apps would undergo a process of joining those federations.
I think this is very much related to my comment https://github.com/solid/process/pull/323#issuecomment-1627258396 we need a social strategy for trusted WebID Providers, Storage Providers, OIDC Providers, App stores/federations, ShapeTree directories etc. Each and every of those plays a certain role in the overall security of the ecosystem and requires some trust management.
Thinking about interactions with Authorization Servers, I stumbled upon the following.
When granting permissions to an agent, a Resource Owner does so based on derived information like a name and description, rather than on the agent's WebID. This seems to enabled a number of imposter scenario's, in which the RO is mislead into granting permissions to another agent than they mean to.
Case A1: A malicious app imposes as another app the RO wants to use, by copying its name and description, and they mistakenly install the wrong one and give it permissions.
Nothing new here, I think; just like pre-Solid, we expect people to only install apps from trusted sources. When the user realizes their mistake, they can revoke the permissions.
Case A2: Similar to A1, but after having been granted the permissions, the malicious app changes its name and description in its WebID to something vague and inconspicuous. If the Authorization Server/Agent rely on the latest data of the WebID, the user will no longer find the app by name when they want to revoke its access, and will have a hard time spotting its new disguise.
Can we do something about this? Should the AS keep the initial info of each agent? Should it warn the user when an app's WebID has changed?
Case B: An RO granted a malicious but usefull app access to some contact data, in order to display a friends list with the option to share something with them. When the user clicks on a share button and selects a friend, however, the app copies the friend info to a spoof WebID, and asks the AS to give it permissions. Seeing the correct info displayed, the user might grant the wrong WebID permissions, which will even remain granted when those of the app itself get revoked.
This is the one that triggered me to create this issue, as it is i.m.o. a very serious one; claiming that this is still a case where the user simply trusted the wrong app seems too stern. The only way I currently see to prevent this, is to have the AS itself manage the user's contacts, and only let the user add contacts based on out-of-band info (a link/id/qr given by the friend themselves).
Eager to hear other thoughts!