Connect to GDPR terminology

[Mitzi-Laszlo]

Considering that GDPR is a key text in data protection it would be useful to connect the Solid specification terminology to the General Data Protection Regulation terminology as defined by Article 4. Including the terminology explicitly will facilitate the guidelines applied for fair data usages.

The key terms include =

WebID = data subject identifier
Pod Provider = data controller (although the data subject has the last word)
Solid App = data processor

[megoth]

Any suggestion on how this could be inserted into the specification? Perhaps as an appendix, or should it be more integrated into the specification itself?

[RubenVerborgh]

Not in spec; the spec is a technical matter.

We can/should definitely document elsewhere though.

[Mitzi-Laszlo]

How about we try plotting the options and considerations to get multiple perspectives, feel free to add to this liberally.

Route Forward	Pros to Consider	Cons to Consider
Include an appendix explaining how the Solid spec terminology links to GDPR terminology	1. keeps the Solid spec purely technical	1. gives the impression that personal data control is an afterthought (few people read appendices)
Include a diagram at the start of the Solid spec explaining the players and how the interact followed by a short paragraph explaining how the Solid spec terminology links to GDPR terminology	1. introduces personal data control as a core value from the get go rather than an afterthought 2. shows a sign that bridging to GDPR is considered important 3. connects engineers to lawyers who work towards a common goal	(suggest cons)

[RubenVerborgh]

Cons:

• GDPR is not universal law, so text will not be meaningful to non-EU citizens
• GDPR and law can evolve; the technical spec should not
• We would be introducing a substantial dependency in a technical specification (not something desirable in general) to a legal document (even less desirable, because then the audience becomes restricted to intersection of tech+law)

There is also no precedent to such a move.

So I very strongly object; GDPR is not a technical matter and does not belong in the technical spec.

Happy to think about a separate note (with a EU focus) that ties the technical spec to GDPR.

gives the impression that personal data control is an afterthought

Not necessarily, this can be the motivating section of the spec, without a GDPR mention.

introduces personal data control as a core value from the get go rather than an afterthought

We can still do this.

shows a sign that bridging to GDPR is considered important

We probably should not do this (it's a political statement)

3. connects engineers to lawyers who work towards a common goal

A separate note could do that. On that topic, I have this one forthcoming actually:

Verborgh R., Wrigley S. & Ballardini R.M., "Decentralizing the Web and the Industrial Internet: an Alternative Solution to Data Control" in Ballardini, R.M., Pitkänen, O. & Kuoppamäki, P., Regulating Industrial Internet through IPR, Data Protection and Competition Law, Kluwer Law Int. (Accepted; Forthcoming in 2019)

[RubenVerborgh]

Another important objection:

Solid can be used to address GDPR. But the Web can also be used to address GDPR.
That does not mean that any Solid solution is automatically GDPR-compliant. This is very new and uncertain legal territory; it is doubtful that we can make any meaningful GDPR claims about Solid in general (only for specific cases).