What are Solid accounts?

Solid is an open W3C standard 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 Pods, one or more logins and one authorisation agent.

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. This identifier takes the form of a HTTP URI. When surfing to this HTTP URI, you are redirected to a profile document. In Solid, this profile document should be hosted on a different HTTP URI than the HTTP URI of the actual identifier.

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 (1) "Pods" (or better storage locations), (2) login methods and (3) authorisation agents.


At use.id, we have decided to support multiple pods, multiple login methods, but only one authorisation agent. We have also decided to not allow people editing their profile document outside of the use.id app. These decisions are driven by convenience and security reasons and could be changed in the future.


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 Linked Data Platform server with support for access control lists. 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.