initial WebID Document considerations

biblio.json

@@ -26,5 +26,15 @@
         ],
         "href": "https://solidos.solidcommunity.net/",
         "title": "SolidOS"
+    },
+    "WebID": {
+        "authors": [
+            "Andrei Sambra",
+            "Henry Story",
+            "Tim Berners-Lee"
+        ],
+        "href": "https://www.w3.org/2005/Incubator/webid/spec/identity/",
+        "title": "WebID 1.0",
+        "publisher": "WebID Incubator Group"
     }
 }

index.bs

@@ -118,3 +118,41 @@ The attacker writes a malicious `text/html` file to the server. Depending on the
 #### Considerations
 
 Servers are strongly encouraged to consider the countermeasures in the context of the use cases they want to enable or disable on a given storage. For instance, using `Content-Security-Policy: sandbox` will universally prohibit various functionalities for applications, including but not limited to accessing local storage, executing scripts, using forms, interacting with plugins, or including external content. This broad range of restrictions may not be desirable for various categories of applications that rely on client-side storage mechanisms, collaborative features, or dynamic content interaction.
+
+## Protecting WebID Document ## {#protecting-webid-document}
+
+Solid access policy enforcement relies heavily on the identities of agents. Requesting Parties are identified
+by [[WebID]] and applications by ClientID [[Solid.OIDC]].
+A User's WebID Document includes trust anchors, like designation of their [[Solid.OIDC]] Provider (also known as _issuer_).
+In other approaches, public keys could be published or discoverable via the user's WebID Document.
+
+### Fully impersonate the user
+
+If a malicious app can write or append to the user's WebID Document,
+it could inject trust anchors, allowing complete impersonation.
+
+#### Exploit Prerequisites
+
+* Solid's authorization system depends on a specific trust anchor in the user's WebID Document.
+    For example, [[Solid.OIDC]] issuer designation or pubic keys/keyset.
+* User authorizes a malicious Solid application to write or append to their WebID Document.
+
+#### Attack
+
+* The attacker publishes an attractive malicious application, such as one that generates cool AI avatars and setting them in the user's profile.
+* User authenticates with the malicious application.
+  * If the access control system enforces client constraints, the user also authorizes the application to write or append to their WebID Document.
+* Application injects attacker's trust anchor into the user's WebID Document.
+* The attacker can now completely impersonate the user, with full access to all the data owned by the user,
+    as well as access to any data shared with that user by others, to the full extent they granted to the impersonated user.
+
+### Countermeasures
+
+* There is no requirement to expose WebID Document via [[Solid.Protocol]] nor to host it in Solid Storage.
+    Service providers who offer hosting of WebID Documents can minimally support 
+    a set of discovery features that rely on the WebID document and provide a
+    highly secured interface to change it, possibly requiring two-factor authentication.
+
+#### Considerations
+Users need a way to manage their social profiles, approaches like linking from the user's WebID Document to
+less protected vcard are available to accomplish it without opening discussed attack vectors.