I’ve been reading about Solid and if I’m not wrong, you use your Solid POD to say who you are. My question then is how do you make sure the person accessing the Solid POD itself is it’s true owner? Sorry if my question is dumb/unclear.
Could you clarify that you mean with this? Do you mean the person who made the POD or the one who is hosting it?
So my understanding of Solid goes like this:
The POD’s owner aka person who made the POD owns all data stored in it, while the host is providing the server to host the POD, but has no access to the data in it. The POD’s owner uses his POD as identification, instead of traditional usernames/passwords.
My question is how would one “log in” to their PODs? Assuming it’s a username/password system, where would the usernames/passwords be stored? If it’s stored on a central server isn’t that counterproductive? Or is my understanding of Solid flawed?
Thanks in advance 
At the moment I think you have two options either via user/pass or WebID-TLS.
They are stored on the Solid Server instance. That instance can be either hosted by you or a third party.
Counterproductive to what? There is a difference here between having access to your data, the way authenticate with your POD, where your credentials are stored, and where the data is stored. All of this things are configurable in my opinion.
Note that my understanding of authentication is rather limited, so I hope someone else can elaborate more 
2 Likes
When you authenticate, you end up, after signing in, with a proof of ownership for a specific WebID - a URL that indicates who you “are”. The WebID is managed by your chosen WebID provider - your “Identity Provider”.
When you access a POD’s data, you send your authenticated credentials with each request, proving that you are WebID “X”.
The POD server then verifies that WebID “X” has access to the data you request. This authorization is controlled by the access control lists on the POD server.
The WebID can be any WebID and the POD can be any POD - hosted on different servers by different providers.
But when you sign up for a WebID on a Solid server, you also get a POD on that server. The default access control list for the POD includes your new WebID, such that you automatically is granted access to your own POD. Thus the Solid server acts as both an identity provider and a POD server.
So both your identity management (WebID) as well as data management (POD) is de-centralized and you are free to choose your own providers.
3 Likes
You can see at https://solid.community/register that there is an option (at the bottom) to register the WebID your want to associate with your POD when signing up for one (I haven’t tried it though).
Thank you for the details on authentication and authorisation.
What seems still open from the OP and I would like to hear that too is if it’s possible for the data storage host not to access the POD? I guess not yet easily.
What I read is that the POD host can always read the data as it’s unencrypted. Signing will at least prevent tempering and should be easy to implement but checks will have to be in the app. Encryption will prevent unauthorised reading. Storing and accessing the keys for signing and encryption separately has the advantage that they are very little data in comparison to the POD itself. Decoupling these is an advantage that Solid gives.
I am guessing signing and encryption on Solid is not really implemented but technologies exist already. Showing an example on Solid will be a very nice to have.
Data is not encrypted on the server. The client (typically a web browser) does not encrypt anything before sending it to the Solid server.
So if PODs are hosted “en masse” with a central POD provider, equivalent to Google e-mail hosting, you have not gained much in terms of security by using PODs.
But what you can do with a POD, which is not possible with for instance Facebook, Twitter or the likes, is that you can host your POD on a server under your own control and still be able to use the same applications as if you chose a big shared POD host. This is similar to moving your e-mail off from gmail and onto your own hosted server. The e-mails do not get encrypted by that move, but now you have control of what the content is used for.
1 Like
But should we push clients then to encrypt the data?
1 Like
Probably not. It will prohibit the server from being able to work with the RDF data - like for instance doing “Globbing” or SPARQL searches.
But nothing stops you from encrypting images, office documents and so on before storing them. Unless of course the Solid server at some future time starts to offer text indexing and searching of your documents … which it won’t be able to do with encrypted data.
Is it even possible to do client side encryption with JavaScript in the browser?
@hiraeth, back to this topic's still to some extent unanswered initial post, you use one or more instances of a Solid PODS to setup a (WebID) profile, colloquially called pod—in your wording—saying (to applications you authorized) who you are. You may be known (authorized) to those instances as their owner, but you have not to be. Insofar as apparent, an instance has got one and only one owner by design. In fact, you can ‘host yourself’ on instances of PODS to which you are authorized as their owner, just as you like. Take note of the fact that hosting your pods outside of the PODS instances you own is not a design goal. In fact, it runs counter to the main goal of the design, the web decentralization, which unites hopefully all of us for good reasons.
At least with Node Solid Server (NSS) 4.2.0-rc.0, cf. /Symptom: Access to Main (“index”) Page Denied for Owner's WebID When Setting Up a Solid Server on a Windows Machine, as such a PODS, there is a dedicated built-in authentication mechanism in each PODS instance intended to make sure that (at least) their owners (owner's WebIDs) are accessed (authorized) as such. Both hosted users' and owners' authentication make use of Web Access Control (WAC). In a sense,—in your wording—the owner owns all data stored in a PODS he owns, since authorized applications can access (WebID) profiles (—insofar as currently apparent—solely) based on WAC setup, which the owner can change just as he likes.
Both hosted users and owners retain complete ownership and control of data in the (instances of) PODS: what data each pod contains, where each pod is stored, and which applications have permission to use the data. Different pods might contain distributed personal information, such as personal profile data, contact information, financial information, health, travel plans, or other information. Both hosted users and owners could then join authenticated social-networking applications by giving them permission to access appropriate information in specific pods on specific PODS instances, cf. Design of Solid (web decentralization project).
1 Like
Cit. @hiraeth in this topic on this forum.
From the users' viewpoint, PODS is indeed—in your wording—a username/password system, since both hosted users and owners do access it via username and password, though not so do authorized applications. Usernames and corresponding (hashed) passwords are stored where they belong—in the one and the only one appropriate PODS instance. There is no central server by design there.
The aforementioned dedicated built-in authentication mechanism on principle could additionally be involved in accessing all data stored in a PODS instance to make sure that all users' data (user's WebID profiles) get authorized access. However, the implementation of this—insofar as apparent—currently is undocumented and at least testing the installation of Node Solid Server (NSS) 4.2.0-rc.0 as a PODS instance fails locally yet, cf. Fig.0b presented on an intermittently with intermediate interruptions, as a general rule between 20:00 and 07:00 GMT/UTC o'clock, and temporarily operated web server. Additionally, there is a currently unresolved symptom, which hedges about the scope of the aforementioned built-in authentication mechanism.
Take note of the fact that references (links) to the temporarily operated web server still may shift over time.
Currently there are ten topics on this forum, including this one of yours—though you have not broached the issue of possible pods encryption—, coping or to some extent coping with that issue.
In fact, possible pods encryption has nothing to do with user authentication and hence should not be coped with within this topic currently going by the name of Basic question about authentication.
However, should you be bent on this additional discourse and should the numerous topics on this forum be insufficient, I propose to rename this topic accordingly and start your extended discourse.