Start here

Take a look at the short video and the text below to familiarise with the basics of Solid.

1. Solid Accounts: Share your data regardless of where it is stored

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.

In reality, personal data is stored everywhere and made accessible via APIs that all look a bit different. 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.

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, in the image below, 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.

2. How does this work?

In the next sections, we dive deeper in the concepts that make this all work.

2.1 Apps and people are identified using URIs (called WebIDs)

First of all, apps and people are identified using global identifiers in the form of an URI. These URIs are called "WebIDs".

In this example, you can see that the app’s identifier is webid.health.app and John’s identifier is health.id/john. When you go to these URIs, you will see a list of APIs that contain data about John and John's login methods.

2.2 People can sign in and grant access using a dialect of OpenID Connect

People can log on to apps using their identifier (i.e. WebID).

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.

2.3 Using OpenID Connect, people and machines can get tokens to access APIs

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.

2.4 Solid APIs have resources with a type, subject and identifier.

A Solid API 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 (i.e. a URI).

• An example of a data type is https://dbpedia.com/types/patient
• An example of a subject is https://health.id/john
• And an example of a resource is https://ins.provider.com/patient/123.

Every resource must be connected to a type and a subject.

In the example below, you can see that the resource is an instance of the Patient type and is about John.

Keep in mind that such a resource can be anything: a json file, a pdf, an image or a document containing triples.

2.5 Solid APIs are permissioned using WebIDs and fields within tokens

Now, 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, in the example above, you can 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.
• When Dr Tom is logged in, using any app or login method, he has access to a specific resource called /p/123.

2.6 Solid APIs support discovery of data and may allow for access requests

Finally, Solid APIs have two endpoints 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.