Solid WebID Profile
Version 1.0.0, Editor’s Draft, 2022-06-22
More details about this document
- This version
- https://solid.github.io/webid-profile/
- Latest version
- https://solid.github.io/webid-profile/
- Latest published version
- https://solid.github.io/webid-profile/
- Editors
- Virginia Balseiro
- Timea Turdean
- Jeff Zucker
- Contributors
- Sarven Capadisli
- Tim Berners-Lee
- Created
- Published
- Modified
- Repository
- GitHub
- Issues
- Language
- English
- License
- MIT License
- Document Status
- Editor’s Draft
- Policy
-
- Rule
- Offer
- Unique Identifier
- https://solidproject.org/TR/webid-profile#document-policy-offer
- Target
- https://solidproject.org/TR/webid-profile
- Permission
-
- Assigner
- W3C Solid Community Group
- Action
MIT License. Copyright © 2022 W3C Solid Community Group.
Abstract
A WebID is a way to identify oneself within various social, conceptual, and contextual relations. Social agents need to be able to present themselves on the Web and set the circumstances in which their profiles can be used in a standard manner. A Solid Profile is the representation of a social agent's identity in the Solid ecosystem.
This document specifies the discovery and the data model of a Solid Profile. It describes profiles and extension documents describing an individual's social information and and application-level preferences
A Solid profile can include information about the social agent, such as personal information and links to other resources about or related to the agent. A profile and its associated documents can be publicly readable, restricted to named audiences, or private.
This specification aims to provide recommendations and considerations for various circumstances under which profiles are used or shared, such as the use of multiple profiles, connectivity of profiles, preferences, social graph, and anonymous and pseudonymous profiles.
Status of This Document
This section describes the status of this document at the time of its publication.
This document was published by the Solid Community Group as an Editor’s Draft. The sections that have been incorporated have been reviewed following the Solid process. However, the information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.
Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
Introduction
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 and pseudonymous 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:
- Application developers that want to implement a client to use WebIDs and Solid profiles.
Terminology
This section is non-normative.
This document uses terminology from the Solid Protocol [SOLID-PROTOCOL] and Web Access Control [WAC] specifications.
The Solid WebID Profile specification defines the following terms. These terms are referenced throughout this specification.
- Solid Profile
- A Solid Profile is...
- Solid Profile
- An extended profile is...
Namespaces
Prefix | Namespace | Description |
---|---|---|
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns# | [rdf-schema] |
rdfs |
http://www.w3.org/2000/01/rdf-schema | [rdf-schema] |
ldp |
http://www.w3.org/ns/ldp# | [LDP] |
solid |
http://www.w3.org/ns/solid/terms# | Solid Terms |
pim |
http://www.w3.org/ns/pim/space# | Workspace Ontology |
acl |
http://www.w3.org/ns/auth/acl# | ACL Ontology |
dcterms |
http://purl.org/dc/terms/ | [DC-TERMS] |
Conformance
All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Discovering a complete Solid profile
It is possible to have all profile information in a single WebID Profile Document, but a more likely situation is that some information is in that document and some is in extended profile documents. With a couple of exceptions noted below, there is no guarantee that any specific piece of data is located in a given document. Therefore it is almost always best to load all profile documents, to do so in a recommended order, and to treat the Solid Profile as a graph assembled by loading documents rather than as a set of documents.
When an application wants to retrieve a complete profile, it SHOULD
- Load the WebID Profile Document reachable at the WebID URI.
- If the application is operating on behalf of the WebID owner, find a triple in that document with the WebID as subject and pim:preferencesFile as predicate, then load the object of that triple.
Once all of the accessible extended profile documents have been loaded, the profile will consist of all statements with the WebID as subject, regardless of which document the statements occurred in. An application with only public permissions will see only statements from publicly accessible extended profile documents while other apps will see statements from public and also private extended profile documents they have access to.
Profiles can contain, and apps are free to follow, any kind of links to related documents. In order to promote interoperability and limit the burden on apps, this specification recommends a limited number of related documents which a profile ought to contain so that apps can discover them.
The discovery process starts with the WebID, a URI that points to exactly one document, referred to here as a WebID Profile Document [WEBID]. This document can be expected to contain pointers to a Preferences File Document containing settings and resources meant only for the WebID owner, Type Index Documents containing links to specific types of resources, and might also contain Extended Profile Documents containing additional information about the WebID owner. The documents which make up a Solid Profile are illustrated below.

