Revise Solid report
This commit is contained in:
Sarven Capadisli
Golda Velez
parent
876ec49a5a
commit
02f2dd0077
|
|
@ -1,102 +1,123 @@
|
|||
# Solid
|
||||
|
||||
Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. It relies as much as possible on existing W3C standards and protocols, tying them together into a common framework.
|
||||
Solid (derived from "social linked data") is a protocol to separate applications from data and to give users control of their data. This adds several things to existing Web protocols: standardized identity integration, access control systems, and read-write interfaces over HTTP.
|
||||
|
||||
The main concept behind Solid is that users store their personal data in a "pod" (personal online data store), and applications request access to it, rather than storing user data and accounts on an application server.
|
||||
While Web platforms today have their own protocols and APIs for storing and accessing data for getting control, the Solid universal model means any application can write any data of its choosing anywhere on the Web. Solid allows applications to read and write to a private server, contribute to others’ Pods (derived from "personal online data stores"), and make it easy to build new relationships.
|
||||
|
||||
### Identity
|
||||
|
||||
Solid uses WebID URIs as universal usernames. The WebID URI's primary function is to point to the location of a public WebID Profile document.
|
||||
"[Any resource of significance should be given a URI](https://www.w3.org/DesignIssues/Axioms#Universality2)".
|
||||
|
||||
Example WebIDs: `https://alice.databox.com/profile/card#me` or `http://somepersonalsite.com/#webid`
|
||||
By applying the best practices of the [Architecture of the World Wide Web](https://www.w3.org/TR/webarch/), Solid uses *WebID* as a universal identification mechanism. A WebID is an HTTP URI which refers to an Agent (Person, Organization, Group, Device, etc.). A description of the WebID can be found in the Profile Document, a type of web page that any social network user is familiar with. Individuals can associate themselves with multiple identities, and they can be public or private. Identities can be interlinked with one another.
|
||||
|
||||
A WebID is a globally unique, decentralized identifier. It enables cross-service federated sign-in, and does not tie a user's identity to a server. A WebID Profile Document is in Linked Data format, and contains identity information such as a username, profile image, preferences, and public key certificates.
|
||||
Tim Berners-Lee's WebID: [https://www.w3.org/People/Berners-Lee/card#i](https://www.w3.org/People/Berners-Lee/card#i)
|
||||
|
||||
Solid requires cross-domain, de-centralized authentication mechanisms not tied to any particular identity provider or certificate authority, so it uses the WebID-TLS protocol instead of passwords. Instead of creating an account with a username and password for each service, a user selects a security certificate for the site from a popup. The server matches the private key stored by the user's browser with the public key stored in that user's WebID Profile Document to authenticate them.
|
||||
|
||||
Username and password authentication mechanisms are an active area of research. Solid recommends that servers implement secondary account recovery mechanisms, such as email recovery, in case browser certificates are lost.
|
||||
|
||||
There is some discussion of [using DIDs in addition to WebIDs](https://github.com/solid/identity-panel/issues/1).
|
||||
WebID is integral to authenticating identities and used in setting fine grained access controls to Web resources. Different authentication mechanisms can be loosely coupled with WebID (orthogonal specifications). The [Solid OpenID Connect](https://solid.github.io/authentication-panel/solid-oidc/) (Solid OIDC) specification defines how resource servers verify the identity of relying parties and end users based on the authentication performed by an OpenID provider. The WebID-TLS protocol specifies how a service can authenticate a user after requesting their Certificate without needing to rely on this being signed by a well known Certificate Authority.
|
||||
|
||||
### Network
|
||||
|
||||
Solid allows inboxes for any resources, such as actors or articles. An example of an inbox for [annotations related to a particular article](https://linkedresearch.org/annotation/csarven.ca/%23i/87bc9a28-9f94-4b1b-a4b9-503899795f6e).
|
||||
The [Solid Protocol](https://solidproject.org/TR/protocol) specifies how clients and servers exchange data securely over the Internet, and they do so using the HTTP Web standard. The WebSocket Protocol is used for live updates between clients and servers.
|
||||
|
||||
Solid provides a [HTTPS REST API](https://github.com/solid/solid-spec/blob/master/api-rest.md) and a [Websockets API](https://github.com/solid/solid-spec/blob/master/api-websockets.md) for a PubSub mechanism. Smart clients currently retrieve messages with pull/get, rather than through server push.
|
||||
|
||||
Nofitications use the [Linked Data Notifications](https://www.w3.org/TR/ldn/) standard.
|
||||
Clients request read-write operations using various HTTP methods (GET, OPTIONS, POST, PUT, PATCH, DELETE..) on resources identified by URLs. The [Linked Data](https://www.w3.org/DesignIssues/LinkedData) design principles are applied to identify, describe, and discover human- and machine-readable information. Resources may be publicly accessible, require credential or capability based authorization.
|
||||
|
||||
### Data
|
||||
|
||||
A data storage space is called a "pod" (personal online data store). All a user's data is stored in their pod. Users may self-host their pods (on their own server) or use a "pod Provider", a federated pod server. Applications read and write data into the pod depending on the authorizations granted by the users associated with that pod. A person may have multiple pods, for example for work and for home. Data may be replicated across pods. A key concept of the pod is that users may switch Pods easily without losing their data (such as their contacts and chat history).
|
||||
Pods are data stores that serve as a standardized place for individuals to manage any kind of data using disparate applications, and apply identity-based control permissions for data sharing.
|
||||
|
||||
Solid [strongly encourages](https://github.com/solid/solid-spec#content-representation) the use of RDF-based Linked Data (RDF in the form of JSON-LD, Turtle, HTML+RDFa, etc) for interoperability with the ecosystem. The Solid [content representation spec](https://github.com/solid/solid-spec/blob/master/content-representation.md) encourages consistent naming conventions.
|
||||
Solid users may self-host their Pods (on their own server) or use a Pod provider. Applications read and write data into the Pod depending on the authorizations granted by the users associated with that Pod. A person may have multiple Pods. Data may be replicated across Pods.
|
||||
|
||||
An example payload:
|
||||
Because Solid Pods are generic universal data stores, the application level data standards need to be understood only by the applications. These “client-client” specs exist for basic profile and contact information as well as chat, and will be developed for other areas such as calendars, fitness, financial, etc. The goal is that all personal data will be in Pods. Users are free to switch between applications and share data between them.
|
||||
|
||||
```
|
||||
{
|
||||
"@context": {
|
||||
"@language": "en",
|
||||
"sioc": "http://rdfs.org/sioc/ns#",
|
||||
"foaf": "http://xmlns.com/foaf/0.1/"
|
||||
},
|
||||
"@id": "",
|
||||
"@type": "sioc:Comment",
|
||||
"sioc:reply_of": { "@id": "http://example.org/article" },
|
||||
"sioc:created_at": {
|
||||
"@type": "http://www.w3.org/2001/XMLSchema#dateTime",
|
||||
"@value": "2015-12-23T16:44:21Z"
|
||||
},
|
||||
"sioc:content": "This is a great article!",
|
||||
"sioc:has_creator": {
|
||||
"@id": "http://example.org/profile",
|
||||
"@type": "sioc:UserAccount",
|
||||
"sioc:account_of": { "@id": "http://example.org/profile#alice" },
|
||||
"sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },
|
||||
"foaf:name": "Alice"
|
||||
}
|
||||
}
|
||||
```
|
||||
*Resource Description Framework* (RDF) provides an interoperable means of publishing and linking self-describing Web resources where assertions can be made about anything at any level of abstraction in the form of triple statements.
|
||||
|
||||
Solid supports sharing and reuse of notifications across applications, regardless of how they were generated.
|
||||
|
||||
|
||||
### Moderation & Reputation
|
||||
|
||||
Solid is a decentralized system of information storage and sharing, where moderation could be done by individuals or groups with access privileges to the resources in a Pod (e.g. inbox management, filtering annotations).
|
||||
|
||||
The Solid platform allows you to build all kinds of collaborative systems, such as issue flagging, escalation and management, so any community can make or tweak its own apps for things like collaborative moderation, and engineering is more tailored to community and culture.
|
||||
|
||||
### Social & Discovery
|
||||
|
||||
Solid aims to create tools that enable the building of interoperable decentralized social applications. WebIDs allows user addressing across all Solid-conforming apps. Resources (including WebIDs) are self-describing, hosted on pods, and have HTTP endpoints with standard naming conventions to make discovery easier. Any app that can parse the format can read the inbox and send responses.
|
||||
Solid (**social** linked data) enables social interactions by using decentralised identifiers, data, and applications. Any Web resource can advertise a location to receive notifications about (social) activities e.g. invitation to review an article, a public comment or annotation created somewhere on the Web, a bookmark,like activity, or a follow. A large multi-user Solid social chat application for example could read/write data for each participant in their own Pod, owned by them, with access and duration controlled by them.
|
||||
|
||||
Solid uses the W3C [Linked Data Notifications](https://www.w3.org/TR/ldn/) (LDN) recommendation as a communication protocol that describes how servers (receivers) can have messages pushed to them by applications (senders), as well as how other applications (consumers) may retrieve those messages. Any resource can advertise a receiving endpoint (Inbox) for the messages. Inboxes can be private or shared with individuals or groups, and can be access controlled.
|
||||
|
||||
Solid servers can offer federated [SPARQL](https://www.w3.org/TR/sparql11-overview/) queries as well as [Linked Data Fragments](https://linkeddatafragments.org/) with different interfaces to redistribute the load between clients and servers.
|
||||
|
||||
### Privacy & Access Control
|
||||
|
||||
A user's data is stored on their pod, which applications request access to. A user grants access to their data by selecting a security certificate to use with an application. If the user revokes access of an app to their data, the app will no longer be able to read or update the user's data, but would still have access to the data that the user sent out prior to the revocation.
|
||||
Solid was created on the principle of enhancing user control of their data. Privacy and access controls are core to the mission of safer data sharing through standardization and simplification. Solid offers the ability to run as a decentralised privacy system, such that no central authority is required for massive scale storage and communications. Access control of resources is for trusted peers, where communication between parties can be undetectable and unobservable by unauthorised third-parties.
|
||||
|
||||
Data is always encrypted when in transition between an app and a pod. Pod providers can encrypt data at rest on a pod, but are not required to.
|
||||
Attribute Based Access Control (ABAC) is provided through Web Access Control (WAC), a decentralized cross-domain system. The WAC mechanism is concerned with giving access to agents denoted by an identity (e.g. WebID) to perform various kinds of read-write operations on resources identified by URLs.
|
||||
|
||||
The Access Control List (ACL) ontology is used to describe authorization policies about authorized agents with modes of access on target resources, similar to Role Based Access Control (RBAC). Further feature models developing privately are under consideration, such as Access Control Policies (ACP), as Solid’s data access framework can be extended by the community.
|
||||
|
||||
Applications can determine access privileges that are available to the user and public for any given resource.
|
||||
|
||||
Policies can be attached to assets to permit or prohibit actions, be limited by constraints or duties, as well as have obligations required to be met by stakeholders. Data privacy can be described and represented by vocabularies to help conform to regulations such as handling personal data (e.g. EU General Data Protection Regulation).
|
||||
|
||||
Data can be encrypted in transit between an application and a Pod, as well as stored encrypted. Pod providers and data owners also can encrypt data such that Pod owner data is not exposed to the service.
|
||||
|
||||
Solid uses the [Web Access Control Spec](http://solid.github.io/web-access-control-spec/) for management of access control lists.
|
||||
|
||||
### Interoperability
|
||||
|
||||
Solid provides [specs and recommendations](https://github.com/solid/solid-spec#social-web-app-protocols) for interoperability between Solid ecosystem social applications. There are weekly meetings for the [Solid Data Interoperability Panel](https://github.com/solid/data-interoperability-panel) to discuss data interoperability across applications.
|
||||
Solid servers can be built atop of W3C [Linked Data Platform](https://www.w3.org/TR/ldp/) and [Web Annotation Protocol](https://www.w3.org/TR/annotation-protocol/) servers.
|
||||
|
||||
LDN notifications are in RDF (JSON-LD and other RDF syntaxes can be content negotiated). To allow a wide variety of use cases, notifications can contain any data and be described with any vocabulary e.g. W3C [Activity Streams](https://www.w3.org/TR/activitystreams-vocabulary/).
|
||||
|
||||
W3C [ActivityPub](https://www.w3.org/TR/activitypub/) uses LDN's targeting and delivery mechanism, which is required by its server-to-server protocol for a federated social system. A Solid server can potentially act as an ActivityPub server.
|
||||
|
||||
|
||||
### Scalability
|
||||
|
||||
Scale on the web with the decentralized nature of Solid means an application needs to direct requests to an appropriate server and enable that server to process for an appropriate response. There is a rich history of web application scale optimisation techniques to draw from (caching, store-and-forward, aggregation and a mix of these).
|
||||
|
||||
The network topology of Solid by default is point-to-point (e.g. connections between two endpoints). The authority topology is that nodes interact directly with each other, without scale being held back by third-party nodes. There is no single point of failure, high availability, system performance, and is generally survivable. Solid does not shard or replicate by default, with data localized to a Pod and storage controlled by the owner.
|
||||
|
||||
Solid is potentially compatible with federated social applications. For example, a Solid pod could be used in the implementation of an ActivityPub server. The minimum requirement to be conformant with the Solid protocol is the use of JSON-LD, which ActivityPub uses. Dokieli (a solid app) is able to send notifications to ActivityPub. A [discussion of the links between ActivityPub and Solid](https://socialhub.activitypub.rocks/t/which-links-between-activitypub-and-solid-project/529/8) highlights similarities, although work is required to close the gap between the specs.
|
||||
|
||||
### Governance & Business Models
|
||||
|
||||
Pod providers can choose whether to charge for hosting a pod. Possible business models include charging users for storage or advertising through applications.
|
||||
The W3C mission is to lead the World Wide Web to its full potential by developing protocols and guidelines that ensure the long-term growth of the Web.
|
||||
|
||||
[Inrupt](https://inrupt.com/faq) is a company committed to the development of Solid. It plans to monetize through consulting and pod hosting fees.
|
||||
The W3C shares similar views to the IETF, ISOC, ICANN, and others in the Internet/Web technical standards ecosystem working on governance of communication platforms so important to humanity.
|
||||
|
||||
W3C governance for the Solid standard is aligned with W3C ethical Web principles such as neutrality, multi-stakeholder and balanced participation, open and due process, consensus based decisions, open deliverables, and online accountability/transparency.
|
||||
|
||||
Solid business models are a reflection of the human condition, constrained only by imagination and regulation. A Solid server that holds data in Pods, for example, could be a business in running a Solid service itself or related to business in handling the data served via Solid (e.g. from information assets such as original works to information about assets such as shopping carts).
|
||||
|
||||
Much in the same way a Web server created almost infinite business models, Solid in fact expands the Web by decoupling application development and identity management from data storage (Solid Pods) -- more apps can be written with more identity management options to access much more data maintained more carefully for more sharing.
|
||||
|
||||
### Implementations & Applications
|
||||
|
||||
A list of [Solid Apps](https://solidproject.org/use-solid/apps). Apps built to use Solid data pods are considered part of the Solid ecosystem.
|
||||
Social, Healthcare, Fitness, Finance, Retail, AI, Scientific communication..
|
||||
|
||||
Solid does not have many widely used social applications yet, although there has been research such as [A Demonstration of the Solid Platform for Social Web Applications](http://crosscloud.org/2016/www-mansour-pdf.pdf).
|
||||
The Solid community develops and supports a wide range of [applications](https://solidproject.org/apps). Applications generate notifications about activities, interactions, and new information, which may be presented to the user or processed further.
|
||||
|
||||
An example application is:
|
||||
The eventual vision of Solid is that all data of all applications is stored in pods somewhere, and all applications can access that data using interoperable standards. There is significant progress, significant momentum, and a huge amount to be done.
|
||||
|
||||
Example Solid applications:
|
||||
|
||||
* [SolidOS](https://solidos.solidcommunity.net/) is a Web-based Operating System for any new computer or data store.
|
||||
* [dokieli](https://dokie.li/) is a client-side editor for decentralised article publishing, annotations and social interactions.
|
||||
* [Media Kraken](https://noeldemartin.github.io/media-kraken/) is an application to track films and create collections.
|
||||
|
||||
Open Source Solid servers:
|
||||
|
||||
* [Node Solid Server](https://github.com/solid/node-solid-server/)
|
||||
* [Community Solid Server](https://github.com/solid/community-server/)
|
||||
* [PHP Solid Server](https://github.com/pdsinterop/php-solid-server/)
|
||||
|
||||
Commercial Solid servers:
|
||||
* [Enterprise Solid Server](https://docs.inrupt.com/ess/)
|
||||
|
||||
- [dokieli](https://dokie.li/) for publishing articles and posts
|
||||
|
||||
### Links
|
||||
|
||||
- [Solid](https://solid.mit.edu/)
|
||||
- [Solid spec](https://github.com/solid/solid-spec)
|
||||
- [Solid repo](https://github.com/solid/solid)
|
||||
- [Solid paper](http://emansour.com/research/lusail/solid_protocols.pdf)
|
||||
- [Solid Community Group Meetings](https://www.w3.org/community/solid/wiki/Meetings)
|
||||
* [Solid Project](https://solidproject.org/)
|
||||
* [Solid Technical Reports](https://solidproject.org/TR/)
|
||||
* [W3C Solid Community Group](https://www.w3.org/community/solid/)
|
||||
* [Solid repositories](https://github.com/solid/)
|
||||
* [Solid Roadmap](https://solidos.solidcommunity.net/public/Roadmap/Tasks/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue