Imposing as a (social) agent

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!

No file, test, or implementation entry point is named. Start by reading the issue's Case A1, A2, and B scenarios and the repository's Solid interoperability specification context. A complete outcome would need an agreed approach for identifying agents and handling changed or spoofed WebIDs, but the issue does not define one.