Protecting the WebID document

[jeff-zucker]

Protecting the WebID document

The problem

A bad-actor app operated by you could erase or change the solid:oidcIssuer in your WebID document, thereby denying you access to your pod and possibly impersonating you on other pods. For example, a photo management app might surreptitiously alter your WebID document.

Who needs to care

People who use Solid to access sensitive data.

Who can get by ignoring this issue for now

If you just have an experimental pod (all pods on solidcommunity.net are experimental) you should not be accessing sensitive data and therefore the worst that would happen is you'd have to reopen your account and possibly replace data.

The best solutions

1. Servers should prevent modification of protected triples. This is what the Solid WebID Profile Draft Spec recommends. Unfortunately, currently few, if any, servers do this. Action item : server implementers and pod providers, get working on this!
2. Solid should have app-level consent. When this is available, you will be able to restrict access to the WebID document to apps you trust. Unfortunately, we don't have this available now. Action item : spec writers, get working on this!

Simple workarounds to protect your solid:oidcIssuer until the best solutions are available

1. create a social profile - everything in your current profile except triples you want to protect like solid:oidcIssuer
2. create a WebID document containing only triples you want to protect and a triple using rdf:seeAlso to point to the social profile
3. place the social profile in your pod
4. Do one of these two things to protect the WebID document

Protection method (4a) - put it on a server that doesn't serve Solid

4a1. Put the WebID document on a web server that doesn't serve Solid
4a2. In your pod's profile at .e.g /profile/card, use a 303 redirect to point to the WebID document

Protection method (4b) - use two WebIDs

4b1. Get two WebIds - which we'll call me-owner and me-user
4b2. Set up a pod using the me-owner WebID
4b3. Put your WebID document at the profile location for your pod e.g. /profile/card
4b4. Permission the WebID document (and any other documents you want to protect) to be writable only by me-owner
4b5. Give permission to everything else on your pod to me-user
4b6. Only use trusted apps like SolidOS or Penny or Solid File Client with your me-owner WebID
4b7. Use any app with your me-user WebID, the app will not have write access to your WebID document even though you are operating it

Problems with the workarounds

The Solid WebID Profile Draft Spec has this advisory : "To promote self-describing resources and efficient discovery and reuse of profile information, implementations and authors are encouraged to prioritize using the Solid WebID Profile before resorting to an Extended WebID Profile." The workarounds break this important principle. By putting all of the social information in a separate document, we have forced users to follow seeAlso and therefore a) the WebID document is not self-describing and b) There will be at least an extra hop for every retrieval of the social information. The self-describing issue is really at the heart of Solid - a URL represents a thing and should describe that thing. Our WebID URL should describe us, not point to some other document that describes us except for peripheral information.

So, while writing to the main WebID document rather than to an extended seeAlso document is a short-term problem now, it will eventually be the desired solution. To accomodate this, any app that wants to read or write to the profile should first attempt to read/write to the WebID document, and only read/write on an extended seeAlso document if they can't do so at the main WebID document. This approach will work in the short-term when we depend on the separation of the WebID/social profiles AND it will work in the future when servers and permissions handle the issue and we can again have a single main profile document that has both the WebID information and the social profile.

Note: there are other reasons we might want to write to a seeAlso extended document rather than to the main WebID document, for example, triples that should be restricted to users with permissions. So the rule should be - unless there is a reason for creating an extended seeAlso document, write (or attempt to write) to the main WebID document and only fall back to the seeAlso if you can't write to the main.

(cc) Jeff Zucker, January 2026

[csarven]

I think this is a well-reasoned and thoughtful analysis. Thanks for putting it together.