Solid WebID Profile

Social agents need to present themselves on the Web and set the circumstances in which their profiles can be used. A WebID is a way to identify a person or organization within various social, conceptual, and contextual relations. This specification describes the discovery and the data model of a Solid Profile as the representation of a social agent's identity in the Solid ecosystem for various circumstances under which profiles are used or shared, as well as preferences specific to applications.

This report was published by the Solid Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

This section is non-normative.

A city has public places where I can do all kinds of things, and also a private house with a private room which may be just mine. In that house there are spaces where I do things with family, friends, colleagues. The web must, like a well-designed building, provide a gradient of intimacy between the private and the public, so I can easily recognize the difference, easily know which I am in, and easily welcome people to come into the more intimate parts, as I want to.

If the web is like a well-designed building, the Solid Profile can be likened to the lobby, serving as a public space where visitors can discover which parts of the building's interior the owner has given consent for them to see.

The Solid ecosystem enables a social agent, such as an individual or an organization, to establish an identity by obtaining a unique identifier, called a WebID. The associated Solid Profile serves as a starting point for applications to access information related to the social agent.

There are different circumstances under which profiles are used or shared, including:

• Communication and use of multiple profiles for different purposes.
• Connectivity of multiple profiles and cross-context recognition.
• Cascade of profile information.
• Persistence and evolution of profiles.
• Anonymous, pseudonymous, and meronymous profiles.
• Self-controlled and third-party-controlled identities.
• Information for the purpose of verification, authentication, authorization purposes.
• Compilation of preferences, choices, activities and interactions of an agent.
• Social graph for different kinds of relationships between agents.
• Factors specific to physical, physiological, genetic, mental, economic, cultural, social, or behavioural identity.

In order to support these different use cases, access to the Solid profile document itself, or any of the linked associated documents, might be limited to certain groups, agents, or applications.

This specification is for:

• Server developers that want to enable clients to send and retrieve information pertaining to Solid WebID Profiles;
• Application developers that want to implement a client to produce and consume information pertaining to Solid WebID Profiles.

A Solid profile is comprised of statements expressing a social agent's identity, which can be found in one or more resources. The discovery of these statements initiates with the WebID, a URI pointing to a single document referred to as a WebID Profile Document. This document can contain references to:

• Preferences File Document, containing preferences, settings, and resources exclusively for the WebID owner.
• Type Index Documents, containing links to specific resource types.
• Extended Profile Documents, containing supplementary information about the WebID owner.

A profile can be assembled by collecting all statements that have the WebID as the subject or the object, regardless of their originating documents, as illustrated below.

The Preferences Document is a resource intended to hold information only accessible to an application that is logged in and authenticated as the WebID owner or as an agent delegated by the WebID owner to act in their behalf. The preference Document can include settings and preferences, and pointers to the owner's personal, private data, be it contacts, pictures or health data. An application operating on behalf of the owner can gather configuration settings from the owner, store them in the Preferences Document, and then read them there on subsequent visits. Such an application might also record private information (for example, a driver's license number) and later, at the direction of the owner, retrieve the information to fill out a form. A Solid WebID Profile Document MUST have exactly one triple with the WebID as subject, pim:preferencesFile as predicate, and the location of the Preferences Document as object. For example:

<?WebID> <http://www.w3.org/ns/pim/space#preferencesFile> <?PreferencesDocument> .

When an application operating on behalf of the WebID owner cannot discover a pim:preferencesFile triple, and has write and control access, and wishes to write preference data, it could create a document accessible only to the WebID owner. An application that creates a Preference Document can insert a triple in the WebID Profile Document with the WebID as subject, pim:preferencesFile as predicate, and the URL of the created document as object.

The solid:oidcIssuer predicate denotes a Solid OIDC Identity Provider capable of authenticating the WebID owner. Applications can use the value of solid:oidcIssuer to initiate the login process.

A Solid WebID Profile can advertise an inbox with the ldp:inbox property [LDN] to allow applications to send and discover notifications about activities, interactions, and new information for the attention of the owner of the WebID. It is discouraged for Solid WebID Profiles to advertise more than one inbox.

Applications can create an inbox (see resource containment) as needed with desired permissions and policies, and then associate the inbox to a WebID by updating the WebID Profile Document.

A user, a server or an application with appropriate permissions can add triples to profiles using any predicates. This specification covers only those predicates related to resource infrastructure that are in common use at the time of this writing and which we recommend as a standard. Some of the other predicates you might encounter include acl:trustedApp and cert:key. The Interoperability panel is also working on proposals which will add additional infrastructure related predicates to Solid profiles.