idnits 2.17.1 draft-hallambaker-mesh-protocol-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 Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 9 March 2020 5 Expires: 10 September 2020 7 Mathematical Mesh 3.0 Part V: Protocol Reference 8 draft-hallambaker-mesh-protocol-05 10 Abstract 12 The Mathematical Mesh 'The Mesh' is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. The core protocols of 15 the Mesh are described with examples of common use cases and 16 reference data. 18 [Note to Readers] 20 Discussion of this draft takes place on the MATHMESH mailing list 21 (mathmesh@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 24 This document is also available online at 25 http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 10 September 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 62 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 63 3. Mesh Service . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Partitioning . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. DNS Web Service Discovery . . . . . . . . . . . . . . . . 7 68 4.2. Web Service Protocol Binding . . . . . . . . . . . . . . 7 69 4.2.1. Transport Security . . . . . . . . . . . . . . . . . 8 70 4.2.2. HTTP Message Binding . . . . . . . . . . . . . . . . 8 71 4.2.3. Request . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. DARE Message Encapsulation . . . . . . . . . . . . . . . 10 74 4.3.1. Null Authentication . . . . . . . . . . . . . . . . . 11 75 4.3.2. Device Authentication . . . . . . . . . . . . . . . . 11 76 4.3.3. Profile Authentication . . . . . . . . . . . . . . . 11 77 4.3.4. Ticket Authentication . . . . . . . . . . . . . . . . 11 78 4.4. Payload Encoding . . . . . . . . . . . . . . . . . . . . 11 79 4.5. Error handling and response codes . . . . . . . . . . . . 12 80 5. Service Description . . . . . . . . . . . . . . . . . . . . . 13 81 6. Account Management . . . . . . . . . . . . . . . . . . . . . 14 82 7. Container Synchronization . . . . . . . . . . . . . . . . . . 16 83 7.1. Status Transaction . . . . . . . . . . . . . . . . . . . 17 84 7.2. Download Transaction . . . . . . . . . . . . . . . . . . 17 85 7.2.1. Conflict Detection . . . . . . . . . . . . . . . . . 17 86 7.2.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 17 87 7.3. Upload Transaction . . . . . . . . . . . . . . . . . . . 17 88 8. Device Connection . . . . . . . . . . . . . . . . . . . . . . 18 89 8.1. Device Authenticated . . . . . . . . . . . . . . . . . . 18 90 8.2. PIN Authenticated . . . . . . . . . . . . . . . . . . . . 19 91 8.3. EARL connection mode . . . . . . . . . . . . . . . . . . 19 92 9. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . . . 19 93 9.1. Message Exchange . . . . . . . . . . . . . . . . . . . . 20 94 9.1.1. Client-Service (Post Transaction) . . . . . . . . . . 20 95 9.1.2. Service-Service (Post Transaction) . . . . . . . . . 20 96 9.1.3. Service-Client (Synchronization) . . . . . . . . . . 21 98 10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 21 99 10.1. Request Messages . . . . . . . . . . . . . . . . . . . . 22 100 10.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 22 101 10.1.2. Message: MeshRequestUser . . . . . . . . . . . . . . 22 102 10.2. Response Messages . . . . . . . . . . . . . . . . . . . 22 103 10.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 22 104 10.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 23 105 10.4. Common Structures . . . . . . . . . . . . . . . . . . . 23 106 10.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 23 107 10.4.2. Structure: ConstraintsSelect . . . . . . . . . . . . 23 108 10.4.3. Structure: ConstraintsData . . . . . . . . . . . . . 24 109 10.4.4. Structure: PolicyAccount . . . . . . . . . . . . . . 24 110 10.4.5. Structure: ContainerStatus . . . . . . . . . . . . . 24 111 10.4.6. Structure: ContainerUpdate . . . . . . . . . . . . . 24 112 10.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 25 113 10.5.1. Message: MeshHelloResponse . . . . . . . . . . . . . 25 114 10.6. Transaction: CreateAccount . . . . . . . . . . . . . . . 25 115 10.6.1. Message: CreateRequest . . . . . . . . . . . . . . . 26 116 10.6.2. Message: CreateResponse . . . . . . . . . . . . . . 26 117 10.7. Transaction: DeleteAccount . . . . . . . . . . . . . . . 26 118 10.7.1. Message: DeleteRequest . . . . . . . . . . . . . . . 26 119 10.7.2. Message: DeleteResponse . . . . . . . . . . . . . . 26 120 10.8. Transaction: Complete . . . . . . . . . . . . . . . . . 27 121 10.8.1. Message: CompleteRequest . . . . . . . . . . . . . . 27 122 10.8.2. Message: CompleteResponse . . . . . . . . . . . . . 27 123 10.9. Transaction: Status . . . . . . . . . . . . . . . . . . 27 124 10.9.1. Message: StatusRequest . . . . . . . . . . . . . . . 27 125 10.9.2. Message: StatusResponse . . . . . . . . . . . . . . 27 126 10.10. Transaction: Download . . . . . . . . . . . . . . . . . 28 127 10.10.1. Message: DownloadRequest . . . . . . . . . . . . . 28 128 10.10.2. Message: DownloadResponse . . . . . . . . . . . . . 28 129 10.11. Transaction: Upload . . . . . . . . . . . . . . . . . . 29 130 10.11.1. Message: UploadRequest . . . . . . . . . . . . . . 29 131 10.11.2. Message: UploadResponse . . . . . . . . . . . . . . 29 132 10.11.3. Structure: EntryResponse . . . . . . . . . . . . . 29 133 10.12. Transaction: Post . . . . . . . . . . . . . . . . . . . 30 134 10.12.1. Message: PostRequest . . . . . . . . . . . . . . . 30 135 10.12.2. Message: PostResponse . . . . . . . . . . . . . . . 30 136 10.13. Transaction: Connect . . . . . . . . . . . . . . . . . . 30 137 10.13.1. Message: ConnectRequest . . . . . . . . . . . . . . 30 138 10.13.2. Message: ConnectResponse . . . . . . . . . . . . . 31 139 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 140 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 141 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 142 14. Normative References . . . . . . . . . . . . . . . . . . . . 31 143 15. Informative References . . . . . . . . . . . . . . . . . . . 32 145 1. Introduction 147 This document describes the Mesh Service protocol supported by Mesh 148 Services, an account-based protocol that facilitates exchange of data 149 between devices connected to a Mesh profile and between Mesh 150 accounts. 152 Mesh Service Accounts support the following services: 154 * Provides the master persistence store for the Catalogs and Spools 155 associated with the account. 157 * Enables synchronization of Catalogs and Spools with connected 158 devices. 160 * Enforces access control on inbound Mesh Messages from other users 161 and other Mesh Services. 163 * Authenticates outbound Mesh Messages, certifying that they comply 164 with abuse mitigation policies. 166 A Mesh Profile MAY be bound to multiple Mesh Service Accounts at the 167 same time but only one Mesh Service Account is considered to be 168 authoritative at a time. Users may add or remove Mesh Service 169 Accounts and change the account designated as authoritative at any 170 time. 172 The Mesh Services are build from a very small set of primitives which 173 provide a surprisingly extensive set of capabilities. These 174 primitives are: 176 "Hello" Describes the features and options provided by the service 177 and provides a 'null' transaction which MAY be used to establish 178 an authentication ticket without performing any action, 180 CreateAccount, DeleteAccount Manage the creation and deletion of 181 accounts at the service. 183 Status, Download, "Upload" Support synchronization of Mesh 184 containers between the service (Master) and the connected devices 185 (Replicas). 187 Connect Initiate the process of connecting a device to a Mesh 188 profile from the device itself. 190 Post Request that a Mesh Message be transferred to one or more Mesh 191 Accounts. 193 Although these functions could in principle be used to replace many 194 if not most existing Internet application protocols, the principal 195 value of any communication protocol lies in the size of the audience 196 it allows them to communicate with. Thus, while the Mesh Messaging 197 service is designed to support efficient and reliable transfer of 198 messages ranging in size from a few bytes to multiple terabytes, the 199 near-term applications of these services will be to applications that 200 are not adequately supported by existing protocols if at all. 202 2. Definitions 204 This section presents the related specifications and standard, the 205 terms that are used as terms of art within the documents and the 206 terms used as requirements language. 208 2.1. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 2.2. Defined Terms 216 The terms of art used in this document are described in the _Mesh 217 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 219 2.3. Related Specifications 221 The architecture of the Mathematical Mesh is described in the _Mesh 222 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 223 documentation set and related specifications are described in this 224 document. 226 2.4. Implementation Status 228 The implementation status of the reference code base is described in 229 the companion document [draft-hallambaker-mesh-developer]. 231 3. Mesh Service 233 A Mesh Service is a minimally trusted service. In particular a user 234 does not need to trust a Mesh service to protect the confidentiality 235 or integrity of most data stored in the account catalogs and spools. 237 Unless the use of the Mesh Service is highly restricted, a user does 238 need to trust the Mesh Service in certain respects: 240 Data Loss A service could refuse to respond to requests to download 241 data. 243 Integrity (Stale Data) The use of Merkle Trees limits but does not 244 eliminate the ability of a Mesh Service to respond to requests 245 with stale data. 247 Messaging A service could reject requests to post messages to or 248 accept messages from other mesh users. 250 This risk is a necessary consequence of the fact that the Mesh 251 Service Provider is accountable to other Mesh Service Providers 252 for abuse originating from their service. 254 Traffic analysis A Mesh Service has knowledge of the number of Mesh 255 Messages being sent and received by its users and the addresses to 256 which they are being sent to or received from. 258 The need to trust the Mesh Service in these respects is mitigated by 259 accountability and the user's ability to change Mesh Service 260 providers at any time they choose with minimal inconvenience. 262 It is possible that some of these risks will be reduced in future 263 versions of the Mesh Service Protocol but it is highly unlikely that 264 these can be eliminated entirely without compromising practicality or 265 efficiency. 267 3.1. Data Model 269 The design of the Mesh Service model followed a quasi-formal approach 270 in which the system was reduced to schemas which could in principle 271 be rendered in a formal development method but without construction 272 of proofs. 274 Like the contents of Mesh Accounts, a Mesh Service may be represented 275 by a collection of catalogs and spools, for example: 277 Account Catalog Contains the account entries. 279 Incident Spool Reports of potential abuse 281 Backup of the service MAY be implemented using the same container 282 synchronization mechanism used to synchronize account catalogs and 283 spools. 285 3.2. Partitioning 287 Mesh Services supporting a large number of accounts or large activity 288 volume MAY partition the account catalog between one or more hosts 289 using the usual tiered service model in which a front-end server 290 receives traffic for any account hosted at the server and routes the 291 request to the back-end service that provides the persistence store 292 for that account. 294 In addition, the Mesh Service Protocol supports a 'direct connection' 295 partitioning model in which devices are given a DNS name which MAY 296 allow for direct connection to the persistence host or to a front-end 297 service offering service that is in some way specific to that 298 account. 300 4. Protocol Bindings 302 Mesh Service transactions are mapped to an underlying messaging and 303 transport protocol. The following binding 305 Mesh Services MUST support the Web Service binding specified in this 306 document and MAY support the UDP binding currently in development. 308 4.1. DNS Web Service Discovery 310 The DNS Web Service discovery mechanism is used to discover Mesh 311 Services regardless of the protocol binding .The service name, DNS 312 prefix and and .well-known service suffix are specified as follows: 314 * Service Name: mmm 316 * DNS Prefix: _mmm._tcp 318 * Well Known service suffix: /.well-known/mmm 320 4.2. Web Service Protocol Binding 322 The Web Service Protocol binding makes use of the most widely 323 deployed and used protocols: 325 * Discovery: DNS Service discovery 327 * Transport: TLS 329 * Application: HTTP 331 * Presentation: DARE Message 332 * Encoding: JSON, JSON-B 334 The chief limitations of the Web Service Protocol Binding are that 335 the use of TCP based transport results in unsatisfactory latency for 336 some applications and that the HTTP application layer only serves to 337 allow a host to support multiple services on the same TCP/IP port. 339 4.2.1. Transport Security 341 Mesh Services MUST offer TLS transport and MAY offer non TLS 342 transport. MESH clients SHOULD use TLS transport when connecting to 343 a MESH service. 345 TLS version 1.3 [RFC8446] or higher MUST be supported. Client 346 authentication SHOULD NOT be used. 348 4.2.2. HTTP Message Binding 350 All messages are exchanged as HTTP POST transactions. Support for 351 and use of HTTP/1.1 [RFC7230] is REQUIRED. Services MAY support 352 HTTP/2. 354 In contrast to other approaches to the design of Web Services, the 355 only use made of the HTTP transport is to distinguish between 356 different services on the same host using the Host header and .well- 357 known convention and for message framing. No use is made of the URI 358 request line to identify commands, nor are the caching or proxy 359 capabilities of HTTP made use of. 361 4.2.3. Request 363 The HTTP request MAY contain any valid HTTP header specified in 364 [RFC7230]. 366 Request Line URI "/well-known/" (unless overridden using a 367 TXT path attribute) 369 Request Line Method POST 371 Host: Header 373 Content-Encoding As specified in section yy below. 375 Content-Type As specified in section zz below. 377 Content-Length or Transfer-Encoding As specified in [RFC7230]. 379 Payload The content payload as specified in section XX below. 381 [Note, this is showing the payload, not the binding as is intended 382 because the current code doesn't implement it as intended yet] 384 { 385 "Hello": {}} 387 4.2.4. Response 389 The response MAY contain any HTTP response header but since JWB 390 services do not make use of HTTP caching and messages are not 391 intended to be modified by HTTP intermediaries, only a limited number 392 of headers have significance: 394 Response Code The HTTP response code. This is processed as 395 described in section zz below. 397 Content-Type As specified in section zz below. 399 Content-Length or Transfer-Encoding As specified in [RFC7230]. 401 Cache-Control Since the only valid HTTP method for a JWB request is 402 POST, JWB responses are not cacheable. The use of the cache- 403 control header is therefore unnecessary. However, experience 404 suggests that reviewers find it easier to understand protocol 405 specifications if they are reminded of the fact that caching is 406 neither supported nor desired. 408 [Note, this is showing the payload, not the binding as is intended 409 because the current code doesn't implement it as intended yet] 411 { 412 "MeshHelloResponse": { 413 "Status": 201, 414 "Version": { 415 "Major": 3, 416 "Minor": 0, 417 "Encodings": [{ 418 "ID": ["application/json"]}]}, 419 "EnvelopedProfileService": [{ 420 "dig": "SHA2"}, 421 "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2l 422 nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CTlQtV09MNy1SNE42LVdOUTYtR 423 FpHSC1OQVJVLVFYR1MiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA 424 gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N 425 DgiLAogICAgICAgICAgIlB1YmxpYyI6ICJCaGd0R2lOb3RBZXZLMWcycDlLd2V 426 DcmJHa0lEY19lYzRnZmRSWDVqaEtPaWJMdjl4cmpTCiAgcDFrQ3EwX0RnMmJLe 427 UxORUtQckdoek9BIn19fX19", 428 { 429 "signatures": [{ 430 "alg": "SHA2", 431 "kid": "MBNT-WOL7-R4N6-WNQ6-DZGH-NARU-QXGS", 432 "signature": "QaCCgc0s5SWqDS-ftqKShfu2cB_VJmuh4WuJQ-hBm3y 433 lQYHgo 434 siL6Ht80U0jQIludWJCx0InbB6AYyBGG9MeA6U7qZVuMEGvWTpVokuzeJX8n-f 435 Tf2lfp5XSaxz0lcW6nr3JkbBbZnyG2fEc7sefHykA"}], 436 "PayloadDigest": "e1HeM8pDoyymfVoAerBTHiXr7YlaO9Ojatj412YBhwO 437 jg 438 ATZy-RPuov4GPFxG30Okoj2TnGejIWJTgI8EeADEg"}], 439 "EnvelopedProfileHost": [{ 440 "dig": "SHA2"}, 441 "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF 442 0dXJlIjogewogICAgICAiVURGIjogIk1CMk8tTVlJVC1TVlpNLUFQNVAtTjdYU 443 y1YUEhOLUNOWUEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA 444 gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL 445 AogICAgICAgICAgIlB1YmxpYyI6ICJpbTR5QUpvUHZTT2ZkUUc4Q093RVA4ZmQ 446 5MjVldEp2OENZek1kUHJOSm1jMy1zWm4tUGtxCiAgZGd1Sm1UcHBSejJlbjJuS 447 1NHQkxvWVlBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICA 448 gIlVERiI6ICJNQTNWLUNESkUtTUROWC1OMkJTLUlSWUUtM08zRC1QSDJHIiwKI 449 CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV 450 DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd 451 WJsaWMiOiAiTExXb3FZMUE0dG1OVUhwZ0FxN1JjcTd0WkZsVDB4bGlrbGNZd3F 452 uckJoalVrVV9oaWowagogIEhJQ1doMmt0aENhemtMSndxZFVlQmdjQSJ9fX19f 453 Q", 454 { 455 "signatures": [{ 456 "alg": "SHA2", 457 "kid": "MB2O-MYIT-SVZM-AP5P-N7XS-XPHN-CNYA", 458 "signature": "Iu3PBwDlL_8tYTxhEAvABwfnvPHlGQgVjmACHGf1bPK 459 L9bDJw 460 Z41ct7tLm16II6yCHyoSWsPfgoAhiwuNGTmtdSiSnWPDcCqMED9mISXuzdvyKa 461 vXC1WKCcGZ9xX2T6RQt_uwjIzQ14NOBJ_0Kq0DBkA"}], 462 "PayloadDigest": "XOuVH5GtU_-ChBeUrSEpeunqcZI_T401sX0pP4L_dFL 463 ey 464 8vqINGvmKiFOQlLOH2cHmqAd26gfjEUOJtVzWIh6g"}]}} 466 4.3. DARE Message Encapsulation 468 The payload of the HTTP requests and responses is a DARE Message 469 whose payload contains the Mesh Service request or response. 471 The DARE Message encapsulation is used to authenticate the request or 472 response data. The form of the authentication depending on the 473 credentials available to the sender at the time the request is made. 475 Mesh Service MUST support the use of Mutually Authenticated Key 476 Exchange [draft-hallambaker-mesh-security] to establish the Master 477 Key used for authentication of requests and responses. 479 Requests and Responses MUST be authenticated. Requests and Responses 480 MUST be encrypted if the transport is not encrypted and MAY be 481 encrypted otherwise. 483 4.3.1. Null Authentication 485 Null Authentication MAY be used to make a "Hello" Request. 487 The Null Authentication mechanism MUST NOT be used for any Mesh 488 Service request or response other than a "Hello" request. 490 Since the Mutually Authenticated key exchange requires both parties 491 to know the public key of the other, it is not possible for a client 492 to authenticate itself to the service until it has obtained the 493 service public key. One means by which the client MAY obtain the 494 service public key is by requesting the service return the credential 495 in a "Hello" transaction. 497 4.3.2. Device Authentication 499 Device Authentication is used in two circumstances 501 * When requesting creation of an account 503 * When a device is requesting connection to a profile. 505 4.3.3. Profile Authentication 507 Profile Authentication has the same form as Device Authentication 508 except that the client provides its Device Connection Assertion as 509 part of the request: 511 4.3.4. Ticket Authentication 513 Ticket Authentication is used after a device has obtained an 514 authentication ticket from a service. The ticket is returned in the 515 response to a previous Profile Authentication exchange. 517 4.4. Payload Encoding 519 The Dare Message payload of a "Hello" request MUST be encoded in JSON 520 encoding. The payload of all other requests MUST be in either JSON 521 encoding or one of the encodings advertised as being accepted in a 522 Hello response from the Service. Services MUST accept JSON encoding 523 and MAY support the JSON-B or JSON-C encodings as specified in this 524 document. Services MUST generate a response that is compatible with 525 the DARE Message Content-Type specified in the request. 527 JSON was originally developed to provide a serialization format for 528 the JavaScript programming language [ECMA-262]. While this approach 529 is generally applicable to the type systems of scripting programming 530 languages, it is less well matched to the richer type systems of 531 modern object oriented programming languages such as Java and C#. 533 Working within a subset of the capabilities of JSON allows a Web 534 Service protocol to be accessed with equal ease from either platform 535 type. The following capabilities of JSON are avoided: 537 The ability to use arbitrary strings as field names. 539 The use of JSON objects to define maps directly 541 The following data field types are used: 543 Integer Integer values are encoded as JSON number values. 545 String Test strings are encoded as JSON text strings. 547 Boolean Boolean values are encoded as JSON 'false', 'true' or 'null' 548 tokens according to value. 550 Sequence Sequences of data items that are encoded as JSON arrays 552 Object of known type Objects whose type is known to the receiver are 553 encoded as JSON objects 555 Object of variable type Objects whose type is not known to the 556 receiver are encoded as JSON objects containing a single field 557 whose name describes the type of the object value and whose value 558 contains the value. 560 Binary Data Byte sequences are converted to BASE64-url encoding 561 [RFC4648] and encoded as JSON string values. 563 Date Time Date Time values are converted to Internet time format as 564 described in [RFC3339] and encoded as JSON string values. 566 4.5. Error handling and response codes 568 It is possible for an error to occur at any of the three layers in 569 the Web Service binding: 571 Service Layer 572 HTTP Layer 574 Transport Layer 576 Services SHOULD always attempt to return error codes at the highest 577 level possible. However, it is clearly impossible for a connection 578 that is refused at the Transport layer to return an error code at the 579 HTTP layer. It is however possible for a HTTP layer error response 580 to contain a content body. 582 In the case that a response contains both a HTTP response code and a 583 well-formed payload containing a response, the payload response SHALL 584 have precedence. 586 5. Service Description 588 The Hello transaction is used to determine the features supported by 589 the service and obtain the service credentials 591 The request payload: 593 { 594 "Hello": {}} 596 The response payload: 598 { 599 "MeshHelloResponse": { 600 "Status": 201, 601 "Version": { 602 "Major": 3, 603 "Minor": 0, 604 "Encodings": [{ 605 "ID": ["application/json"]}]}, 606 "EnvelopedProfileService": [{ 607 "dig": "SHA2"}, 608 "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2l 609 nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CTlQtV09MNy1SNE42LVdOUTYtR 610 FpHSC1OQVJVLVFYR1MiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA 611 gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N 612 DgiLAogICAgICAgICAgIlB1YmxpYyI6ICJCaGd0R2lOb3RBZXZLMWcycDlLd2V 613 DcmJHa0lEY19lYzRnZmRSWDVqaEtPaWJMdjl4cmpTCiAgcDFrQ3EwX0RnMmJLe 614 UxORUtQckdoek9BIn19fX19", 615 { 616 "signatures": [{ 617 "alg": "SHA2", 618 "kid": "MBNT-WOL7-R4N6-WNQ6-DZGH-NARU-QXGS", 619 "signature": "QaCCgc0s5SWqDS-ftqKShfu2cB_VJmuh4WuJQ-hBm3y 620 lQYHgo 621 siL6Ht80U0jQIludWJCx0InbB6AYyBGG9MeA6U7qZVuMEGvWTpVokuzeJX8n-f 622 Tf2lfp5XSaxz0lcW6nr3JkbBbZnyG2fEc7sefHykA"}], 623 "PayloadDigest": "e1HeM8pDoyymfVoAerBTHiXr7YlaO9Ojatj412YBhwO 624 jg 625 ATZy-RPuov4GPFxG30Okoj2TnGejIWJTgI8EeADEg"}], 626 "EnvelopedProfileHost": [{ 627 "dig": "SHA2"}, 628 "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF 629 0dXJlIjogewogICAgICAiVURGIjogIk1CMk8tTVlJVC1TVlpNLUFQNVAtTjdYU 630 y1YUEhOLUNOWUEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA 631 gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL 632 AogICAgICAgICAgIlB1YmxpYyI6ICJpbTR5QUpvUHZTT2ZkUUc4Q093RVA4ZmQ 633 5MjVldEp2OENZek1kUHJOSm1jMy1zWm4tUGtxCiAgZGd1Sm1UcHBSejJlbjJuS 634 1NHQkxvWVlBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICA 635 gIlVERiI6ICJNQTNWLUNESkUtTUROWC1OMkJTLUlSWUUtM08zRC1QSDJHIiwKI 636 CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV 637 DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd 638 WJsaWMiOiAiTExXb3FZMUE0dG1OVUhwZ0FxN1JjcTd0WkZsVDB4bGlrbGNZd3F 639 uckJoalVrVV9oaWowagogIEhJQ1doMmt0aENhemtMSndxZFVlQmdjQSJ9fX19f 640 Q", 641 { 642 "signatures": [{ 643 "alg": "SHA2", 644 "kid": "MB2O-MYIT-SVZM-AP5P-N7XS-XPHN-CNYA", 645 "signature": "Iu3PBwDlL_8tYTxhEAvABwfnvPHlGQgVjmACHGf1bPK 646 L9bDJw 647 Z41ct7tLm16II6yCHyoSWsPfgoAhiwuNGTmtdSiSnWPDcCqMED9mISXuzdvyKa 648 vXC1WKCcGZ9xX2T6RQt_uwjIzQ14NOBJ_0Kq0DBkA"}], 649 "PayloadDigest": "XOuVH5GtU_-ChBeUrSEpeunqcZI_T401sX0pP4L_dFL 650 ey 651 8vqINGvmKiFOQlLOH2cHmqAd26gfjEUOJtVzWIh6g"}]}} 653 6. Account Management 655 A Mesh Account is bound to a Mesh Service by completing a 656 "CreateAccount" transaction with the service. 658 The client requesting the account creation specifies the 659 "ProfileMesh" profile describing the requested account and lists of 660 initial entries to populate the devices and contacts catalogs. 661 Additional catalogs MAY be synchronized if the account creation 662 request is accepted. 664 The request payload: 666 { 667 "CreateAccount": { 668 "ServiceID": "alice@example.com", 669 "SignedProfileMesh": [{}, 670 "ewogICJQcm9maWxlTWVzaCI6IHsKICAgICJLZXlPZ 671 mZsaW5lU2lnbmF0dXJlIjogewogICAgICAiVURGIjogIk1ES0QtWFRVUi1HRlA 672 0LVFENTItU1ROQi1RN0dTLU1FV1ciLAogICAgICAiUHVibGljUGFyYW1ldGVyc 673 yI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnY 674 iOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJZLUVZOVI0Xy1tR0h2S 675 FVFSjQ4bFl0clViM3BFOTZWaWZ4SmVoRjZkWlFOWlJjMDdFR29XCiAgSWRrZjd 676 qMXotMG82ZURDLVgtckJiVkNBIn19fSwKICAgICJLZXlzT25saW5lU2lnbmF0d 677 XJlIjogW3sKICAgICAgICAiVURGIjogIk1BNkEtNUpFQS03UFJOLUhIRzYtR0N 678 MUi1DWUhTLURSQUkiLAogICAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogI 679 CAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAgICJjcnYiOiA 680 iRWQ0NDgiLAogICAgICAgICAgICAiUHVibGljIjogIlJkWGwweEJ4SFR0cnpae 681 jRvRzRDSVlXN3RnVFMtcDRWeFZ2UmxkLXkwQVpzZ0VBNS1yLWkKICBuZGxTVVN 682 lWGM3WkxhR0Z5TGl3U3IwcUEifX19XSwKICAgICJLZXlFbmNyeXB0aW9uIjoge 683 wogICAgICAiVURGIjogIk1ES0QtWFRVUi1HRlA0LVFENTItU1ROQi1RN0dTLU1 684 FV1ciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVib 685 GljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICA 686 gICAgIlB1YmxpYyI6ICJZLUVZOVI0Xy1tR0h2SFVFSjQ4bFl0clViM3BFOTZWa 687 WZ4SmVoRjZkWlFOWlJjMDdFR29XCiAgSWRrZjdqMXotMG82ZURDLVgtckJiVkN 688 BIn19fX19"], 689 "SignedAssertionAccount": [{ 690 "dig": "SHA2"}, 691 "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJLZXlPZmZsaW5lU2l 692 nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CQUwtNDRZWi1YNEdYLVVTQkwtS 693 kFNVS1BVzMyLVNMQlEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA 694 gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N 695 DgiLAogICAgICAgICAgIlB1YmxpYyI6ICItUkNVeG5RSWJDb0hnTlJWUU81TEl 696 ERFVQQ3JvcjJxLU9MaDFGTlMzQVZ5QnJ3TzNCZWROCiAgYzduWHJOQ01yT1RhZ 697 jFNRmUwWk1HcVlBIn19fSwKICAgICJLZXlzT25saW5lU2lnbmF0dXJlIjogW3s 698 KICAgICAgICAiVURGIjogIk1BREUtSjNTRS1MT0FNLTdGNjQtU0paSy1CT05FL 699 URSUEMiLAogICAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICA 700 gIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL 701 AogICAgICAgICAgICAiUHVibGljIjogIndvQW01X1hpVWtFdDA2a1Vpa1R1eGJ 702 2QjdPdU1hc0lONDlTMzY0Ykpqc0o2WVMzZ3ZDM1EKICB4eDNxQUZBYVhGTjg0Z 703 mNpMllOdklpeUEifX19XSwKICAgICJTZXJ2aWNlSURzIjogWyJhbGljZUBleGF 704 tcGxlLmNvbSJdLAogICAgIk1lc2hQcm9maWxlVURGIjogIk1ES0QtWFRVUi1HR 705 lA0LVFENTItU1ROQi1RN0dTLU1FV1ciLAogICAgIktleUVuY3J5cHRpb24iOiB 706 7CiAgICAgICJVREYiOiAiTUJMUi1KQVNXLUlET1EtRFZIUS1RRjJOLVlQWVUtR 707 VI0NiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJ 708 saWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgI 709 CAgICAiUHVibGljIjogInVnejk4Z3A0X3M4bnRiQ28wdlpxX1pJZU9iV25SNW1 710 pZjRiclo5S2FXOXdLUWFjS0RfLWUKICBDcUdBUmg4Q2dLME1Ra0FqaXVXbG82d 711 0EifX19fX0", 712 { 713 "signatures": [{ 714 "alg": "SHA2", 715 "kid": "MA6A-5JEA-7PRN-HHG6-GCLR-CYHS-DRAI", 716 "signature": "XOpsadhMHH_5eH8Np42s0_lp49a2Hc1tvspOIyYiHAh 717 xwA0NZ 718 VPAw1Mox6kwjfdntb3EyaHnFF2AxLrqI4GvwYjNmcuk2RDW9mCjj7uRZ38_jcX 719 --9Ld_MYQucH8lankfDDRUlI6Vbglp_4Oub1oYgIA"}], 720 "PayloadDigest": "woWiugDhBt-mBSTPaikozWhXk8oioq4ntulInpK9_cH 721 r8 722 vKt3PEX8rW96F5LFCGbNkd3u4Mp8cV9Lis45KJBjg"}]}} 724 The response payload: 726 { 727 "CreateResponse": { 728 "Status": 201, 729 "StatusDescription": "Operation completed successfully"}} 731 An account registration is deleted using the "DeleteAccount" 732 transaction. 734 7. Container Synchronization 736 All the state associated with a Mesh profile is stored as a sequence 737 of DARE Messages in a Dare Container. The Mesh Service holding the 738 master copy of the persistence stores and the devices connected to 739 the profile containing complete copies (replicas) or partial copies 740 (redactions). 742 Thus, the only primitive needed to achieve synchronization of the 743 profile state are those required for synchronization of a DARE 744 Container. These steps are: 746 * Obtain the status of the catalogs and spools associated with the 747 account. 749 * Download catalog and spool updates 751 * Upload catalog updates. 753 To ensure a satisfactory user experience, Mesh Messages are 754 intentionally limited in size to 64 KB or less, thus ensuring that an 755 application can retrieve the most recent 100 messages almost 756 instantaneously on a high bandwidth connection and without undue 757 delay on a slower one. 759 7.1. Status Transaction 761 The status transaction returns the status of the containers the 762 device is authorized to access for the specified account together 763 with the updated Device Connection Entry if this has been modified 764 since the entry presented to authenticate the request was issued. 766 7.2. Download Transaction 768 The download transaction returns a collection of entries from one or 769 more containers associated with the profile. 771 Optional filtering criteria MAY be specified to only return objects 772 matching specific criteria and/or only return certain parts of the 773 selected messages. 775 The service MAY limit the number of entries returned in an individual 776 response for performance reasons. 778 7.2.1. Conflict Detection 780 Clients SHOULD check to determine if updates to a container conflict 781 with pending updates on the device waiting to be uploaded. For 782 example, if a contact that the user modified on the device attempting 783 to synchronize was subsequently deleted. 785 The means of resolving such conflicts is not in the scope of this 786 specification. 788 7.2.2. Filtering 790 Clients may request container updates be filtered to redact catalog 791 entries that have been updated or deleted or spool entries that have 792 been read, deleted or were received before a certain date. 794 7.3. Upload Transaction 796 The upload transaction upload objects to a catalog or spool. 798 Multiple objects MAY be uploaded at once. Object updates MAY be 799 conditional on the successful completion of other upload requests. 801 The transaction MAY be performed in one request/response round trip 802 or with separate round trips to confirm that the transaction is 803 accepted by the service before sending large number of updates. 805 8. Device Connection 807 Devices request connection to a Mesh profile using the "Connect" 808 transaction. Three connection mechanisms are currently defined. All 809 three of which offer strong mutual authentication. 811 Device Authenticated 813 Pin Authenticated 815 EARL Connection Mode 817 The first two of these mechanisms are initiated from the device being 818 connected which requires that the Mesh Service Account it is being 819 connected to be entered into it. Use of these mechanisms thus 820 requires keyboard and display affordances or accessibility 821 equivalents. 823 The last mechanism is initiated from an administration device that is 824 already connected to the account. It is intended for use in 825 circumstances where the device being connected does not have the 826 necessary affordances to allow the Device or PIN authenticated modes. 828 In either case, the connection request is completed by the device 829 requesting synchronization with the Mesh Account using its device 830 credential for authentication. If the connection request was 831 accepted, the device will be provisioned with the Device Connection 832 Assertion allowing it to complete the process. 834 The Device Connection Assertion includes an overlay device profile 835 containing a set of private key contributions to be used to perform 836 key cogeneration on the original set of device keys to create a new 837 device profile to be used for all purposes associated with the Mesh 838 Profile to which it has just been connected. This assures the user 839 that the keys the device uses for performing operation in the context 840 of their profile are not affected by any compromise that might have 841 occurred during manufacture or at any point after up to the time it 842 was connected to their profile. 844 8.1. Device Authenticated 846 The direct connection mechanism requires that both the administration 847 device and the device originating the connection request have data 848 entry and output affordances and that it is possible for the user to 849 compare the authentication codes presented by the two devices to 850 check that they are identical. 852 8.2. PIN Authenticated 854 The PIN Connection mechanism is similar to the Direct connection 855 mechanism except that the process is initiated on an administration 856 device by requesting assignment of a new authentication PIN. The PIN 857 is then input to the connecting device to authenticate the request. 859 8.3. EARL connection mode 861 The EARL/QR code connection mechanisms are used to connect a 862 constrained device to a Mesh profile by means of an Encrypted 863 Authenticated Resource Locator, typically presented as a QR code on 864 the device itself or its packaging. 866 9. Mesh Messaging 868 Mesh Messages provide a means of communication between Mesh Service 869 Accounts with capabilities that are not possible or poorly supported 870 in traditional SMTP mail messaging: 872 * End-to-end confidentiality and authentication by default. 874 * Abuse mitigation by applying access control to every inbound and 875 outbound message. 877 * End-to-end secure group messaging. 879 * Transfer of very large data sets (Terabytes). 881 Note that although Mesh Messaging is designed to facilitate the 882 transfer of very large data sets, the size of Mesh Messages 883 themselves is severely restricted. The current default maximum size 884 being 64 KB. This approach allows Mesh 886 In addition, the platform anticipates but does not currently support 887 additional cryptographic security capabilities: 889 * Traffic analysis resistance using mix networks (Chaum). 891 * Simultaneous contract binding using fair contract signing 892 (Micali). 894 While these capabilities might in time cause Mesh Messaging to 895 replace SMTP, this is not a near term goal. The short-term goal of 896 Mesh Messaging is to support the Contact Exchange and Confirmation 897 applications. 899 Two important classes of application that are not currently supported 900 directly are payments and presence. While prototypes of these 901 applications have been considered, it is not clear if these are best 902 implemented as special cases of the Confirmation and Contact Exchange 903 applications or as separate applications in their own right. 905 9.1. Message Exchange 907 To enable effective abuse mitigation, Mesh Messaging enforces a four 908 corner communication model in which all outbound and inbound messages 909 pass through a Mesh Service which accredits and authorizes the 910 messages on the user's behalf. 912 (Artwork only available as svg: No external link available, see 913 draft-hallambaker-mesh-protocol-05.html for artwork.) 915 Figure 1 917 The Post transaction is used for client-service and service-service 918 messaging transactions. 920 9.1.1. Client-Service (Post Transaction) 922 To send a message, the client creates the Mesh Message structure, 923 encapsulates it in a DARE Message and forwards this to its service 924 using a "Post" transaction. 926 The Post transaction is authenticated to the service by device using 927 the usual means of profile or ticket authentication. 929 The DARE Message MUST be signed under a device signature key 930 accredited by a Device Connection Assertion provided in the message 931 signature block. 933 9.1.2. Service-Service (Post Transaction) 935 The Mesh Service receiving the message from the user's device MAY 936 attempt immediate retransmission or queue it to be sent at a future 937 time. Mesh Services SHOULD forward messages without undue delay. 939 The Post transaction forwarding the message to the destination 940 service carries the same payload as the original request but is 941 authenticated by the service forwarding it. This authentication MAY 942 be my means of either profile or ticket authentication. 944 9.1.2.1. Denial of Service Mitigation 946 Services SHOULD implement Denial of Service mitigation strategies 947 including limiting the maximum time taken to complete a transaction 948 and refusing connections from clients that engage in patterns of 949 behavior consistent with abuse. 951 The limitation in message size allows Mesh Services to aggressively 952 time out connections that take too long to complete a transaction. A 953 Mesh Service that hosted on a 10Mb/s link should be able to transfer 954 20 messages a second. If the service is taking more than 5 seconds 955 to complete a transaction, either the source or the destination 956 service is overloaded or the message itself is an attack. 958 Imposing hard constraints on Mesh Service performance requires 959 deployments to scale and apply resources appropriately. If a service 960 is attempting to transfer 100 messages simultaneously and 40% are 961 taking 4 seconds or more, this indicates that the number of 962 simultaneous transfers being attempted should be reduced. 963 Contrawise, if 90% are completinin less than a second, the number of 964 threads allocated to sending outbound messages might be increased. 966 9.1.2.2. Access Control 968 The inbound service MUST subject inbound messages to Access Control 969 according to the credentials presented in the DARE Message payload. 971 After verifying the signature and checking that the key is properly 972 accredited in accordance with site policy, the service applies 973 authorization controls taking account of: 975 * The accreditation of the sender 977 * The accreditation of the transmitting Service 979 * The type of Mesh Message being sent 981 * User policy as specified in their Contact Catalog 983 * Site policy. 985 9.1.3. Service-Client (Synchronization) 987 The final recipient receives the message by synchronizing their 988 inbound spool. 990 10. Protocol Schema 991 HTTP Well Known Service Prefix: /.well-known/mmm 993 Every Mesh Portal Service transaction consists of exactly one request 994 followed by exactly one response. Mesh Service transactions MAY 995 cause modification of the data stored in the Mesh Service or the Mesh 996 itself but do not cause changes to the connection state. The 997 protocol itself is thus idempotent. There is no set sequence in 998 which operations are required to be performed. It is not necessary 999 to perform a Hello transaction prior to any other transaction. 1001 10.1. Request Messages 1003 A Mesh Portal Service request consists of a payload object that 1004 inherits from the MeshRequest class. When using the HTTP binding, 1005 the request MUST specify the portal DNS address in the HTTP Host 1006 field. 1008 10.1.1. Message: MeshRequest 1010 Base class for all request messages. 1012 [No fields] 1014 10.1.2. Message: MeshRequestUser 1016 Base class for all request messages made by a user. 1018 Inherits: MeshRequest 1020 Account: String (Optional) The fully qualified account name 1021 (including DNS address) to which the request is directed. 1023 DeviceProfile: DareEnvelope (Optional) Device profile of the device 1024 making the request. 1026 10.2. Response Messages 1028 A Mesh Portal Service response consists of a payload object that 1029 inherits from the MeshResponse class. When using the HTTP binding, 1030 the response SHOULD report the Status response code in the HTTP 1031 response message. However the response code returned in the payload 1032 object MUST always be considered authoritative. 1034 10.2.1. Message: MeshResponse 1036 Base class for all response messages. Contains only the status code 1037 and status description fields. 1039 [No fields] 1041 10.3. Imported Objects 1043 The Mesh Service protocol makes use of JSON objects defined in the 1044 JOSE Signatgure and Encryption specifications and in the DARE Data At 1045 Rest Encryption extensions to JOSE. 1047 10.4. Common Structures 1049 The following common structures are used in the protocol messages: 1051 10.4.1. Structure: KeyValue 1053 Describes a Key/Value structure used to make queries for records 1054 matching one or more selection criteria. 1056 Key: String (Optional) The data retrieval key. 1058 Value: String (Optional) The data value to match. 1060 10.4.2. Structure: ConstraintsSelect 1062 Specifies constraints to be applied to a search result. These allow 1063 a client to limit the number of records returned, the quantity of 1064 data returned, the earliest and latest data returned, etc. 1066 Container: String (Optional) The container to be searched. 1068 IndexMin: Integer (Optional) Only return objects with an index value 1069 that is equal to or higher than the value specified. 1071 IndexMax: Integer (Optional) Only return objects with an index value 1072 that is equal to or lower than the value specified. 1074 NotBefore: DateTime (Optional) Only data published on or after the 1075 specified time instant is requested. 1077 Before: DateTime (Optional) Only data published before the specified 1078 time instant is requested. This excludes data published at the 1079 specified time instant. 1081 PageKey: String (Optional) Specifies a page key returned in a 1082 previous search operation in which the number of responses 1083 exceeded the specified bounds. 1085 When a page key is specified, all the other search parameters 1086 except for MaxEntries and MaxBytes are ignored and the service 1087 returns the next set of data responding to the earlier query. 1089 10.4.3. Structure: ConstraintsData 1091 Specifies constraints on the data to be sent. 1093 MaxEntries: Integer (Optional) Maximum number of entries to send. 1095 BytesOffset: Integer (Optional) Specifies an offset to be applied to 1096 the payload data before it is sent. This allows large payloads to 1097 be transferred incrementally. 1099 BytesMax: Integer (Optional) Maximum number of payload bytes to 1100 send. 1102 Header: Boolean (Optional) Return the entry header 1104 Payload: Boolean (Optional) Return the entry payload 1106 Trailer: Boolean (Optional) Return the entry trailer 1108 10.4.4. Structure: PolicyAccount 1110 Describes the account creation policy including constraints on 1111 account names, whether there is an open account creation policy, etc. 1113 Minimum: Integer (Optional) Specifies the minimum length of an 1114 account name. 1116 Maximum: Integer (Optional) Specifies the maximum length of an 1117 account name. 1119 InvalidCharacters: String (Optional) A list of characters that the 1120 service does not accept in account names. The list of characters 1121 MAY not be exhaustive but SHOULD include any illegal characters in 1122 the proposed account name. 1124 10.4.5. Structure: ContainerStatus 1126 Container: String (Optional) 1128 Index: Integer (Optional) 1130 Digest: Binary (Optional) 1132 10.4.6. Structure: ContainerUpdate 1133 Inherits: ContainerStatus 1135 Envelopes: DareEnvelope [0..Many] The entries to be uploaded. 1137 10.5. Transaction: Hello 1139 Request: HelloRequest 1141 Response: MeshHelloResponse 1143 Report service and version information. 1145 The Hello transaction provides a means of determining which protocol 1146 versions, message encodings and transport protocols are supported by 1147 the service. 1149 The PostConstraints field MAY be used to advise senders of a maximum 1150 size of payload that MAY be sent in an initial Post request. 1152 10.5.1. Message: MeshHelloResponse 1154 ConstraintsUpdate: ConstraintsData (Optional) Specifies the default 1155 data constraints for updates. 1157 ConstraintsPost: ConstraintsData (Optional) Specifies the default 1158 data constraints for message senders. 1160 PolicyAccount: PolicyAccount (Optional) Specifies the account 1161 creation policy 1163 EnvelopedProfileService: DareEnvelope (Optional) The enveloped 1164 master profile of the service. 1166 EnvelopedProfileHost: DareEnvelope (Optional) The enveloped profile 1167 of the host. 1169 10.6. Transaction: CreateAccount 1171 Request: CreateRequest 1173 Response: CreateResponse 1175 Request creation of a new service account. 1177 Attempt 1179 10.6.1. Message: CreateRequest 1181 Request binding of an account to a service address. 1183 Inherits: MeshRequest 1185 ServiceID: String (Optional) The service account to bind to. 1187 SignedProfileMesh: DareEnvelope (Optional) The persistent profile 1188 that will be used to validate changes to the account assertion. 1190 SignedAssertionAccount: DareEnvelope (Optional) The signed assertion 1191 describing the account. 1193 10.6.2. Message: CreateResponse 1195 Inherits: MeshResponse 1197 Reports the success or failure of a Create transaction. 1199 Reason: String (Optional) Text explaining the status of the creation 1200 request. 1202 URL: String (Optional) A URL to which the user is directed to 1203 complete the account creation request. 1205 10.7. Transaction: DeleteAccount 1207 Request: DeleteRequest 1209 Response: DeleteResponse 1211 Request deletion of a service account. 1213 10.7.1. Message: DeleteRequest 1215 Request creation of a new portal account. The request specifies the 1216 requested account identifier and the Mesh profile to be associated 1217 with the account. 1219 Inherits: MeshRequestUser 1221 [No fields] 1223 10.7.2. Message: DeleteResponse 1225 Inherits: MeshResponse 1226 Reports the success or failure of a Delete transaction. 1228 [No fields] 1230 10.8. Transaction: Complete 1232 Request: CompleteRequest 1234 Response: CompleteResponse 1236 10.8.1. Message: CompleteRequest 1238 Inherits: StatusRequest 1240 ServiceID: String (Optional) 1242 ResponseID: String (Optional) 1244 10.8.2. Message: CompleteResponse 1246 Inherits: MeshResponse 1248 SignedResponse: DareEnvelope (Optional) The signed assertion 1249 describing the result of the connect request 1251 10.9. Transaction: Status 1253 Request: StatusRequest 1255 Response: StatusResponse 1257 10.9.1. Message: StatusRequest 1259 Inherits: MeshRequestUser 1261 DeviceUDF: String (Optional) 1263 ProfileMasterDigest: Binary (Optional) 1265 Catalogs: String [0..Many] 1267 Spools: String [0..Many] 1269 10.9.2. Message: StatusResponse 1271 Inherits: MeshResponse 1272 EnvelopedProfileMaster: DareEnvelope (Optional) The master profile 1273 that provides the root of trust for this Mesh 1275 EnvelopedCatalogEntryDevice: DareEnvelope (Optional) The catalog 1276 device entry 1278 ContainerStatus: ContainerStatus [0..Many] 1280 10.10. Transaction: Download 1282 Request: DownloadRequest 1284 Response: DownloadResponse 1286 Request objects from the specified container with the specified 1287 search criteria. 1289 10.10.1. Message: DownloadRequest 1291 Inherits: MeshRequestUser 1293 Request objects from the specified container(s). 1295 A client MAY request only objects matching specified search criteria 1296 be returned and MAY request that only specific fields or parts of the 1297 payload be returned. 1299 Select: ConstraintsSelect [0..Many] Specifies constraints to be 1300 applied to a search result. These allow a client to limit the 1301 number of records returned, the quantity of data returned, the 1302 earliest and latest data returned, etc. 1304 ConstraintsPost: ConstraintsData (Optional) Specifies the data 1305 constraints to be applied to the responses. 1307 10.10.2. Message: DownloadResponse 1309 Inherits: MeshResponse 1311 Return the set of objects requested. 1313 Services SHOULD NOT return a response that is disproportionately 1314 large relative to the speed of the network connection without a clear 1315 indication from the client that it is relevant. A service MAY limit 1316 the number of objects returned. A service MAY limit the scope of 1317 each response. 1319 Updates: ContainerUpdate [0..Many] The updated data 1321 10.11. Transaction: Upload 1323 Request: UploadRequest 1325 Response: UploadResponse 1327 Request objects from the specified container with the specified 1328 search criteria. 1330 10.11.1. Message: UploadRequest 1332 Inherits: MeshRequestUser 1334 Upload entries to a container. This request is only valid if it is 1335 issued by the owner of the account 1337 Updates: ContainerUpdate [0..Many] The data to be updated 1339 Self: DareEnvelope [0..Many] Entries to be added to the inbound 1340 spool on the account, e.g. completion messages. 1342 10.11.2. Message: UploadResponse 1344 Inherits: MeshResponse 1346 Response to an upload request. 1348 Entries: EntryResponse [0..Many] The responses to the entries. 1350 ConstraintsData: ConstraintsData (Optional) If the upload request 1351 contains redacted entries, specifies constraints that apply to the 1352 redacted entries as a group. Thus the total payloads of all the 1353 messages must not exceed the specified value. 1355 10.11.3. Structure: EntryResponse 1357 IndexRequest: Integer (Optional) The index value of the entry in the 1358 request. 1360 IndexContainer: Integer (Optional) The index value assigned to the 1361 entry in the container. 1363 Result: String (Optional) Specifies the result of attempting to add 1364 the entry to a catalog or spool. Valid values for a message are 1365 'Accept', 'Reject'. Valid values for an entry are 'Accept', 1366 'Reject' and 'Conflict'. 1368 ConstraintsData: ConstraintsData (Optional) If the entry was 1369 redacted, specifies constraints that apply to the redacted entries 1370 as a group. Thus the total payloads of all the messages must not 1371 exceed the specified value. 1373 10.12. Transaction: Post 1375 Request: PostRequest 1377 Response: PostResponse 1379 Request to post to a spool from an external party. The request and 1380 response messages are extensions of the corresponding messages for 1381 the Upload transaction. It is expected that additional fields will 1382 be added as the need arises. 1384 10.12.1. Message: PostRequest 1386 Inherits: MeshRequest 1388 Accounts: String [0..Many] The account(s) to which the request is 1389 directed. 1391 Message: DareEnvelope [0..Many] The entries to be uploaded. These 1392 MAY be either complete messages or redacted messages. In either 1393 case, the messages MUST conform to the ConstraintsUpdate specified 1394 by the service 1396 Self: DareEnvelope [0..Many] Messages to be appended to the user's 1397 self spool. this is typically used to post notifications to the 1398 user to mark messages as having been read or responded to. 1400 10.12.2. Message: PostResponse 1402 Inherits: UploadResponse 1404 [No fields] 1406 10.13. Transaction: Connect 1408 Request: ConnectRequest 1410 Response: ConnectResponse 1412 Request information necessary to begin making a connection request. 1414 10.13.1. Message: ConnectRequest 1415 Inherits: MeshRequest 1417 MessageConnectionRequestClient: DareEnvelope (Optional) The 1418 connection request generated by the client 1420 10.13.2. Message: ConnectResponse 1422 Inherits: MeshResponse 1424 EnvelopedConnectionResponse: DareEnvelope (Optional) The connection 1425 request generated by the client 1427 EnvelopedProfileMaster: DareEnvelope (Optional) The master profile 1428 that provides the root of trust for this Mesh 1430 EnvelopedAccountAssertion: DareEnvelope (Optional) The current 1431 account assertion 1433 11. Security Considerations 1435 The security considerations for use and implementation of Mesh 1436 services and applications are described in the Mesh Security 1437 Considerations guide [draft-hallambaker-mesh-security]. 1439 12. IANA Considerations 1441 All the IANA considerations for the Mesh documents are specified in 1442 this document 1444 13. Acknowledgements 1446 A list of people who have contributed to the design of the Mesh is 1447 presented in [draft-hallambaker-mesh-architecture]. 1449 14. Normative References 1451 [draft-hallambaker-mesh-architecture] 1452 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 1453 Architecture Guide", Work in Progress, Internet-Draft, 1454 draft-hallambaker-mesh-architecture-12, 16 January 2020, 1455 . 1458 [draft-hallambaker-mesh-security] 1459 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 1460 Security Considerations", Work in Progress, Internet- 1461 Draft, draft-hallambaker-mesh-security-03, 16 January 1462 2020, . 1465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1466 Requirement Levels", BCP 14, RFC 2119, 1467 DOI 10.17487/RFC2119, March 1997, 1468 . 1470 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1471 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1472 . 1474 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1475 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1476 . 1478 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1479 (HTTP/1.1): Message Syntax and Routing", RFC 7230, 1480 DOI 10.17487/RFC7230, June 2014, 1481 . 1483 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1484 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1485 . 1487 15. Informative References 1489 [draft-hallambaker-mesh-developer] 1490 Hallam-Baker, P., "Mathematical Mesh: Reference 1491 Implementation", Work in Progress, Internet-Draft, draft- 1492 hallambaker-mesh-developer-09, 23 October 2019, 1493 . 1496 [ECMA-262] Ecma International, "ECMAScript(R) 2017 Language 1497 Specification", June 2017.