Solid WebID Profile

Version 1.0.0, Editor’s Draft, 2023-09-04

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

Abstract

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.

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 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:

  • 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.

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 a description of a social agent's identity within the Solid ecosystem, which can be used to describe their persona, preferences, abilities, affiliations, social activities and relationships, characteristics, and digital presence, as well as to aid in the discovery of storage and location of specific data.
Extended Solid Profile
An extended Solid profile is an additional profile document that provides supplemental description to a Solid profile to help distribute and manage information about a WebID for use in different circumstances. Extended profile documents can be used for various purposes, such as organizing information or limiting access to certain data.
Preferences Document
A preferences document is a specific resource intended to store data which helps authorized applications accommodate the user's preferences, such as settings, personalization details, and pointers to the user's private data.

Namespaces

Prefixes and 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

This section describes the conformance model of the Solid WebID Profile..

Normative and Informative Content

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”, “SHOULD”, and “MAY” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The key words “strongly encouraged”, “strongly discouraged”, “encouraged", “discouraged", “can", “cannot”, “could”, “could not”, “might”, and “might not” are used for non-normative content.

Specification Category

The Solid WebID Profile identifies the following Specification Category to distinguish the types of conformance: notation/syntax, processor behavior, protocol.

Classes of Products

The Solid WebID Profile identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

Reader Application
A Solid app that issues HTTP requests to consume content pertaining to WebID Profiles.
Writer Application
A Solid app that issues HTTP requests to produce and consume content pertaining to WebID Profiles.
Server
A Solid Server that responds to HTTP requests processing payloads pertaining to Solid WebID Profiles.

Interoperability

Reader Application–Server interoperability
Interoperability of implementations for Reader Applications and Servers is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.
Writer Application–Server interoperability
Interoperability of implementations for Writer Applications and Servers is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.

Discovery

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:

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.

Solid Profile Discovery Overview
Note:

Depending on the established access control rules, certain resources may be inaccessible to specific applications or agents.

Reading and Writing Profiles

Reading Profile

To retrieve a representation of a Solid WebID Profile, Reader Application MUST make an HTTP GET request targeting a Solid WebID Profile resource including a Content-Type header requesting a representation in text/turtle or application/ld+json.

Solid WebID Profile

The Solid WebID Profile has the following properties:

  • One rdf:type property whose object is foaf:Agent.
  • One pim:preferencesFile.
  • Zero or one ldp:inbox.
  • Zero or more pim:storage properties to indicate agent's storages.
  • Zero or more rdfs:seeAlso to refer to related documents extending the profile.
Note:

The Solid WebID Profiles may include other information pertaining to scenarios in which profiles are used or shared as mentioned in use cases.

Preferences Document

The Preferences Document has the following properties:

  • One rdf:type property whose object is pim:ConfigurationFile.
  • Zero or more rdfs:seeAlso.

Extended Profile Documents

The Extended Profile Documents are also self-describing Solid WebID Profiles and share the same data model. Reader Applications retrieve representations of Extended Profile Documents the same way as they retrieve Solid WebID Profiles.

Reader Application MAY retrieve a representation of an Extended Profile Document.

Updating Profile

Writer Applications perform write operations against Solid Protocol servers.

Note:

To promote self-describing resources and efficient discovery and reuse of profile information, implementations and authors are encouraged to prioritize using the Solid WebID Profile before resorting to an Extended WebID Profile.

Writer Application MUST use an HTTP PUT or PATCH request targeting the Solid WebID Profile to be updated.

Solid WebID Profile might include protected properties, such as solid:oidcIssuer.

Servers MUST NOT allow HTTP PUT or PATCH on a Solid WebID Profile to update its protected triples; if the server receives such a request, it MUST respond with a 409 status code.

Servers MUST respond with a 422 status code [RFC4918] when unable to process the contained instructions, including unrecognised JSON-LD context in representation data, semantically erroneous Solid WebID Profile or Preferences Document data.

Extending a Profile

Writer Applications perform write operations against Solid Protocol servers.

Ownership by WebID URI entails that the social agent has authority over the representation of the resource it identifies, including access to perform write operations targeting the Solid WebID Profile.

Writer Application MUST use an HTTP PUT or PATCH request targeting the Extended Profile to be created.

Writer Application MUST use an HTTP PUT or PATCH request targeting the Extended Profile to be updated

Note:

While the rdfs:seeAlso property is recommended to establish links to extended profiles or additional information, the use of the owl:sameAs property is encouraged when connecting two WebIDs that denote the same entity, as shown in the example: <https://dbpedia.org/resource/Tim_Berners-Lee> owl:sameAs <https://www.w3.org/People/Berners-Lee/card#i>.

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.

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.

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
[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
[RFC9110]
HTTP Semantics. R. Fielding, M. Nottingham, J. Reschke, Editors. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9110
[RFC9112]
HTTP/1.1. R. Fielding, M. Nottingham, J. Reschke, Editors. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9112
[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/