Story

Solid and authentic sources

Introduction.

Governments, companies, organizations or even other individuals can be authentic source of a certain individuals' information.

For example, a government is the Authentic source of my official residence address.
A company can have some official contract details about me. 
My local club will be the authentic source to validate if I am a member of that club.
And maybe a person wrote a review about another person.

This data is most often stored somewhere under the control of that person or organisation.

An authentic source in the context we talk about here, is seen as the place where the data is managed: a database.
An authentic source is also often seen as the "single source of truth".

Usually, the data there is considered up to date. Parties will, if possible, consult the authentic source to validate this data.


This seems to be in conflict with the ideas of Solid, where the data subject should have data-access control of his or her data. 

And legally, as a person, I have a right of access to most of this information concerning myself (leaving aside legal research, private assessment reports and other exceptions).

As an individual, I also have the right to share this personal information with third parties.

We know that data in a Solid pod is mutable : A person can change, edit and delete his personal data. This means you are allowed to lie as well.
But we don't automatically have the right to edit the Authentic source's data. And we shouldn't. Data in our pods can and will differ from the authentic data.


Sometimes, if you are sharing data, you do need to be able to verify if the data is authentic.

Third parties cannot always access the authentic source, or there is no way for myself as an individual to give them my consent (automated or delegated or otherwise).

One of Solid's strengths is precisely bringing together different personal data (from one person), so the data can be reused and new insights and services can be generated.

 
How can we have good data access control when dealing with authentic data sources?


We will describe a few scenario's, so we can have the best of both worlds.


Scenario 1. A copy


You (authentic source) allow the person to put a copy in their own data vault, and it is the person's own responsibility to do what they want with it.

This does not provide sufficient guarantees that the information shared is correct, and additional guarantees should be provided to the person requesting the information. The problem is solved by:

a)   Delivering a verifiable credential :

This can be done using blockchain, by the  W3C verifiable credential model , or by another form of digital signature. This can also include a time-stamp, or an expiry date. This solution is similar to an IDcard or a passport: A verifiable document that shows who you are, and what is on it is accepted as correct, and considered invalid when tampered with.  

This means that you can now share both the data as the credential (if needed), and keep your pod updated once in while (if your credential is about to expire). 

b)   Additional validation at the original source :

In this case, the person needing the validation will need to request the information at the authentic source. 
It may be the case that the person still needs your permission, and you then are asked to give a permit (again, a verifiable permit!) to them, so they can complete their request. 

Making a copy creates uncertainty, thus the need for extra validation or credentials

Scenario 2. Authentic source with Access control


In this case, you don't put a copy on your local pod, but you will get the permission from the authentic source to share access to the source to third parties.
The original source remains the (preferably?) only point of contact.

This could be done in the same way as Scenario 1.b,
or

b)   The original Data Source gets a solid compatible layer, where the Data Subject can modify the read access rights (of its data).
In other words, the Data Subject gets access control from the original Data Source, and may modify the ACL (access control list) by adding and removing new Web IDs. These Web IDs are then given access to the data-subject's information contained on the original data source.

This scenario is more or less making a Solid pod from the authentic source. 

Giving the data subject access control permissions is like treating the authentic source as a Solid pod


Questions, feedback or suggestions?

Yes, I want to speak with the author(s)...

More about the author(s)

Christophe Cop

Christophe Cop

Christophe is a data-scientist with a background in psychology and statistics. He has been an enthusiast of personal data control ever since GDPR came into effect. Co-founder of Konsolidate and SOLID Project Lead