Private Preferences
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.
Extended Profile Documents
Solid Profile owners may use the
rdfs:seeAlso
predicate to link to extended profile
documents which contain information that they do not want in the
WebID Profile Document or in the Preferences Document. This can
be done to help organize information - for example to keep all
friends (objects of foaf:knows
predicates) in a
separate rdfs:seeAlso
document. It can also be done
to limit access to the data - for example to store a phone
number where only trusted friends can view it.
Reading Extended Profile Documents
An application wanting to load a complete Solid Profile MUST examine
statements in the WebID Profile Document and the Preferences
Document that have the WebID as subject,
rdfs:seeAlso
as predicate and the URL of an
Extended Profile Document as object. When the application has loaded
those two documents, it SHOULD load the documents specified
in the URLs of all rdfs:seeAlso
triples found
and SHOULD treat all statements in the linked documents that
have the WebID as subject as part of the Solid Profile. An
application may but can not be expected to load the objects of
rdfs:seeAlso
triples found in documents that
are themselves the object of an
rdfs:seeAlso
triple. In other words, look in
the WebID Profile Document and in the Preferences Document
for rdfs:seeAlso
triples but don't necessarily
follow any additional rdfs:seeAlso
triples
found in those documents. An application can examine any statement
found in the linked documents for other purpose, which are
not described by this specification.
Writing Extended Profile Documents
When an application wants to write data in an Extended Profile
Document, it SHOULD give the document appropriate
permissions depending on the needs of the WebID owner. If
the document is meant only for the WebID owner, the app
SHOULD create an rdfs:seeAlso
triple pointing
to it in the Preferences File. If the document is meant for
the public or for a restricted audience, the triple SHOULD
be created in the WebID Profile Document.
Source: pull/2
Identity Provider
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.
Storage
The pim:storage
predicate denotes a storage
available to the agent to use.
A Solid Profile SHOULD contain at least one triple with the
WebID as subject, pim:storage
as predicate, and the
storage as the object.
Inbox
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.
Other predicates
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.
References
Normative References
- [DC-TERMS]
- Dublin Core Metadata Terms, version 1.1. DCMI Usage Board. DCMI. 11 October 2010. DCMI Recommendation. URL: http://dublincore.org/documents/2010/10/11/dcmi-terms/
- [FETCH]
- Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
- [IANA-MEDIA-TYPES]
- Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
- [LDN]
- Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/
- [LDP]
- Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
- [RDF-SCHEMA]
- RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
- [RDF11-CONCEPTS]
- RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
- [RFC3986]
- Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
- [RFC6454]
- The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
- [RFC7230]
- Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
- [RFC7231]
- Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
- [RFC8174]
- Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
- [SOLID-OIDC]
- SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 28 March 2022. Version 0.1.0. URL: https://solidproject.org/TR/oidc
- [SOLID-PROTOCOL]
- Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo. W3C Solid Community Group. 17 December 2021. Version 0.9.0. URL: https://solidproject.org/TR/protocol
- [WAC]
- Web Access Control. Sarven Capadisli. W3C Solid Community Group. 11 July 2021. Draft. URL: https://solidproject.org/TR/wac
- [WEBARCH]
- Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
- [WEBID]
- WebID 1.0. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor’s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
Informative References
- [COGA-USABLE]
- Making content usable for people with cognitive and learning disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
- [PRIVACY-PRINCIPLES]
- Privacy Principles. Robin Berjon; Jeffrey Yasskin. W3C. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/privacy-principles/
- [SECURITY-PRIVACY-QUESTIONNAIRE]
- Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
- W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/