The website uses cookies. By using this site, you agree to our use of cookies as described in the Privacy Policy.
I Agree
Diego Araújo
24 articles
My Web Markups - Diego Araújo
  • 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.
2 annotations
  • 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.
4 annotations
  • 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.
6 annotations
  • 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.
7 annotations
  • 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).
2 annotations
  • 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).
8 annotations