Linked Data Notifications
125 | 126 |-
127 |
- This version: 128 |
- https://linkedresearch.org/ldn/ 129 |
- Latest published version: 130 |
- https://www.w3.org/TR/ldn/ 131 |
- Previous version: 132 |
- https://www.w3.org/TR/2017/REC-ldn-20170502/ 133 |
-
145 |
- Notifications Inbox 146 |
- inbox/ 147 |
-
150 |
- Annotation Service 151 |
- annotation/ 152 |
-
155 |
- Published 156 | 157 |
-
160 |
- Modified 161 | 162 |
-
171 |
- Implementation reports 172 |
- https://linkedresearch.org/ldn/tests/summary 173 |
-
176 |
- Test suite 177 |
- https://linkedresearch.org/ldn/tests/ 178 |
-
181 |
- In reply to 182 |
- Social Web Working Group Charter 183 |
Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
186 | 187 |Abstract
190 |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.
192 |Status of This Document
197 |This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
199 | 200 |This document was published by the Social Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-socialweb@w3.org (subscribe, archives). All comments are welcome.
201 | 202 |Publication as a Working 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.
203 | 204 |This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
205 | 206 |This document is governed by the 1 September 2015 W3C Process Document.
207 |Introduction
212 |Data on the Web should not be locked in to particular systems or be only readable by the applications which created it. Users should be free to switch between applications and share data between them. Applications generate notifications about activities, interactions, and new information, which may be presented to the user or processed further.
214 | 215 |Linked Data Notifications (LDN) supports sharing and reuse of notifications across applications, regardless of how they were generated. This allows for more modular systems, which decouple data storage from the applications which display or otherwise make use of the data. The protocol is intended to allow senders, receivers and consumers of notifications, which are independently implemented and run on different technology stacks, to seamlessly work together, contributing to decentralisation of our interactions on the Web.
216 | 217 |Instead of treating notifications as ephemeral or non-persistent entities, this specification enables the notion of a notification as an individual entity with its own URI. As such, notifications can be retrieved and reused. We support a range of different application domains, social and otherwise, thus the contents of notifications are left up to applications to define. Authentication and verification of notifications is encouraged, but the mechanism to do so is at the discretion of receivers and consumers, as needs differ according to types of notification and different application domains.
218 | 219 |Overview
228 |A sender is triggered, either by a human or an automatic process, to deliver a notification to a server. The notification is data intended for the attention of the receiver, for example: a personal message from a friend; a pingback link; a comment on a blog post; an invitation to collaborate; a calendar reminder; a scientific observation.
236 | 237 |The sender chooses a target resource to send notifications to; the sender then discovers the location of the target’s Inbox, and sends the notification there. Any resource can advertise an Inbox. The receiver exposes the notification data (according to appropriate access control) for use by consumers.
238 | 239 |Consumers discover the location of the Inbox in the same way as the sender, and may perform further processing on the notifications, combine it with some other data, or simply present it in a suitable human-readable way.
240 |Summary
245 |Senders and consumers discover a resource’s Inbox URL through a relation in the HTTP Link header or body of the resource.
The Sender:
249 |-
250 |
- Creates the body of the notification according to the needs of application. 251 |
- Sends the notification to the Inbox URL by making a
POSTrequest, containing the body in JSON-LD or in another serialization acceptable by the server.
252 |
The Receiver:
255 |-
256 |
- Responds to
GETrequests made to the Inbox URL with a listing of the URLs of notifications that have previously been accepted.
257 | - Responds to
GETrequests made to the individual notification URLs with JSON-LD (or optionally other serializations).
258 | - Accepts
POSTrequests at the Inbox URL to create notifications.
259 | - Optionally enforces constraints on notifications sent to the Inbox. 260 |
The Consumer:
263 |-
264 |
- Retrieves the contents of the Inbox URL with a
GETrequest, and uses according to the needs of application.
265 |
Relation to Linked Data Platform
271 |LDN is a specialized use of Linked Data Platform [LDP] for sending and consuming notifications. It is not dependent on a complete implementation of LDP, but an easy-to-implement subset. Having knowledge of LDP is not required to understand this specification, but those who do will find some concepts familiar. We describe the particular features necessary to make it easy to exchange notifications in a decentralised, interoperable way. An LDN Inbox is comparable to an LDP BasicContainer.
Conformance
280 |The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative.
282 | 283 |Conformance Classes
285 |LDN implementations may be senders, receivers or consumers. The conformance criteria for each of these roles are described in their respective sections of this specification.
287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 |Protocol
346 |This section describes the discovery of the URL to which notifications are delivered or read from (the Inbox) and the delivery mechanism. Notification contents are described in Payload.
348 | 349 |Discovery
351 |An Inbox, the endpoint to which notifications are sent or from which they are consumed, can be discovered from any resource, for example a blog post, a user profile, a dataset, a video. The starting point for discovery is the resource which the notification is to or about: the target. Choosing the most appropriate target resource from which to begin discovery is at the discretion of the sender or consumer, since any resource (RDF or non-RDF) may have its own Inbox.
353 | 354 |Senders and consumers do the following to discover the Inbox URL:
355 |-
356 |
- make an HTTP
HEADorGETrequest on the target URL, and use theLinkheader with arelvalue ofhttp://www.w3.org/ns/ldp#inbox.
357 | - make an HTTP
GETrequest on the target URL to retrieve an RDF representation [RDF 1.1], whose encoded RDF graph contains a relation of typehttp://www.w3.org/ns/ldp#inbox. The subject of that relation is target and the object is the Inbox.
358 |
These may be carried out in either order, but if the first fails to result in an Inbox the second MUST be tried. Senders and consumers SHOULD omit the Link header discovery when specifically targeting URIs with fragment identifiers.
Note
364 |If the target contains a fragment identifier, the fragment is not part of the request to the server. Senders and consumers should be aware that any Inbox found in the Link header will be for the resolved URL, without the fragment. See [Cool URIs for the Semantic Web - Hash URIs].
A resource MUST advertise only one Inbox. One Inbox MAY be used by multiple resources, for example using the same Inbox for replies to all of my blog posts and shares of all of my photos.
370 | 371 |Discovery example 1: Link header
373 |379 |HEAD /article HTTP/1.1374 |Host: example.org375 |Accept: application/ld+json376 |377 |HTTP/1.1 200 OK378 |Link: <http://example.org/inbox/>; rel="http://www.w3.org/ns/ldp#inbox"
HEAD request, and receiving a Link header.Discovery example 2: JSON-LD
384 |396 |GET /profile HTTP/1.1385 |Host: example.org386 |Accept: application/ld+json387 |388 |HTTP/1.1 200 OK389 |Content-Type: application/ld+json390 |391 |{392 |"@context": "http://www.w3.org/ns/ldp",393 |"@id": "http://example.org/profile",394 |"inbox": "http://example.org/inbox/"395 |}
GET request to retrieve JSON-LD. Response in JSON-LD compact form.Discovery example 3: Visible HTML
401 |411 |GET /event HTTP/1.1402 |Host: example.org403 |Accept: text/html, application/ld+json404 |405 |HTTP/1.1 200 OK406 |Content-Type: text/html;charset=utf-8407 |408 |<p about="http://example.org/event" typeof="http://schema.org/Event" lang="en">409 |<a rel="http://www.w3.org/ns/ldp#inbox" href="/inbox/">RSVP</a> to event410 |</p>
GET request to retrieve HTML. The Inbox link is visible to humans, and marked up with RDFa so the Inbox URL can be discovered by machines.Discovery example 4: Invisible HTML
416 |424 |GET /article HTTP/1.1417 |Host: example.org418 |Accept: text/html, application/ld+json419 |420 |HTTP/1.1 200 OK421 |Content-Type: text/html;charset=utf-8422 |423 |<link href="/inbox/" rel="http://www.w3.org/ns/ldp#inbox" />
GET request to retrieve HTML. An invisible Inbox expressed with a link element, marked up with RDFa for machine discovery.Discovery example 5: Invisible HTML
429 |439 |GET /article HTTP/1.1430 |Host: example.org431 |Accept: text/html, application/ld+json432 |433 |HTTP/1.1 200 OK434 |Content-Type: text/html;charset=utf-8435 |436 |<section id="results" about="#results"437 |property="http://www.w3.org/ns/ldp#inbox" resource="/inbox/">438 |</section>
GET request to retrieve HTML. An invisible Inbox expressed with the RDFa property attribute, so that a resource identified with a fragment URI may be the target.Discovery example 6: Turtle
444 |453 |GET / HTTP/1.1445 |Host: csarven.ca446 |Accept: text/turtle, application/ld+json447 |448 |HTTP/1.1 200 OK449 |Content-Type: text/turtle;charset=utf-8450 |451 |<http://csarven.ca/#i>452 |<http://www.w3.org/ns/ldp#inbox> <http://csarven.ca/inbox/> .
GET request to retrieve Turtle.Please see Social Web Protocols for recommendations on how to carry out discovery, particularly with consideration to servers which may be unaware of this protocol.
457 |Sender
462 |Following discovery, senders who want to send notifications MUST deliver them through a POST request to the Inbox URL. Senders can expect a 201 Created (with a Location Link header) or a 202 Accepted in response to a successful request.
The sender MAY use an OPTIONS request to determine the RDF content types accepted by the server, and serialize the notification in the request body according to the value of the Accept-Post header [Accept-Post] returned. Otherwise, the body of the POST request MUST contain the notification payload in JSON-LD with header Content-Type: application/ld+json. The Content-Type header MAY include a profile URI [RFC6906].
The sender MAY include additional headers or content for the purposes of authentication or authorization e.g., Authorization: Bearer XXX.
If the sender has any services that listen on localhost that do not require authentication, it’s possible for a malicious script to run at the Inbox endpoint that could cause the sender to make an arbitrary POST request to itself. Senders SHOULD NOT make POST requests to the Inbox that are localhost or a loopback IP address.
Sending example request
473 |487 |POST /inbox/ HTTP/1.1474 |Host: example.org475 |Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"476 |Content-Language: en477 |478 |{479 |"@context": "https://www.w3.org/ns/activitystreams",480 |"@id": "",481 |"@type": "Announce",482 |"actor": "https://rhiaro.co.uk/#me",483 |"object": "http://example.net/note",484 |"target": "http://example.org/article",485 |"updated": "2016-06-28T19:56:20.114Z"486 |}
Sending example response
492 |494 |HTTP/1.1 201 Created493 |Location: http://example.org/inbox/5c6ca040
POST request on an Inbox.Receiver
501 |Receivers MUST support GET and POST requests on the Inbox URL. In LDP terms, an Inbox is a Container.
Receiving notifications
506 |Upon receipt of a POST request, if the notification resource was processed successfully, receivers MUST respond with status code 201 Created and the Location header set to the URL from which the notification data can be retrieved (see Consumer). If the request was queued to be processed asynchronously, the receiver MUST respond with a status code of 202 Accepted and include information about the status of the request in the body of the response.
Receivers which enforce constraints on the notifications (see Constraints) SHOULD fail to process the notification if the constraints are not met and return the appropriate 4xx error code.
Receivers MUST accept notifications where the request body is JSON-LD, with the Content-Type: application/ld+json, which MAY include a profile URI [RFC6906].
Receivers MAY accept other RDF content types (e.g., text/turtle, text/html), and if so, SHOULD advertise the content types they accept with an Accept-Post [Accept-Post] header in response to an OPTIONS request on the Inbox URL.
Receiver example 1: options response
517 |523 |OPTIONS /inbox/ HTTP/1.1518 |Host: example.org519 |520 |HTTP/1.1 200 OK521 |Allow: GET, HEAD, OPTIONS, POST522 |Accept-Post: application/ld+json, text/turtle
OPTIONS request with Accept-Post.Receiver example 2: post response
528 |529 |546 |POST /inbox/ HTTP/1.1530 |Host: example.org531 |Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"532 |Content-Language: en533 |534 |{535 |"@context": "https://www.w3.org/ns/activitystreams",536 |"@id": "",537 |"@type": "Announce",538 |"actor": "https://rhiaro.co.uk/#me",539 |"object": "http://example.net/note",540 |"target": "http://example.org/article",541 |"updated": "2016-06-28T19:56:20.114Z"542 |}543 |544 |HTTP/1.1 201 Created545 |Location: http://example.org/inbox/92d72f00
POST request on the Inbox by creating a notification.Making Inbox contents available to consumers
553 |A successful GET request on the Inbox MUST return a HTTP 200 OK with the URIs of notifications, subject to the requester’s access (returning 4xx error codes as applicable). Receivers MAY list only URIs of notifications in the Inbox that the consumer is able to access. The Inbox URL MUST use the http://www.w3.org/ns/ldp#contains predicate to refer to the notifications.
Each notification MUST be an RDF source. If non-RDF resources are returned, the consumer MAY ignore them. A successful GET request on the notification URI MUST return a HTTP 200 OK subject to the requester’s access (returning 4xx error codes as applicable).
The JSON-LD content type MUST be available for all resources, but clients may send Accept headers preferring other content types (RFC7231 Section 3.4 - Content Negotiation). If the client sends no Accept header, the server may send the data in JSON-LD or any format which faithfully conveys the same information (e.g., Turtle).
Any additional description about the Inbox itself MAY also be returned (e.g., Constraints).
561 | 562 |Note
564 |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.
566 |Receiver example 3: get response
571 |588 |GET /inbox/ HTTP/1.1572 |Host: example.org573 |Accept: application/ld+json574 |Accept-Language: en-GB,en;q=0.8, en-US;q=0.6575 |576 |HTTP/1.1 200 OK577 |Content-Type: application/ld+json578 |Content-Language: en579 |580 |{581 |"@context": "http://www.w3.org/ns/ldp",582 |"@id": "http://example.org/inbox/",583 |"contains": [584 |"http://example.org/inbox/5c6ca040",585 |"http://example.org/inbox/92d72f00"586 |]587 |}
GET request on the Inbox with a listing of notifications.Sender Verification
595 |Receivers SHOULD verify the sender of the notification. For example:
597 |-
598 |
- by having a whitelist of senders with write access to the Inbox 599 |
- requiring authentication to enforce receiver’s knowledge of every sender 600 |
- retrieving a copy of the notification from the sender’s domain to verify its origin 601 |
- checking a digital signature which accompanies the notification 602 |
Preventing Abuse
608 |Receivers SHOULD use constraints to filter unwarranted notifications from being created on the server and exposed by the Inbox.
610 | 611 |Receivers could consider implementing access control on the Inbox URL to restrict writing to a whitelist of trusted senders.
612 |Consumer
619 |Consumers retrieve the URIs of notifications in an Inbox through making a GET request on the Inbox URL (to find this URL, see discovery).
The URIs of the notifications MUST be discoverable through the http://www.w3.org/ns/ldp#contains predicate of the Inbox URL (see example for Inbox content).
When retrieving the Inbox or the individual notifications, the consumer SHOULD explicitly set the Accept header to indicate preferred content types, including for JSON-LD. Fetching the individual notifications — if any, how many, or according to a particular criteria (e.g., content-length, timestamp) — is at the discretion of the consumer.
The consumer MAY include additional headers or content for the purposes of authentication or authorization.
627 | 628 |Consumers MAY perform additional fetching or inferring of information from the payload (e.g., dereferencing resources referenced in the notification to fetch their contents) at their discretion. Consumers MAY also want to check the notifications against any constraints as announced by an Inbox before further processing or use.
629 | 630 |Note
632 |The fetched URI for a notification may contain RDF statements with one or more subject IRIs different from the requested URI itself. Consumers should also not assume that the notification contains any triples with the requested URI as the subject. This is also pertinent when the body of the notification uses relative IRIs. Implementations may wish to treat notification URIs as graphs which contain the RDF from the notification payload.
634 |Note
639 |Consumers should be aware that anything can be posted to an Inbox (depending on restrictions in place by the receiver, which are not defined by this protocol), so when it comes to making use of notification data consumers may want to take precautions when ascertaining the veracity of the contents.
641 |Consumer example: getting a notification
646 |679 |GET /inbox/14a792f0 HTTP/1.1647 |Host: example.org648 |Accept: application/ld+json, text/turtle, application/xhtml+xml, text/html649 |Accept-Language: en-GB,en;q=0.8, en-US;q=0.6650 |651 |HTTP/1.1 200 OK652 |Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"653 |Content-Language: en654 |655 |{656 |"@context": [657 |"https://www.w3.org/ns/activitystreams",658 |{ "@language": "en" }659 |],660 |"@id": "http://example.org/inbox/14a792f0",661 |"@type": "Announce",662 |"actor": {663 |"@id": "http://csarven.ca/#i",664 |"name": "Sarven Capadisli"665 |},666 |"object": {667 |"@context": "http://www.w3.org/ns/anno.jsonld",668 |"@id": "http://example.net/note",669 |"@type": "Annotation",670 |"motivation": "http://www.w3.org/ns/oa#assessing",671 |"rights": "http://creativecommons.org/licenses/by/4.0/"672 |},673 |"target": "http://example.org/article",674 |"updated": {675 |"@type": "http://www.w3.org/2001/XMLSchema#dateTime",676 |"@value": "2016-06-28T19:56:20.114Z"677 |}678 |}
Payload
688 |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.
690 | 691 |Payload Examples
693 |This section is non-normative.
695 | 696 |Payload example 1
698 |703 |{699 |"@context": "http://schema.org/",700 |"@id": "http://example.net/note#foo",701 |"citation": { "@id": "http://example.org/article#results" }702 |}
Payload example 2
708 |717 |{709 |"@context": "https://www.w3.org/ns/activitystreams",710 |"@id": "",711 |"@type": "Announce",712 |"actor": "https://rhiaro.co.uk/#me",713 |"object": "http://example.net/note",714 |"target": "http://example.org/article",715 |"updated": "2016-06-28T19:56:20.114Z"716 |}
Payload example 3
722 |729 |{723 |"@context": { "pingback": "http://purl.org/net/pingback/" },724 |"@id": "",725 |"@type": "pingback:Item",726 |"pingback:source": { "@id": "http://example.net/note#foo" },727 |"pingback:target": { "@id": "http://example.org/article#results" }728 |}
Payload example 4
734 |741 |{735 |"@context": "http://schema.org/",736 |"@id": "",737 |"@type": "RsvpAction",738 |"event": { "@id": "http://example.org/event" },739 |"agent": { "@id": "https://rhiaro.co.uk/#me" }740 |}
A notification may contain arbitrary information, including references to multiple resources with their own URIs, without necessarily referring to one particular external resource or origin for the data. The receiver is expected to return all triples that were initially sent when such a notification is requested by a consumer.
745 | 746 |Payload example 5
748 |770 |{749 |"@context": {750 |"@language": "en",751 |"sioc": "http://rdfs.org/sioc/ns#",752 |"foaf": "http://xmlns.com/foaf/0.1/"753 |},754 |"@id": "",755 |"@type": "sioc:Comment",756 |"sioc:reply_of": { "@id": "http://example.org/article" },757 |"sioc:created_at": {758 |"@type": "http://www.w3.org/2001/XMLSchema#dateTime",759 |"@value": "2015-12-23T16:44:21Z"760 |},761 |"sioc:content": "This is a great article!",762 |"sioc:has_creator": {763 |"@id": "http://example.org/profile",764 |"@type": "sioc:UserAccount",765 |"sioc:account_of": { "@id": "http://example.org/profile#alice" },766 |"sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },767 |"foaf:name": "Alice"768 |}769 |}
Payload example 6
775 |804 |{776 |"@context": [{"prov": "http://www.w3.org/ns/prov#"}],777 |"@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",778 |"@type": "prov:Activity",779 |"http://www.w3.org/2000/01/rdf-schema#label": {780 |"@language": "en",781 |"@value": "Make it so"782 |},783 |"prov:endedAtTime": {784 |"@type": "http://www.w3.org/2001/XMLSchema#dateTime",785 |"@value": "2016-06-14T20:57:39.000Z"786 |},787 |"prov:generated": {788 |"@id": "http://example.org/entity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",789 |"@type": "prov:Entity",790 |"prov:specializationOf": { "@id": "http://example.org/entity/file" },791 |"prov:wasGeneratedBy": {792 |"@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7"793 |}794 |},795 |"prov:wasAssociatedWith": {796 |"@id": "http://csarven.ca/#i",797 |"@type": "prov:Agent",798 |"http://xmlns.com/foaf/0.1/name": {799 |"@language": "hy",800 |"@value": "Սարվէն Չափատիշլի"801 |}802 |}803 |}
Security, Privacy and Content Considerations
813 |This section is non-normative. Normative requirements for security and privacy are called out in the section of the specification to which they are most applicable.
815 | 816 |Constraints
818 |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.
Target Ownership
825 |Publishers of the resources advertising an Inbox (target) should do so on a server they trust. Publishers must be aware that third-party access to headers or content could result in notifications being redirected.
827 |Subscribing to Notifications
832 |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.
834 |Activity Streams 2.0 Support
839 |Receiver implementations that wish to support Activity Streams 2.0 Core can see Social Web Protocols - Inbox Interop for Content-Type and vocabulary equivalences.
841 |Natural Language Content
846 |Building an international base of users is important in a federated network. Some LDN interactions can return content with natural language text, such as HTML fragments, or summary fields. Providing multiple language representations of each item might not be feasible in all circumstances. Implementations are encouraged to provide means of discovering the available languages and/or negotiating the language returned, such as using the HTTP Accept-Language header to negotiate and select the most appropriate language representation to send for a given request.
Authenticated Inboxes
853 |If a receiver expects senders or consumers to authenticate, it should check the validity of their credentials before returning any other data, including other error codes. For example, the receiver should not first check for the existence of the inbox and return 404 Not Found if the requester has not been verified.
Authentication involving token passing must be done over HTTPS.
856 |Security and Privacy Review
861 |These questions provide an overview of security and privacy considerations for this specification as guided by Self-Review Questionnaire: Security and Privacy.
863 | 864 |-
865 |
- Does this specification deal with personally-identifiable information?
- Notification payloads may contain any data including that which identifies the sender or the receiver. Access to notification data is under the control of the receiver. In the case of sending sensitive information, the sender should be aware that the receiver may implement access control on the Inbox that allows for public reading of the contents. 866 |
- Does this specification deal with high-value data?
- Same implications as personally-identifiable information in notification payload (as mentioned above). 867 |
- Does this specification introduce new state for an origin that persists across browsing sessions?
- No. 868 |
- Does this specification expose persistent, cross-origin state to the web?
- No. 869 |
- Does this specification expose any other data to an origin that it doesn’t currently have access to?
- No. 870 |
- Does this specification enable new script execution/loading mechanisms?
- No. 871 |
- Does this specification allow an origin access to a user’s location?
- No. 872 |
- Does this specification allow an origin access to sensors on a user’s device?
- No. 873 |
- Does this specification allow an origin access to aspects of a user’s local computing environment?
- No. 874 |
- Does this specification allow an origin access to other devices?
- No. 875 |
- Does this specification allow an origin some measure of control over a user agent’s native UI?
- No. 876 |
- Does this specification expose temporary identifiers to the web?
- No. 877 |
- Does this specification distinguish between behavior in first-party and third-party contexts?
- No. 878 |
- How should this specification work in the context of a user agent’s "incognito" mode?
- Works in such a way that the website would not be able to determine that the user was in "incognito". 879 |
- Does this specification persist data to a user’s local device?
- No. 880 |
- Does this specification have a "Security Considerations" and "Privacy Considerations" section?
- :) 881 |
- Does this specification allow downgrading default security characteristics?
- No. 882 |
Exit Criteria
890 |This specification advanced to Proposed Recommendation with at least two independent, interoperable implementations of each feature. Each feature was implemented by a different set of products. There was no requirement that all features needed to be implemented by a single product.
892 | 893 |-
894 |
- Independent implementations are developed by different parties and cannot share, reuse or derive form another qualifying implementation code which is directly pertinent to the implementation of this specification. 895 |
- Interoperability occurs between senders and receivers, or between consumers and receivers, when the sender/consumer makes a request to the receiver, and the receiver sends the expected response, as defined by this specification. 896 |
- An implementation is an LDN sender, receiver or consumer which implements the corresponding conformance class of the specification. 897 |
For the purposes of evaluating exit criteria, each of the following was considered a feature:
900 |-
901 |
- Advertising the Inbox of a given resource through the
Linkheader.
902 | - Advertising the Inbox of a given resource through the body of the resource. 903 |
- Sending a notification to the Inbox of a given target. 904 |
- Receiving a notification and responding with the appropriate status code according to how it was processed and if it was accepted. Responding to
GETrequests on the Inbox with the Inbox listing, and responding toGETrequests on the individual notifications with their representations.
905 | - Reading the Inbox listing of a given target. 906 |
- Reading the individual notifications in the Inbox of a given target. 907 |
Acknowledgements
913 |We would like to thank and acknowledge the following people for their contributions to this specification:
915 | 916 |-
917 |
- Aaron Coburn 918 |
- Addison Phillips 919 |
- Adrian Pohl 920 |
- Albert Meroño Peñuela 921 |
- Alex Kearney 922 |
- Andrei Vlad Sambra 923 |
- Andreas Kuckartz 924 |
- Bart van Leeuwen 925 |
- Benjamin Goering 926 |
- Benjamin Young 927 |
- Bernadette Hyland 928 |
- Chris Webber 929 |
- Christian M. Amsüss 930 |
- Dan Brickley 931 |
- Dmitri Zagidulin 932 |
- Erik Wilde 933 |
- Fabien Gandon 934 |
- Felix Sasaki 935 |
- Graham Klyne 936 |
- Henry Story 937 |
- Jeffrey Witt 938 |
- John Klensin 939 |
- Kingsley Idehen 940 |
- Kjetil Kjernsmo 941 |
- Melvin Carvalho 942 |
- Natanael Arndt 943 |
- Nick Smith 944 |
- Nicola Greco 945 |
- Nuno Freire 946 |
- Raphaël Troncy 947 |
- Richard Ishida 948 |
- Rob Sanderson 949 |
- Sandro Hawke 950 |
- Stian Soiland-Reyes 951 |
- Tim Berners-Lee 952 |
- Xavier Sumba 953 |
Change Log
959 |This section is non-normative.
961 | 962 |REC-ldn-20170502 ← PR-ldn-20170321 ← CR-ldn-20170223 ← CR-ldn-20161101 ← WD-ldn-20161011 ← WD-ldn-20160926 ← WD-ldn-20160913 ← WD-ldn-20160824 ← WD-ldn-20160726
963 | 964 |Changes from 21 March 2017 PR to this version
966 |-
968 |
- Fix a syntax error in an example 969 |
- Add 'in reply to' link to Social Web Group Charter 970 |
- Add links to past versions of the spec 971 |
- Update references 972 |
Changes from 23 February 2017 CR to 21 March 2017 PR
978 |-
980 |
- Update acknowledgements 981 |
Changes from 1 November 2016 CR to 23 February 2017 CR
987 |-
989 |
- Add Acknowledgements 990 |
- Clarify the implied response codes for notifications and request URI in note 991 |
- Update references 992 |
Changes from 11 October 2016 WD to 1 November 2016 CR
998 |-
1000 |
- Add Natural Language Content section under Considerations 1001 |
- Fix reference to PubSub 1002 |
- Add URLs to implementation reports and test suite 1003 |
- Add legend to SVG 1004 |
- Fix AS2 bib fragment 1005 |
- Reword payload verification 1006 |
- Added 'Authenticated Inboxes' security guidance 1007 |
Changes from 26 September 2016 WD to 11 October 2016 WD
1013 |-
1015 |
- Add and update examples 1016 |
- Improve discovery wording for HTTP HEAD/GET 1017 |
- Editorial; grammar, paraphrasing 1018 |
- Fix Accept-Post reference and be explicit about its appearance in OPTIONS 1019 |
- Integrate feedback from internationalisation review (examples) 1020 |
Changes from 13 September 2016 WD to 26 September 2016 WD
1026 |-
1028 |
- Fix typos and links 1029 |
- Reorder sections to Sending, Receiving, Consuming 1030 |
- Update examples 1031 |
- Add reference to RFC7231 1032 |
- Clarify wording for URI discovery 1033 |
- Add sub-headings for the non-normative sections under Considerations 1034 |
- Add overview diagram 1035 |
- Add non-normative sub-section for Retry Discovery under Considerations 1036 |
- Mention being courteous for Discovery 1037 |
- Move Preventing Abuse to respective normative sections 1038 |
- Move Sender Verification to go under Receiving 1039 |
- Move ActivitStreams 2.0 Support to Considerations 1040 |
- Move Payload Verification to Consuming as a Note 1041 |
- Move normative and some non-normatives from Considerations to earlier sections 1042 |
- Add Security and Privacy Review section 1043 |
- Update Introduction 1044 |
Changes from 24 August 2016 WD to 13 September 2016 WD
1050 |-
1052 |
- Typos, punctuation, naming 1053 |
- Add Exit Criteria 1054 |
- Clarify behaviour when Accept header is used and omitted 1055 |
- Add a note about subject of the relation for the Link header field 1056 |
- Add GET for possible Link header, clarify subject URI (for its Inbox) in target URL 1057 |
- Revise Abstract 1058 |
- Add consideration about target ownership 1059 |
- Mention 'any resource can have its own inbox' 1060 |
- Add Subscribing to Notifications section 1061 |
Changes from 27 July 2016 WD to 24 August 2016 WD
1067 |-
1069 |
- Improve examples; update, syntactical fixes, @context in https 1070 |
- Typos, punctuation, naming 1071 |
- Use informative discretion about the payload 1072 |
References
1080 |Normative References
1083 |-
1085 |
- [ldp] 1086 |
- Steve Speicher; John Arwe; Ashok Malhotra. W3C. Linked Data Platform 1.0. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/ 1087 |
- [rdf11-concepts] 1088 |
- Richard Cyganiak; David Wood; Markus Lanthaler. W3C. RDF 1.1 Concepts and Abstract Syntax. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/ 1089 |
- [rfc2119] 1090 |
- S. Bradner. IETF. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 1091 |
- [rfc6906] 1092 |
- E. Wilde. IETF. The 'profile' Link Relation Type. March 2013. Informational. URL: https://tools.ietf.org/html/rfc6906 1093 |
Informative References
1099 |-
1101 |
- [accept-post] 1102 |
- Steve Speicher; John Arwe; Ashok Malhotra. W3C. The Accept-Post Response Header (Linked Data Platform 1.0). 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/#header-accept-post 1103 |
- [activitypub] 1104 |
- Christopher Webber; Jessica Tallon; Owen Shepherd. W3C. ActivityPub. 13 April 2017. W3C Candidate Recommendation. URL: https://www.w3.org/TR/activitypub/ 1105 |
- [activitystreams-core] 1106 |
- James Snell; Evan Prodromou. W3C. Activity Streams 2.0. 13 April 2017. W3C Proposed Recommendation. URL: https://www.w3.org/TR/activitystreams-core/ 1107 |
- [annotation-protocol] 1108 |
- Robert Sanderson. W3C. Web Annotation Protocol. 23 February 2017. W3C Proposed Recommendation. URL: https://www.w3.org/TR/annotation-protocol/ 1109 |
- [cooluris] 1110 |
- Leo Sauermann; Richard Cyganiak. W3C. Cool URIs for the Semantic Web. 3 December 2008. W3C Note. URL: https://www.w3.org/TR/cooluris 1111 |
- [ldp-paging] 1112 |
- Steve Speicher; John Arwe; Ashok Malhotra. W3C. Linked Data Platform Paging 1.0. 30 June 2015. W3C Note. URL: https://www.w3.org/TR/ldp-paging/ 1113 |
- [websub] 1114 |
- Julien Genestoux; Aaron Parecki. W3C. WebSub. 11 April 2017. W3C Candidate Recommendation. URL: https://www.w3.org/TR/websub/ 1115 |
- [rfc6455] 1116 |
- I. Fette; A. Melnikov. IETF. The WebSocket Protocol. December 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6455 1117 |
- [rfc7231] 1118 |
- R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7231 1119 |
- [security-privacy-questionnaire-20151210] 1120 |
- Mike West. W3C. Self-Review Questionnaire: Security and Privacy. 10 December 2015. W3C Note. URL: https://www.w3.org/TR/2015/NOTE-security-privacy-questionnaire-20151210/ 1121 |
- [shacl] 1122 |
- Holger Knublauch; Dimitris Kontokostas. W3C. Shapes Constraint Language (SHACL). 2 February 2017. W3C Working Draft. URL: https://www.w3.org/TR/shacl/ 1123 | 1124 |
- Amy Guy. W3C. Social Web Protocols. 2 November 2016. W3C Working Draft. URL: https://www.w3.org/TR/social-web-protocols/ 1125 |
- [webpush] 1126 |
- M. Thomson; E. Damaggio; B. Raymor. IETF. Generic Event Delivery Using HTTP Push. December 2016. Proposed Standard. URL: https://tools.ietf.org/html/rfc8030 1127 |
Social Web Working Group
221 |LDN is one of several related specifications being produced by the Social Web Working Group. Implementers interested in alternative approaches and complementary protocols should start by reading the overview document Social Web Protocols. Specific subsections of Social Web Protocols are referenced throughout this specification to highlight points of extensibility or interoperability with other protocols.
223 |