Host my own pod server but use external authentication provider


I took a look at the Solid Community Server recently: GitHub - solid/community-server: Community Solid Server: an open and modular implementation of the Solid specifications. Looks like with this server I can create a new Pod and use different authentication providers. Originally I thought I have to host both my Pod and authentication provider on the same server but now looks like it’s not the only option and actually they can run on different servers. But my question is where my ACL lives in this case, is it on my Pod or on the authentication provider? Also many authentication providers also create a Pod for a specific WebID by default, if I create a new Pod on a different server with the same WebID, does that mean I can create as many Pods as I want using one WebID?


An Access Control List typically lives on the same server that hosts the resource it applies to (so that would be “on your Pod” - though once you start using separate resource servers and authentication providers, the concept of a Pod starts to become somewhat fuzzy).

If you have full control over a Pod, you can give another WebID equal access to everything in that Pod. So in that sense one WebID can have many Pods. However, keep in mind that while your WebID can point to multiple Pods, at this point in time that is not very common, so most Solid apps will just store the data they generate on an arbitrary one of them.


My understanding is that identity providers and pod providers are loosely coupled by design and that access to resources has to do with the identity in the access control of the resource, not on which pod the resource is located on. This means that all Solid Servers behave the way CSS does - you can get your identity one place and access a pod in another using that identity.

As @Vincent points out, there is currently no standard method to suss out which pod a user wants which piece of data stored on. People are working on ways to make such discovery easier, perhaps by using an owl:sameAs relationship for pim:storage. I believe this is being discussed in the interoperability panel so if it’s of interest, that would be the place to check.

1 Like