idnits 2.17.1 draft-dunglas-mercure-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: An application CAN send events directly to subscribers without using an external hub server, if it is able to do so. In this case, it *MAY NOT* implement the endpoint to publish updates. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Also, when the client is a web browser, the JWT SHOULD not be made accessible to JavaScript scripts for resilience against Cross-site Scription (XSS) attacks (https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)). It's the main reason why, when the client is a web browser, using "HttpOnly" cookies as the authorization mechanism SHOULD always be preferred. -- The document date (3 April 2020) is 1477 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 7386 (Obsoleted by RFC 7396) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Dunglas 3 Internet-Draft Les-Tilleuls.coop 4 Intended status: Informational 3 April 2020 5 Expires: 5 October 2020 7 The Mercure Protocol 8 draft-dunglas-mercure-05 10 Abstract 12 Mercure is a protocol enabling the pushing of data updates to web 13 browsers and other HTTP clients in a fast, reliable and battery- 14 efficient way. It is especially useful for publishing real-time 15 updates of resources served through web APIs to reactive web and 16 mobile apps. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 5 October 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Subscription . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5.1. Publishers . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.2. Subscribers . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Reconnection and State Reconciliation . . . . . . . . . . . . 9 59 7. Subscription Events . . . . . . . . . . . . . . . . . . . . . 10 60 8. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 11 63 9.2. Link Relation Types Registry . . . . . . . . . . . . . . 11 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 66 12. Informative References . . . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 69 1. Terminology 71 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 72 *SHOULD NOT*, RECOMMENDED, MAY, and OPTIONAL, when they appear in 73 this document, are to be interpreted as described in [RFC2119]. 75 * Topic: The unit to which one can subscribe to changes. The topic 76 MUST be identified by an IRI [RFC3987] or by a string. Using an 77 HTTPS [RFC7230] or HTTP [RFC7230] URI [RFC3986] is RECOMMENDED. 79 * Publisher: An owner of a topic. Notifies the hub when the topic 80 feed has been updated. As in almost all pubsub systems, the 81 publisher is unaware of the subscribers, if any. Other pubsub 82 systems might call the publisher the "source". Typically a 83 website or a web API, but can also be a web browser. 85 * Subscriber: A client application that subscribes to real-time 86 updates of topics. Typically a Progressive Web App or a Mobile 87 App, but can also be a server. 89 * Target: A subscriber, or a group of subscribers. A publisher is 90 able to securely dispatch updates to specific targets. The target 91 MUST be identified by an IRI [!@RFC3987] or by a string. Using an 92 HTTPS [RFC7230] or HTTP [RFC7230] URI is RECOMMENDED. 94 * Hub: A server that handles subscription requests and distributes 95 the content to subscribers when the corresponding topics have been 96 updated. Any hub MAY implement its own policies on who can use 97 it. 99 2. Discovery 101 The URL of the hub SHOULD should be the "well-known" [RFC5785] fixed 102 path "/.well-known/mercure". 104 If the publisher is a server, it SHOULD advertise the URL of one or 105 more hubs to the subscriber, allowing it to receive live updates when 106 topics are updated. If more than one hub URL is specified, it is 107 RECOMMENDED that the publisher notifies each hub, so the subscriber 108 MAY subscribe to one or more of them. 110 The publisher SHOULD include at least one Link Header [RFC5988] with 111 "rel=mercure" (a hub link header). The target URL of these links 112 MUST be a hub implementing the Mercure protocol. 114 The publisher MAY provide the following target attributes in the Link 115 Headers: 117 * "last-event-id": the globally unique identifier of the last event 118 dispatched by the publisher at the time of the generation of this 119 resource. If provided, it MUST be passed to the hub through a 120 query parameter called "Last-Event-ID" and will be used to ensure 121 that possible updates having been made during between the resource 122 generation time and the connection to the hub are not lost. See 123 section #Re-Connection-and-State-Reconciliation. If this 124 attribute is provided, the publisher MUST always set the "id" 125 parameter when sending updates to the hub. 127 * "content-type": the content type of the updates that will pushed 128 by the hub. If omitted, the subscriber MUST assume that the 129 content type will be the same as that of the original resource. 130 Setting the "content-type" attribute is especially useful to hint 131 that partial updates will be pushed, using formats such as JSON 132 Patch [RFC6902] or JSON Merge Patch [RFC7386]. 134 * "key-set=": the key(s) to decrypt updates encoded in the 135 JWKS (JSON Web Key Set) format (see the Encryption section). 137 All these attributes are optional. 139 The publisher MAY also include one Link Header [RFC5988] with 140 "rel=self" (the self link header). It SHOULD contain the canonical 141 URL for the topic to which subscribers are expected to use for 142 subscriptions. If the Link with "rel=self" is omitted, the current 143 URL of the resource MUST be used as a fallback. 145 Minimal example: 147 GET /books/foo.jsonld HTTP/1.1 148 Host: example.com 150 HTTP/1.1 200 Ok 151 Content-type: application/ld+json 152 Link: ; rel="mercure" 154 {"@id": "/books/foo.jsonld", "foo": "bar"} 156 Links embedded in HTML or XML documents (as defined in the WebSub 157 recommendation) MAY also be supported by subscribers. 159 Note: the discovery mechanism described in this section is strongly 160 inspired from the one specified in the WebSub recommendation 161 (https://www.w3.org/TR/websub/#discovery). 163 3. Subscription 165 The subscriber subscribes to a URL exposed by a hub to receive 166 updates from one or many topics. To subscribe to updates, the client 167 opens an HTTPS connection following the Server-Sent Events 168 specification (https://html.spec.whatwg.org/multipage/server-sent- 169 events.html) to the hub's subscription URL advertised by the 170 publisher. The "GET" HTTP method must be used. The connection 171 SHOULD use HTTP/2 to leverage mutliplexing and other advanced 172 features of this protocol. 174 The subscriber specifies the list of topics to get updates from by 175 using one or several query parameters named "topic". The value of 176 these query parameters MUST be URI templates [RFC6570]. 178 Note: a URL is also a valid URI template. 180 The protocol doesn't specify the maximum number of "topic" parameters 181 that can be sent, but the hub MAY apply an arbitrary limit. 183 The EventSource JavaScript interface 184 (https://html.spec.whatwg.org/multipage/server-sent-events.html#the- 185 eventsource-interface) MAY be used to establish the connection. Any 186 other appropriate mechanism including, but not limited to, readable 187 streams (https://developer.mozilla.org/en- 188 US/docs/Web/API/Streams_API/Using_readable_streams) and 189 XMLHttpRequest (https://developer.mozilla.org/en- 190 US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest) (used by popular 191 polyfills) MAY also be used. 193 The hub sends updates concerning all subscribed resources matching 194 the provided URI templates and the provided targets (see section 195 #Authorization). If no targets are specified, the update is 196 dispatched to all subscribers. The hub MUST send these updates as 197 text/event-stream compliant events 198 (https://html.spec.whatwg.org/multipage/server-sent-events.html#sse- 199 processing-model). 201 The "data" property MUST contain the new version of the topic. It 202 can be the full resource, or a partial update by using formats such 203 as JSON Patch "@RFC6902" or JSON Merge Patch "@RFC7386". 205 All other properties defined in the Server-Sent Events specification 206 MAY be used and SHOULD be supported by hubs. 208 The resource SHOULD be represented in a format with hypermedia 209 capabilities such as JSON-LD [W3C.REC-json-ld-20140116], Atom 210 [RFC4287], XML [W3C.REC-xml-20081126] or HTML 211 [W3C.REC-html52-20171214]. 213 Web Linking [RFC5988] SHOULD be used to indicate the IRI of the 214 resource sent in the event. When using Atom, XML or HTML as the 215 serialization format for the resource, the document SHOULD contain a 216 "link" element with a "self" relation containing the IRI of the 217 resource. When using JSON-LD, the document SHOULD contain an "@id" 218 property containing the IRI of the resource. 220 Example: 222 // The subscriber subscribes to updates 223 // for the https://example.com/foo topic 224 // and to any topic matching https://example.com/books/{name} 225 const url = new URL('https://example.com/.well-known/mercure'); 226 url.searchParams.append('topic', 'https://example.com/foo'); 227 url.searchParams.append('topic', 'https://example.com/bar/{id}'); 229 const eventSource = new EventSource(url); 231 // The callback will be called every time an update is published 232 eventSource.onmessage = function ({data}) { 233 console.log(data); 234 }; 236 The hub MAY require that subscribers are authorized to receive 237 updates. 239 4. Publication 241 The publisher send updates by issuing "POST" HTTPS requests on the 242 hub URL. When it receives an update, the hub dispatches it to 243 subscribers using the established server-sent events connections. 245 An application CAN send events directly to subscribers without using 246 an external hub server, if it is able to do so. In this case, it 247 *MAY NOT* implement the endpoint to publish updates. 249 The request MUST be encoded using the "application/x-www-form- 250 urlencoded" format and contain the following data: 252 * "topic": IRIs of the updated topic. If this key is present 253 several times, the first occurrence is considered to be the 254 canonical URL of the topic, and other ones are considered to be 255 alternate URLs. The hub MUST dispatch this update to subscribers 256 that are subscribed to both canonical or alternate URLs. 258 * "data": the content of the new version of this topic. 260 * "target" (optional): target audience of this update. This key can 261 be present several times. See section #Authorization for further 262 information. 264 * "id" (optional): the topic's revision identifier: it will be used 265 as the SSE's "id" property. If omitted, the hub MUST generate a 266 valid globally unique id. It MAY be a UUID [RFC4122]. Even if 267 provided, the hub MAY ignore the id provided by the client and 268 generate its own id. 270 * "type" (optional): the SSE's "event" property (a specific event 271 type). 273 * "retry" (optional): the SSE's "retry" property (the reconnection 274 time). 276 In the event of success, the HTTP response's body MUST be the "id" 277 associated to this update generated by the hub and a success HTTP 278 status code MUST be returned. The publisher MUST be authorized to 279 publish updates. See section #Authorization. 281 5. Authorization 283 To ensure that they are authorized, both publishers and subscribers 284 must present a valid JWS [RFC7515] in compact serialization to the 285 hub. This JWS SHOULD be short-lived, especially if the subscriber is 286 a web browser. A different key MAY be used to sign subscribers' and 287 publishers' tokens. 289 Two mechanisms are defined to present the JWS to the hub: 291 * using an "Authorization" HTTP header 293 * using a cookie 295 If the publisher or the subscriber is not a web browser, it SHOULD 296 use an "Authorization" HTTP header. This "Authorization" header MUST 297 contain the string "Bearer" followed by the JWS. The hub will check 298 that the JWS conforms to the rules (defined later) ensuring that the 299 client is authorized to publish or subscribe to updates. 301 By the "EventSource" specification, web browsers can not set custom 302 HTTP headers for such connections, and they can only be estabilished 303 using the "GET" HTTP method. However, cookies are supported and can 304 be included even in cross-domain requests if the CORS credentials are 305 set (https://html.spec.whatwg.org/multipage/server-sent- 306 events.html#dom-eventsourceinit-withcredentials): 308 If the publisher or the subscriber is a web browser, it SHOULD send a 309 cookie called "mercureAuthorization" containing the JWS when 310 connecting to the hub. 312 Whenever possible, the "mercureAuthorization" cookie SHOULD be set 313 during the discovery to improve the overall security. See section 314 #Discovery. Consequently, if the cookie is set during the discovery, 315 both the publisher and the hub have to share the same second level 316 domain. The "Domain" attribute MAY be used to allow the publisher 317 and the hub to use different subdomains. 319 The cookie SHOULD have the "Secure", "HttpOnly" and "SameSite" 320 attributes set. The cookie's "Path" attribute SHOULD also be set to 321 the hub's URL. See section #Security-Considerations. 323 When using authorization mechanisms, the connection MUST use an 324 encryption layer such as HTTPS. 326 If both an "Authorization" HTTP header and a cookie named 327 "mercureAuthorization" are presented by the client, the cookie MUST 328 be ignored. If the client tries to execute an operation it is not 329 allowed to, a 403 HTTP status code SHOULD be returned. 331 5.1. Publishers 333 Publishers MUST be authorized to dispatch updates to the hub, and 334 MUST prove that they are allowed to send updates. 336 To be allowed to publish an update, the JWT presented by the 337 publisher MUST contain a claim called "mercure", and this claim MUST 338 contain a "publish" key. "mercure.publish" MUST contain an array of 339 targets the publisher is allowed to dispatch updates to. 341 If "mercure.publish": 343 * is not defined, then the publisher MUST NOT be authorized to 344 dispatch any update 346 * contains an empty array, then the publisher is only allowed to 347 dispatch public updates 349 * contains the reserved string "*" as an array value, then the 350 publisher is authorized to dispatch updates to all targets 352 If a topic is not public, the "POST" request sent by the publisher to 353 the hub MUST contain a list of keys named "target". Their values 354 MUST be of type "string", and it is RECOMMENDED to use valid IRIs. 355 They can be, for instance, a user ID or a list of group IDs. If an 356 update contains at least one target the publisher is not authorized 357 for, the hub MUST NOT dispatch the update (even if some targets in 358 the list are allowed) and SHOULD return a 403 HTTP status code. 360 5.2. Subscribers 362 Subscribers MAY need to be authorized to connect to the hub. To 363 receive updates destined to specific targets, they MUST be 364 authorized, and MUST prove they belong to at least one of the 365 specified targets. If the subscriber is not authorized, it MUST NOT 366 receive any update having at least one target. 368 To receive updates destined for specific targets, the JWS presented 369 by the subscriber MUST have a claim named "mercure" with a key named 370 "subscribe" that contains an array of strings: a list of targets the 371 user is authorized to receive updates for. The targets SHOULD be 372 IRIs. 374 If at least one target is specified, the update MUST NOT be sent to 375 the subscriber by the hub, unless the "mercure.subscribe" array of 376 the JWS presented by the subscriber contains at least one of the 377 specified targets. 379 If the "mercure.subscribe" array contains the reserved string value 380 "*", then the subscriber is authorized to receive updates destined 381 for all targets. 383 6. Reconnection and State Reconciliation 385 To allow re-establishment in case of connection lost, events 386 dispatched by the hub SHOULD include an "id" property. The value 387 contained in this "id" property SHOULD be a globally unique 388 identifier. To do so, a UUID [RFC4122] MAY be used. 390 According to the server-sent events specification, in case of 391 connection lost the subscriber will try to automatically re-connect. 392 During the re-connection, the subscriber MUST send the last received 393 event id in a Last-Event-ID (https://html.spec.whatwg.org/multipage/ 394 iana.html#last-event-id) HTTP header. 396 The server-sent events specification doesn't allow this HTTP header 397 to be set during the first connection (before a reconnection). In 398 order to fetch any update dispatched between the initial resource 399 generation by the publisher and the connection to the hub, the 400 subscriber MUST send the event id provided during the discovery in 401 the "last-event-id" link's attribute in a query parameter named 402 "Last-Event-ID" when connecting to the hub. 404 If both the "Last-Event-ID" HTTP header and the query parameter are 405 present, the HTTP header MUST take precedence. 407 If the "Last-Event-ID" HTTP header or query parameter exists, the hub 408 SHOULD send all events published following the one bearing this 409 identifier to the subscriber. 411 The hub MAY discard some messages for operational reasons. The 412 subscriber MUST NOT assume that no update will be lost, and MUST re- 413 fetch the original topic to ensure this (for instance, after a long 414 disconnection time). 416 The hub MAY also specify the reconnection time using the "retry" key, 417 as specified in the server-sent events format. 419 7. Subscription Events 421 The hub MAY publish an update when a subscription to a topic is 422 created or terminated. If this feature is implemented by the hub, an 423 update MUST be dispatched every time that a subscription is created 424 or terminated, and for each topic to which the client subscribes. 426 The topic of this update MUST follow the pattern 427 "https://mercure.rocks/subscriptions/{topic}/{subscriptionID}" where 428 "topic" is the URL-encoded value of the subscribed topic and 429 "subscriptionID" is an unique identifier for this subscription. 430 "subscriptionID" MAY be a UUID [RFC4122]. 432 The content of the update MUST be a JSON-LD 433 [W3C.REC-json-ld-20140116] document containing at least the following 434 properties: 436 * "@id": the identifier of this update, it MUST be the same value as 437 the subscription update's topic 439 * "@type": the fixed value "https://mercure.rocks/Subscription" 441 * "topic": the topic to which the subscription refers 443 * "active": "true" when the subscription is created, and "false" 444 when it is terminated 446 * "subscribe": the subscription targets provided by the subscriber 447 (see section #Authorization) 449 * "publish": the publication targets provided by the subscriber (see 450 section #Authorization) 452 * "address" (optional): the IP address ([RFC0791], [RFC8200]) of the 453 subscriber 455 The JSON-LD document MAY contain other properties. 457 In order to only allow authorized subscribers to receive subscription 458 events, the subscription update MUST be marked as intended for 459 subscribers providing the following targets: 461 * the fixed value "https://mercure.rocks/targets/subscriptions" 463 * a URL following the pattern "https://mercure.rocks/targets/ 464 subscriptions/{topic}" where topic is the URL-encoded value of the 465 subscribed topic 467 8. Encryption 469 Using HTTPS does not prevent the hub from accessing the update's 470 content. Depending of the intended privacy of information contained 471 in the update, it MAY be necessary to prevent eavesdropping by the 472 hub. 474 To make sure that the message content can not be read by the hub, the 475 publisher MAY encode the message before sending it to the hub. The 476 publisher SHOULD use JSON Web Encryption [RFC7516] to encrypt the 477 update content. The publisher MAY provide the relevant encryption 478 key(s) in the "key-set" attribute of the Link HTTP header during the 479 discovery. The "key-set" attribute SHOULD contain a key encoded 480 using the JSON Web Key Set [RFC7517] format. Any other out-of-band 481 mechanism MAY be used instead to share the key between the publisher 482 and the subscriber. 484 Update encryption is considered a best practice to prevent mass 485 surveillance. This is especially relevant if the hub is managed by 486 an external provider. 488 9. IANA Considerations 490 9.1. Well-Known URIs Registry 492 A new "well-known" URI as described in Section 2 has been registered 493 in the "Well-Known URIs" registry as described below: 495 * URI Suffix: mercure 497 * Change Controller: IETF 499 * Specification document(s): This specification, Section 2 501 * Related information: N/A 503 9.2. Link Relation Types Registry 505 A new "Link Relation Type" as described in Section 2 has been 506 registered in the "Link Relation Type" registry with the following 507 entry: 509 * Relation Name: mercure 511 * Description: The Mercure Hub to use to subscribe to updates of 512 this resource. 514 * Reference: This specification, Section 2 515 Note: this relation type has not been registered yet. In the 516 meantime, the relation type "https://git.io/mercure" MAY be used 517 instead. 519 10. Security Considerations 521 The confidentiality of the secret key(s) used to generate the JWTs is 522 a primary concern. The secret key(s) MUST be stored securely. They 523 MUST be revoked immediately in the event of compromission. 525 Possessing valid JWTs allows any client to subscribe, or to publish 526 to the hub. Their confidentiality MUST therefore be ensured. To do 527 so, JWTs MUST only be transmitted over secure connections. 529 Also, when the client is a web browser, the JWT SHOULD not be made 530 accessible to JavaScript scripts for resilience against Cross-site 531 Scription (XSS) attacks (https://www.owasp.org/index.php/Cross- 532 site_Scripting_(XSS)). It's the main reason why, when the client is 533 a web browser, using "HttpOnly" cookies as the authorization 534 mechanism SHOULD always be preferred. 536 In the event of compromission, revoking JWTs before their expiration 537 is often difficult. To that end, using short-lived tokens is 538 strongly RECOMMENDED. 540 The publish endpoint of the hub may be targeted by Cross-Site Request 541 Forgery (CSRF) attacks (https://www.owasp.org/index.php/Cross- 542 Site_Request_Forgery_(CSRF)) when the cookie-based authorization 543 mechanism is used. Therefore, implementations supporting this 544 mechanism MUST mitigate such attacks. 546 The first prevention method to implement is to set the 547 "mercureAuthorization" cookie's "SameSite" attribute. However, some 548 web browsers still not support this attribute 549 (https://caniuse.com/#feat=same-site-cookie-attribute) and will 550 remain vulnerable. Additionally, hub implementations SHOULD use the 551 "Origin" and "Referer" HTTP headers set by web browsers to verify 552 that the source origin matches the target origin. If none of these 553 headers are available, the hub SHOULD discard the request. 555 CSRF prevention techniques, including those previously mentioned, are 556 described in depth in OWASP's Cross-Site Request Forgery (CSRF) 557 Prevention Cheat Sheet (https://www.owasp.org/index.php/Cross- 558 Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet). 560 11. Normative References 562 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 563 RFC 7516, DOI 10.17487/RFC7516, May 2015, 564 . 566 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 567 DOI 10.17487/RFC7517, May 2015, 568 . 570 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 571 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 572 January 2005, . 574 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 575 (IPv6) Specification", STD 86, RFC 8200, 576 DOI 10.17487/RFC8200, July 2017, 577 . 579 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 580 Resource Identifier (URI): Generic Syntax", STD 66, 581 RFC 3986, DOI 10.17487/RFC3986, January 2005, 582 . 584 [W3C.REC-json-ld-20140116] 585 Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0", 586 World Wide Web Consortium Recommendation REC-json-ld- 587 20140116, 16 January 2014, 588 . 590 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 591 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 592 2015, . 594 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 595 DOI 10.17487/RFC0791, September 1981, 596 . 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 604 Protocol (HTTP/1.1): Message Syntax and Routing", 605 RFC 7230, DOI 10.17487/RFC7230, June 2014, 606 . 608 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 609 Uniform Resource Identifiers (URIs)", RFC 5785, 610 DOI 10.17487/RFC5785, April 2010, 611 . 613 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 614 DOI 10.17487/RFC5988, October 2010, 615 . 617 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 618 and D. Orchard, "URI Template", RFC 6570, 619 DOI 10.17487/RFC6570, March 2012, 620 . 622 12. Informative References 624 [RFC6902] Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object 625 Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, 626 April 2013, . 628 [RFC7386] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7386, 629 DOI 10.17487/RFC7386, October 2014, 630 . 632 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 633 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 634 December 2005, . 636 [W3C.REC-html52-20171214] 637 Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and 638 S. Moon, "HTML 5.2", World Wide Web Consortium 639 Recommendation REC-html52-20171214, 14 December 2017, 640 . 642 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 643 Unique IDentifier (UUID) URN Namespace", RFC 4122, 644 DOI 10.17487/RFC4122, July 2005, 645 . 647 [W3C.REC-xml-20081126] 648 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 649 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 650 Edition)", World Wide Web Consortium Recommendation REC- 651 xml-20081126, 26 November 2008, 652 . 654 Author's Address 656 Kevin Dunglas 657 Les-Tilleuls.coop 658 82 rue Winston Churchill 659 59160 Lille 660 France 662 Email: kevin@les-tilleuls.coop