What are Solid accounts?

Solid is specification for user and company accounts. These accounts can be used for consent-based data sharing.

A Solid compatible account consists of several components: one WebID, one or more data stores and one or more logins. Each account must have one primary data store and one primary login.

Don't worry, these components are really easy to understand. They are based on old, trusted, tried and tested web technology 😁.

Solid account components at use.id

In use.id we put some limitations on how such Solid accounts are implemented.

WebID and WebID Profile Document

A WebID is a unique identifier for a Solid account and takes the form of a URL.

For example, https://use.id/john is a WebID. When surfing to this WebID, you will be redirected (HTTP 302) to John's WebID profile document: https://use.id/john/profile. Go ahead and access these URIs yourself!

If you've accessed these URIs, you see that a WebID profile document contains a list of storage locations and login methods. A profile document contains exactly one storage location and one login method.

Logins

A WebID can be associated with multiple logins. These logins are actually OpenID Connect Identity providers at which the WebID holder has an account.

In this case of John, you can see by surfing to https://use.id/john that he has an account at https://idp.use.id.

OpenID Connect Identity providers in Solid have some additional requirements compared to traditional OIDC. Most importantly, they must support DPoP, use WebIDs as Client IDs and provide some additional claims.

Of course, you are free to rely on the use.id Identity Provider. Currently, the use.id IDP supports one time password authentication (code grant flow) for end users (H2M) and client credentials for apps (M2M).

Storage locations (aka pods)

A WebID can also be associated with multiple storage locations. In short, a storage location is a HTTP REST API that follows certain rules related to access controls and data discovery. Traditionally, in Solid, storage locations are often called pods (i.e. personal online data stores). However, we prefer to use the term storage location as it can contain really any kind of data.

Basically, a storage location is a HTTP server on which you can store files (called resources) and folders (called containers).

Access control lists are defined using WebIDs (e.g. https://use.id/john has read access to https://pods.government.com/john/diploma).

At use.id, you don't have to worry about how to compose access control lists. This is something that will be handled by the use.id authorisation agent. Of course, you can sometimes retrieve the ACL for a certain resource. If you do so, you'll see that it is formatted according to Web Access Control or Access Control Policies.

At use.id, every WebID will automatically have a use.id pod by default. You are free to add other pods if you want to.

Authorisation Agent

An authorisation agent is an application that you, as a WebID holder, trust to make changes to the access control rules of your data on your behalf. Each use.id WebID has an authorisation agent associated with it by default.

The reason for such an authorisation agent is simple: otherwise apps can use your identity token to gain access to resources that they shouldn't have access to.

In the next page, you'll learn more about the benefits of Solid accounts.