Hi, I am Lauro Vanderborght. This is episode seven of Digita’s Solid Tech Talks. Up to now, we explained how interoperable data exchange is possible within the Solid ecosystem. In this episode, we will give an overview of how data can be exchanged securely, completely under the control of the user. In the next episodes, we will further explain all the details.

Let’s start by discussing the different components that consider data exchange. We have a user who has data to be stored in the decentralized Solid ecosystem. To do this, the user needs a Solid pod. This does not have to be a personal pod. It could be a public pod, business pod, school pod, whatever. To interact with the data, the user can choose different applications. These applications don’t need to have a link with the pod upfront: they could be linked dynamically, however, the user chooses. All these interactions between applications and pods happen over the network. So we have users, pods, applications, and the network.

Now, what are the elements of secure access? We start with the basics: we need to make sure that all interactions over the network are secure. Then, every agent -- so users and applications -- needs to be verified: its identity needs to be authenticated. Finally, every interaction needs to be checked, to make sure that the interaction is permitted: the agent is authorized to do that type of interaction. Describing which agent is allowed which type of interaction is called access control.

To create a secure network, we make use of the more secure version of the HTTP protocol, conveniently called HTTP Secure, or HTTPS. HTTP requests are not encrypted, so they could easily be intercepted by anyone who uses the same network. HTTPS requests are encrypted using Transport Layer Security or TLS, so their content cannot be viewed or changed by people using the same network.

Having a secure network does not mean servers should not be cautious of malicious requests: the actual content and HTTP headers of a request are checked by Solid pod servers to make sure that no invalid interactions are tried to test the security of the server.

The remaining elements are identity, authentication, and authorization via access control. Because we are in the Solid ecosystem, each of these elements could be decentralized: distributed across different servers.

Agents need a digital identity. You now typically have a different digital identity for each application, which means you have to create an account for every application. Within the Solid ecosystem, a single identity can be used across all applications and pods. An identity is another type of resource, so, it is again a URL. This specific type of URL is called a WebID, which dereferences RDF data that contains profile information.

To authenticate, agents need to validate their identity. Given Solid’s distributed nature, this can be done via a separate component, the Identity Provider. Agents can register themselves a WebID at an identity provider, and then use that identity provider to authenticate themselves.

If you know about OpenID Connect or OAuth 2.0, you might have heard about identity providers before: there are applications that allow you to ‘sign in with Google’, which means that Google is the identity provider for that application. In fact, Solid is extending these standards for identification and authentication, in the standard Solid-OpenId Connect, or Solid-OIDC. The big difference is that existing standards require applications to create a trust relationship with identity providers. This means that applications supporting OpenID can only present users with a predetermined set of identity providers: the advent of a new identity provider requires the vendor of the application to create a new trust relationship and update its application. In Solid-OIDC, no link needs to pre-exist between applications and identity providers. Agents have full control over which identity provider they want to use.

Finally, each interaction between an agent and a pod needs to be authorized: agents should only be able to interact with a pod in ways they are permitted to. For example, your friends are able to see your family pictures but not your latest paycheck, and your boss is able to update certain professional data but is not able to see your family pictures. These permissions are described as an access control policy. Each resource within a pod can have an auxiliary resource with such an access control policy. This means that the user can very precisely describe which data gets shared, and with who.

Outside of the Solid ecosystem, applications are pretty much bound to specific servers. This means that these servers could use cross-origin protection to make sure that requests to the server only happen from a specific list of application sources. In fact, this protection is enabled by default in HTTP. Because Solid applications by design are not bound to specific servers, Solid pods disable this protection using Cross-origin Resource Sharing or CORS, indicating that cross-origin requests are allowed via HTTP response headers. Instead, the access control policy makes sure that unpermitted applications cannot interact with the Solid pod.

In the next videos, we’ll dive into the actual identity, authentication, and authorization flows. See you soon.