How’s it going with Solid? Well, let me give you an update in less than five minutes.
As you know, Solid is a standard for online accounts and data sharing.
Solid accounts are special, because they allow people to access and share their data regardless of where this data is stored.
With use.id, we already did over 25 real-world projects involving such Solid accounts.
We used the requirements of these projects to advance the Solid specification.
Even though these advancements are yet to be approved by the W3C, I’m happy to our vision on the Solid specification.
Let me first start by saying what we mean by “people can access and share data regardless of where it is stored”.
Well, data about people is stored everywhere.
For example, your insurance provider stores data about you, your hospital stores data about you and you probably also store some of your documents in your Dropbox.
Most of these data is accessible via APIs, but, these APIs always look a bit different.
When these APIs all follow the Solid rules, they can be connected to one or multiple of your accounts.
Once connected, you can login to an app and give this app access to the data you want.
For example, here you can see that John has logged in to a certain app and granted this app access to his data.
John can now use this app to access his data regardless of where this data is stored.
But, how does this work?
I’ll give you a very short technical overview.
First of all, apps and people are identified using global identifiers in the form of an URI.
In this example, you can see that the app’s identifier is webid.health.app and John’s identifier is health.id/john
You also need to know that people can log on to apps using their identifier.
While they log in, they can also decide to give the app access to some of the data that is connected to their account.
Logging in and sharing access works via a journey that follows a dialect of OpenID connect.
Once logged in, the app receives a token containing the identifier of the person, the identifier of the app and the identifier of the login method.
Of course, apps, or better, machines, can also login and once they do, they get a token a different kind of token, one without the identifier of a person.
Let us now take a look at what such a Solid API actually is…
First of all, a Solid API, or at least, the one that we’re proposing to the W3C, must be structured around three concepts: data types, data subjects and data resources.
Each of those concepts must be identified using a globally unique identifier. This identifier, can of course, be a URI.
An example of a data type is dbpedia.com/types/patient
An example of a subject is health.id/john
And an example of a resource is /patient/123.
And an example of a resource is /patient/123.
Every resource must be connected to a type and a subject.
Here, you can see that the resource is an instance of the Patient type and is about John.
Note that such a resource can be anything: a json file, a pdf, an image or a document containing triples.
Second of all, we need to talk about access permissions.
Remember the tokens that I’ve mentioned earlier?
Well, Solid APIs are permissioned based on the information that is present within those tokens.
For example, here you see that when john is logged on to the health app with his health login, he has read access to all the patient data about him.
Likewise, when Dr Tom is logged in, using any app or login method, he has access to a specific resource called /p/123.
Third of all, there are two endpoints of these APIs that are of particular interest: the /resources endpoint and the /access endpoint.
When you send a GET request to the resources endpoint, you can get an overview of all the resources you have access to - given a certain token of course.
When you send a PATCH request to the access endpoint, you can add or remove access rules for a set of resources.
Voila, that’s it.
Of course, the more companies that make their APIs compatible with Solid accounts,
the more we can give people access to their data, regardless of where it is stored!
With use.id, we already did over 25 real-world projects involving such Solid accounts.
We used the requirements of these projects to advance the Solid specification.
Even though these advancements are yet to be approved by the W3C, I’m happy to our vision on the Solid specification.
