Open Mitzi-Laszlo opened 5 years ago
kjetilk
commented
5 years ago Hmmmm, not quite sure about what this would entail in terms of the spec, as we have group listings, and to me, it seems like each of these are group listings, and that the group listings are those explicit lists of employee's WebID.
pmcb55
commented
5 years ago I think it helps to think of any single interaction (e.g. between a employer and an employee, or between an NGO and a refugee) as inherently populating two Pods. So when you ask 'Where is the tax information to be able to pay a salary?', I think the answer is that it's in the employee's Pod (naturally enough!), but there is also a copy of that data in the employer's Pod - i.e. the single interaction event of that employee formally starting to work for that employer resulted in that individual's tax info also being recorded in the employer's Pod. And obviously, only company employees belonging to the 'HR' group would have access to that part of the employer's Pod that holds individuals' tax info.
So to answer your question of 'when does it make sense for the data to sit in the company Pod rather than the personal Pod of the employee?', the answer is simply that the data will always sit in the personal Pod of the employee (since it will always be their data), but a copy of some of that data can also sit in the company Pod too if the individual consented to that (which we assume they did when signing their employment contract!), and the company needs that data to perform a company function (like paying a salary).
Mitzi-Laszlo
commented
5 years ago @pmcb55 how do you define an interaction?
"the data will always sit in the personal Pod of the employee (since it will always be their data) but a copy of some of that data can also sit in the company Pod too if the individual consented to that (which we assume they did when signing their employment contract!), and the company needs that data to perform a company function (like paying a salary)."
Under this assessment you are presuming that an individual can only act on behalf of themselves and not on behalf of a company which is not representative of our legal structures. Just because the employee generates the data does not mean they are acting in their personal capacity, they could be acting as a representative of the company.
As a company I would be pretty uncomfortable having company data stored as if it were personal data in employee Pods controlled by employees that I could not control.
As a data subject, I would be uncomfortable if my Pod were controlled by my employer without being able to move my Pod. What if, as an employee, I wanted to store my personal data generated during work hours elsewhere? Would the company be able to override that?
Perhaps we should use the GDPR definition of personal data which can be found in Article 4 (1) https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679
" ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;"
So, for example, if I write a document for the company I work for that does not state my identity or an indication of my identity, it would not be personal data and therefore not sit in my Pod. Rather, the data would sit in the Pod of the company I work for.
RubenVerborgh
commented
5 years ago However, the scenario of a Pod being controlled by multiple data subjects is not as clearly defined by the Solid spec.
The spec will very likely never define this.
The job of the technical spec is to explain how servers communicate with apps. Just like how the job of the HTTP spec is to explain that from servers to Web browsers.
Now there is important advice to be given here, definitely, but that advice is not protocol-technical in nature (and that is the topic covered by the technical spec).
When a single individual (data subject) controls a Pod for their personal data the Solid spec is clear.
However, the scenario of a Pod being controlled by multiple data subjects is not as clearly defined by the Solid spec.
In the case that a Pod is for a legal person, for example, a company, when does it make sense for the data to sit in the company Pod rather than the personal Pod of the employee? Employment data, such as messages and documents are company data. Therefore, it could make sense to explicitly state that the WebID of the employees of a company are used to give access control of the company Pod. The only time when personal data of a data subject is needed by a company Pod is for the employment agreement. Data needed in this transaction includes:
It would be helpful to include a more explicit description of how to have multiple WebIDs associated to a Pod who each have difference access control of that Pod.
There are fairly standard relationships between data subjects and companies such as:
The same logic could apply to the Pod of a public institutions.