idnits 2.17.1 draft-hallambaker-mesh-protocol-02.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2019) is 1715 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1509 -- Looks like a reference, but probably isn't: '2' on line 1512 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft August 13, 2019 4 Intended status: Informational 5 Expires: February 14, 2020 7 Mathematical Mesh 3.0 Part V: Protocol Reference 8 draft-hallambaker-mesh-protocol-02 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 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html 20 [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 14, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. Mesh Service . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Partitioning . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. DNS Web Service Discovery . . . . . . . . . . . . . . . . 7 67 4.2. Web Service Protocol Binding . . . . . . . . . . . . . . 7 68 4.2.1. Transport Security . . . . . . . . . . . . . . . . . 8 69 4.2.2. HTTP Message Binding . . . . . . . . . . . . . . . . 8 70 4.2.3. Request . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. DARE Message Encapsulation . . . . . . . . . . . . . . . 11 73 4.3.1. Null Authentication . . . . . . . . . . . . . . . . . 11 74 4.3.2. Device Authentication . . . . . . . . . . . . . . . . 11 75 4.3.3. Profile Authentication . . . . . . . . . . . . . . . 11 76 4.3.4. Ticket Authentication . . . . . . . . . . . . . . . . 12 77 4.4. Payload Encoding . . . . . . . . . . . . . . . . . . . . 12 78 4.5. Error handling and response codes . . . . . . . . . . . . 13 79 5. Service Description . . . . . . . . . . . . . . . . . . . . . 13 80 6. Account Management . . . . . . . . . . . . . . . . . . . . . 15 81 7. Container Synchronization . . . . . . . . . . . . . . . . . . 16 82 7.1. Status Transaction . . . . . . . . . . . . . . . . . . . 17 83 7.2. Download Transaction . . . . . . . . . . . . . . . . . . 17 84 7.2.1. Conflict Detection . . . . . . . . . . . . . . . . . 17 85 7.2.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 17 86 7.3. Upload Transaction . . . . . . . . . . . . . . . . . . . 17 87 8. Device Connection . . . . . . . . . . . . . . . . . . . . . . 18 88 8.1. Device Authenticated . . . . . . . . . . . . . . . . . . 18 89 8.2. PIN Authenticated . . . . . . . . . . . . . . . . . . . . 19 90 8.3. EARL connection mode . . . . . . . . . . . . . . . . . . 19 91 9. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . . . 19 92 9.1. Message Exchange . . . . . . . . . . . . . . . . . . . . 20 93 9.1.1. Client-Service (Post Transaction) . . . . . . . . . . 20 94 9.1.2. Service-Service (Post Transaction) . . . . . . . . . 20 95 9.1.3. Service-Client (Synchronization) . . . . . . . . . . 21 96 10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 22 97 10.1. Request Messages . . . . . . . . . . . . . . . . . . . . 22 98 10.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 22 99 10.1.2. Message: MeshRequestUser . . . . . . . . . . . . . . 22 100 10.2. Response Messages . . . . . . . . . . . . . . . . . . . 22 101 10.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 23 102 10.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 23 103 10.4. Common Structures . . . . . . . . . . . . . . . . . . . 23 104 10.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 23 105 10.4.2. Structure: ConstraintsSelect . . . . . . . . . . . . 23 106 10.4.3. Structure: ConstraintsData . . . . . . . . . . . . . 24 107 10.4.4. Structure: PolicyAccount . . . . . . . . . . . . . . 24 108 10.4.5. Structure: ContainerStatus . . . . . . . . . . . . . 24 109 10.4.6. Structure: ContainerUpdate . . . . . . . . . . . . . 25 110 10.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 25 111 10.5.1. Message: MeshHelloResponse . . . . . . . . . . . . . 25 112 10.6. Transaction: Complete . . . . . . . . . . . . . . . . . 26 113 10.6.1. Message: CompleteRequest . . . . . . . . . . . . . . 26 114 10.7. Transaction: Status . . . . . . . . . . . . . . . . . . 26 115 10.7.1. Message: StatusRequest . . . . . . . . . . . . . . . 26 116 10.7.2. Message: StatusResponse . . . . . . . . . . . . . . 26 117 10.8. Transaction: Download . . . . . . . . . . . . . . . . . 27 118 10.8.1. Message: DownloadRequest . . . . . . . . . . . . . . 27 119 10.8.2. Message: DownloadResponse . . . . . . . . . . . . . 27 120 10.9. Transaction: Upload . . . . . . . . . . . . . . . . . . 28 121 10.9.1. Message: UploadRequest . . . . . . . . . . . . . . . 28 122 10.9.2. Message: UploadResponse . . . . . . . . . . . . . . 28 123 10.9.3. Structure: EntryResponse . . . . . . . . . . . . . . 28 124 10.10. Transaction: Post . . . . . . . . . . . . . . . . . . . 29 125 10.10.1. Message: PostRequest . . . . . . . . . . . . . . . 29 126 10.10.2. Message: PostResponse . . . . . . . . . . . . . . . 29 127 10.11. Transaction: Connect . . . . . . . . . . . . . . . . . . 30 128 10.11.1. Message: ConnectRequest . . . . . . . . . . . . . . 30 129 10.11.2. Message: ConnectResponse . . . . . . . . . . . . . 30 130 10.12. Transaction: CreateAccount . . . . . . . . . . . . . . . 30 131 10.12.1. Message: CreateRequest . . . . . . . . . . . . . . 31 132 10.12.2. Message: CreateResponse . . . . . . . . . . . . . . 31 133 10.13. Transaction: DeleteAccount . . . . . . . . . . . . . . . 31 134 10.13.1. Message: DeleteRequest . . . . . . . . . . . . . . 31 135 10.13.2. Message: DeleteResponse . . . . . . . . . . . . . . 32 136 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 137 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 138 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 139 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 140 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 141 14.2. Informative References . . . . . . . . . . . . . . . . . 33 142 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 143 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 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 o Provides the master persistence store for the Catalogs and Spools 155 associated with the account. 157 o Enables synchronization of Catalogs and Spools with connected 158 devices. 160 o Enforces access control on inbound Mesh Messages from other users 161 and other Mesh Services. 163 o 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 and 177 provides a 'null' transaction which MAY be used to establish an 178 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 containers 184 between the service (Master) and the connected devices (Replicas). 186 Connect Initiate the process of connecting a device to a Mesh 187 profile from the device itself. 189 Post Request that a Mesh Message be transferred to one or more Mesh 190 Accounts. 192 Although these functions could in principle be used to replace many 193 if not most existing Internet application protocols, the principal 194 value of any communication protocol lies in the size of the audience 195 it allows them to communicate with. Thus, while the Mesh Messaging 196 service is designed to support efficient and reliable transfer of 197 messages ranging in size from a few bytes to multiple terabytes, the 198 near-term applications of these services will be to applications that 199 are not adequately supported by existing protocols if at all. 201 2. Definitions 203 This section presents the related specifications and standard, the 204 terms that are used as terms of art within the documents and the 205 terms used as requirements language. 207 2.1. Requirements Language 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119] . 213 2.2. Defined Terms 215 The terms of art used in this document are described in the Mesh 216 Architecture Guide [draft-hallambaker-mesh-architecture] . 218 2.3. Related Specifications 220 The architecture of the Mathematical Mesh is described in the Mesh 221 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 222 documentation set and related specifications are described in this 223 document. 225 2.4. Implementation Status 227 The implementation status of the reference code base is described in 228 the companion document [draft-hallambaker-mesh-developer] . 230 3. Mesh Service 232 A Mesh Service is a minimally trusted service. In particular a user 233 does not need to trust a Mesh service to protect the confidentiality 234 or integrity of most data stored in the account catalogs and spools. 236 Unless the use of the Mesh Service is highly restricted, a user does 237 need to trust the Mesh Service in certain respects: 239 Data Loss A service could refuse to respond to requests to download 240 data. 242 Integrity (Stale Data) The use of Merkle Trees limits but does not 243 eliminate the ability of a Mesh Service to respond to requests 244 with stale data. 246 Messaging A service could reject requests to post messages to or 247 accept messages from other mesh users. 249 This risk is a necessary consequence of the fact that the Mesh 250 Service Provider is accountable to other Mesh Service Providers 251 for abuse originating from their service. 253 Traffic analysis A Mesh Service has knowledge of the number of Mesh 254 Messages being sent and received by its users and the addresses to 255 which they are being sent to or received from. 257 The need to trust the Mesh Service in these respects is mitigated by 258 accountability and the user's ability to change Mesh Service 259 providers at any time they choose with minimal inconvenience. 261 It is possible that some of these risks will be reduced in future 262 versions of the Mesh Service Protocol but it is highly unlikely that 263 these can be eliminated entirely without compromising practicality or 264 efficiency. 266 3.1. Data Model 268 The design of the Mesh Service model followed a quasi-formal approach 269 in which the system was reduced to schemas which could in principle 270 be rendered in a formal development method but without construction 271 of proofs. 273 Like the contents of Mesh Accounts, a Mesh Service may be represented 274 by a collection of catalogs and spools, for example: 276 Account Catalog Contains the account entries. 278 Incident Spool Reports of potential abuse 280 Backup of the service MAY be implemented using the same container 281 synchronization mechanism used to synchronize account catalogs and 282 spools. 284 3.2. Partitioning 286 Mesh Services supporting a large number of accounts or large activity 287 volume MAY partition the account catalog between one or more hosts 288 using the usual tiered service model in which a front-end server 289 receives traffic for any account hosted at the server and routes the 290 request to the back-end service that provides the persistence store 291 for that account. 293 In addition, the Mesh Service Protocol supports a 'direct connection' 294 partitioning model in which devices are given a DNS name which MAY 295 allow for direct connection to the persistence host or to a front-end 296 service offering service that is in some way specific to that 297 account. 299 4. Protocol Bindings 301 Mesh Service transactions are mapped to an underlying messaging and 302 transport protocol. The following binding 304 Mesh Services MUST support the Web Service binding specified in this 305 document and MAY support the UDP binding currently in development. 307 4.1. DNS Web Service Discovery 309 The DNS Web Service discovery mechanism is used to discover Mesh 310 Services regardless of the protocol binding .The service name, DNS 311 prefix and and .well-known service suffix are specified as follows: 313 o Service Name: mmm 315 o DNS Prefix: _mmm._tcp 317 o Well Known service suffix: /.well-known/mmm 319 4.2. Web Service Protocol Binding 321 The Web Service Protocol binding makes use of the most widely 322 deployed and used protocols: 324 o Discovery: DNS Service discovery 326 o Transport: TLS 328 o Application: HTTP 330 o Presentation: DARE Message 331 o Encoding: JSON, JSON-B 333 The chief limitations of the Web Service Protocol Binding are that 334 the use of TCP based transport results in unsatisfactory latency for 335 some applications and that the HTTP application layer only serves to 336 allow a host to support multiple services on the same TCP/IP port. 338 4.2.1. Transport Security 340 Mesh Services MUST offer TLS transport and MAY offer non TLS 341 transport. MESH clients SHOULD use TLS transport when connecting to 342 a MESH service. 344 TLS version 1.3 [RFC8446] or higher MUST be supported. Client 345 authentication SHOULD NOT be used. 347 4.2.2. HTTP Message Binding 349 All messages are exchanged as HTTP POST transactions. Support for 350 and use of HTTP/1.1 [RFC7230] is REQUIRED. Services MAY support 351 HTTP/2. 353 In contrast to other approaches to the design of Web Services, the 354 only use made of the HTTP transport is to distinguish between 355 different services on the same host using the Host header and .well- 356 known convention and for message framing. No use is made of the URI 357 request line to identify commands, nor are the caching or proxy 358 capabilities of HTTP made use of. 360 4.2.3. Request 362 The HTTP request MAY contain any valid HTTP header specified in 363 [RFC7230] . 365 Request Line URI /well-known/ (unless overridden using a 366 TXT path attribute) 368 Request Line Method POST 370 Host: Header 372 Content-Encoding As specified in section yy below. 374 Content-Type As specified in section zz below. 376 Content-Length or Transfer-Encoding As specified in [RFC7230] . 378 Payload The content payload as specified in section XX below. 380 [Note, this is showing the payload, not the binding as is intended 381 because the current code doesn't implement it as intended yet] 383 { 384 "Hello": {}} 386 4.2.4. Response 388 The response MAY contain any HTTP response header but since JWB 389 services do not make use of HTTP caching and messages are not 390 intended to be modified by HTTP intermediaries, only a limited number 391 of headers have significance: 393 Response Code The HTTP response code. This is processed as 394 described in section zz below. 396 Content-Type As specified in section zz below. 398 Content-Length or Transfer-Encoding As specified in [RFC7230] . 400 Cache-Control Since the only valid HTTP method for a JWB request is 401 POST, JWB responses are not cacheable. The use of the cache- 402 control header is therefore unnecessary. However, experience 403 suggests that reviewers find it easier to understand protocol 404 specifications if they are reminded of the fact that caching is 405 neither supported nor desired. 407 [Note, this is showing the payload, not the binding as is intended 408 because the current code doesn't implement it as intended yet] 410 { 411 "MeshHelloResponse": { 412 "Version": { 413 "Major": 3, 414 "Minor": 0, 415 "Encodings": [{ 416 "ID": ["application/json"]}]}, 417 "EnvelopedProfileService": [{ 418 "dig": "S512"}, 419 "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2l 420 nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CQ1AtT0dGWS1LRkFRLTZFTzMtV 421 lg2Uy02VjRHLUVOTlUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA 422 gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N 423 DgiLAogICAgICAgICAgIlB1YmxpYyI6ICJtSGxST1NhenBVVHp3Rk5aMHFJMU1 424 iWGpwdGhPVXhwbGUwVzhOVWFxOE03MVZUNWVOd1hqCiAgY2ZRLXRNbExnd3FfV 425 WZmMUZHbW1sSC1BIn19fX19", 426 { 427 "signatures": [{ 428 "signature": "T1N3-fnOitSUDFezSINPbh76AtbmL2ghN-antjwUrmCL0z_S- 429 IcArALioAMEaDECg2Q4bgE8IZ4Apgf9SVoj58M_dqeMEWra3mavkV3NEScBcQG 430 Tn_TxS468u9CxfKBDK9NxI7k6c1XUc4xTZGKejR8A"}], 431 "PayloadDigest": "JZHVlp6xFPQ3WG9AQrRYVkLbLiM51nEKo7ryZMnK8TJAv 432 oVKL7kQYlP3dBtayIEvGowVxFURj_vRs0EXo08Blw"}], 433 "EnvelopedProfileHost": [{ 434 "dig": "S512"}, 435 "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF 436 0dXJlIjogewogICAgICAiVURGIjogIk1ES1EtVlRURC1IUUtCLVlINk8tSDU3Q 437 y00S0RILTZLV0kiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA 438 gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL 439 AogICAgICAgICAgIlB1YmxpYyI6ICJvdURsS3lJVWtzU19DV1VocW9XYVBGUDk 440 zS2E5Wmc1M2RRQ0M0NGd1YUdPQkI5UzEyZUhsCiAgejJLb1g5LVBjdFFIMzE1N 441 jdUY21NRENBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICA 442 gIlVERiI6ICJNQzNELUlENjItTDVWWi1JV0xDLVdSTFgtN0ZUVC1GN1NUIiwKI 443 CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV 444 DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd 445 WJsaWMiOiAiNEJmZVcwV1FCNU8zRU9yalc0THZBZGtMejcxQnRKc2xzM3d6dzB 446 hY3VINUVkdXBXV1Q4dgogIEUzTU9ia2tmbURfNHRQWjdCNlZhbnRlQSJ9fX19f 447 Q", 448 { 449 "signatures": [{ 450 "signature": "POQFQQOpcuNWxUAyi3DSGtaC9yJJJ9J6wr79Qzij8jN52gx4n 451 8MitwM1T2rYMgJp6WqpSKWJfaUA2wafnkmQvVkiVT-35Mbog22krLD-HySbJAP 452 a1lUXnzzOzbLSsBwRqPyJS0m60HFxKx0h0gZh0xIA"}], 453 "PayloadDigest": "C716Q-5VPWfV5imuX-_rgmST2-J8SjFxQ_EQAPrGDD1Mr 454 UKex_wn2cckWa_qyGsHrYPMKDt_2C4U7ZU9iyUdfw"}]}} 456 4.3. DARE Message Encapsulation 458 The payload of the HTTP requests and responses is a DARE Message 459 whose payload contains the Mesh Service request or response. 461 The DARE Message encapsulation is used to authenticate the request or 462 response data. The form of the authentication depending on the 463 credentials available to the sender at the time the request is made. 465 Mesh Service MUST support the use of Mutually Authenticated Key 466 Exchange [draft-hallambaker-mesh-security] to establish the Master 467 Key used for authentication of requests and responses. 469 Requests and Responses MUST be authenticated. Requests and Responses 470 MUST be encrypted if the transport is not encrypted and MAY be 471 encrypted otherwise. 473 4.3.1. Null Authentication 475 Null Authentication MAY be used to make a Hello Request. 477 The Null Authentication mechanism MUST NOT be used for any Mesh 478 Service request or response other than a Hello request. 480 Since the Mutually Authenticated key exchange requires both parties 481 to know the public key of the other, it is not possible for a client 482 to authenticate itself to the service until it has obtained the 483 service public key. One means by which the client MAY obtain the 484 service public key is by requesting the service return the credential 485 in a Hello transaction. 487 4.3.2. Device Authentication 489 Device Authentication is used in two circumstances 491 o When requesting creation of an account 493 o When a device is requesting connection to a profile. 495 4.3.3. Profile Authentication 497 Profile Authentication has the same form as Device Authentication 498 except that the client provides its Device Connection Assertion as 499 part of the request: 501 4.3.4. Ticket Authentication 503 Ticket Authentication is used after a device has obtained an 504 authentication ticket from a service. The ticket is returned in the 505 response to a previous Profile Authentication exchange. 507 4.4. Payload Encoding 509 The Dare Message payload of a Hello request MUST be encoded in JSON 510 encoding. The payload of all other requests MUST be in either JSON 511 encoding or one of the encodings advertised as being accepted in a 512 Hello response from the Service. Services MUST accept JSON encoding 513 and MAY support the JSON-B or JSON-C encodings as specified in this 514 document. Services MUST generate a response that is compatible with 515 the DARE Message Content-Type specified in the request. 517 JSON was originally developed to provide a serialization format for 518 the JavaScript programming language [ECMA-262] . While this approach 519 is generally applicable to the type systems of scripting programming 520 languages, it is less well matched to the richer type systems of 521 modern object oriented programming languages such as Java and C#. 523 Working within a subset of the capabilities of JSON allows a Web 524 Service protocol to be accessed with equal ease from either platform 525 type. The following capabilities of JSON are avoided: 527 The ability to use arbitrary strings as field names. 529 The use of JSON objects to define maps directly 531 The following data field types are used: 533 Integer Integer values are encoded as JSON number values. 535 String Test strings are encoded as JSON text strings. 537 Boolean Boolean values are encoded as JSON 'false', 'true' or 'null' 538 tokens according to value. 540 Sequence Sequences of data items that are encoded as JSON arrays 542 Object of known type Objects whose type is known to the receiver are 543 encoded as JSON objects 545 Object of variable type Objects whose type is not known to the 546 receiver are encoded as JSON objects containing a single field 547 whose name describes the type of the object value and whose value 548 contains the value. 550 Binary Data Byte sequences are converted to BASE64-url encoding 551 [RFC4648] and encoded as JSON string values. 553 Date Time Date Time values are converted to Internet time format as 554 described in [RFC3339] and encoded as JSON string values. 556 4.5. Error handling and response codes 558 It is possible for an error to occur at any of the three layers in 559 the Web Service binding: 561 Service Layer 563 HTTP Layer 565 Transport Layer 567 Services SHOULD always attempt to return error codes at the highest 568 level possible. However, it is clearly impossible for a connection 569 that is refused at the Transport layer to return an error code at the 570 HTTP layer. It is however possible for a HTTP layer error response 571 to contain a content body. 573 In the case that a response contains both a HTTP response code and a 574 well-formed payload containing a response, the payload response SHALL 575 have precedence. 577 5. Service Description 579 The Hello transaction is used to determine the features supported by 580 the service and obtain the service credentials 582 The request payload: 584 { 585 "Hello": {}} 587 The response payload: 589 { 590 "MeshHelloResponse": { 591 "Version": { 592 "Major": 3, 593 "Minor": 0, 594 "Encodings": [{ 595 "ID": ["application/json"]}]}, 596 "EnvelopedProfileService": [{ 597 "dig": "S512"}, 598 "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2l 599 nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CQ1AtT0dGWS1LRkFRLTZFTzMtV 600 lg2Uy02VjRHLUVOTlUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA 601 gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N 602 DgiLAogICAgICAgICAgIlB1YmxpYyI6ICJtSGxST1NhenBVVHp3Rk5aMHFJMU1 603 iWGpwdGhPVXhwbGUwVzhOVWFxOE03MVZUNWVOd1hqCiAgY2ZRLXRNbExnd3FfV 604 WZmMUZHbW1sSC1BIn19fX19", 605 { 606 "signatures": [{ 607 "signature": "T1N3-fnOitSUDFezSINPbh76AtbmL2ghN-antjwUrmCL0z_S- 608 IcArALioAMEaDECg2Q4bgE8IZ4Apgf9SVoj58M_dqeMEWra3mavkV3NEScBcQG 609 Tn_TxS468u9CxfKBDK9NxI7k6c1XUc4xTZGKejR8A"}], 610 "PayloadDigest": "JZHVlp6xFPQ3WG9AQrRYVkLbLiM51nEKo7ryZMnK8TJAv 611 oVKL7kQYlP3dBtayIEvGowVxFURj_vRs0EXo08Blw"}], 612 "EnvelopedProfileHost": [{ 613 "dig": "S512"}, 614 "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF 615 0dXJlIjogewogICAgICAiVURGIjogIk1ES1EtVlRURC1IUUtCLVlINk8tSDU3Q 616 y00S0RILTZLV0kiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA 617 gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL 618 AogICAgICAgICAgIlB1YmxpYyI6ICJvdURsS3lJVWtzU19DV1VocW9XYVBGUDk 619 zS2E5Wmc1M2RRQ0M0NGd1YUdPQkI5UzEyZUhsCiAgejJLb1g5LVBjdFFIMzE1N 620 jdUY21NRENBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICA 621 gIlVERiI6ICJNQzNELUlENjItTDVWWi1JV0xDLVdSTFgtN0ZUVC1GN1NUIiwKI 622 CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV 623 DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd 624 WJsaWMiOiAiNEJmZVcwV1FCNU8zRU9yalc0THZBZGtMejcxQnRKc2xzM3d6dzB 625 hY3VINUVkdXBXV1Q4dgogIEUzTU9ia2tmbURfNHRQWjdCNlZhbnRlQSJ9fX19f 626 Q", 627 { 628 "signatures": [{ 629 "signature": "POQFQQOpcuNWxUAyi3DSGtaC9yJJJ9J6wr79Qzij8jN52gx4n 630 8MitwM1T2rYMgJp6WqpSKWJfaUA2wafnkmQvVkiVT-35Mbog22krLD-HySbJAP 631 a1lUXnzzOzbLSsBwRqPyJS0m60HFxKx0h0gZh0xIA"}], 632 "PayloadDigest": "C716Q-5VPWfV5imuX-_rgmST2-J8SjFxQ_EQAPrGDD1Mr 633 UKex_wn2cckWa_qyGsHrYPMKDt_2C4U7ZU9iyUdfw"}]}} 635 6. Account Management 637 A Mesh Account is bound to a Mesh Service by completing a 638 CreateAccount transaction with the service. 640 The client requesting the account creation specifies the ProfileMesh 641 profile describing the requested account and lists of initial entries 642 to populate the devices and contacts catalogs. Additional catalogs 643 MAY be synchronized if the account creation request is accepted. 645 The request payload: 647 { 648 "CreateAccount": { 649 "ServiceID": "alice@example.com", 650 "SignedProfileMesh": [{ 651 "dig": "S512"}, 652 "ewogICJQcm9maWxlUGVyc29uYWwiOiB7CiAgICAiS2V5T2ZmbGluZVN 653 pZ25hdHVyZSI6IHsKICAgICAgIlVERiI6ICJNQU9aLTNNVkUtRzVFTi02NEJJL 654 UkzUk0tT0RGSi1INVc0IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiA 655 gICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkN 656 DQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMFZ4cTEwNVFKNHkwSUp1X3BFMml 657 CbTZ5N05UcnVRUWtaaFVJSkdZdS02bUJoTkpDVEtqbgogIFNJa2tiNlNLNmFMU 658 mx6cHd2LVVXQ3pNQSJ9fX0sCiAgICAiS2V5c09ubGluZVNpZ25hdHVyZSI6IFt 659 7CiAgICAgICAgIlVERiI6ICJNQkU3LVVDSkYtWkFaMi1NTEdQLUxCNTUtSFpCV 660 C1YTUhWIiwKICAgICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICA 661 gICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgICAiY3J2IjogIkVkNDQ4I 662 iwKICAgICAgICAgICAgIlB1YmxpYyI6ICJSZDNzbkRaLWlPT1lBMUJTcGhkN0g 663 5SjFDNXhmU1Iyb2pCRUdLMVNsalJVRDA4TVI0dEZzCiAgV28wWTJjR0NPWUxiS 664 ElpNmFUNkhmZkFBIn19fV0sCiAgICAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICA 665 gIlVERiI6ICJNQkdBLUMyVVEtUUZWRy01SE5BLTJXVFotSUtOSy1FV0hUIiwKI 666 CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV 667 DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd 668 WJsaWMiOiAiNDJJeVZKV2c0VzFKOS1GMGl0UEFEZDAweUFZUXdCOGtXUDBVa1l 669 XTHFKdVI2ZzB3bmtZUQogIENGOFpyNHpUZTJsTmhEUFVmOEJSOFZTQSJ9fX19f 670 Q", 671 { 672 "signatures": [{ 673 "signature": "VALT2etUKtiTIYngz7uaXF3OxOFiE_VpdeHHLe1Rpz6HjuyQ4 674 j7WWJf2Aj7rmhMTYRW2H9NcjdAAd80TRAuxvtIRZhqLl5HL7UHwkzRumbPGic2 675 7dqudEyGp-FD6VYqHxD7WztJMzHklLk-COjbP4y8A"}], 676 "PayloadDigest": "8QolTaruD1-DZwTZ-aB7olA1eit5fb7TUhRSI1heCNYjR 677 FJ1vSAArAq4h_Wr7AVBnk1WzLLDnEaF8xZezfz2MA"}], 678 "SignedAssertionAccount": [{ 679 "dig": "S512"}, 680 "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJTZXJ2aWNlSURzIjo 681 gWyJhbGljZUBleGFtcGxlLmNvbSJdLAogICAgIk1lc2hQcm9maWxlVURGIjogI 682 k1BT1otM01WRS1HNUVOLTY0QkktSTNSTS1PREZKLUg1VzQiLAogICAgIktleUV 683 uY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUFGWi1WVU1QLTdQVTMtNFRQN 684 y03TVJaLUJLQlEtVk1OTiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewo 685 gICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZ 686 DQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIjFsY1pVTmpIR0pXa1BXbVM5TUh 687 lR1lOZkRTWkdVTzRsR2s1WHBxN1hnSC0tU0dMUUU0RV8KICBzLTBiMFBJOG0wZ 688 mp0eklNVUVZRElfSUEifX19fX0", 689 { 690 "signatures": [{ 691 "signature": "0tYuHZB3Xmk_MaOGK09khjSHr9jHUx_JLTixvYDZ7zEGCN_nD 692 TcLLeZujb8-wqMJalMjb_7aAggAmapk0tPfnGGbYnWmwBIKamrdpbnfMHtFm-i 693 Ny4S2rfaVLNEHSH9s42mYsdw9eitPX8xZEgXUIQ8A"}], 694 "PayloadDigest": "alXz9HJmuEpu2PglvnL5U-_nm4PLrWlWGIMlP5rfRUE4f 695 heefPxgiqG8rBAGahZPyGSpIzCK-7Sgh0sxx7-pgw"}]}} 696 697 The response payload: 698
699 700