Network Working Group P. Hallam-Baker Internet-Draft August 13, 2019 Intended status: Informational Expires: February 14, 2020 Mathematical Mesh 3.0 Part V: Protocol Reference draft-hallambaker-mesh-protocol-02 Abstract The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html [1] . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 14, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Hallam-Baker Expires February 14, 2020 [Page 1] Internet-Draft Mesh Protocol Reference August 2019 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 3. Mesh Service . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Partitioning . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 7 4.1. DNS Web Service Discovery . . . . . . . . . . . . . . . . 7 4.2. Web Service Protocol Binding . . . . . . . . . . . . . . 7 4.2.1. Transport Security . . . . . . . . . . . . . . . . . 8 4.2.2. HTTP Message Binding . . . . . . . . . . . . . . . . 8 4.2.3. Request . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 9 4.3. DARE Message Encapsulation . . . . . . . . . . . . . . . 11 4.3.1. Null Authentication . . . . . . . . . . . . . . . . . 11 4.3.2. Device Authentication . . . . . . . . . . . . . . . . 11 4.3.3. Profile Authentication . . . . . . . . . . . . . . . 11 4.3.4. Ticket Authentication . . . . . . . . . . . . . . . . 12 4.4. Payload Encoding . . . . . . . . . . . . . . . . . . . . 12 4.5. Error handling and response codes . . . . . . . . . . . . 13 5. Service Description . . . . . . . . . . . . . . . . . . . . . 13 6. Account Management . . . . . . . . . . . . . . . . . . . . . 15 7. Container Synchronization . . . . . . . . . . . . . . . . . . 16 7.1. Status Transaction . . . . . . . . . . . . . . . . . . . 17 7.2. Download Transaction . . . . . . . . . . . . . . . . . . 17 7.2.1. Conflict Detection . . . . . . . . . . . . . . . . . 17 7.2.2. Filtering . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Upload Transaction . . . . . . . . . . . . . . . . . . . 17 8. Device Connection . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Device Authenticated . . . . . . . . . . . . . . . . . . 18 8.2. PIN Authenticated . . . . . . . . . . . . . . . . . . . . 19 8.3. EARL connection mode . . . . . . . . . . . . . . . . . . 19 9. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Message Exchange . . . . . . . . . . . . . . . . . . . . 20 9.1.1. Client-Service (Post Transaction) . . . . . . . . . . 20 9.1.2. Service-Service (Post Transaction) . . . . . . . . . 20 9.1.3. Service-Client (Synchronization) . . . . . . . . . . 21 10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 22 Hallam-Baker Expires February 14, 2020 [Page 2] Internet-Draft Mesh Protocol Reference August 2019 10.1. Request Messages . . . . . . . . . . . . . . . . . . . . 22 10.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 22 10.1.2. Message: MeshRequestUser . . . . . . . . . . . . . . 22 10.2. Response Messages . . . . . . . . . . . . . . . . . . . 22 10.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 23 10.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 23 10.4. Common Structures . . . . . . . . . . . . . . . . . . . 23 10.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 23 10.4.2. Structure: ConstraintsSelect . . . . . . . . . . . . 23 10.4.3. Structure: ConstraintsData . . . . . . . . . . . . . 24 10.4.4. Structure: PolicyAccount . . . . . . . . . . . . . . 24 10.4.5. Structure: ContainerStatus . . . . . . . . . . . . . 24 10.4.6. Structure: ContainerUpdate . . . . . . . . . . . . . 25 10.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 25 10.5.1. Message: MeshHelloResponse . . . . . . . . . . . . . 25 10.6. Transaction: Complete . . . . . . . . . . . . . . . . . 26 10.6.1. Message: CompleteRequest . . . . . . . . . . . . . . 26 10.7. Transaction: Status . . . . . . . . . . . . . . . . . . 26 10.7.1. Message: StatusRequest . . . . . . . . . . . . . . . 26 10.7.2. Message: StatusResponse . . . . . . . . . . . . . . 26 10.8. Transaction: Download . . . . . . . . . . . . . . . . . 27 10.8.1. Message: DownloadRequest . . . . . . . . . . . . . . 27 10.8.2. Message: DownloadResponse . . . . . . . . . . . . . 27 10.9. Transaction: Upload . . . . . . . . . . . . . . . . . . 28 10.9.1. Message: UploadRequest . . . . . . . . . . . . . . . 28 10.9.2. Message: UploadResponse . . . . . . . . . . . . . . 28 10.9.3. Structure: EntryResponse . . . . . . . . . . . . . . 28 10.10. Transaction: Post . . . . . . . . . . . . . . . . . . . 29 10.10.1. Message: PostRequest . . . . . . . . . . . . . . . 29 10.10.2. Message: PostResponse . . . . . . . . . . . . . . . 29 10.11. Transaction: Connect . . . . . . . . . . . . . . . . . . 30 10.11.1. Message: ConnectRequest . . . . . . . . . . . . . . 30 10.11.2. Message: ConnectResponse . . . . . . . . . . . . . 30 10.12. Transaction: CreateAccount . . . . . . . . . . . . . . . 30 10.12.1. Message: CreateRequest . . . . . . . . . . . . . . 31 10.12.2. Message: CreateResponse . . . . . . . . . . . . . . 31 10.13. Transaction: DeleteAccount . . . . . . . . . . . . . . . 31 10.13.1. Message: DeleteRequest . . . . . . . . . . . . . . 31 10.13.2. Message: DeleteResponse . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . 33 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 Hallam-Baker Expires February 14, 2020 [Page 3] Internet-Draft Mesh Protocol Reference August 2019 1. Introduction This document describes the Mesh Service protocol supported by Mesh Services, an account-based protocol that facilitates exchange of data between devices connected to a Mesh profile and between Mesh accounts. Mesh Service Accounts support the following services: o Provides the master persistence store for the Catalogs and Spools associated with the account. o Enables synchronization of Catalogs and Spools with connected devices. o Enforces access control on inbound Mesh Messages from other users and other Mesh Services. o Authenticates outbound Mesh Messages, certifying that they comply with abuse mitigation policies. A Mesh Profile MAY be bound to multiple Mesh Service Accounts at the same time but only one Mesh Service Account is considered to be authoritative at a time. Users may add or remove Mesh Service Accounts and change the account designated as authoritative at any time. The Mesh Services are build from a very small set of primitives which provide a surprisingly extensive set of capabilities. These primitives are: Hello Describes the features and options provided by the service and provides a 'null' transaction which MAY be used to establish an authentication ticket without performing any action, CreateAccount, DeleteAccount Manage the creation and deletion of accounts at the service. Status, Download, Upload Support synchronization of Mesh containers between the service (Master) and the connected devices (Replicas). Connect Initiate the process of connecting a device to a Mesh profile from the device itself. Post Request that a Mesh Message be transferred to one or more Mesh Accounts. Hallam-Baker Expires February 14, 2020 [Page 4] Internet-Draft Mesh Protocol Reference August 2019 Although these functions could in principle be used to replace many if not most existing Internet application protocols, the principal value of any communication protocol lies in the size of the audience it allows them to communicate with. Thus, while the Mesh Messaging service is designed to support efficient and reliable transfer of messages ranging in size from a few bytes to multiple terabytes, the near-term applications of these services will be to applications that are not adequately supported by existing protocols if at all. 2. Definitions This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language. 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 2.2. Defined Terms The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . 2.3. Related Specifications The architecture of the Mathematical Mesh is described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh documentation set and related specifications are described in this document. 2.4. Implementation Status The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer] . 3. Mesh Service A Mesh Service is a minimally trusted service. In particular a user does not need to trust a Mesh service to protect the confidentiality or integrity of most data stored in the account catalogs and spools. Unless the use of the Mesh Service is highly restricted, a user does need to trust the Mesh Service in certain respects: Hallam-Baker Expires February 14, 2020 [Page 5] Internet-Draft Mesh Protocol Reference August 2019 Data Loss A service could refuse to respond to requests to download data. Integrity (Stale Data) The use of Merkle Trees limits but does not eliminate the ability of a Mesh Service to respond to requests with stale data. Messaging A service could reject requests to post messages to or accept messages from other mesh users. This risk is a necessary consequence of the fact that the Mesh Service Provider is accountable to other Mesh Service Providers for abuse originating from their service. Traffic analysis A Mesh Service has knowledge of the number of Mesh Messages being sent and received by its users and the addresses to which they are being sent to or received from. The need to trust the Mesh Service in these respects is mitigated by accountability and the user's ability to change Mesh Service providers at any time they choose with minimal inconvenience. It is possible that some of these risks will be reduced in future versions of the Mesh Service Protocol but it is highly unlikely that these can be eliminated entirely without compromising practicality or efficiency. 3.1. Data Model The design of the Mesh Service model followed a quasi-formal approach in which the system was reduced to schemas which could in principle be rendered in a formal development method but without construction of proofs. Like the contents of Mesh Accounts, a Mesh Service may be represented by a collection of catalogs and spools, for example: Account Catalog Contains the account entries. Incident Spool Reports of potential abuse Backup of the service MAY be implemented using the same container synchronization mechanism used to synchronize account catalogs and spools. Hallam-Baker Expires February 14, 2020 [Page 6] Internet-Draft Mesh Protocol Reference August 2019 3.2. Partitioning Mesh Services supporting a large number of accounts or large activity volume MAY partition the account catalog between one or more hosts using the usual tiered service model in which a front-end server receives traffic for any account hosted at the server and routes the request to the back-end service that provides the persistence store for that account. In addition, the Mesh Service Protocol supports a 'direct connection' partitioning model in which devices are given a DNS name which MAY allow for direct connection to the persistence host or to a front-end service offering service that is in some way specific to that account. 4. Protocol Bindings Mesh Service transactions are mapped to an underlying messaging and transport protocol. The following binding Mesh Services MUST support the Web Service binding specified in this document and MAY support the UDP binding currently in development. 4.1. DNS Web Service Discovery The DNS Web Service discovery mechanism is used to discover Mesh Services regardless of the protocol binding .The service name, DNS prefix and and .well-known service suffix are specified as follows: o Service Name: mmm o DNS Prefix: _mmm._tcp o Well Known service suffix: /.well-known/mmm 4.2. Web Service Protocol Binding The Web Service Protocol binding makes use of the most widely deployed and used protocols: o Discovery: DNS Service discovery o Transport: TLS o Application: HTTP o Presentation: DARE Message Hallam-Baker Expires February 14, 2020 [Page 7] Internet-Draft Mesh Protocol Reference August 2019 o Encoding: JSON, JSON-B The chief limitations of the Web Service Protocol Binding are that the use of TCP based transport results in unsatisfactory latency for some applications and that the HTTP application layer only serves to allow a host to support multiple services on the same TCP/IP port. 4.2.1. Transport Security Mesh Services MUST offer TLS transport and MAY offer non TLS transport. MESH clients SHOULD use TLS transport when connecting to a MESH service. TLS version 1.3 [RFC8446] or higher MUST be supported. Client authentication SHOULD NOT be used. 4.2.2. HTTP Message Binding All messages are exchanged as HTTP POST transactions. Support for and use of HTTP/1.1 [RFC7230] is REQUIRED. Services MAY support HTTP/2. In contrast to other approaches to the design of Web Services, the only use made of the HTTP transport is to distinguish between different services on the same host using the Host header and .well- known convention and for message framing. No use is made of the URI request line to identify commands, nor are the caching or proxy capabilities of HTTP made use of. 4.2.3. Request The HTTP request MAY contain any valid HTTP header specified in [RFC7230] . Request Line URI /well-known/ (unless overridden using a TXT path attribute) Request Line Method POST Host: Header Content-Encoding As specified in section yy below. Content-Type As specified in section zz below. Content-Length or Transfer-Encoding As specified in [RFC7230] . Payload The content payload as specified in section XX below. Hallam-Baker Expires February 14, 2020 [Page 8] Internet-Draft Mesh Protocol Reference August 2019 [Note, this is showing the payload, not the binding as is intended because the current code doesn't implement it as intended yet] { "Hello": {}} 4.2.4. Response The response MAY contain any HTTP response header but since JWB services do not make use of HTTP caching and messages are not intended to be modified by HTTP intermediaries, only a limited number of headers have significance: Response Code The HTTP response code. This is processed as described in section zz below. Content-Type As specified in section zz below. Content-Length or Transfer-Encoding As specified in [RFC7230] . Cache-Control Since the only valid HTTP method for a JWB request is POST, JWB responses are not cacheable. The use of the cache- control header is therefore unnecessary. However, experience suggests that reviewers find it easier to understand protocol specifications if they are reminded of the fact that caching is neither supported nor desired. [Note, this is showing the payload, not the binding as is intended because the current code doesn't implement it as intended yet] Hallam-Baker Expires February 14, 2020 [Page 9] Internet-Draft Mesh Protocol Reference August 2019 { "MeshHelloResponse": { "Version": { "Major": 3, "Minor": 0, "Encodings": [{ "ID": ["application/json"]}]}, "EnvelopedProfileService": [{ "dig": "S512"}, "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2l nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CQ1AtT0dGWS1LRkFRLTZFTzMtV lg2Uy02VjRHLUVOTlUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N DgiLAogICAgICAgICAgIlB1YmxpYyI6ICJtSGxST1NhenBVVHp3Rk5aMHFJMU1 iWGpwdGhPVXhwbGUwVzhOVWFxOE03MVZUNWVOd1hqCiAgY2ZRLXRNbExnd3FfV WZmMUZHbW1sSC1BIn19fX19", { "signatures": [{ "signature": "T1N3-fnOitSUDFezSINPbh76AtbmL2ghN-antjwUrmCL0z_S- IcArALioAMEaDECg2Q4bgE8IZ4Apgf9SVoj58M_dqeMEWra3mavkV3NEScBcQG Tn_TxS468u9CxfKBDK9NxI7k6c1XUc4xTZGKejR8A"}], "PayloadDigest": "JZHVlp6xFPQ3WG9AQrRYVkLbLiM51nEKo7ryZMnK8TJAv oVKL7kQYlP3dBtayIEvGowVxFURj_vRs0EXo08Blw"}], "EnvelopedProfileHost": [{ "dig": "S512"}, "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF 0dXJlIjogewogICAgICAiVURGIjogIk1ES1EtVlRURC1IUUtCLVlINk8tSDU3Q y00S0RILTZLV0kiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL AogICAgICAgICAgIlB1YmxpYyI6ICJvdURsS3lJVWtzU19DV1VocW9XYVBGUDk zS2E5Wmc1M2RRQ0M0NGd1YUdPQkI5UzEyZUhsCiAgejJLb1g5LVBjdFFIMzE1N jdUY21NRENBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICA gIlVERiI6ICJNQzNELUlENjItTDVWWi1JV0xDLVdSTFgtN0ZUVC1GN1NUIiwKI CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd WJsaWMiOiAiNEJmZVcwV1FCNU8zRU9yalc0THZBZGtMejcxQnRKc2xzM3d6dzB hY3VINUVkdXBXV1Q4dgogIEUzTU9ia2tmbURfNHRQWjdCNlZhbnRlQSJ9fX19f Q", { "signatures": [{ "signature": "POQFQQOpcuNWxUAyi3DSGtaC9yJJJ9J6wr79Qzij8jN52gx4n 8MitwM1T2rYMgJp6WqpSKWJfaUA2wafnkmQvVkiVT-35Mbog22krLD-HySbJAP a1lUXnzzOzbLSsBwRqPyJS0m60HFxKx0h0gZh0xIA"}], "PayloadDigest": "C716Q-5VPWfV5imuX-_rgmST2-J8SjFxQ_EQAPrGDD1Mr UKex_wn2cckWa_qyGsHrYPMKDt_2C4U7ZU9iyUdfw"}]}} Hallam-Baker Expires February 14, 2020 [Page 10] Internet-Draft Mesh Protocol Reference August 2019 4.3. DARE Message Encapsulation The payload of the HTTP requests and responses is a DARE Message whose payload contains the Mesh Service request or response. The DARE Message encapsulation is used to authenticate the request or response data. The form of the authentication depending on the credentials available to the sender at the time the request is made. Mesh Service MUST support the use of Mutually Authenticated Key Exchange [draft-hallambaker-mesh-security] to establish the Master Key used for authentication of requests and responses. Requests and Responses MUST be authenticated. Requests and Responses MUST be encrypted if the transport is not encrypted and MAY be encrypted otherwise. 4.3.1. Null Authentication Null Authentication MAY be used to make a Hello Request. The Null Authentication mechanism MUST NOT be used for any Mesh Service request or response other than a Hello request. Since the Mutually Authenticated key exchange requires both parties to know the public key of the other, it is not possible for a client to authenticate itself to the service until it has obtained the service public key. One means by which the client MAY obtain the service public key is by requesting the service return the credential in a Hello transaction. 4.3.2. Device Authentication Device Authentication is used in two circumstances o When requesting creation of an account o When a device is requesting connection to a profile. 4.3.3. Profile Authentication Profile Authentication has the same form as Device Authentication except that the client provides its Device Connection Assertion as part of the request: Hallam-Baker Expires February 14, 2020 [Page 11] Internet-Draft Mesh Protocol Reference August 2019 4.3.4. Ticket Authentication Ticket Authentication is used after a device has obtained an authentication ticket from a service. The ticket is returned in the response to a previous Profile Authentication exchange. 4.4. Payload Encoding The Dare Message payload of a Hello request MUST be encoded in JSON encoding. The payload of all other requests MUST be in either JSON encoding or one of the encodings advertised as being accepted in a Hello response from the Service. Services MUST accept JSON encoding and MAY support the JSON-B or JSON-C encodings as specified in this document. Services MUST generate a response that is compatible with the DARE Message Content-Type specified in the request. JSON was originally developed to provide a serialization format for the JavaScript programming language [ECMA-262] . While this approach is generally applicable to the type systems of scripting programming languages, it is less well matched to the richer type systems of modern object oriented programming languages such as Java and C#. Working within a subset of the capabilities of JSON allows a Web Service protocol to be accessed with equal ease from either platform type. The following capabilities of JSON are avoided: The ability to use arbitrary strings as field names. The use of JSON objects to define maps directly The following data field types are used: Integer Integer values are encoded as JSON number values. String Test strings are encoded as JSON text strings. Boolean Boolean values are encoded as JSON 'false', 'true' or 'null' tokens according to value. Sequence Sequences of data items that are encoded as JSON arrays Object of known type Objects whose type is known to the receiver are encoded as JSON objects Object of variable type Objects whose type is not known to the receiver are encoded as JSON objects containing a single field whose name describes the type of the object value and whose value contains the value. Hallam-Baker Expires February 14, 2020 [Page 12] Internet-Draft Mesh Protocol Reference August 2019 Binary Data Byte sequences are converted to BASE64-url encoding [RFC4648] and encoded as JSON string values. Date Time Date Time values are converted to Internet time format as described in [RFC3339] and encoded as JSON string values. 4.5. Error handling and response codes It is possible for an error to occur at any of the three layers in the Web Service binding: Service Layer HTTP Layer Transport Layer Services SHOULD always attempt to return error codes at the highest level possible. However, it is clearly impossible for a connection that is refused at the Transport layer to return an error code at the HTTP layer. It is however possible for a HTTP layer error response to contain a content body. In the case that a response contains both a HTTP response code and a well-formed payload containing a response, the payload response SHALL have precedence. 5. Service Description The Hello transaction is used to determine the features supported by the service and obtain the service credentials The request payload: { "Hello": {}} The response payload: Hallam-Baker Expires February 14, 2020 [Page 13] Internet-Draft Mesh Protocol Reference August 2019 { "MeshHelloResponse": { "Version": { "Major": 3, "Minor": 0, "Encodings": [{ "ID": ["application/json"]}]}, "EnvelopedProfileService": [{ "dig": "S512"}, "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJLZXlPZmZsaW5lU2l nbmF0dXJlIjogewogICAgICAiVURGIjogIk1CQ1AtT0dGWS1LRkFRLTZFTzMtV lg2Uy02VjRHLUVOTlUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0N DgiLAogICAgICAgICAgIlB1YmxpYyI6ICJtSGxST1NhenBVVHp3Rk5aMHFJMU1 iWGpwdGhPVXhwbGUwVzhOVWFxOE03MVZUNWVOd1hqCiAgY2ZRLXRNbExnd3FfV WZmMUZHbW1sSC1BIn19fX19", { "signatures": [{ "signature": "T1N3-fnOitSUDFezSINPbh76AtbmL2ghN-antjwUrmCL0z_S- IcArALioAMEaDECg2Q4bgE8IZ4Apgf9SVoj58M_dqeMEWra3mavkV3NEScBcQG Tn_TxS468u9CxfKBDK9NxI7k6c1XUc4xTZGKejR8A"}], "PayloadDigest": "JZHVlp6xFPQ3WG9AQrRYVkLbLiM51nEKo7ryZMnK8TJAv oVKL7kQYlP3dBtayIEvGowVxFURj_vRs0EXo08Blw"}], "EnvelopedProfileHost": [{ "dig": "S512"}, "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJLZXlPZmZsaW5lU2lnbmF 0dXJlIjogewogICAgICAiVURGIjogIk1ES1EtVlRURC1IUUtCLVlINk8tSDU3Q y00S0RILTZLV0kiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiL AogICAgICAgICAgIlB1YmxpYyI6ICJvdURsS3lJVWtzU19DV1VocW9XYVBGUDk zS2E5Wmc1M2RRQ0M0NGd1YUdPQkI5UzEyZUhsCiAgejJLb1g5LVBjdFFIMzE1N jdUY21NRENBIn19fSwKICAgICJLZXlBdXRoZW50aWNhdGlvbiI6IHsKICAgICA gIlVERiI6ICJNQzNELUlENjItTDVWWi1JV0xDLVdSTFgtN0ZUVC1GN1NUIiwKI CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd WJsaWMiOiAiNEJmZVcwV1FCNU8zRU9yalc0THZBZGtMejcxQnRKc2xzM3d6dzB hY3VINUVkdXBXV1Q4dgogIEUzTU9ia2tmbURfNHRQWjdCNlZhbnRlQSJ9fX19f Q", { "signatures": [{ "signature": "POQFQQOpcuNWxUAyi3DSGtaC9yJJJ9J6wr79Qzij8jN52gx4n 8MitwM1T2rYMgJp6WqpSKWJfaUA2wafnkmQvVkiVT-35Mbog22krLD-HySbJAP a1lUXnzzOzbLSsBwRqPyJS0m60HFxKx0h0gZh0xIA"}], "PayloadDigest": "C716Q-5VPWfV5imuX-_rgmST2-J8SjFxQ_EQAPrGDD1Mr UKex_wn2cckWa_qyGsHrYPMKDt_2C4U7ZU9iyUdfw"}]}} Hallam-Baker Expires February 14, 2020 [Page 14] Internet-Draft Mesh Protocol Reference August 2019 6. Account Management A Mesh Account is bound to a Mesh Service by completing a CreateAccount transaction with the service. The client requesting the account creation specifies the ProfileMesh profile describing the requested account and lists of initial entries to populate the devices and contacts catalogs. Additional catalogs MAY be synchronized if the account creation request is accepted. The request payload: { "CreateAccount": { "ServiceID": "alice@example.com", "SignedProfileMesh": [{ "dig": "S512"}, "ewogICJQcm9maWxlUGVyc29uYWwiOiB7CiAgICAiS2V5T2ZmbGluZVN pZ25hdHVyZSI6IHsKICAgICAgIlVERiI6ICJNQU9aLTNNVkUtRzVFTi02NEJJL UkzUk0tT0RGSi1INVc0IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiA gICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkN DQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMFZ4cTEwNVFKNHkwSUp1X3BFMml CbTZ5N05UcnVRUWtaaFVJSkdZdS02bUJoTkpDVEtqbgogIFNJa2tiNlNLNmFMU mx6cHd2LVVXQ3pNQSJ9fX0sCiAgICAiS2V5c09ubGluZVNpZ25hdHVyZSI6IFt 7CiAgICAgICAgIlVERiI6ICJNQkU3LVVDSkYtWkFaMi1NTEdQLUxCNTUtSFpCV C1YTUhWIiwKICAgICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICA gICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgICAiY3J2IjogIkVkNDQ4I iwKICAgICAgICAgICAgIlB1YmxpYyI6ICJSZDNzbkRaLWlPT1lBMUJTcGhkN0g 5SjFDNXhmU1Iyb2pCRUdLMVNsalJVRDA4TVI0dEZzCiAgV28wWTJjR0NPWUxiS ElpNmFUNkhmZkFBIn19fV0sCiAgICAiS2V5RW5jcnlwdGlvbiI6IHsKICAgICA gIlVERiI6ICJNQkdBLUMyVVEtUUZWRy01SE5BLTJXVFotSUtOSy1FV0hUIiwKI CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUV DREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd WJsaWMiOiAiNDJJeVZKV2c0VzFKOS1GMGl0UEFEZDAweUFZUXdCOGtXUDBVa1l XTHFKdVI2ZzB3bmtZUQogIENGOFpyNHpUZTJsTmhEUFVmOEJSOFZTQSJ9fX19f Q", { "signatures": [{ "signature": "VALT2etUKtiTIYngz7uaXF3OxOFiE_VpdeHHLe1Rpz6HjuyQ4 j7WWJf2Aj7rmhMTYRW2H9NcjdAAd80TRAuxvtIRZhqLl5HL7UHwkzRumbPGic2 7dqudEyGp-FD6VYqHxD7WztJMzHklLk-COjbP4y8A"}], "PayloadDigest": "8QolTaruD1-DZwTZ-aB7olA1eit5fb7TUhRSI1heCNYjR FJ1vSAArAq4h_Wr7AVBnk1WzLLDnEaF8xZezfz2MA"}], "SignedAssertionAccount": [{ "dig": "S512"}, "ewogICJQcm9maWxlQWNjb3VudCI6IHsKICAgICJTZXJ2aWNlSURzIjo gWyJhbGljZUBleGFtcGxlLmNvbSJdLAogICAgIk1lc2hQcm9maWxlVURGIjogI k1BT1otM01WRS1HNUVOLTY0QkktSTNSTS1PREZKLUg1VzQiLAogICAgIktleUV Hallam-Baker Expires February 14, 2020 [Page 15] Internet-Draft Mesh Protocol Reference August 2019 uY3J5cHRpb24iOiB7CiAgICAgICJVREYiOiAiTUFGWi1WVU1QLTdQVTMtNFRQN y03TVJaLUJLQlEtVk1OTiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewo gICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZ DQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIjFsY1pVTmpIR0pXa1BXbVM5TUh lR1lOZkRTWkdVTzRsR2s1WHBxN1hnSC0tU0dMUUU0RV8KICBzLTBiMFBJOG0wZ mp0eklNVUVZRElfSUEifX19fX0", { "signatures": [{ "signature": "0tYuHZB3Xmk_MaOGK09khjSHr9jHUx_JLTixvYDZ7zEGCN_nD TcLLeZujb8-wqMJalMjb_7aAggAmapk0tPfnGGbYnWmwBIKamrdpbnfMHtFm-i Ny4S2rfaVLNEHSH9s42mYsdw9eitPX8xZEgXUIQ8A"}], "PayloadDigest": "alXz9HJmuEpu2PglvnL5U-_nm4PLrWlWGIMlP5rfRUE4f heefPxgiqG8rBAGahZPyGSpIzCK-7Sgh0sxx7-pgw"}]}} The response payload: