My Weekly Reading Progress Report

Each Access Need represents a request to access, create, or manage all or a subset of data in Data Registries and/or Remote Data Registries.
11.1. Application Authorization For authorization purposes, client Applications in use today fall into two buckets: Strongly identifiable applications can be identified by third parties independently from the user or Agent controlling them. Only server-side applications are strongly identifiable. As confidential clients, they can keep secrets and can present attestations and third-party credentials via DNS / domain certificates. In the case of a strongly identifiable application, the identity of Agent and the Application are one and the same. The Application has its own identity. A given Agent can authorize a given Application to access data based solely on the identity of that Application. Weakly identifiable applications include in-browser Javascript Applications and native desktop or mobile Applications. They are considered weakly identifiable because they are not able to keep secrets on an instance level. They are often referred to as public clients. Native apps should be strongly-identifiable in theory (since they are able to keep secrets on an instance level), but not in practice because the OS manufacturers do not make their trust infrastructure available. Weakly identifiable clients are only strongly identifiable to the user or Agent controlling them. In the case of Weakly identifiable applications, the ability for a Solid pod to limit access to data by the Application in use is only as strong as the trustworthiness of the Agent piloting that Application, along with their ability to avoid using malicious Applications. The identity of the Application can be manipulated by the Agent in control. This means that Alice can strongly control the Applications that she uses to access her own data, but has limited ability to control the Applications that Bob uses to access the data she shares with him.

Solid Application Interoperability

2 annotations

solid.github.io

432

Other ideas about specifying trusted apps A reader can ask to use a given app, by publishing the fact that she trusts a given app. <#me> acl:trustsForUse [ acl:origin <https://calendar.example.com>; acl:mode acl:Read, acl:Append]. <#me> acl:trustsForUse [ acl:origin <https://contacts.example.com>; acl:mode acl:Read, acl:Write, acl:Control]. A writer could have also more sophisticated requirements, such as that any app Alice wants to use must be signed by developer from a given list, and so on. Therefore, by pulling the profiles of the reader and/or the writer, and/or the Origin app itself, the system can be adjusted to allow new apps to be added without bad things happening
dding trusted web apps. ** NB: this feature was only added recently and is still considered experimental. It’s likely to change in the near future. ** The authorization of trusted web app is a running battle between readers and writers on the web, and malevolent parties trying to break in to get unauthorized access. The history or Cross-Site Scripting attacks and the introduction of the Same Origin Policy is not detailed here, The CORS specification in general prevents any web app from accessing any data from or associated with a different origin. The web server can get around CORS. It is a pain to to do so, as it involves the server code echoing back the Origin header in the ACAO header, and also it must be done only when the web app in question actually is trustworthy. In solid a maxim is, you have complete control of he data. Therefore it is up to the owner of the data, the publisher, the controller of the ACL, or more broadly the person running the solid server, to specify who gets access, be it people or apps. However another maxim is that you can chose which app you use. So of Alice publishes data, and Bob want to use his favorite app, then how does that happen? A Web server MAY be configured such that a given list of origins is unconditionally trusted for incoming HTTP requests. The origin check is then bypassed for these domains, but all other access control mechanisms remain active. A specific ACL can be made to allow a given app to access a given file or folder of files, using acl:origin. Someone with acl:Control access to the resource could give in their profile a statement that they will allow users to use a given app. <#me> acl:trustedApp [ acl:origin <https://calendar.example.com>; acl:mode acl:Read, acl:Append]. <#me> acl:trustedApp [ acl:origin <https://contacts.example.com>; acl:mode acl:Read, acl:Write, acl:Control]. We define the owners of the resource as people given explicit Control access to it. (Possible future change: also anyone with Control access, even through a group, as the group can be used as a role) For each owner x, the server looks up the (extended?) profile, and looks in it for a triple of the form ?x acl:trustedApp ?y. The set of trust objects is the accumulated set of ?y found in this way. For the app ?z to have access, for every mode of access ?m required there must be some trust object ?y such that ?y acl:origin ?z; acl:mode ?m. Note access to different modes may be given in the same or different trust objects.
Note it is a really good idea to make it clear both in the text of the status message and in the body of the message the difference between the user not being allowed and the web app they are using not being trusted.
Web Access Control (WAC) is a decentralized cross-domain access control system.

Web Access Control (WAC) | web-access-control-spec

4 annotations

solid.github.io

479

Disparate applications cannot practically interoperate over the same data safely and effectively

data-interoperability-panel/problems-and-goals.md at master · solid/data-interoperability-panel

1 annotation

github.com

555

To create or update an ACL resource (see Web Access Control), an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it. [Source]
MUST implement the server part of HTTP/1.1 Authentication [RFC7235].
HOULD additionally implement the server part of HTTP/1.1 Caching
MUST implement the server part of HTTP/1.1 Conditional Requests
When both http and https are supported, all http URIs MUST redirect to their https counterparts
SHOULD use TLS
SHOULD additionally be an HTTP/2
MUST be an HTTP/1.1
HTTP/1.1

The Solid Protocol

9 annotations

solidproject.org

549

4.2.1.3 LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values, for responses that contain resource representations or successful responses to HTTP HEAD requests.
4.2.1.1 LDP servers MUST at least be HTTP/1.1 conformant servers [RFC7230].
4.2.1.4 LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to an LDPR's HTTP Request-URI [RFC5988].
LDP-PAGING].
The rules for Linked Data Platform Resources address basic questions such as: What resource representations should be used? How is optimistic collision detection handled for updates? What should client expectations be for changes to linked-to resources, such as type changes? How can the server make it easy for the client to create resources? How do I GET the representation of a large resource broken up into pages?
Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web.
This specification describes the use of HTTP for accessing, updating, creating and deleting resources from servers that expose their resources as Linked Data. It provides clarifications and extensions of the rules of Linked Data [LINKED-DATA]:

Linked Data Platform 1.0

7 annotations

www.w3.org

587

Shape Trees
Shape Trees
Solid Application Interoperability Primer
Shape Trees

Solid Technical Reports

4 annotations

solid.github.io

572

A shape tree is a machine-readable template describing the expected layout of a tree of resources in a container-based ecosystem.

Shape Trees Specification

1 annotation

shapetrees.github.io

494

A horizontally-distributable (share-nothing) high-performance LDP implementation. Also supports Memento, WebAccessControl and ActivityStreams.

LDP Implementations - W3C Wiki

1 annotation

www.w3.org

538

The Social Web Protocols are a collection of standards which enable various aspects of decentralised social interaction on the Web. This document describes the purposes of each, and how they fit together

Social Web Protocols

1 annotation

www.w3.org

507

5.4 Activity Streams 2.0 Support Receiver implementations that wish to support Activity Streams 2.0 Core can see Social Web Protocols - Inbox Interop for Content-Type and vocabulary equivalences.
5.3 Subscribing to Notifications This specification describes how consumers can read notifications from a receiver through pull, however consumers may want to ask to have incoming notifications or changes to Inbox’s contents pushed to them. Similarly, receivers may wish to make a request for notifications from a particular sender. This kind of subscription mechanism is left out of scope, but senders, receivers and consumers are not prohibited from making such an arrangement. Implementations that wish to enable subscribing may want to use existing mechanisms e.g., ActivityPub, WebSub, The WebSocket Protocol, HTTP Web Push.
5.1 Constraints Inbox URLs can announce their own constraints (e.g., SHACL, Web Annotation Protocol) via an HTTP Link header or body of the resource with a rel value of http://www.w3.org/ns/ldp#constrainedBy. Senders should comply with constraint specifications or the receiver may reject their notification and return an appropriate 4xx error code
The payload of the notification MUST be JSON-LD unless another RDF syntax has been negotiated with the receiver. To allow for a wide variety of use cases, the actual vocabulary of the payload is deliberately not specified here.
This specification does not define a paging mechanism to serve the list of notifications in an Inbox. Implementations that wish to enable paging may want to use existing mechanisms to allow efficient retrievals e.g., Linked Data Platform Paging 1.0, Activity Streams 2.0 Collection.
Linked Data Notifications is a 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. Messages are expressed in RDF, and can contain any data.

Linked Data Notifications

6 annotations

www.w3.org

451

that evil Pods can’t steal a user’s token.

Solid OIDC Primer

1 annotation

solid.github.io

518

URIs and IRIs: IRIs are a generalization of URIs [RFC3986] that permits a wider range of Unicode characters. Every absolute URI and URL is an IRI, but not every IRI is an URI. When IRIs are used in operations that are only defined for URIs, they must first be converted according to the mapping defined in section 3.1 of [RFC3987]. A notable example is retrieval over the HTTP protocol. The mapping involves UTF-8 encoding of non-ASCII characters, %-encoding of octets not allowed in URIs, and Punycode-encoding of domain names.
An IRI (Internationalized Resource Identifier) within an RDF graph is a Unicode string [UNICODE] that conforms to the syntax defined in RFC 3987 [RFC3987].

RDF 1.1 Concepts and Abstract Syntax

2 annotations

www.w3.org

486

If the Client does not use a WebID as the client identifier, then it MUST present a client identifier registered with the IdP via either OIDC dynamic or static registration. See also [OpenIDConnectDynamicClientRegistration].
OAuth and OIDC require the Client application to identify itself to the IdP and RS by presenting a client identifier (Client ID). Solid applications SHOULD use a WebID as their Client ID

SOLID-OIDC

2 annotations

solid.github.io

520

Shape trees marry RDF vocabularies, shapes, and resources into "little trees" that provide machine to machine interoperability, while at the same time creating concepts that humans can easily comprehend, such as medical records, notes, notebooks, calendars, and financial records.

Shape Trees Primer

1 annotation

shapetrees.org

468

Arguably the Semantic Web or Linked Data never took off, so why is Solid working with it? The Semantic Web and Linked Data principles and technologies have always meant to make data more reusable, and to make data independent from applications, which is why it is at the core of Solid.
How to integrate iOS and Android apps into Solid? It is possible for developers to take an iOS or Android app and make it Solid compatible by following the standard and supporting documentation. More details Currently there are no developer kits in development for Android or iOS. If you really want to have an app that can be installed on Android or iOS, you might consider writing it as a progressive web app or writing it as a hybrid app.
Doesn’t the Data Transfer Project fix the data concerns? The Data Transfer Project is a great start. The next step is to build a healthy array of options for users to make their data work for themselves.
Is it possible to use Solid offline (at least partially)? Eventually, yes. The Solid long term vision includes local first and a flexibility of different topologies of patch-passing sync networks. However, there are no implementations yet.
patch-passing sync networks.

Frequently Asked Questions · Solid

5 annotations

solidproject.org

510

When using Solid, how is data stored? It depends on the Pod Provider. From a user point of view, how the data is stored is not as important as how it is accessed and controlled. No matter who the Pod Provider is, in order to be Solid compliant, it has to expose data the same way: as resources in folders. However,the implementors of the standard are free to pick the underlying technologies according to their own purposes and constraints. That is why performance may vary from one Pod Provider to another.

Frequently Asked Questions · Solid

1 annotation

solidproject.org

461

These vocabularies are the ones featured in the Solid standard. Access Control List (acl) Linked Data Platform (ldp) Media types (mime) Solid terms Workspace POSIX stat User Interface (ui) Your application requires a vocabulary that you did not find on this page? Maybe it’s out there somewhere. Next, we see how to discover vocabularies.

Well-known vocabularies · Solid

1 annotation

solidproject.org

531

An Agent is a distinct individual, group, organization, or piece of software with an identity that can be strongly authenticated.

Solid Application Interoperability

1 annotation

solid.github.io

466

Each Application an Agent registers has an Application Registration. An Application Registry links to any number of Application Registrations via the interop:hasRegistration property.
An Application is a piece of software that an Agent uses to access, manipulate, and manage the data in their control, as well as the data they’ve been granted access to.

Solid Application Interoperability

2 annotations

solid.github.io

464

WebID requires that servers MUST at least be able to provide Turtle representation of profile documents, but other serialization formats of the graph are allowed, provided that agents are able to parse that serialization and obtain the graph automatically. HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serializations of the same graph at the same URL, as explained in [COOLURIS]
The server MUST provide a text/turtle [turtle] representation of the requested profile
For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI referring to the Profile Document.

WebID 1.0

3 annotations

dvcs.w3.org

544

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

ActivityPub

1 annotation

www.w3.org

530

Servers should not re-use URIs,
If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former. [Source]. Behaviour pertaining to authorization MUST precede this optional redirect [Source]
A Solid server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]
A data pod MUST implement the server part of HTTP/1.1 Authentication [RFC7235]. When a client does not provide valid credentials when requesting a resource that requires it (see WebID), the data pod MUST send a response with a 401 status code (unless 404 is preferred for security reasons).
A data pod MUST implement the server part of HTTP/1.1 Conditional Requests [RFC7232] to ensure that updates requested by clients will only be applied if given preconditions are met. It SHOULD additionally implement the server part of HTTP/1.1 Caching [RFC7234] to improve performance. A data pod MAY implement the server part of HTTP/1.1 Range Requests [RFC7233] to further improve performance for large representations.
When both http and https are supported, all http URIs MUST redirect to their https counterparts using a response with a 301 status code and a Location header.
A data pod MUST be an HTTP/1.1 server [RFC7230][RFC7231]. It SHOULD additionally be an HTTP/2 server [RFC7540] to improve performance, especially in cases where individual clients are expected to send high numbers of successive requests.

The Solid Protocol

7 annotations

solidproject.org

611

It is often the case that a group or "tree" of documents has been constructed to serve a common purpose, wherein the vast majority of URI references in these documents point to resources within the tree rather than outside it. Similarly, documents located at a particular site are much more likely to refer to other resources at that site than to resources at remote sites. Relative referencing of URIs allows document trees to be partially independent of their location and access scheme. For instance, it is possible for a single set of hypertext documents to be simultaneously accessible and traversable via each of the "file", "http", and "ftp" schemes if the documents refer to each other with relative references. Furthermore, such document trees can be moved, as a whole, without changing any of the relative references.
An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification. Our use of the terms "identify" and "identifying" refer to this purpose of distinguishing one resource from all other resources, regardless of how that purpose is accomplished (e.g., by name, address, or context). These terms should not be mistaken as an assumption that an identifier defines or embodies the identity of what is referenced, though that may be the case for some identifiers. Nor should it be assumed that a system using URIs will access the resource identified: in many cases, URIs are used to denote resources without any intention that they be accessed. Likewise, the "one" resource identified might not be singular in nature (e.g., a resource might be a named set or a mapping that varies over time).

RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax

2 annotations

tools.ietf.org

612

In particular, they MUST ignore HTTP cookies from untrusted origins.
A data pod MUST NOT assume that HTTP request headers sent by a client are valid, and MUST reject or sanitize invalid header values before processing them or incorporating them in messages sent to others. For example, values for Host and Origin MUST NOT be assumed to be free of possibly malicious sequences such as /.. or others, and invalid Origin values MUST NOT be echoed into the Access-Control-Allow-Origin response header.
A data pod MUST implement the CORS protoco
A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN]. A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [LDN].
Servers MUST NOT directly associate more than one ACL auxiliary resource to a subject resource.
When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.
The root container (pim:Storage) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with acl:Control access privilege.
When a server supports a data pod, it MUST provide one or more storages (pim:Storage) – a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).

The Solid Protocol

8 annotations

solidproject.org

537