Network Working Group P. M. Hallam-Baker Internet-Draft ThresholdSecrets.com Intended status: Informational 5 August 2021 Expires: 6 February 2022 Mathematical Mesh 3.0 Part V: Protocol Reference draft-hallambaker-mesh-protocol-09 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. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html. 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 6 February 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Hallam-Baker Expires 6 February 2022 [Page 1] Internet-Draft Mesh Protocol Reference August 2021 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 to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Related Specifications . . . . . . . . . . . . . . . . . 7 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 7 3. Mesh Protocols . . . . . . . . . . . . . . . . . . . . . . . 7 4. Mesh Service . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Partitioning . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 9 5.1. DNS Web Service Discovery . . . . . . . . . . . . . . . . 9 5.2. Web Service Protocol Binding . . . . . . . . . . . . . . 9 5.2.1. Transport Security . . . . . . . . . . . . . . . . . 10 5.2.2. HTTP Message Binding . . . . . . . . . . . . . . . . 10 5.2.3. Request . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 11 5.3. DARE Message Encapsulation . . . . . . . . . . . . . . . 11 5.3.1. Null Authentication . . . . . . . . . . . . . . . . . 12 5.3.2. Device Authentication . . . . . . . . . . . . . . . . 12 5.3.3. Profile Authentication . . . . . . . . . . . . . . . 12 5.3.4. Ticket Authentication . . . . . . . . . . . . . . . . 12 5.4. Payload Encoding . . . . . . . . . . . . . . . . . . . . 12 5.5. Error handling and response codes . . . . . . . . . . . . 13 6. Key Establishment Protocol . . . . . . . . . . . . . . . . . 14 6.1. Processes . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Start = initial -> Begin | cloaked -> Begin . . . . . 14 6.1.2. Begin = challenge -> Present | complete -> WaitClient | refused -> Stop . . . . . . . . . . . . . . . . . . . 15 6.1.3. Present = represent -> Begin . . . . . . . . . . . . 15 6.1.4. WaitClient = request -> WaitService . . . . . . . . . 15 6.1.5. WaitService = response -> WaitClient | refused -> Stop . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Client Events . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Initial . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Cloaked . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.3. Present . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.4. Request . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Server Events . . . . . . . . . . . . . . . . . . . . . . 16 6.3.1. Challenge . . . . . . . . . . . . . . . . . . . . . . 16 Hallam-Baker Expires 6 February 2022 [Page 2] Internet-Draft Mesh Protocol Reference August 2021 6.3.2. Complete . . . . . . . . . . . . . . . . . . . . . . 16 6.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 16 6.3.4. Refused . . . . . . . . . . . . . . . . . . . . . . . 16 7. Mesh Service Transactions . . . . . . . . . . . . . . . . . . 16 7.1. Service Description . . . . . . . . . . . . . . . . . . . 16 7.2. Account Creation . . . . . . . . . . . . . . . . . . . . 18 7.2.1. Bind User Account . . . . . . . . . . . . . . . . . . 19 7.2.2. Bind Group Account . . . . . . . . . . . . . . . . . 21 7.2.3. Unbind Account . . . . . . . . . . . . . . . . . . . 23 7.3. Persistence Store Management . . . . . . . . . . . . . . 23 7.3.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24 7.3.2. Download . . . . . . . . . . . . . . . . . . . . . . 24 7.3.3. Conflict Detection . . . . . . . . . . . . . . . . . 24 7.3.4. Filtering . . . . . . . . . . . . . . . . . . . . . . 24 7.3.5. Transact . . . . . . . . . . . . . . . . . . . . . . 24 7.4. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Publication . . . . . . . . . . . . . . . . . . . . . . . 31 7.5.1. Claim Transaction . . . . . . . . . . . . . . . . . . 32 7.5.2. PollClaim Transaction . . . . . . . . . . . . . . . . 32 7.6. Cryptographic . . . . . . . . . . . . . . . . . . . . . . 33 7.6.1. Generate Key Shares . . . . . . . . . . . . . . . . . 33 7.6.2. Key Agreement . . . . . . . . . . . . . . . . . . . . 35 7.6.3. Sign . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Message Interactions . . . . . . . . . . . . . . . . . . . . 35 8.1. Message PIN Interaction . . . . . . . . . . . . . . . . . 36 8.1.1. Registration . . . . . . . . . . . . . . . . . . . . 36 8.1.2. Authentication . . . . . . . . . . . . . . . . . . . 37 8.1.3. Validation . . . . . . . . . . . . . . . . . . . . . 37 8.1.4. Example . . . . . . . . . . . . . . . . . . . . . . . 38 8.2. Completion Interaction . . . . . . . . . . . . . . . . . 40 8.3. Contact Exchange Interaction . . . . . . . . . . . . . . 40 8.3.1. Remote . . . . . . . . . . . . . . . . . . . . . . . 41 8.3.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.3.3. EARL . . . . . . . . . . . . . . . . . . . . . . . . 44 8.4. Group Invitation . . . . . . . . . . . . . . . . . . . . 44 8.5. Confirmation Interaction . . . . . . . . . . . . . . . . 45 9. Device Connection Interactions . . . . . . . . . . . . . . . 46 9.1. Dynamic QR Code (PIN) Authenticated . . . . . . . . . . . 48 9.1.1. Phase 1: . . . . . . . . . . . . . . . . . . . . . . 49 9.1.2. Phase 2: . . . . . . . . . . . . . . . . . . . . . . 49 9.1.3. Phase 3: . . . . . . . . . . . . . . . . . . . . . . 55 9.1.4. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . 56 9.2. Witness Authenticated . . . . . . . . . . . . . . . . . . 57 9.2.1. Phase 1: . . . . . . . . . . . . . . . . . . . . . . 57 9.2.2. Phase 2: . . . . . . . . . . . . . . . . . . . . . . 57 9.2.3. Phase 3: . . . . . . . . . . . . . . . . . . . . . . 57 9.2.4. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . 58 9.3. Static QR Code Authenticated . . . . . . . . . . . . . . 58 Hallam-Baker Expires 6 February 2022 [Page 3] Internet-Draft Mesh Protocol Reference August 2021 9.3.1. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 59 9.3.2. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 59 9.3.3. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . 59 9.3.4. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . 59 10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 59 10.1. Request Messages . . . . . . . . . . . . . . . . . . . . 59 10.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 59 10.1.2. Message: MeshRequestUser . . . . . . . . . . . . . . 60 10.2. Response Messages . . . . . . . . . . . . . . . . . . . 60 10.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 60 10.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 60 10.4. Common Structures . . . . . . . . . . . . . . . . . . . 60 10.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 60 10.4.2. Structure: ConstraintsSelect . . . . . . . . . . . . 61 10.4.3. Structure: ConstraintsData . . . . . . . . . . . . . 61 10.4.4. Structure: PolicyAccount . . . . . . . . . . . . . . 62 10.4.5. Structure: ContainerStatus . . . . . . . . . . . . . 62 10.4.6. Structure: ContainerUpdate . . . . . . . . . . . . . 62 10.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 62 10.5.1. Message: MeshHelloResponse . . . . . . . . . . . . . 62 10.6. Transaction: BindAccount . . . . . . . . . . . . . . . . 63 10.6.1. Message: BindRequest . . . . . . . . . . . . . . . . 63 10.6.2. Message: BindResponse . . . . . . . . . . . . . . . 63 10.7. Transaction: UnbindAccount . . . . . . . . . . . . . . . 64 10.7.1. Message: UnbindRequest . . . . . . . . . . . . . . . 64 10.7.2. Message: UnbindResponse . . . . . . . . . . . . . . 64 10.8. Transaction: Connect . . . . . . . . . . . . . . . . . . 64 10.8.1. Message: ConnectRequest . . . . . . . . . . . . . . 64 10.8.2. Message: ConnectResponse . . . . . . . . . . . . . . 64 10.9. Transaction: Complete . . . . . . . . . . . . . . . . . 65 10.9.1. Message: CompleteRequest . . . . . . . . . . . . . . 65 10.9.2. Message: CompleteResponse . . . . . . . . . . . . . 65 10.10. Transaction: Status . . . . . . . . . . . . . . . . . . 65 10.10.1. Message: StatusRequest . . . . . . . . . . . . . . 65 10.10.2. Message: StatusResponse . . . . . . . . . . . . . . 65 10.11. Transaction: Download . . . . . . . . . . . . . . . . . 66 10.11.1. Message: DownloadRequest . . . . . . . . . . . . . 66 10.11.2. Message: DownloadResponse . . . . . . . . . . . . . 66 10.12. Transaction: Transact . . . . . . . . . . . . . . . . . 67 10.12.1. Message: TransactRequest . . . . . . . . . . . . . 67 10.12.2. Message: TransactResponse . . . . . . . . . . . . . 67 10.12.3. Structure: EntryResponse . . . . . . . . . . . . . 67 10.13. Transaction: Post . . . . . . . . . . . . . . . . . . . 68 10.13.1. Message: PostRequest . . . . . . . . . . . . . . . 68 10.13.2. Message: PostResponse . . . . . . . . . . . . . . . 68 10.14. Transaction: Claim . . . . . . . . . . . . . . . . . . . 68 10.14.1. Message: ClaimRequest . . . . . . . . . . . . . . . 69 10.14.2. Message: ClaimResponse . . . . . . . . . . . . . . 69 Hallam-Baker Expires 6 February 2022 [Page 4] Internet-Draft Mesh Protocol Reference August 2021 10.15. Transaction: PollClaim . . . . . . . . . . . . . . . . . 69 10.15.1. Message: PollClaimRequest . . . . . . . . . . . . . 69 10.15.2. Message: PollClaimResponse . . . . . . . . . . . . 69 10.15.3. Structure: CryptographicOperation . . . . . . . . . 69 10.15.4. Structure: CryptographicOperationSign . . . . . . . 70 10.15.5. Structure: CryptographicOperationKeyAgreement . . . 70 10.15.6. Structure: CryptographicOperationGenerate . . . . . 70 10.15.7. Structure: CryptographicOperationShare . . . . . . 70 10.15.8. Structure: CryptographicResult . . . . . . . . . . 70 10.15.9. Structure: CryptographicResultKeyAgreement . . . . 70 10.15.10. Structure: CryptographicResultShare . . . . . . . . 70 10.16. Transaction: Operate . . . . . . . . . . . . . . . . . . 70 10.16.1. Message: OperateRequest . . . . . . . . . . . . . . 71 10.16.2. Message: OperateResponse . . . . . . . . . . . . . 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71 14. Normative References . . . . . . . . . . . . . . . . . . . . 71 15. Informative References . . . . . . . . . . . . . . . . . . . 72 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: * Provides the master persistence store for the Catalogs and Spools associated with the account. * Enables synchronization of Catalogs and Spools with connected devices. * Enforces access control on inbound Mesh Messages from other users and other Mesh Services. * 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. Hallam-Baker Expires 6 February 2022 [Page 5] Internet-Draft Mesh Protocol Reference August 2021 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. 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]. Hallam-Baker Expires 6 February 2022 [Page 6] Internet-Draft Mesh Protocol Reference August 2021 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 Protocols The Mesh specifies two separate types of protocol interactions: Mesh Service Protocol A synchronous protocol supporting interactions between devices and a Mesh Service Host and between Mesh Service hosts. Mesh Messaging Protocol An asynchronous protocol that supports interactions between devices connected to the same account and between accounts. The Mesh Messaging Protocol uses the Mesh Service Protocol as transport. The Mesh Service Protocol in turn is supported by either the HTTPS binding over TCP or by the Mesh Datagram binding over UDP. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-protocol-09.html for artwork.) Figure 1: Protocol Layering Mesh Services MUST support the HTTPS binding and MAY support the Mesh Datagram binding. 4. 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: Data Loss A service could refuse to respond to requests to download data. Hallam-Baker Expires 6 February 2022 [Page 7] Internet-Draft Mesh Protocol Reference August 2021 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. 4.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 6 February 2022 [Page 8] Internet-Draft Mesh Protocol Reference August 2021 4.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. 5. 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. 5.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: * Service Name: mmm * DNS Prefix: _mmm._tcp * Well Known service suffix: /.well-known/mmm 5.2. Web Service Protocol Binding The Web Service Protocol binding makes use of the most widely deployed and used protocols: * Discovery: DNS Service discovery * Transport: TLS * Application: HTTP * Presentation: DARE Message Hallam-Baker Expires 6 February 2022 [Page 9] Internet-Draft Mesh Protocol Reference August 2021 * 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. 5.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. 5.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. 5.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 6 February 2022 [Page 10] Internet-Draft Mesh Protocol Reference August 2021 [No dump of the binding yet] ~~~~ 5.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. [No dump of the binding yet] ~~~~ 5.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. Hallam-Baker Expires 6 February 2022 [Page 11] Internet-Draft Mesh Protocol Reference August 2021 5.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. 5.3.2. Device Authentication Device Authentication is used in two circumstances * When requesting creation of an account * When a device is requesting connection to a profile. 5.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: 5.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. 5.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. Hallam-Baker Expires 6 February 2022 [Page 12] Internet-Draft Mesh Protocol Reference August 2021 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. 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. 5.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 Hallam-Baker Expires 6 February 2022 [Page 13] Internet-Draft Mesh Protocol Reference August 2021 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. 6. Key Establishment Protocol The key establishment protocol is the mechanism used to establish an authentication context between a Mesh Client and a Mesh Host. The key establishment protocol runs in parallel with regular Mesh communications. Each key establishment message consists of three segments: * Plaintext KEP * Encrypted KEP * Payload + Padding When using HTTP transport, the ability of the client to respond to a packet sent by the host has already been established. When using UDP transport, amplification and resource denial attacks are possible. 6.1. Processes 6.1.1. Start = initial -> Begin | cloaked -> Begin Depending on the discovery process, the client begins the connection establishment protocol with either the initial or cloaked message. * If the client has the Service credential, it MAY use either the initial or cloaked message to initiate the connection. * Otherwise, the initial message is used. When using UDP transport, amplification the client MUST pad the initial and cloaked messages to the MTA and the host MUST reject messages that lack the required padding. Hallam-Baker Expires 6 February 2022 [Page 14] Internet-Draft Mesh Protocol Reference August 2021 6.1.2. Begin = challenge -> Present | complete -> WaitClient | refused -> Stop From the Host point of view, the initial and cloaked messages are equivalent. The host MAY refuse the connection request by returning the refused event. In this case the key establishment is aborted. Otherwise, the host either completes the connection request immediately or presents the client with a challenge to protect against resource exhaustion attacks. 6.1.3. Present = represent -> Begin If the host presents a challenge, the client responds with the represent event containing the response to the challenge. This MAY involve a proof of work test to demonstrate that the client has performed a certain degree of work before the host commits resources to the public key operations. 6.1.4. WaitClient = request -> WaitService A client that has reached the WaitClient state has established a ticket and shared secret. These are then used to enhance all further requests. 6.1.5. WaitService = response -> WaitClient | refused -> Stop A host that has reached the WaitClient state has established a ticket and shared secret. These are then used to enhance all further responses. 6.2. Client Events 6.2.1. Initial Client knows * Service DNS (Direct or from callsign) Client presents * Client ephemeral key * Account Profile * Device Connection Hallam-Baker Expires 6 February 2022 [Page 15] Internet-Draft Mesh Protocol Reference August 2021 * Payload is plaintext 6.2.2. Cloaked Encrypted version of the Initial request. Client knows * Service DNS with Host key (Direct or from callsign) Client presents * Client ephemeral key * Account Profile * Device Connection * Payload is plaintext 6.2.3. Present 6.2.4. Request 6.3. Server Events 6.3.1. Challenge 6.3.2. Complete 6.3.3. Response 6.3.4. Refused 7. Mesh Service Transactions 7.1. Service Description The Hello transaction is used to determine the features supported by the service and obtain the service credentials The request payload: { "HelloRequest":{}} Hallam-Baker Expires 6 February 2022 [Page 16] Internet-Draft Mesh Protocol Reference August 2021 The response payload: { "MeshHelloResponse":{ "Status":201, "Version":{ "Major":3, "Minor":0, "Encodings":[{ "ID":["application/json" ]} ]}, "EnvelopedProfileService":[{ "EnvelopeId":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkJZLUU0VkEtQ0 1XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZVNlcnZpY2UiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAg IkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"}, "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJQcm9maWxlU2lnbmF0dX JlIjogewogICAgICAiVWRmIjogIk1CQlktRTRWQS1DTVdGLTUyVDctRVNMQS1QR05 ULUNOTlgiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVi bGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgI CAgIlB1YmxpYyI6ICJKNDlrcGhHMGJZTFlrSXRDZm5jeURNOWFUcWpBUGd6Ql9Wen pjQU5VYjU5a0hfdUxuM1hBCiAgcFpCWVRmelI4NlFuN1hvMm5xX215NFlBIn19fSw KICAgICJTZXJ2aWNlQXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNE Ui1NSEtLLVRVN0otRDZORi1TR000LTZTRlAtWlNYNiIsCiAgICAgICJQdWJsaWNQY XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAicjI3YVNLOWZkUEJ hZ2ExLWJmZE8zX0JVQlp6R1JWSHBwcGVfY05KM2NPRmYxQ3I4dGt2bAogIHZoQjhw eldjZ09mQndlUTJKYWU1bFRLQSJ9fX0sCiAgICAiU2VydmljZUVuY3J5cHRpb24iO iB7CiAgICAgICJVZGYiOiAiTUM3NS03TUtMLVpWQUktWEw2NC01UlpDLUxBWFMtNj NGVyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWN LZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQ dWJsaWMiOiAibHlmbXdvY2xwVm5KVTNPbVVwYmlVVm53YWljUXJEalc0OHRVZ1JYW DdFNEZ5am9iZ212bAogIDJvVTlrQ3ZmY1JrNWRzdG1xSDhEUHBhQSJ9fX0sCiAgIC AiU2VydmljZVNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ080LU1CTkwtWlR MSi1KNURCLUQ3SUYtTk9GUC03QTZWIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMi OiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogI kVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAielB1M1pNdTZZYjlvZHlnaExCb3 ZwMWE4T0c1eUUzdzQ3ei12ZEFLNUlaVkZHaEpPVEVmRwogIGZxTjFMTEFGU2hQXzl iekxuZG1qTklJQSJ9fX19fQ", { "signatures":[{ "alg":"S512", "kid":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX", "signature":"GXYGhu6H4ZOuZiayoRy94x6WnIJiHhYHGvmD1Mzp Td9rqAHYspxMo-l6SyheWNccwzqP3Ps3v-AAg7P3SF-Dt8zyoRYYgS8Mwg3MavHlQ Hallam-Baker Expires 6 February 2022 [Page 17] Internet-Draft Mesh Protocol Reference August 2021 TJbAiyq1fruykJddR1EkB1FAxWayl73usHTWO_ffBauqiMA"} ], "PayloadDigest":"tf1ucBynDXcgOCrUO9HubDJLozl39Imevt14slRR PCRFoQRMOc1vvyMfDrPMcmAUmZN6nv34yLooay3-HMF1jg"} ], "EnvelopedProfileHost":[{ "EnvelopeId":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkZDLUozQkMtRV FURC1VUVBNLVVSQlAtRlJDQS1WSEIzIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZUhvc3QiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"}, "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj ogewogICAgICAiVWRmIjogIk1CRkMtSjNCQy1FUVRELVVRUE0tVVJCUC1GUkNBLVZ IQjMiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI lB1YmxpYyI6ICJkMU5BS3FoNTJWUVRnZm9lWlZHbWpoX3VrNk9PWFFZcXJvRFlwMW 5fdWIxblBrQk9qbTVyCiAgMkg2VGotdlFTbmtuQ0U5OVJRTDl0cUtBIn19fSwKICA gICJFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1ENUotQzNRUy1USUpTLTdN SUItVjZZNi1HV0hFLVRLQUkiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKI CAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OC IsCiAgICAgICAgICAiUHVibGljIjogIm52REpzV0dXNGtSUWFZeEM4Z3NJQ0E0bnp 4Zm0yTnVBeVprU1lwYnhJVHcxMU1ULUtONFYKICBuNmR1QXFheFptbnktNm81clFv TnFKMkEifX19LAogICAgIlNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ1ZGL TY1R1AtQjVTWC1TRlY2LUVZVFItUlJYUS01Qk0zIiwKICAgICAgIlB1YmxpY1Bhcm FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA iY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAic2o0ejN5TTlpZEkw bEZ4d0NhRjZFckFwSHpaQ0ltdGhLVnhuYk5FQWVSRDRUSGZPRmNwTwogIHlQMXkwR DROcEZlaDZlZmdERVBLY2VlQSJ9fX0sCiAgICAiQXV0aGVudGljYXRpb24iOiB7Ci AgICAgICJVZGYiOiAiTUFRWi1OV0lZLUdDN0ktQ1E2SS1HTUEzLU1CNEYtUllBWCI sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa WMiOiAiVTFYNWtKRU55NDYwTzZ5VEdIY3FzMkFBMXphU2Ffbm4yR3FxRHBxcENtRE RZREhHMWVEUwogIDZKSGR1QmNkTVlZeWdteUdRbncyRjRDQSJ9fX19fQ", { "signatures":[{ "alg":"S512", "kid":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3", "signature":"zIbCIREQXwu5GBXdPKHZmO5dkJ3h-Jta65FYKLy8 lQrNp2yLPN_ox5QHlp-tkw8fnFsIe3IMQIgAOOWqpdJejQGLhiymClaz7BPEQlsEt o0q-pwH2iBiHoPiMv65YOaZPzblW2X4j3BsCt4I2StEciAA"} ], "PayloadDigest":"njYw-Th6easiJpjiAz6pz9rsb8xxhZTO5UaXM8_P P75IfULeBhkki3773VDhqL71EIAwvIfktFRF0G50CxKm3A"} ]}} 7.2. Account Creation Hallam-Baker Expires 6 February 2022 [Page 18] Internet-Draft Mesh Protocol Reference August 2021 7.2.1. Bind User Account A User Account is bound to a Mesh Service by completing a "BindAccount" transaction with the service. The "BindRequest" message specifies the account address and "ProfileUser"of the account to be serviced. The "BindAccount" transaction is unique in that it can fail to complete for reasons that are outside the scope of the Mesh specifications. Creation of an account might require payment to be made or authentication of the user's credentials. It is thus quite normal for the result of a CreateRequest to be the account being created in an 'on hold' state which can only be changed out of band. If the request is at least partially successful, a BindResponse message is returned. In the case of partial success, a description of the request status and link to a Web page providing further details MAY be returned. The request payload: { "HelloRequest":{}} The response payload: { "MeshHelloResponse":{ "Status":201, "Version":{ "Major":3, "Minor":0, "Encodings":[{ "ID":["application/json" ]} ]}, "EnvelopedProfileService":[{ "EnvelopeId":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkJZLUU0VkEtQ0 1XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZVNlcnZpY2UiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAg IkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"}, "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJQcm9maWxlU2lnbmF0dX JlIjogewogICAgICAiVWRmIjogIk1CQlktRTRWQS1DTVdGLTUyVDctRVNMQS1QR05 ULUNOTlgiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVi bGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgI Hallam-Baker Expires 6 February 2022 [Page 19] Internet-Draft Mesh Protocol Reference August 2021 CAgIlB1YmxpYyI6ICJKNDlrcGhHMGJZTFlrSXRDZm5jeURNOWFUcWpBUGd6Ql9Wen pjQU5VYjU5a0hfdUxuM1hBCiAgcFpCWVRmelI4NlFuN1hvMm5xX215NFlBIn19fSw KICAgICJTZXJ2aWNlQXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNE Ui1NSEtLLVRVN0otRDZORi1TR000LTZTRlAtWlNYNiIsCiAgICAgICJQdWJsaWNQY XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAicjI3YVNLOWZkUEJ hZ2ExLWJmZE8zX0JVQlp6R1JWSHBwcGVfY05KM2NPRmYxQ3I4dGt2bAogIHZoQjhw eldjZ09mQndlUTJKYWU1bFRLQSJ9fX0sCiAgICAiU2VydmljZUVuY3J5cHRpb24iO iB7CiAgICAgICJVZGYiOiAiTUM3NS03TUtMLVpWQUktWEw2NC01UlpDLUxBWFMtNj NGVyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWN LZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQ dWJsaWMiOiAibHlmbXdvY2xwVm5KVTNPbVVwYmlVVm53YWljUXJEalc0OHRVZ1JYW DdFNEZ5am9iZ212bAogIDJvVTlrQ3ZmY1JrNWRzdG1xSDhEUHBhQSJ9fX0sCiAgIC AiU2VydmljZVNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ080LU1CTkwtWlR MSi1KNURCLUQ3SUYtTk9GUC03QTZWIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMi OiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogI kVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAielB1M1pNdTZZYjlvZHlnaExCb3 ZwMWE4T0c1eUUzdzQ3ei12ZEFLNUlaVkZHaEpPVEVmRwogIGZxTjFMTEFGU2hQXzl iekxuZG1qTklJQSJ9fX19fQ", { "signatures":[{ "alg":"S512", "kid":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX", "signature":"GXYGhu6H4ZOuZiayoRy94x6WnIJiHhYHGvmD1Mzp Td9rqAHYspxMo-l6SyheWNccwzqP3Ps3v-AAg7P3SF-Dt8zyoRYYgS8Mwg3MavHlQ TJbAiyq1fruykJddR1EkB1FAxWayl73usHTWO_ffBauqiMA"} ], "PayloadDigest":"tf1ucBynDXcgOCrUO9HubDJLozl39Imevt14slRR PCRFoQRMOc1vvyMfDrPMcmAUmZN6nv34yLooay3-HMF1jg"} ], "EnvelopedProfileHost":[{ "EnvelopeId":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkZDLUozQkMtRV FURC1VUVBNLVVSQlAtRlJDQS1WSEIzIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZUhvc3QiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"}, "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj ogewogICAgICAiVWRmIjogIk1CRkMtSjNCQy1FUVRELVVRUE0tVVJCUC1GUkNBLVZ IQjMiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI lB1YmxpYyI6ICJkMU5BS3FoNTJWUVRnZm9lWlZHbWpoX3VrNk9PWFFZcXJvRFlwMW 5fdWIxblBrQk9qbTVyCiAgMkg2VGotdlFTbmtuQ0U5OVJRTDl0cUtBIn19fSwKICA gICJFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1ENUotQzNRUy1USUpTLTdN SUItVjZZNi1HV0hFLVRLQUkiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKI CAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OC IsCiAgICAgICAgICAiUHVibGljIjogIm52REpzV0dXNGtSUWFZeEM4Z3NJQ0E0bnp 4Zm0yTnVBeVprU1lwYnhJVHcxMU1ULUtONFYKICBuNmR1QXFheFptbnktNm81clFv Hallam-Baker Expires 6 February 2022 [Page 20] Internet-Draft Mesh Protocol Reference August 2021 TnFKMkEifX19LAogICAgIlNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ1ZGL TY1R1AtQjVTWC1TRlY2LUVZVFItUlJYUS01Qk0zIiwKICAgICAgIlB1YmxpY1Bhcm FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA iY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAic2o0ejN5TTlpZEkw bEZ4d0NhRjZFckFwSHpaQ0ltdGhLVnhuYk5FQWVSRDRUSGZPRmNwTwogIHlQMXkwR DROcEZlaDZlZmdERVBLY2VlQSJ9fX0sCiAgICAiQXV0aGVudGljYXRpb24iOiB7Ci AgICAgICJVZGYiOiAiTUFRWi1OV0lZLUdDN0ktQ1E2SS1HTUEzLU1CNEYtUllBWCI sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa WMiOiAiVTFYNWtKRU55NDYwTzZ5VEdIY3FzMkFBMXphU2Ffbm4yR3FxRHBxcENtRE RZREhHMWVEUwogIDZKSGR1QmNkTVlZeWdteUdRbncyRjRDQSJ9fX19fQ", { "signatures":[{ "alg":"S512", "kid":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3", "signature":"zIbCIREQXwu5GBXdPKHZmO5dkJ3h-Jta65FYKLy8 lQrNp2yLPN_ox5QHlp-tkw8fnFsIe3IMQIgAOOWqpdJejQGLhiymClaz7BPEQlsEt o0q-pwH2iBiHoPiMv65YOaZPzblW2X4j3BsCt4I2StEciAA"} ], "PayloadDigest":"njYw-Th6easiJpjiAz6pz9rsb8xxhZTO5UaXM8_P P75IfULeBhkki3773VDhqL71EIAwvIfktFRF0G50CxKm3A"} ]}} [Future: Consider converting this to a Messaging flow.] 7.2.2. Bind Group Account Mesh Group Accounts are created in the same manner as user accounts except that a ProfileGroup is specified. The request payload: { "TransactRequest":{ "Updates":[{ "Container":"MMM_Member", "Envelopes":[[{ "dig":"S512", "policy":{ "enc":"none", "dig":"none", "Sealed":true}, "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24v bW1tLWNhdGFsb2cifQ", "SequenceInfo":{ "DataEncoding":"JSON", "ContainerType":"Merkle", "Index":0}}, Hallam-Baker Expires 6 February 2022 [Page 21] Internet-Draft Mesh Protocol Reference August 2021 "", { "PayloadDigest":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_ SpIdNs6c5H0NE8XYXysP-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg", "TreeDigest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpL Ab2JbsO1YQnJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"} ] ]}, { "Container":"MMM_Access", "Envelopes":[[{ "dig":"S512", "policy":{ "enc":"none", "dig":"none", "Sealed":true}, "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24v bW1tLWNhdGFsb2cifQ", "SequenceInfo":{ "DataEncoding":"JSON", "ContainerType":"Merkle", "Index":0}}, "", { "PayloadDigest":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_ SpIdNs6c5H0NE8XYXysP-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg", "TreeDigest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpL Ab2JbsO1YQnJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"} ] ]}, { "Container":"MMM_Publication", "Envelopes":[[{ "dig":"S512", "policy":{ "enc":"none", "dig":"none", "Sealed":true}, "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24v bW1tLWNhdGFsb2cifQ", "SequenceInfo":{ "DataEncoding":"JSON", "ContainerType":"Merkle", "Index":0}}, "", { "PayloadDigest":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_ SpIdNs6c5H0NE8XYXysP-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg", Hallam-Baker Expires 6 February 2022 [Page 22] Internet-Draft Mesh Protocol Reference August 2021 "TreeDigest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpL Ab2JbsO1YQnJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"} ] ]} ]}} The response payload: { "TransactResponse":{ "Status":201, "StatusDescription":"Operation completed successfully"}} 7.2.3. Unbind Account An account registration is deleted using the"UnbindAccount" transaction. The request payload: The response payload: 7.3. Persistence Store Management All the state associated with a Mesh profile is stored as a sequence of DARE Messages in a Dare Container. The Mesh Service holding the master copy of the persistence stores and the devices connected to the profile containing complete copies (replicas) or partial copies (redactions). Thus, the only primitive needed to achieve synchronization of the profile state are those required for synchronization of a DARE Container. These steps are: * Obtain the status of the catalogs and spools associated with the account. * Download catalog and spool updates * Upload catalog updates. To ensure a satisfactory user experience, Mesh Messages are intentionally limited in size to 64 KB or less, thus ensuring that an application can retrieve the most recent 100 messages almost instantaneously on a high bandwidth connection and without undue delay on a slower one. Hallam-Baker Expires 6 February 2022 [Page 23] Internet-Draft Mesh Protocol Reference August 2021 7.3.1. Status The status transaction returns the status of the containers the device is authorized to access for the specified account together with the updated Device Connection Entry if this has been modified since the entry presented to authenticate the request was issued. The request payload: The response payload: 7.3.2. Download The download transaction returns a collection of entries from one or more containers associated with the profile. Optional filtering criteria MAY be specified to only return objects matching specific criteria and/or only return certain parts of the selected messages. The service MAY limit the number of entries returned in an individual response for performance reasons. Obsolete example 1 7.3.3. Conflict Detection Clients SHOULD check to determine if updates to a container conflict with pending updates on the device waiting to be uploaded. For example, if a contact that the user modified on the device attempting to synchronize was subsequently deleted. The means of resolving such conflicts is not in the scope of this specification. 7.3.4. Filtering Clients may request container updates be filtered to redact catalog entries that have been updated or deleted or spool entries that have been read, deleted or were received before a certain date. 7.3.5. Transact The transact transaction appends envelopes to one or more stores. The operation is atomic, that is either all the changes specified will be made to the stores or none will. This ensures that simultaneous attempts to update a store do not result in race conditions. Hallam-Baker Expires 6 February 2022 [Page 24] Internet-Draft Mesh Protocol Reference August 2021 Each update to a catalog or container specifies the expected container index and apex digest. This provides a strong guarantee of consistency. The service MUST verify each update to check that the Merkle Tree values specified are consistent with the store entries and that the signature on the apex value (if specified) is valid and correct. Services MAY impose limits on the size and number of additions performed in response to a "TransactRequest" message to ensure that processing time does not degrade performance for other users. Obsolete example 2 7.4. Messaging Mesh Messaging is an asynchronous messaging service that allows exchange of information between devices connected to a Mesh account and between Mesh users. To enable effective abuse mitigation, Mesh Messaging enforces a four corner communication model in which all outbound and inbound messages pass through a Mesh Service which accredits and authorizes the messages on the user's behalf. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-protocol-09.html for artwork.) Figure 2 The Post transaction is used for client-service and service-service messaging transactions. Client-Service (Post Transaction) To send a message, the client creates the Mesh Message structure, encapsulates it in a DARE Message and forwards this to its service using a "Post" transaction. The Post transaction is authenticated to the service by device using the usual means of profile or ticket authentication. The DARE Message MUST be signed under a device signature key accredited by a Device Connection Assertion provided in the message signature block. The request payload: Hallam-Baker Expires 6 February 2022 [Page 25] Internet-Draft Mesh Protocol Reference August 2021 { "ConnectRequest":{ "EnvelopedRequestConnection":[{ "EnvelopeId":"MCXG-4JUY-HJYA-ZUTD-MOLU-K2V7-6THR", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQjVXLVQzM0EtVF hXTi1TVVhVLVFGSjMtTFJZMy1TTEc0IiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs CiAgIkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzozMVoifQ"}, "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi AiTkI1Vy1UMzNBLVRYV04tU1VYVS1RRkozLUxSWTMtU0xHNCIsCiAgICAiQXV0aGV udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1DVjQtTEdK QS1KNlRJLVpKNEQtU1hKVy1CT0syLUhDWkwiLAogICAgICAgICJkaWciOiAiUzUxM iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk NJNklDSk5RMVkwTFV4SFNrRXRTalpVU1MxCiAgYVNqUkVMVk5ZU2xjdFFrOUxNaTF JUTFwTUlpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV 04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeExUQTRMVEExVkRFMk9qTT NPak14V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V 3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK VlpHWWlPaUFpVFVOV05DMU1SMHBCTFVvMlZFa3RXCiAga28wUkMxVFdFcFhMVUpQU 3pJdFNFTmFUQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli R2xqSWpvZ0luQXRWVlpYYkRaU2FEUmhSazQwUWtzCiAgeldqRkdjMnhpY0Y5cU9YT kdOa3BvWTJoVVpsTm5jbVp5T0V4R1JWTnFRazlqWlZnS0lDQTFUbDl6WlZGeE0KIC AxQjViWEpJTFhkd2VFMUlTV3RWYzBFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVUZSVWkxSU5FRTBMVFJIUXpZ dFdqUlpXUzB5V1V3MUxWYzNVakl0VVZwTVNTSXNDCiAgaUFnSUNBZ0lDSlFkV0pzY VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpTUZWc2NrVmxMVXd6YVRCeUxYQm9Z VEpyTm1rMVNESlZNMlJSWlZKdmNWOVBaMTlKT0ZwCiAgcFNta3lhbTB6UlRsQ1dsQ Xhkd29nSUZoWlNEQlVaRVp3UkZKV0xVSjJWeTAwUVVObVpUQXRRU0o5Zlgwc0MKIC BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxRE4 wZ3ROa1ZHV1MwelRGUgogIEJMVWsxUzBNdFF6ZFlXQzFCU0ZwSUxVbEVOVklpTEFv Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSnhNVzV vVlRSSlVXZEdOSGMzYQogIFRWRFFXVjZNR2wyT0RaMFdtcFJOVmw0VmpOSmVUSmpW MWQxVjNGdlRuSjFTMFZJTm5ocUNpQWdiRTVPU3pnCiAgMVJIZFZaWFJFZERkR2JHb HZXVEJ6YVRKQkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJFTklMVVJIV1VndFdFaEZSUzFQTlVGVUx WZE9RVlF0UTFGVFR5MQogIEZURUpMSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT 2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC BnSUNBZ0lsQjFZbXhwWXlJNklDSnBVMUJxZEdFNFpHTnJRVkpyVEd4UGR6bHlkRFZ UVFZCMVFWaEROVjg1VQogIDJ0dk1FZzBVVVZQYldwWVJtbExUbWR6Wm1wakNpQWdO RmMyWldGRGEwUmpSM0oyVDNOTVpXZDFiVlE0ZDIxCiAgQkluMTlmWDE5IiwKICAgI Hallam-Baker Expires 6 February 2022 [Page 26] Internet-Draft Mesh Protocol Reference August 2021 CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQ1Y0LUxHSkEtSjZUSS1aSjRELVN YSlctQk9LMi1IQ1pMIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICJiYjV6aTVQ ZzVRcjNqSUtYRUI5SnFkQ1VEVWN3RVowSDBrQ1FuQjVMcjZ2djJsZVJYCiAgbmZve mFuZnM2VnhkcFR5MVF2RDB0SmVOLW1BdHBPWHg4bU1mRU50MmZJRjVjbzlCZzYxUk lTSXotODJ3cEkKICB4RUl2OEF5Q3NhWHJRZ09rZzZCQ1BXVTBXNUJRWk9ORmlkSG8 wWndVQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJQV1dkcjBtNE5Pdjc4 ZjIzcEhQaTBrZzNfRTltZU10bVM4V0NhQS1wQ0M4am8KICB0LVZuN3BGeVNtVFlmV XhtbkR1dTAxM0dXVHBtQlk4eWszYkRBY0NtUSJ9XSwKICAgICJDbGllbnROb25jZS I6ICJkNU5WMUVlcVlXa20zTEVCeTBqMVBnIiwKICAgICJBY2NvdW50QWRkcmVzcyI 6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ" ]}} The response payload: { "ConnectResponse":{ "Status":201, "StatusDescription":"Operation completed successfully", "EnvelopedAcknowledgeConnection":[{ "EnvelopeId":"MBI4-NKXK-OCSH-URV5-VDUT-PH57-WBDY", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJCVlZMLTJBVFYtMl UyUS1WM0FMLUhVNTQtQzU1Si1YWktVIiwKICAiTWVzc2FnZVR5cGUiOiAiQWNrbm9 3bGVkZ2VDb25uZWN0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmpl Y3QiLAogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6MzJaIn0", "SequenceInfo":{ "Index":1, "TreePosition":0}, "Received":"2021-08-05T16:37:32Z"}, "ewogICJBY2tub3dsZWRnZUNvbm5lY3Rpb24iOiB7CiAgICAiTWVzc2FnZU lkIjogIkJWVkwtMkFUVi0yVTJRLVYzQUwtSFU1NC1DNTVKLVhaS1UiLAogICAgIkV udmVsb3BlZFJlcXVlc3RDb25uZWN0aW9uIjogW3sKICAgICAgICAiRW52ZWxvcGVJ ZCI6ICJNQ1hHLTRKVVktSEpZQS1aVVRELU1PTFUtSzJWNy02VEhSIiwKICAgICAgI CAiQ29udGVudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpaQ0k2SUNKT1FqVl hMVlF6TTBFdFZGaFhUaTEKICBUVlZoVkxWRkdTak10VEZKWk15MVRURWMwSWl3S0l DQWlUV1Z6YzJGblpWUjVjR1VpT2lBaVVtVnhkV1Z6ZAogIEVOdmJtNWxZM1JwYjI0 aUxBb2dJQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJC iAgc0NpQWdJa055WldGMFpXUWlPaUFpTWpBeU1TMHdPQzB3TlZReE5qb3pOem96TV ZvaWZRIn0sCiAgICAgICJld29nSUNKU1pYRjFaWE4wUTI5dWJtVmpkR2x2YmlJNkl Ic0tJQ0FnSUNKCiAgTlpYTnpZV2RsU1dRaU9pQWlUa0kxVnkxVU16TkJMVlJZVjA0 dFUxVllWUzFSUmtvekxVeFNXVE10VTB4SE4KICBDSXNDaUFnSUNBaVFYVjBhR1Z1Z EdsallYUmxaRVJoZEdFaU9pQmJld29nSUNBZ0lDQWdJQ0pGYm5abGJHOQogIHdaVW xrSWpvZ0lrMURWalF0VEVkS1FTMUtObFJKTFZwS05FUXRVMWhLVnkxQ1Qwc3lMVWh EV2t3aUxBb2dJCiAgQ0FnSUNBZ0lDSmthV2NpT2lBaVV6VXhNaUlzQ2lBZ0lDQWdJ Q0FnSWtOdmJuUmxiblJOWlhSaFJHRjBZU0kKICA2SUNKbGQyOW5TVU5LVm1KdGJIa GtWMVpLV2tOSk5rbERTazVSTVZrd1RGVjRTRk5yUlhSVGFscFZVMU14QwogIGlBZ1 lWTnFVa1ZNVms1WlUyeGpkRkZyT1V4TmFURkpVVEZ3VFVscGQwdEpRMEZwVkZkV2V tTXlSbTVhVmxJCiAgMVkwZFZhVTlwUVdsVlNFcDJXbTFzYzFvS0lDQlZVbXhrYld4 Hallam-Baker Expires 6 February 2022 [Page 27] Internet-Draft Mesh Protocol Reference August 2021 cVdsTkpjME5wUVdkSmJVNHdaVk5KTmtsRFMKICBtaGpTRUp6WVZkT2FHUkhiSFppY VRsMFlsY3dkbUl5U25GYVYwNHdTV2wzUzBsRFFRb2dJR2xSTTBwc1dWaAogIFNiRn BEU1RaSlEwbDVUVVJKZUV4VVFUUk1WRUV4VmtSRk1rOXFUVE5QYWsxNFYybEtPU0o 5TEFvZ0lDQWdJCiAgQ0FpWlhkdlowbERTbEZqYlRsdFlWZDRiRkpIVmpKaFYwNXNT V3B2WjJWM2IyZEpRMEZuU1d4Q2VXSXlXZ28KICBnSUhCaVIxWlVZVmRrZFZsWVVqR mpiVlZwVDJsQ04wTnBRV2RKUTBGblNVTktWbHBIV1dsUGFVRnBWRlZPVgogIDA1RE 1VMVNNSEJDVEZWdk1sWkZhM1JYQ2lBZ2EyOHdVa014VkZkRmNGaE1WVXBRVTNwSmR GTkZUbUZVUTBsCiAgelEybEJaMGxEUVdkSlEwcFJaRmRLYzJGWFRsRlpXRXBvWWxk V01GcFlTbnBKYW04S0lDQm5aWGR2WjBsRFEKICBXZEpRMEZuU1VOS1VXUlhTbk5oV jA1TVdsaHNSbEV3VWtsSmFtOW5aWGR2WjBsRFFXZEpRMEZuU1VOQlowbAogIHRUbm xrYVVrMlNRb2dJRU5LUmxwRVVUQlBRMGx6UTJsQlowbERRV2RKUTBGblNVTkJhVlZ JVm1saVIyeHFTCiAgV3B2WjBsdVFYUldWbHBZWWtSYVUyRkVVbWhTYXpRd1VXdHpD aUFnZWxkcVJrZGpNbmhwWTBZNWNVOVlUa2QKICBPYTNCdldUSm9WVnBzVG01amJWc DVUMFY0UjFKV1RuRlJhemxxV2xablMwbERRVEZVYkRsNldsWkdlRTBLSQogIENBeF FqVmlXRXBKVEZoa2QyVkZNVWxUVjNSV1l6QkZhV1pZTVRsTVFXOW5TVU5CWjBsclZ uVlpNMG8xWTBoCiAgU2NHSXlOR2xQYVVJM1EybEJaMGxEUVFvZ0lHZEpRMHBXV2tk WmFVOXBRV2xVVlVaU1ZXa3hTVTVGUlRCTVYKICBGSklVWHBaZEZkcVVscFhVekI1V jFWM01VeFdZek5WYWtsMFZWWndUVk5UU1hORENpQWdhVUZuU1VOQlowbAogIERTbE ZrVjBwellWZE9VVmxZU21oaVYxWXdXbGhLZWtscWIyZGxkMjluU1VOQlowbERRV2R KUTBwUlpGZEtjCiAgMkZYVGt4YVdHd0tJQ0JHVVRCU1NVbHFiMmRsZDI5blNVTkJa MGxEUVdkSlEwRm5TVzFPZVdScFNUWkpRMHAKICBaVGtSUk5FbHBkMHRKUTBGblNVT kJaMGxEUVdkSlEwcFJaQW9nSUZkS2MyRlhUV2xQYVVGcFRVWldjMk5yVgogIG14TV ZYZDZZVlJDZVV4WVFtOVpWRXB5VG0xck1WTkVTbFpOTWxKU1dsWktkbU5XT1ZCYU1 UbEtUMFp3Q2lBCiAgZ2NGTnRhM2xoYlRCNlVsUnNRMWRzUVhoa2QyOW5TVVpvV2xO RVFsVmFSVnAzVWtaS1YweFZTakpXZVRBd1UKICBWVk9iVnBVUVhSUlUwbzVabGd3Y zBNS0lDQnBRV2RKUTBGcFZUSnNibUp0UmpCa1dFcHNTV3B2WjJWM2IyZAogIEpRME ZuU1VOQmFWWlhVbTFKYW05blNXc3hSRTR3WjNST2ExWkhWMU13ZWxSR1Vnb2dJRUp NVldzeFV6Qk5kCiAgRkY2WkZsWFF6RkNVMFp3U1V4VmJFVk9Wa2xwVEVGdlowbERR V2RKUTBGcFZVaFdhV0pIYkdwVlIwWjVXVmMKICB4YkdSSFZubGpDaUFnZVVrMlNVa HpTMGxEUVdkSlEwRm5TVU5CYVZWSVZtbGlSMnhxVXpKV05WSlZUa1ZUUQogIDBrMl NVaHpTMGxEUVdkSlEwRm5TVU5CWjBsRFNtcGpibGtLSUNCcFQybEJhVkpYVVRCT1J HZHBURUZ2WjBsCiAgRFFXZEpRMEZuU1VOQlowbHNRakZaYlhod1dYbEpOa2xEU25o TlZ6VnZWbFJTU2xWWFpFZE9TR016WVFvZ0kKICBGUldSRkZYVmpaTlIyd3lUMFJhT UZkdGNGSk9WbXcwVm1wT1NtVlVTbXBXTVdReFZqTkdkbFJ1U2pGVE1GWgogIEpUbT VvY1VOcFFXZGlSVFZQVTNwbkNpQWdNVkpJWkZaYVdGSkZaRVJrUjJKSGJIWlhWRUo 2WVZSS1FrbHVNCiAgVGxtVTNkTFNVTkJaMGxEU2tKa1dGSnZXbGMxTUdGWFRtaGtS MngyWW1sSk5ra0tJQ0JJYzB0SlEwRm5TVU4KICBCWjBsc1ZtdGFhVWsyU1VOS1RsS kZUa2xNVlZKSVYxVm5kRmRGYUVaU1V6RlFUbFZHVlV4V1pFOVJWbEYwVQogIFRGR1 ZGUjVNUW9nSUVaVVJVcE1TV2wzUzBsRFFXZEpRMEZuU1d4Q01WbHRlSEJaTVVKb1k yMUdkRnBZVW14CiAgamJrMXBUMmxDTjBOcFFXZEpRMEZuU1VOQlowbHNRakZaQ2lB Z2JYaHdXVEIwYkdWVlZrUlNSV2RwVDJsQ04KICAwTnBRV2RKUTBGblNVTkJaMGxEU VdsWk0wb3lTV3B2WjBsc1p6Qk9SR2RwVEVGdlowbERRV2RKUTBFS0lDQgogIG5TVU 5CWjBsc1FqRlpiWGh3V1hsSk5rbERTbkJWTVVKeFpFZEZORnBIVG5KUlZrcHlWRWQ 0VUdSNmJIbGtSCiAgRlpVVkZaQ01WRldhRVJPVmpnMVZRb2dJREowZGsxRlp6QlZW VlpRWWxkd1dWSnRiRXhVYldSNldtMXdha04KICBwUVdkT1JtTXlXbGRHUkdFd1Vtc FNNMG95VkROT1RWcFhaREZpVmxFMFpESXhDaUFnUWtsdU1UbG1XREU1SQogIGl3S0 lDQWdJQ0FnZXdvZ0lDQWdJQ0FnSUNKemFXZHVZWFIxY21Weklqb2dXM3NLSUNBZ0l DQWdJQ0FnSUNBCiAgZ0ltRnNaeUk2SUNKVE5URXlJaXdLSUNBZ0lDQWdJQ0FnSUNB Hallam-Baker Expires 6 February 2022 [Page 28] Internet-Draft Mesh Protocol Reference August 2021 Z0ltdHBaQ0k2SUNKTlExWTBMVXhIU2tFdFMKICBqWlVTUzFhU2pSRUxWTllTbGN0U Ws5TE1pMUlRMXBNSWl3S0lDQWdJQ0FnSUNBZ0lDQWdJbk5wWjI1aGRIVgogIHlaU0 k2SUNKaVlqVjZhVFZRWnpWUmNqTnFTVXRZUlVJNVNuRmtRMVZFVldOM1JWb3dTREJ yUTFGdVFqVk1jCiAgaloyZGpKc1pWSllDaUFnYm1admVtRnVabk0yVm5oa2NGUjVN VkYyUkRCMFNtVk9MVzFCZEhCUFdIZzRiVTEKICBtUlU1ME1tWkpSalZqYnpsQ1p6W XhVa2xUU1hvdE9ESjNjRWtLSUNCNFJVbDJPRUY1UTNOaFdISlJaMDlyWgogIHpaQ1 ExQlhWVEJYTlVKUldrOU9SbWxrU0c4d1duZFZRU0o5WFN3S0lDQWdJQ0FnSUNBaVV HRjViRzloWkVSCiAgcFoyVnpkQ0k2SUNKUVYxZGtjakJ0TkU1UGRqYzRaakl6Y0Vo UWFUQnJaek5mUlRsdFpVMTBiVk00VjBOaFEKICBTMXdRME00YW04S0lDQjBMVlp1T jNCR2VWTnRWRmxtVlhodGJrUjFkVEF4TTBkWFZIQnRRbGs0ZVdzellrUgogIEJZME 50VVNKOVhTd0tJQ0FnSUNKRGJHbGxiblJPYjI1alpTSTZJQ0prTlU1V01VVmxjVmx YYTIwelRFVkNlCiAgVEJxTVZCbklpd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2NtVnpj eUk2SUNKaGJHbGpaVUJsZUdGdGNHeGxMbU4KICB2YlNKOWZRIl0sCiAgICAiU2Vyd mVyTm9uY2UiOiAiVFRPSlJPMFA0LUxBMlRFVU1TWUw5ZyIsCiAgICAiV2l0bmVzcy I6ICJCVlZMLTJBVFYtMlUyUS1WM0FMLUhVNTQtQzU1Si1YWktVIn19", {} ], "EnvelopedProfileAccount":[{ "EnvelopeId":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQzQ0LUlaQzMtSV daVC1WQ1ZaLUwyQUctSEk0RS1MT1YyIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzozMVoifQ"}, "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj ogewogICAgICAiVWRmIjogIk1DNDQtSVpDMy1JV1pULVZDVlotTDJBRy1ISTRFLUx PVjIiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI lB1YmxpYyI6ICJXNXVnRVd5Q3o5ODZQdzd4UFA5LWFwMDlQRnBxZmM5eF9NQjBVcT FiclVwRWcxeWxJYWl0CiAgRTVZYUpJQWVUYl9DYzV5NFlyNUQ2a2dBIn19fSwKICA gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy dmljZVVkZiI6ICJNQkJZLUU0VkEtQ01XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKI CAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ1FYLVBGN0 EtTFkzRy0zWlBJLUFJWU8tTFI1RC1ZRzZXIiwKICAgICAgIlB1YmxpY1BhcmFtZXR lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2 IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICIwQVJFMFZhcHNNcVlmX1Atd EZuRTBGWjJacTJ3bjRlMjF2aUNINFRyaHlnN1EwTjhGWG1iCiAgcFl2XzcyX0wyVk t1bGlpaU9oZGRUMU9BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIjo gewogICAgICAiVWRmIjogIk1DTEotTENGWC1FTkUyLTVOVEYtR0JOVi1NVzNQLVZI U1oiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS 2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIl B1YmxpYyI6ICJHWG1nOHprMHB2VjliODgxSk52Um02OWRPVHVMN295WU53emlRUWx 0V0Y0YVhaTUNUamY4CiAgRU0zZ3RDVTd3SEYwenVGc2QxV2dYOEdBIn19fSwKICAg ICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTURBNS1QW TZBLUJHMkwtN1lONi1FQUtQLU8zUUItQ0c1VCIsCiAgICAgICJQdWJsaWNQYXJhbW V0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImN ydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiWGNITjdBYk1UVzFUTVFP ZDBtWHlBSEc2Mk82ajdZSGdJR2hwMU9hajV4VE9LMnVQekd4TQogIGVDZUZPelgwZ Hallam-Baker Expires 6 February 2022 [Page 29] Internet-Draft Mesh Protocol Reference August 2021 i1ZSlhpakw2aGxfYmFXQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6IHsKIC AgICAgIlVkZiI6ICJNQ0dCLTRLQ0ktQ1AzRy1GSlNELVc3VzItVVlLTy1HTkxVIiw KICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVD REgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsa WMiOiAiY0Exd2NLdG4xZGFqNjA2VUQwUEo4eExxRk4wa09keHlqc0YyUUtyUFp4ZF VZZ1NQUlZSaQogIExzTEpPRWw3Y0lzdHRwYUNGd3VQaURPQSJ9fX19fQ", { "signatures":[{ "alg":"S512", "kid":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2", "signature":"p1UxtlxOGp8wd7oESFQkmqR6uV9s-cW4WtonkwN1 BbH9F1KN6lllLPhnNBhlmstQ06cm7BEYtR6AwG2f1yOM1IjdPFzLmm53MBA-g4GLe bflsg87h_kvT9JVSnHq7MDY6ewMo97Boay7r26qf-Ci4xIA"} ], "PayloadDigest":"gNprAKlPBfHdWXEdD7djEQ8IoJzHAJS-zBlZW6Bj 8xjHqsbEhqbSO4AkIEizON5HsGbMSu_BQl_NPSrKZWS9pw"} ]}} Service-Service (Post Transaction) The Mesh Service receiving the message from the user's device MAY attempt immediate retransmission or queue it to be sent at a future time. Mesh Services SHOULD forward messages without undue delay. The Post transaction forwarding the message to the destination service carries the same payload as the original request but is authenticated by the service forwarding it. This authentication MAY be my means of either profile or ticket authentication. Missing example 37 _Denial of Service Mitigation_ Services SHOULD implement Denial of Service mitigation strategies including limiting the maximum time taken to complete a transaction and refusing connections from clients that engage in patterns of behavior consistent with abuse. The limitation in message size allows Mesh Services to aggressively time out connections that take too long to complete a transaction. A Mesh Service that hosted on a 10Mb/s link should be able to transfer 20 messages a second. If the service is taking more than 5 seconds to complete a transaction, either the source or the destination service is overloaded or the message itself is an attack. Imposing hard constraints on Mesh Service performance requires deployments to scale and apply resources appropriately. If a service is attempting to transfer 100 messages simultaneously and 40% are Hallam-Baker Expires 6 February 2022 [Page 30] Internet-Draft Mesh Protocol Reference August 2021 taking 4 seconds or more, this indicates that the number of simultaneous transfers being attempted should be reduced. Contrawise, if 90% are completinin less than a second, the number of threads allocated to sending outbound messages might be increased. _Access Control_ The inbound service MUST subject inbound messages to Access Control according to the credentials presented in the DARE Message payload. After verifying the signature and checking that the key is properly accredited in accordance with site policy, the service applies authorization controls taking account of: * The accreditation of the sender * The accreditation of the transmitting Service * The type of Mesh Message being sent * User policy as specified in their Contact Catalog * Site policy. Service-Client (Synchronization) The final recipient receives the message by synchronizing their device. The message received will be appended to the inbound spool. 7.5. Publication The Publication mechanism allows content to be published through a Mesh Account and retrieved by means of the EARL mechanism described in Uniform Data Fingerprint [draft-hallambaker-mesh-udf]. This mechanism is used in certain flows supported by the Mesh Device Connection and Contact Exchange functions. Content is published by appending an entry to an account's Publication spool. The content may then be retrieved by issuing a claim to the account specifying the publication identifier that is authenticated under the value specified in the EARL. Use of the Publication spool to post content necessarily requires that the content be smaller than the maximum message size imposed by the Mesh Service so that it can be uploaded to the service by means of a Transact transaction. Hallam-Baker Expires 6 February 2022 [Page 31] Internet-Draft Mesh Protocol Reference August 2021 Publication of large data items will require modification of the protocol to support use of a detached message body. Transfer of a detached message body is outside the scope of this document. 7.5.1. Claim Transaction The claim transaction is used to post a claim to a document published by means of an EARL. The claim interaction is used in the Static QR Code connection interaction but MAY be used for other purposes as required by Mesh applications. A claim is made by sending a ClaimRequest message to the service to which the publication is posted. The service responds with a ClaimRespose message specifying the success or failure of the claim. A device is preconfigured during manufacture and a Device Description published to the EARL: The client claiming the publication creates a claim message specifying the resource being claimed and the address of the Mesh account making the claim. Missing example 25 The message is signed by the claimant to make a RequestClaim to the service: The publication is found and the claim is accepted, the publication is returned in the response. The device waiting to be connected uses the PollClaim transaction to receive notification of a claim having been posted. 7.5.2. PollClaim Transaction The PollClaim transaction is used to discover if a claim has been posted to a published document. When an authenticated, authorized request is made, the service responds with the latest claim posted to the publication. The device in the example above periodically polls the service to which the device description is published to find if a claim has been registered. The PollClaimRequest contains the account to which the document is published and the publication ID: Hallam-Baker Expires 6 February 2022 [Page 32] Internet-Draft Mesh Protocol Reference August 2021 The response returns the latest claim made as signed message: 7.6. Cryptographic The Operate transaction is used to perform one or more cryptographic operations using private key material recorded in the Threshold Catalog. Such operations typically represent one part of a threshold key operation divided between the service and a device connected to an account. As with all operations involving the Threshold catalog, the request MUST meet the authentication criteria specified by the catalog entry. These typically include the request being authenticated by a specific key. 7.6.1. Generate Key Shares "CryptographicOperationShare" is used to request that a private key held by the service to be divided into two or more key shares. One key share is then encrypted under the encryption key of the service and the others are encrypted under public keys specified in the request. These parameters are returned in a "CryptographicResultShare". The request payload: { "TransactRequest":{ "Accounts":["bob@example.com" ], "Outbound":[[{ "EnvelopeId":"MBVP-H2LE-JMGK-DDAX-2BVN-LJBM-22LP", "enc":"A256CBC", "kid":"EBQK-CZ5R-DWAD-5VAH-SJ7A-7ZAN-2GE5", "Salt":"xfcHvFiUdMEiUarO1C11jg", "recipients":[{ "kid":"MBSO-V6BO-2RKR-GDCI-DWY3-SWXX-WBXO", "epk":{ "PublicKeyECDH":{ "crv":"X448", "Public":"dMDBhYLBN17FW33UCIWepwHeMe5nGGcRZBmfn _L933z3AStJPv1k2ryTvzPJtX6Hzk_YJSU-9E6A"}}, "wmk":"KtkslCXX8DA3GC4YrOJmQo7yAfy7Eg2g7uTRlbn6GfDf Z5LQmkUETw"} ], "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQUVMLVpEWVgt NFpVUS1LUFJDLVlDNzctVVNBVi1XSEZNIiwKICAiTWVzc2FnZVR5cGUiOiAiR3Jvd XBJbnZpdGF0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLA Hallam-Baker Expires 6 February 2022 [Page 33] Internet-Draft Mesh Protocol Reference August 2021 ogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6NDBaIn0"}, "zMT8ZtPMrikjNcspm6EVshYR1R__pG82CoNG6N91reJwVbH65V5i8ewD QwWNeFhnodVD6LjfTA4cNfV5vNl86BMik-TjhkH94iIlCejr5UrxoRQprlOkY_y-T blYkKGpV2jaMz15yd9OA1FjyKTT7GFpfo21y1JCh1VHOxBmSHEhYe3Ydm111E_U8B jAwjddaT96cVwMs_aAstycWMljTIx7MwUms_mFUeQRa-uuvWZAbtnuM37A8l_ah69 1b4VdOc5WAhWtYP5Z9R-kD_0gfOwsvxXByFZFzl5ykCWkXHTpoIgBrw8tC9L3GDCS mxS0bUn3Py4_FNXyKvSMuRyCpu9kc8VxsN2msdSecS_E1ofZriPKWIl5vD3SZczbs cxj-RDtbO0fv6e46ZRz2CzxrHDiRcEdYE1LE_IkFCDqYrLCTGcpCx7ZS5ptjcqAb2 r67vWay357q8u9RLZUe-fLV-pod_FhGUm8XrmhRZ48c6KFcICinQx9qsXj-Mcr99z yyjrBwTFqHNRQ4m73JcqT4jPtswaA83AD96rLcqawtUZxc2bDRrRP80pdA_vGofWa kqaP-z_mZBoLkdR_E_eB3JdrHDBOKh2Ku8VqBZhoiIxGF6NtRoVJAwHCXBOFSOV0q FUu6X1tVyDXTlmgIgYAvOEpIZzmUtMsAnCYDF4vCxdQVUO3_Mml-owxoiSQcZL3M7 Fclh88YKxNwuMH9wp2aBFYiSZtKdpWoM_zjmE6U3BW6tWh4umriBksS1dBDodUBVh FvSdnSHj20Y8wGQPwiHZ9TtLrm35XFOWw2mqmUvuq3RGhOJBUXr4qLfNCDL_Uvv9G ctTPelZ5cOPCclk-893O5sznv7QRoJBmzrffElw2KTJy6uGlsl3iFsZ9JsQTOHjtu njQfSWCEB_zRqrbt5T9WKlWSIgvHp_EJakS28UO7HEiiemgS0E-Cp6NHQ92CGqHMX ztNvKXN3IaCkroOQbOlq_j9ZefIRwmyb92kMKsxH5tGzWRnC7zvMN9mQS4EQAGlLz DOUIUwnNsPyMohwbBML4TY3-TLg4VGpe7T5ikkodYza8VPhykasZrr-kgZ9iptSZR G1kro3DSluVytPkVPFzIKDo9h5bE54FQCZAptEftI2zzHpPtOHwyrzR1lQDDtI_XE TefFDEq6Mlvj1Zu3bciJBGvxLfQl4W-tbxgu3AUuRUviZMXcMq_TUPsDauGDJtN-6 h7cRYGw8J4N3JZFSJRDZi4wN8TkKtJLR9u0Mt4LBvoqMTeBf-u-ZT_WGgSsVLIRPW LbUObeUXl-nqdQkAQPQ1Fnarv3hdUDOK-PZORfgr_MgT7-I0ErapcHjAoYIPKNbq5 ukw_SJgRXYL9MFyUL5FQO9ee8IS1vPgGCwFrgE7EI7IgeTlhjmBrro9BkQTxfoppz hy4R90HAW0eTzUpCue0X-gNccn0NbI5iqeH1MehfEV1MHSSDV1aOQ1KaE4okZKKUj yddN9iPGL-VRlNjswm2tsq3TDVlfFXodN5IDNh6eK_KXDBv70NDNrM3fu9iH0H5km WAoEEdfzZeGHNcDG8aFE8rlX6_-wJuDDuPUTX1iozNXCMvTs_M46u3DVfEqTlZvRc Ky96QiZHp1lQQsLBnE8UcoQGXwL9FEgWl-R6G7FyVANC0vyWOokNg70tAb40rKzZX 7a9pr0PMxQuv4KBBwN-r96hjoK4n2Yu86savenQUocrz931L_M3dmjq3cpnxj2x4r 0AgMuxQKZJirEOfLl1fq0xsS1k1FwVN1GxcuFeXZFLeBv685qPF3eV1Ha546pLw-E nnPRzLPRHyHfU5aWCZAeU6ygwpVwNhMPtE_9vQDKLvArBvNW4Jafz-kisYIW7wnVU R33-PsKVf0-PxjvdNLjZ9VrACTqK--6ANUpvKjICv6Vxk_M08htaJqUnsxLPa7L4P 5GmN1m4EVRpJByvcJLcqI43RXep2vO8BOxLnD1WuQ21L8uEg4usy1lFVbIIvIlaDJ e_EMtx1n9jN17GORRkOA8tB59TM-XoCSnTmgAwuMByjdZ0J3gj8smooSETJAZHK8u rDYS8fSc-zEWrqfPlg5tLu8r9jXaCHJkT_g1hJMUHTZ5Uj3qTou9W7G3FM8aCxGkF iGC8G9h3PIv4YvWDlB77CEU1dco_oEjMwZZNbF3bAKkhgW5Du0rcx_7MMeDJNV0j1 Jfh41_2d5bKi7-2pyLZ6NZI0EK5bUrqHtdnlmW2XIMBactW9-vD-mXOislFWWOluu 5czJuLyjnmJRRQeV3jLO6A0FP__HKc9OGwVhqeAN7c-2pylOnWYyObFTvLMxeyVCb kdl6Q2QfpRLXO68mb-xwk4JbYWjY3APKTJp-y2jC8czwo_eW1glt-CVmSpLbBUSSl Y4Gn5HomLTHAnHTWAWBgZ54YQf_gsb9VF4UAVmNNE8D5fXvBXcwz4hBlALI7J4Dgh BcFqO2wvSiobYByolAMjaa9G4bIDgAEqa10F589SRfE1cVe1qbmYT0-c8uX1FUD2R R2sRXy4dvHu_tlaLhfPP-RMMaDi7cW39NKmNtHRNvv2h1RcIOPSBMe77wIMR7cDy5 PrtjA0d_NAf5Xrj8YsFbuxx0yItnvge8ZOpM-y8Yq5qr_roNYlJLSLxiF6F7bReiy LNjqC_MmgzWztz96giKQZlZmWgPdOpFj7kDOtk3ruJn6RCF7-fvAx_-pa5Yc99bHW zwfFnLW6Il0bnAgmXibf13klh4iQ1Rid7ZU-TG6c21uQgsdl1bSJBCEdSS7pJSmj6 laHTWLAdo-UYcPuiNLbxbnUwqLja0OLNccmvnZ0GRdRSOOuwbrqYKomI_3gVadKN9 nUh-24Rtu65PGJEsuTSVj24WH9hMgxV2E_i03CxV6QyhmF-vgejl1gSELrYsXlxBB kXOa2-rMwj89fveTIYScNWj1iuxePvyCHK2QcIMj84DeoIUDVpsrreU7XgVKggCwH pag7jXvLgqYHZcHWkybOKnMLZ5kVy6qGMPTMaPpxdfBwnGglLy7TTmkwqms5BxGBi Hallam-Baker Expires 6 February 2022 [Page 34] Internet-Draft Mesh Protocol Reference August 2021 EiUEm_-fcKg3IZmQv5p91xzK30VaUadjqq7EJ3LcuvSEHKqz7r_5m0UsrNaJOO4WD y5igSBwzfOpmyiYPZzRQ5MAp14KUDfZGOtyY7fKPY3Iq9ajz166fwcIxS3HAhskIW YYK8p-4PRvr0GIue2FLyBhH3-RLuK_EHxEfLsbAw83OSIDo1Ne4SUO99sMRNj7ZNB ovY_e4giibi7cEZbxVP5XKIJi0PilJ1h0V6npB9K7lCw6fybROeTDQfb8MW26G3rJ Gya0yJuVUHqnzLLATYhzMJvwpthFvxzdn3Kuv6_XTUqbyRs7IgPXW7D-HhEbOhU4s uhcX6juMtlwWnzjq65VzgxINzFXYh03CewZ9edz6_LlqRRTfTSRvoDJOf67hrVssc tFXcL3CQWs_Nka66Y3QiJHrTwNZenDR-JG8GL0B40Sy-9tBrhJNyqrb7J5YTs8rfN V_PggOt0EKgDFfXtKETHu1A5CZ2mtB_cRR133XCDNP8ecnJ8yW-b9UN1f4sMi8zMi gmQ1oFDTt_dcCaV6hafw8-n6bZ9k4oW6UmgXw5slQbIBcyXX2wpLMJ3UNJswswMIj xF_Ez-jabaIqSDwIANCuXJ-TteQnu4b_aXfeJdYHv0dbWqA8bgYcYLJ118-uH8QHC CwGyoGg5zIqwCpRV8VVXXN1laxK1eGbnINvLwbZXaJY4M6dZ4k3nGpV7ixDx8hELM 9d9EewmHp6ZSQ5IJ6imk6KpfVxdr9pws4FOXqtkrJihUjYOjiVrvZLJK8EbzpXKKS yA7qpoCWDjhLfTRqDutTOVCmqtQkM1v6LSbqfqL_MY6DIlJ93-I9zB7aVH2tvXRiP 8PskHGhcRYnKSMgqyKcrIY7mS4DXLtJ0O7yZ5V7cFgxv9KzK11C71jy-eK5lKx11I aAC-bJEzudOysYaXB44JKPNafKohU3CRWnV6C66j4kl1HMT7rxzgF5U7GwcajlzvX hOEg-DJ7PRekhrFQjJ-czoeWD-Jkw1iBgxTTvoDoxT08c9YiFgPEy_0cGshI7woxQ cl6xIw44Akk07nlMNkQffkX2B4kshbDHWzKmxpLAGYwdTPQI98vjsSqzjEvpQ5YgD njuLyCJzaKb3eBVG4K-FIfXFVW5-U_WaU8zAYpm2bHneCLQMI--AE4j0z7YANoBQL YaCNjW8KhBwfjmFjwF3IywHP_-9nQL6BDFhGmYAemTgGbiUQ51fFYNQ0qMbfDjEAC _-j87FWRg2IINsGFdzf80i42KBTbQ" ] ]}} The response payload: { "TransactResponse":{ "Status":201, "StatusDescription":"Operation completed successfully"}} 7.6.2. Key Agreement CryptographicOperationKeyAgreement is used to request a threshold key agreement operation on a specified public key. The request payload: The response payload: 7.6.3. Sign Threshold signature is not currently supported. 8. Message Interactions Message interactions are asynchronous interactions that occur between devices connected to the same account or between accounts. Hallam-Baker Expires 6 February 2022 [Page 35] Internet-Draft Mesh Protocol Reference August 2021 All messages are signed by the sender and encrypted under the encryption key of the recipient if this is known to the sender. 8.1. Message PIN Interaction The Message PIN Interaction is used to register and validate PIN codes used to authenticate certain transactions. This interaction allows a PIN code issued by one device to be consumed by another allowing for greater convenience in managing devices or contact exchange. For example, Alice might delegate the PIN code issue privilege to her mobile device without delegating the administration privilege to that device. This would allow Alice to use her mobile device to initiate the connection of a large number of devices to her Mesh as her house is being built and approve them later using her administrative device. Use of the Message PIN interaction is optional. An application that issues a PIN code to authenticate a message MAY store the PIN value within the application without persisting it to external storage. Derivation of the SaltedPin, MessageId and Witness values from their respective inputs is described in the Schema Reference [draft-hallambaker-mesh-schema]. 8.1.1. Registration To register a PIN code to an "Account", a device: * Generates the "PIN" code value * Calculates the "SaltedPin" value for the specified "Action" * Calculates the "PinId" binding the specified "SaltedPin"to the "Account". * Creates and signs "MessagePin" containing the "SaltedPin", "Action" and "Account" values with the "MessageId" value "PinId". * Appends the "MessagePin"value to the "Administration" Spool of the "Account". Note that this construction provides limited protection against forgery attacks by a party with access to the "MessagePin". A party with such access can use it to construct the witness value required to authenticate a request. Hallam-Baker Expires 6 February 2022 [Page 36] Internet-Draft Mesh Protocol Reference August 2021 PIN Code values consist of an opaque sequence of octets represented as a UDF nonce value. Codes are presented in canonical UDF form, i.e. Base32 encoding separated into groups of 4 characters. The PIN value is converted to binary form for calculation of the "SaltedPin", thus ensuring that the canonical form of the PIN value is used. 8.1.2. Authentication The PIN Code value is passed out of band to a user who will enter it into a device to authenticate a request made to the issuer. A request that MAY be validated by means of a PIN is a subclass of MessagePinValidated and contains the following fields: AuthenticatedData A DARE Envelope containing the data that is authenticated. ClientNonce A nonce value used to prevent certain replay attacks. PinId Digest value binding the "SaltedPin"to the "Account". PinWitness Witness value calculated as KDF (Device.UDF + AccountAddress, ClientNonce) The device uses the PIN code and Action identifier corresponding to the desired request to calculate the "SaltedPin" value in the same manner as during registration. This value is then used to calculate the "PinId" and "PinWitness" values. 8.1.3. Validation The PIN code is validated by performing the steps of: * Calculating the "SaltedPin" value from the PIN code and "Action" * Calculating "PinId" from "SaltedPin" and "Account" * Retrieving a "MessagePin" from the Administration spool with the "MessageId" "PinId". * Calculating the "PinWitness" value from "SaltedPin", "ClientNonce" and "AuthenticatedData" and checking this matches the value specified in the message. * Performing the requested action. * Posting a "Complete" message to the "Administration" Spool of the "Account" marking the PIN code as used. Hallam-Baker Expires 6 February 2022 [Page 37] Internet-Draft Mesh Protocol Reference August 2021 This process can fail at multiple points resulting in different error results: "PinInvalid" No PIN code is specified, the Pin code indicates an unsupported algorithm or the calculated "PinWitness" does not match the one specified by the request. "PinUsed" The PIN code has been used previously. "PinExpired" The PIN code is no longer valid. Note that in the case that an attempt is made to reuse a PIN, it is not automatically the case that the first use of the PIN was the one that was valid and only the second attempt was invalid. Implementations SHOULD alert the user to the attempted re-use so that this possibility can be considered and appropriate action taken. 8.1.4. Example Alice connects a device using a QR code presented by her administrative device. The administration device creates a PIN code and records it to the Local spool: { "MessagePin":{ "MessageId":"ACCL-WJJ6-QILY-IDQT-67RT-LHGM-PA2K", "Account":"alice@example.com", "Expires":"2021-08-06T16:37:40Z", "Automatic":true, "SaltedPin":"ADBB-JTKR-RGGL-ACEM-TW6E-ZFY6-NQXF", "Action":"Device"}} This pin value is used to authenticate the connection request from the device: { "RequestConnection":{ "MessageId":"NBF4-4PTH-UTSC-RYHZ-EQMK-BVH7-MU3F", "AuthenticatedData":[{ "EnvelopeId":"MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU9LLUk0VFQtM0 VVUy00TE1ZLVo2Sk8tVkVONy1DWDZGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi Q3JlYXRlZCI6ICIyMDIxLTA4LTA1VDE2OjM3OjQwWiJ9"}, "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm Hallam-Baker Expires 6 February 2022 [Page 38] Internet-Draft Mesh Protocol Reference August 2021 UiOiB7CiAgICAgICJVZGYiOiAiTUFPSy1JNFRULTNFVVMtNExNWS1aNkpPLVZFTjc tQ1g2RiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI CAiUHVibGljIjogInRERTlnUy02RFk5bVBFWWFScVJmTjh6bW8zOE83N2ZIR2EtaF JYd0Z1NFhnbjVrMkdQcUEKICBqN1ZXRkVmc2FpX2JtMlJNc2w3UE8xU0EifX19LAo gICAgIkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUQ2Vi01NEZTLTZRRUYt MkNKRy1FVVhBLU5DVk4tWDVINyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjoge wogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYND Q4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMm5Ncl9GUVExYW1VbU13VzFadVQ0Tmp hWXJwRDcyTG5LTUstaXJTc3ZCVldxczVrT3JUSwogIGRQcjh5YkQ3MUoxNmxXNkJk LWJnN3htQSJ9fX0sCiAgICAiU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1BT UktSTdPUy1NQ1VNLVc3SEstNlFTRS1RWE5MLUVKR1MiLAogICAgICAiUHVibGljUG FyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICA gICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJmeTN6bWhJdFFK ZFRaVnJucjVFNlAzT2d6RmVVa2hFYTdOQWNTUHBHUkxvc3U3XzNCUEp6CiAgb1JqO EVDT19kSkpvOUJlMU9jTzdJUW9BIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IH sKICAgICAgIlVkZiI6ICJNQkZOLUIyQ1gtS1JJUS0zTUhMLTdTT1ItWDVXSi1DSFF HIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1Y mxpYyI6ICI2ZmdRRXZEOFNGWjZzb0VzLXJNa1ZXbDFCY202N2s3TVYzcWxlRzQySX ZaN0NOM1FLbDRvCiAgZFhHaVBnOFU0NDZ3bGpQQVJEQnBkNFFBIn19fX19", { "signatures":[{ "alg":"S512", "kid":"MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F", "signature":"14AHQuUENwVXXulI7Hxa1cceWaSS_qBhfy-tydNF n7rJksVfHMDiy8vrrvdV00BGuktPqgp86C2AWSac9FnGXwhNZ3PV2edzsCwC_e21d UoGQ7XPPL886uw5wkDjz7Nt8WxL1Dn8uwpAph_xrIMMNSsA"} ], "PayloadDigest":"ZXcdFX7i4PYf4oJ6O7_dLw7TWEkr0vC_r3_RcaDd cy-Wz4DPbqhCk1VGyU0YLsR6C6NEcHa9ExjBa5OIoZakgA"} ], "ClientNonce":"VGxxL-LKUQyqn_Rpdj86Zg", "PinId":"ACCL-WJJ6-QILY-IDQT-67RT-LHGM-PA2K", "PinWitness":"YhwAi-IvYYP2dMjOd-pXioRqgIq0knwLwnUqMHvpvTueLMc 7ATSXMdBlxOSZ_u8sztqpwwEZEZ5Rc4WQBKP3cA", "AccountAddress":"alice@example.com"}} The administration device can now use the PIN Identifier to retreive the MessagePIN from the Local spool and use it to verify the request. Hallam-Baker Expires 6 February 2022 [Page 39] Internet-Draft Mesh Protocol Reference August 2021 8.2. Completion Interaction Completion messages are dummy messages that are added to a Mesh Spool to mark a change the status of messages previously posted. Any message that is in the inbound spool and has not been erased or redacted MAY be marked as "read", "unread" or "deleted". Any message in the outbound spool MAY be marked as "sent", "received" or "deleted". Services MAY erase or redact messages in accordance with local site policy. Since messages are not removed from the spool on being marked deleted, they may be undeleted by marking them as read or unread. Marking a message deleted MAY make it more likely that the message will be removed if the sequence is subsequently purged. After using the PIN code to authenticate connection of a device in the previous example, the corresponding MessagePin is marked as having been used by appending a completion message to the Local spool. Missing example 32 The completion message is added to the spool in the same upload transaction that adds the device to the device catalog. This ensures that both operations occur or neither occurs. 8.3. Contact Exchange Interaction The contact exchange interaction is used to support unilateral or mutual exchange of contact information. Contact exchange has three functions in the Mesh: * To exchange public key information to allow encryption of messages sent to and verification of signatures on messages sent from the contact subject. * To exchange contact information allowing use of other communication protocols (e.g. telephone, SMS, xmpp, SMTP, OpenPGP, S/MIME, etc). * To request that the recipient grant privileges to accept certain types of messages from the contact subject. Hallam-Baker Expires 6 February 2022 [Page 40] Internet-Draft Mesh Protocol Reference August 2021 Registration of the subject's contact information in a registry service eliminates the need for the first of these functions but not the other two. To prevent abuse, every Mesh Message is subject to access control and a Mesh service will only accept a message from a sender if there is an entry in the Threshold Catalog of the account that expressly permits delivery of messages of the specified type that are authenticated by an authorized signature key. The communication of unsolicited information afforded by the contact exchange interaction is deliberately limited so that a majority of users can accept contact exchange requests without prior authorization. It is however likely that some users will receive a considerable volume of requests forcing them to require contact requests be authorized through some form of third party accreditation. 8.3.1. Remote The Remote Contact Exchange transaction consists of a sequence of "MessageContact" messages sent from the initiator to the responder, responder to the initiator, etc. While there is in principle no limit on the number of messages exchanged, most exchanges will be completed in three exchanges or less: Initiator to Responder Contains Initiator contact data without authentication context from the exchange. Responder to Initiator (optional) Contains Responder contact data authenticated under a PIN challenge presented in the previous message. Initiator to Responder (optional) Contains Initiator contact data authenticated under a PIN challenge presented in the previous message. Each message provides the recipient with additional information which MAY motivate the recipient to provide additional contact information to the sender. { "MessageContact":{ "MessageId":"NDIB-OGS2-XXZG-D2M2-5YJI-QQXN-2IVO", "Sender":"bob@example.com", "Recipient":"alice@example.com", "AuthenticatedData":[{ "dig":"S512", "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250YWN0UG Vyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmV Hallam-Baker Expires 6 February 2022 [Page 41] Internet-Draft Mesh Protocol Reference August 2021 hdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6MzVaIn0"}, "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBbewogIC AgICAgICJVZGYiOiAiTUE2SS1NSjVaLTdCQk8tVEVCQS1IUUY2LUxOUjYtNzJTRiI sCiAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3JrQWRk cmVzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJib2JAZXhhbXBsZS5jb20iL AogICAgICAgICJFbnZlbG9wZWRQcm9maWxlQWNjb3VudCI6IFt7CiAgICAgICAgIC AgICJFbnZlbG9wZUlkIjogIk1BNkktTUo1Wi03QkJPLVRFQkEtSFFGNi1MTlI2LTc yU0YiLAogICAgICAgICAgICAiZGlnIjogIlM1MTIiLAogICAgICAgICAgICAiQ29u dGVudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpaQ0k2SUNKTlFUWkpMVTFLT lZvdE4wSkNUeTEKICBVUlVKQkxVaFJSall0VEU1U05pMDNNbE5HSWl3S0lDQWlUV1 Z6YzJGblpWUjVjR1VpT2lBaVVISnZabWxzWgogIFZWelpYSWlMQW9nSUNKamRIa2l PaUFpWVhCd2JHbGpZWFJwYjI0dmJXMXRMMjlpYW1WamRDSXNDaUFnSWtOCiAgeVpX RjBaV1FpT2lBaU1qQXlNUzB3T0Mwd05WUXhOam96Tnpvek5Wb2lmUSJ9LAogICAgI CAgICAgImV3b2dJQ0pRY205bWFXeGxWWE5sY2lJNklIc0tJQ0FnSUNKUWNtOW1hV3 gKICBsVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQk5ra3R UVW8xV2kwM1FrSlBMVlJGUQogIGtFdFNGRkdOaTFNVGxJMkxUY3lVMFlpTEFvZ0lD QWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzCiAgS0lDQWdJQ0FnSUNBa VVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjbllpT2lBaV IKICBXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSjJhRTU2U2p kUGJFOTFTMmN6WVVReGFVNAogIDVXVEJNVXpWb1EyWTBaMFJDU1RrelVWSnlWa1ZK VERBeFRYRk9ZV2xyY0VkTkNpQWdXbXN5ZG1KU1N6ZENhCiAgbFJ5ZW1oWGJEVlhlV 1ZTTFhsQkluMTlmU3dLSUNBZ0lDSkJZMk52ZFc1MFFXUmtjbVZ6Y3lJNklDSmliMk oKICBBWlhoaGJYQnNaUzVqYjIwaUxBb2dJQ0FnSWxObGNuWnBZMlZWWkdZaU9pQWl UVUpDV1MxRk5GWkJMVU5OVgogIDBZdE5USlVOeTFGVTB4QkxWQkhUbFF0UTA1T1dD SXNDaUFnSUNBaVFXTmpiM1Z1ZEVWdVkzSjVjSFJwYjI0CiAgaU9pQjdDaUFnSUNBZ 0lDSlZaR1lpT2lBaVRVSlRUeTFXTmtKUExUSlNTMUl0UjBSRFNTMUVWMWt6TFZOWF cKICBGZ3RWMEpZVHlJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWp vZ2V3b2dJQ0FnSUNBZ0lDSgogIFFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0Fn SUNBZ0lDQWdJbU55ZGlJNklDSllORFE0SWl3S0lDQWdJCiAgQ0FnSUNBZ0lDSlFkV 0pzYVdNaU9pQWlabVZFTUVScFpqQm1TVlp0VEZCclRUUjVhakp6WmtveGNFRmhPWE 4KICBVVjBGTk5sY3hWa0pGTmxodmVFMUVXRzVET0hoaVZ3b2dJRU5HUmxwaWMyWTJ XVkI0ZEZCTVZVOHhTR2s1VAogIEZkbFFTSjlmWDBzQ2lBZ0lDQWlRV1J0YVc1cGMz UnlZWFJ2Y2xOcFoyNWhkSFZ5WlNJNklIc0tJQ0FnSUNBCiAgZ0lsVmtaaUk2SUNKT lJGcFlMVVJTTmxndFZUTkhRUzFGVWtkQ0xWbzJTMDB0TlZwQlNTMVZURkZVSWl3S0 kKICBDQWdJQ0FnSWxCMVlteHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUN BZ0lsQjFZbXhwWTB0bGVVVgogIERSRWdpT2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oy SWpvZ0lrVmtORFE0SWl3S0lDQWdJQ0FnSUNBZ0lDSlFkCiAgV0pzYVdNaU9pQWllR 3M0U0hONVZIcHFUbEpDTmtod00wVnBjbWwzUVRBeUxYUmpTazk1TjNkdVVtRkNaR0 oKICBPYm5vdFEyMUxlVGRFVFZOS1ZBb2dJRlJ5TTBaQmR6TmFjR2xWYm1GWFpETm5 kbkpTWlc5WlFTSjlmWDBzQwogIGlBZ0lDQWlRV05qYjNWdWRFRjFkR2hsYm5ScFky RjBhVzl1SWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxCiAgRVUwd3RRa1JUUmkxU 1JrUlRMVXBMTkVVdFdFMVRTeTFhV0VKUUxVaEJUa1FpTEFvZ0lDQWdJQ0FpVUhWaW IKICBHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJ WNVJVTkVTQ0k2SUhzS0lDQQogIGdJQ0FnSUNBZ0lDSmpjbllpT2lBaVdEUTBPQ0lz Q2lBZ0lDQWdJQ0FnSUNBaVVIVmliR2xqSWpvZ0lraE9iCiAgVkpPYW5NMVJrbFRPV lJPYUdGVlZqUllUa2RxT0VwdFoyTnFUWE5aT1dkcGJHeE9SRk4yT1RWQ2FXcGZTV3 gKICAxVHpjS0lDQnBSSEpoUjJKTGJUWXlSamQ1UXpGblEycHdTMGRHTkVFaWZYMTl MQW9nSUNBZ0lrRmpZMjkxYgogIG5SVGFXZHVZWFIxY21VaU9pQjdDaUFnSUNBZ0lD Hallam-Baker Expires 6 February 2022 [Page 42] Internet-Draft Mesh Protocol Reference August 2021 SlZaR1lpT2lBaVRVUlRReTFWVFVaVExWcFdXVlV0VERRCiAgM1JpMVpSRkZVTFVOR FJETXRVRVpITnlJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2 UKICB3b2dJQ0FnSUNBZ0lDSlFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSUN BZ0lDQWdJbU55ZGlJNklDSgogIEZaRFEwT0NJc0NpQWdJQ0FnSUNBZ0lDQWlVSFZp Ykdsaklqb2dJa3R5UW5GR1YxSTRkbmgyY1hBNGNVeFliCiAgMWsyWmpBMlYxWnNNe kZ2VmxKVVYzcGlWVlk1YWxWbFprOTFORTh3Y0RCUWMxOEtJQ0JRVkdacVMxUnFiRF EKICB0YkhGT2VuSmtSWGM0Ylc4NFkwRWlmWDE5ZlgwIiwKICAgICAgICAgIHsKICA gICAgICAgICAgInNpZ25hdHVyZXMiOiBbewogICAgICAgICAgICAgICAgImFsZyI6 ICJTNTEyIiwKICAgICAgICAgICAgICAgICJraWQiOiAiTUE2SS1NSjVaLTdCQk8tV EVCQS1IUUY2LUxOUjYtNzJTRiIsCiAgICAgICAgICAgICAgICAic2lnbmF0dXJlIj ogIko1RnhqcmlUWHZ5a2VwNTY5Y0EtTE9rUkc5UkR4RUttMVJIX09tM3F3RnVZS0J PUFAKICBvVVRFQmphR29YdTEtS2NTemVHTm5oakMxSUFiWDVqNE9DYUpmcWJnRTAt b1NZVUlmYnF5YUY1T0c0UTRhVAogIG5PWHVwZlAzaFNxNzZQdWVrT3lfYUttSEZCd zBCMFZVOHZJVzlOVGtBIn1dLAogICAgICAgICAgICAiUGF5bG9hZERpZ2VzdCI6IC JONjdKOFNSbFpVbUgxQzdhQk9iSGxzVHp3SlBkZjlBZEVzY19TLXloSVJ3eFgKICB hS3Q5Q1drSFhicE12ZXRVdXVZMi1jdkJLRmVmLVRhYVo3czZHVXRoQSJ9XSwKICAg ICAgICAiUHJvdG9jb2xzIjogW3sKICAgICAgICAgICAgIlByb3RvY29sIjogIm1tb SJ9XX1dfX0", { "signatures":[{ "alg":"S512", "kid":"MDSC-UMFS-ZVYU-L47F-YDQT-CCD3-PFG7", "signature":"FM74a48A3IDF2nPouls7KkMJhwCqIgmrqInktSf9 zfSfWlIG4V4gtWFWo1Ga7FLJiZULqs_fgLeAsP95OCpARbF41EITbm6XMBxUBVhhd LIymr4qDMl6SSJNlTaXtf6YUvtxs31SKD2Rza5F_6wr7A4A"} ], "PayloadDigest":"z05L3W6dkgu8p8U-5g58pWp7jBNRAmbv-7Dt5w98 e12lzHM3Uo-EDBtiC7Lq24C-BjeZG_Jx5VIHa9Xf0N5EzA"} ], "Reply":true, "Subject":"alice@example.com", "PIN":"AAKO-AYTU-YH3M-DWOO-SLKU-N7ZD-SKUA"}} The Mesh Contact Exchange transaction does not provide for validation of the contact information beyond the binding to the Mesh Account Address used to perform the exchange. 8.3.2. PIN Contact exchange requests MAY be authenticated by a PIN code. Initial contact exchange requests SHOULD include a PIN code value that can be used to authenticate a response (if given). PIN codes MAY also be exchanged out of band. A "MessageContact" authenticated by means of a PIN code is authenticated as described in the PIN Interaction section above. Hallam-Baker Expires 6 February 2022 [Page 43] Internet-Draft Mesh Protocol Reference August 2021 8.3.3. EARL A "MessageContact" message MAY be published as an EARL. This allows contact data to be presented to the recipient on a printed document such as a business card in machine readable format such as a QR code. 8.4. Group Invitation The "GroupInvitation" interaction is used to invite a recipient to join a Mesh Group. The interaction is essentially a form of contact exchange except that a sender SHOULD NOT send group invitations unless there is an existing relationship. Thus the 'first trust' issues intrinsic to the contact exchange interaction do not apply. The message specifies the group name and the contact entry for the group. The contact entry includes the "CapabilityDecryptServiced" used to decrypt messages sent to the group when combined with information provided by the threshold service for the group. Receipt of a "GroupInvitation" message does not require a response. { "GroupInvitation":{ "MessageId":"NAEL-ZDYX-4ZUQ-KPRC-YC77-USAV-WHFM", "Sender":"alice@example.com", "Recipient":"bob@example.com", "Contact":{ "ContactPerson":{ "Anchors":[{ "Udf":"MCTZ-HSH7-NUNV-MQ3Z-XNJ6-XGB3-VBPX", "Validation":"Self"} ], "NetworkAddresses":[{ "Address":"groupw@example.com", "EnvelopedProfileAccount":[{ "EnvelopeId":"MCTZ-HSH7-NUNV-MQ3Z-XNJ6-XGB3-VBPX", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQ1RaLU hTSDctTlVOVi1NUTNaLVhOSjYtWEdCMy1WQlBYIiwKICAiTWVzc2FnZVR5cGUiOiA iUHJvZmlsZUdyb3VwIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3Qi LAogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6MzlaIn0"}, "ewogICJQcm9maWxlR3JvdXAiOiB7CiAgICAiUHJvZmlsZVNpZ2 5hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ1RaLUhTSDctTlVOVi1NUTNaLVhOSjY tWEdCMy1WQlBYIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAg IlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgI CAgICAgICJQdWJsaWMiOiAiZ0VQZEg3T0duUjJIdUtrUjJMTWY3YmlfcUxibm01a3 FaTzFRNEcxS01DQ19VMXh3ZUZyVAogIFd5QmFsc3Vtd20zVjFpQ2c0RFpFalBpQSJ 9fX0sCiAgICAiQWNjb3VudEFkZHJlc3MiOiAiZ3JvdXB3QGV4YW1wbGUuY29tIiwK Hallam-Baker Expires 6 February 2022 [Page 44] Internet-Draft Mesh Protocol Reference August 2021 ICAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ0hVLVE0V FAtR0UyWS02RE5VLVVZRUYtUDNCRi1MWlRCIiwKICAgICAgIlB1YmxpY1BhcmFtZX RlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J 2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJyczJRbjJfTTY0WVRFaUR6 MkxGenUwN1RiZ0t4VUtvTzRWMjR4NEpUY09MQ3JTMGFRSHNZCiAgVUtyRWlqUmNkd nVNYS1oSzhxOEtwVDhBIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIj ogewogICAgICAiVWRmIjogIk1BRFotNzdESC1LV0JNLTVWWUQtSkYyQy1UQ1FWLVF XUjQiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI lB1YmxpYyI6ICJLb2p3Zm1MTnhXUHY2aUJWQ20yc0ltZmxmVDF3ZDJBaWFkWU5iRU hFRWlWQkc2dEQ2bzQ5CiAgYTUzNWRxZnBjNTI4OHF1OTh6YktNNVdBIn19fX19", { "signatures":[{ "alg":"S512", "kid":"MCTZ-HSH7-NUNV-MQ3Z-XNJ6-XGB3-VBPX", "signature":"aYkUH6X9_o8SlGtHGHlbUF5Eo-9fbtt0 EiDHE6UOcSM74-_kaJEsNjBqDoobQFY2wa9_ZKLAxLIAsaboaM4J0eLO2LwY0sLEn 56Hqnomtr9RrSdd3T94RsL9d5VbltUmbm9lri6DbEdTcbApWTIiijsA"} ], "PayloadDigest":"7QnIkdUEegnV-m6hHDZ-uxunsQi6WVv9 lSgKiAFBtZe4pW1XSIwjx--hdhszoqjDEV3d8R0cIdfrAIl705eGcw"} ], "Protocols":[{ "Protocol":"mmm"} ], "Capabilities":[{ "CapabilityDecryptPartial":{ "Id":"MCHU-Q4TP-GE2Y-6DNU-UYEF-P3BF-LZTB", "KeyData":{ "Udf":"NBDJ-WYQO-UIEH-OVLK-B3UM-J5TN-AQ3P", "PrivateParameters":{ "PrivateKeyECDH":{ "crv":"X448z", "Private":"LvKfwJ0uKLkQiW9XdxDmNZOFc-cnAK aKnTDHzDrwa1-mIk3mc0gotskRzBZrfjhgphB9KZhs_Bk"}}}, "SubjectId":"MCHU-Q4TP-GE2Y-6DNU-UYEF-P3BF-LZTB", "ServiceId":"NBDJ-WYQO-UIEH-OVLK-B3UM-J5TN-AQ3P", "ServiceAddress":"groupw@example.com"}} ]} ]}}}} 8.5. Confirmation Interaction The confirmation interaction consists of a "RequestConfirmation" message from the initiator followed by a "ResponseConfirmation" from the responder. Hallam-Baker Expires 6 February 2022 [Page 45] Internet-Draft Mesh Protocol Reference August 2021 The "RequestConfirmation" message specifies the action that is requested. The "ResponseConfirmation" message contains the enveloped RequestConfirmation message signed by the initiator and the disposition of the responder, "Accept = true" if the request is accepted and "Accept = false" otherwise. The service sends out the following request: { "RequestConfirmation":{ "MessageId":"NBLG-QNFG-5NRO-K2PT-JIBB-4AVX-X2L6", "Sender":"console@example.com", "Recipient":"alice@example.com", "Text":"start"}} Alice accepts the request and returns the following response: { "ResponseConfirmation":{ "MessageId":"MDKO-2LBI-LVRI-6F7K-FSQC-NYLV-E76L", "Sender":"alice@example.com", "Recipient":"console@example.com", "Request":[{ "EnvelopeId":"MAHP-YGCF-WQAV-CSRH-Y6GA-AAP3-VKLY", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkxHLVFORkctNU 5STy1LMlBULUpJQkItNEFWWC1YMkw2IiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV zdENvbmZpcm1hdGlvbiIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0 IiwKICAiQ3JlYXRlZCI6ICIyMDIxLTA4LTA1VDE2OjM3OjM4WiJ9", "SequenceInfo":{ "Index":4, "TreePosition":6201}, "Received":"2021-08-05T16:37:38Z"}, "ewogICJSZXF1ZXN0Q29uZmlybWF0aW9uIjogewogICAgIk1lc3NhZ2VJZC I6ICJOQkxHLVFORkctNU5STy1LMlBULUpJQkItNEFWWC1YMkw2IiwKICAgICJTZW5 kZXIiOiAiY29uc29sZUBleGFtcGxlLmNvbSIsCiAgICAiUmVjaXBpZW50IjogImFs aWNlQGV4YW1wbGUuY29tIiwKICAgICJUZXh0IjogInN0YXJ0In19", {} ], "Accept":true}} 9. Device Connection Interactions Connection of a device to a Mesh Account combines synchronous and asynchronous elements and therefore uses a combination of Mesh Service Protocol and Mesh Messaging interactions. Hallam-Baker Expires 6 February 2022 [Page 46] Internet-Draft Mesh Protocol Reference August 2021 Three connection interactions are currently defined support connection of devices with difference affordances: Witness Authenticated For connecting devices that provide data entry and display affordances and are connected to a network. The account the device is to be connected to is entered into the device which displays a witness code. This code is then compared with a code displayed on the administration device to authenticate the request, after which both devices can complete the interaction. Dynamic QR Code (PIN) Authenticated For connecting devices that provide a camera affordance. The user sets the administration device into 'add device' mode, causing a QR code to be displayed. The QR code is scanned by the device being connected after which both devices can complete the interaction. Static QR Code Authenticated For connecting devices that have been preconfigured with a device profile identified by means of a QR Code containing an EARL. The QR code is scanned by the administration device after which both devices can complete the interaction. Each of these interactions provide strong mutual authentication with minimal user effort. The witness authenticated connection interaction is intended for use in cases in which the device is already connected to a network. The QR code interactions are intended to provide support for acquisition of networking capabilities as part of the connection process. These functions are not currently specified. The Static QR Code Authenticated interaction is intended to support Internet of Things (IoT) devices which provide minimal interaction affordances. In each case, the objectives of the device connection interaction are the same: * Mutually authenticate the onboarding device and the Mesh such that the connection interaction only completes if both sides acquire the authentic profile of the other. * To provision the onboarding device with the Mesh ProfileAccount, and an ActivationDevice and ConnectionDevice record allowing the device to interact as a member of the Mesh with the set of rights specified by the user. Hallam-Baker Expires 6 February 2022 [Page 47] Internet-Draft Mesh Protocol Reference August 2021 * To create a CataloguedDevice record and append it to the Device catalog of the account to allow the device to be managed within that account. * (optional) to acquire networking capabilities to allow the above to be completed. The connection of the device to the Mesh Account is achieved through the creation of the ActivationDevice, ConnectionDevice and CataloguedDevice records described earlier. These are created by the administration device in the third phase of each of the connection interactions described below and acquired by the onboarding device in the fourth phase. 9.1. Dynamic QR Code (PIN) Authenticated The Dynamic QR Code (PIN) Authenticated interaction comprises four phases as follows: Phase 1: Issue of PIN credential A PIN code is created and registered with the PIN Registration interaction described earlier and transmitted to the user by an out of band communication (e.g. a QR code that is scanned by the device). Phase 2: Onboarding Device Request to Service The onboarding device performs a Connect transaction on a host servicing the account. This results in the exchange of the account and device profiles and the computation of a witness value from the two profile fingerprints and two nonce values specified by the onboarding device and the service. An AcknowledgeConnection message is posted to the Inbound spool of the account. Phase 3: Administration Device Acceptance The account holder accepts or rejects the connection request from a device that has been granted administration capability. Phase 4: Onboarding Device Completion The onboarding device periodically polls the service for acceptance of the request by the administration device using the Complete transaction. The use of the PIN code to authenticate the request message is shown in $$$$. Hallam-Baker Expires 6 February 2022 [Page 48] Internet-Draft Mesh Protocol Reference August 2021 The PIN code MAY be presented to the onboarding device in any format accepted by the device. Administration MAY support presentation of the account address PIN code as a URI code. Administration devices SHOULD support presentation of the account address PIN code as a QR code containing the corresponding URI. 9.1.1. Phase 1: Alice> account pin PIN=AAJP-KPYV-NSB4-GIYL-AM (Expires=2021-08-06T16:37:40Z) The registration of this PIN value was shown earlier in section $$$ The URI containing the account address and PIN is: mcu://alice@example.com/AAJP-KPYV-NSB4-GIYL-AM 9.1.2. Phase 2: The onboarding device scans the QR code to obtain the account address and PIN code. The PIN code is used to authenticate a connection request: Alice3> device request alice@example.com /pin AAJP-KPYV-NSB4-GIYL-AM Device UDF = MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F Witness value = KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN The device issues a connection request to the service corresponding to the account. This specifies the device profile, the account to which the device is to be connected and the client nonce value: { "ConnectRequest":{ "EnvelopedRequestConnection":[{ "EnvelopeId":"MD22-62AQ-PVVT-NPUS-ATUC-MQH4-PWV2", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkY0LTRQVEgtVV RTQy1SWUhaLUVRTUstQlZINy1NVTNGIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs CiAgIkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzo0MFoifQ"}, "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi AiTkJGNC00UFRILVVUU0MtUllIWi1FUU1LLUJWSDctTVUzRiIsCiAgICAiQXV0aGV udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1BT0stSTRU VC0zRVVTLTRMTVktWjZKTy1WRU43LUNYNkYiLAogICAgICAgICJkaWciOiAiUzUxM iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk NJNklDSk5RVTlMTFVrMFZGUXRNMFZWVXkwCiAgMFRFMVpMVm8yU2s4dFZrVk9OeTF EV0RaR0lpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV Hallam-Baker Expires 6 February 2022 [Page 49] Internet-Draft Mesh Protocol Reference August 2021 04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeExUQTRMVEExVkRFMk9qTT NPalF3V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V 3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK VlpHWWlPaUFpVFVGUFN5MUpORlJVTFRORlZWTXROCiAgRXhOV1MxYU5rcFBMVlpGV GpjdFExZzJSaUlzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli R2xqSWpvZ0luUkVSVGxuVXkwMlJGazViVkJGV1dGCiAgU2NWSm1Uamg2Ylc4ek9FO DNOMlpJUjJFdGFGSllkMFoxTkZobmJqVnJNa2RRY1VFS0lDQnFOMVpYUmtWbWMKIC AyRnBYMkp0TWxKTmMydzNVRTh4VTBFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVVEyVmkwMU5FWlRMVFpSUlVZ dE1rTktSeTFGVlZoQkxVNURWazR0V0RWSU55SXNDCiAgaUFnSUNBZ0lDSlFkV0pzY VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpTW01TmNsOUdVVkV4WVcxVmJVMTNW ekZhZFZRMFRtcGhXWEp3UkRjeVRHNUxUVXN0YVhKCiAgVGMzWkNWbGR4Y3pWclQzS lVTd29nSUdSUWNqaDVZa1EzTVVveE5teFhOa0prTFdKbk4zaHRRU0o5Zlgwc0MKIC BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQlR Va3RTVGRQVXkxTlExVgogIE5MVmMzU0VzdE5sRlRSUzFSV0U1TUxVVktSMU1pTEFv Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSm1lVE4 2YldoSmRGRktaRlJhVgogIG5KdWNqVkZObEF6VDJkNlJtVlZhMmhGWVRkT1FXTlRV SEJIVWt4dmMzVTNYek5DVUVwNkNpQWdiMUpxT0VWCiAgRFQxOWtTa3B2T1VKbE1VO WpUemRKVVc5QkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFrWk9MVUl5UTFndFMxSkpVUzB6VFVoTUx UZFRUMUl0V0RWWFNpMQogIERTRkZISWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT 2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC BnSUNBZ0lsQjFZbXhwWXlJNklDSTJabWRSUlhaRU9GTkdXalp6YjBWekxYSk5hMVp YYkRGQ1kyMDJOMnMzVAogIFZZemNXeGxSelF5U1haYU4wTk9NMUZMYkRSdkNpQWda RmhIYVZCbk9GVTBORFozYkdwUVFWSkVRbkJrTkZGCiAgQkluMTlmWDE5IiwKICAgI CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQU9LLUk0VFQtM0VVUy00TE1ZLVo 2Sk8tVkVONy1DWDZGIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICIxNEFIUXVV RU53VlhYdWxJN0h4YTFjY2VXYVNTX3FCaGZ5LXR5ZE5GbjdySmtzVmZICiAgTURpe Th2cnJ2ZFYwMEJHdWt0UHFncDg2QzJBV1NhYzlGbkdYd2hOWjNQVjJlZHpzQ3dDX2 UyMWRVb0dRN1gKICBQUEw4ODZ1dzV3a0RqejdOdDhXeEwxRG44dXdwQXBoX3hySU1 NTlNzQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJaWGNkRlg3aTRQWWY0 b0o2TzdfZEx3N1RXRWtyMHZDX3IzX1JjYURkY3ktV3oKICA0RFBicWhDazFWR3lVM FlMc1I2QzZORWNIYTlFeGpCYTVPSW9aYWtnQSJ9XSwKICAgICJDbGllbnROb25jZS I6ICJWR3h4TC1MS1VReXFuX1JwZGo4NlpnIiwKICAgICJQaW5JZCI6ICJBQ0NMLVd KSjYtUUlMWS1JRFFULTY3UlQtTEhHTS1QQTJLIiwKICAgICJQaW5XaXRuZXNzIjog Illod0FpLUl2WVlQMmRNak9kLXBYaW9ScWdJcTBrbndMd25VcU1IdnB2VHVlTE1jN wogIEFUU1hNZEJseE9TWl91OHN6dHFwd3dFWkVaNVJjNFdRQktQM2NBIiwKICAgIC JBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ" ]}} Hallam-Baker Expires 6 February 2022 [Page 50] Internet-Draft Mesh Protocol Reference August 2021 The service generates the service nonce value and uses it to create the AcknowledgeConnection message. { "AcknowledgeConnection":{ "MessageId":"KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN", "EnvelopedRequestConnection":[{ "EnvelopeId":"MD22-62AQ-PVVT-NPUS-ATUC-MQH4-PWV2", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkY0LTRQVEgtVV RTQy1SWUhaLUVRTUstQlZINy1NVTNGIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs CiAgIkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzo0MFoifQ"}, "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi AiTkJGNC00UFRILVVUU0MtUllIWi1FUU1LLUJWSDctTVUzRiIsCiAgICAiQXV0aGV udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1BT0stSTRU VC0zRVVTLTRMTVktWjZKTy1WRU43LUNYNkYiLAogICAgICAgICJkaWciOiAiUzUxM iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk NJNklDSk5RVTlMTFVrMFZGUXRNMFZWVXkwCiAgMFRFMVpMVm8yU2s4dFZrVk9OeTF EV0RaR0lpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV 04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeExUQTRMVEExVkRFMk9qTT NPalF3V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V 3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK VlpHWWlPaUFpVFVGUFN5MUpORlJVTFRORlZWTXROCiAgRXhOV1MxYU5rcFBMVlpGV GpjdFExZzJSaUlzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli R2xqSWpvZ0luUkVSVGxuVXkwMlJGazViVkJGV1dGCiAgU2NWSm1Uamg2Ylc4ek9FO DNOMlpJUjJFdGFGSllkMFoxTkZobmJqVnJNa2RRY1VFS0lDQnFOMVpYUmtWbWMKIC AyRnBYMkp0TWxKTmMydzNVRTh4VTBFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVVEyVmkwMU5FWlRMVFpSUlVZ dE1rTktSeTFGVlZoQkxVNURWazR0V0RWSU55SXNDCiAgaUFnSUNBZ0lDSlFkV0pzY VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpTW01TmNsOUdVVkV4WVcxVmJVMTNW ekZhZFZRMFRtcGhXWEp3UkRjeVRHNUxUVXN0YVhKCiAgVGMzWkNWbGR4Y3pWclQzS lVTd29nSUdSUWNqaDVZa1EzTVVveE5teFhOa0prTFdKbk4zaHRRU0o5Zlgwc0MKIC BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQlR Va3RTVGRQVXkxTlExVgogIE5MVmMzU0VzdE5sRlRSUzFSV0U1TUxVVktSMU1pTEFv Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSm1lVE4 2YldoSmRGRktaRlJhVgogIG5KdWNqVkZObEF6VDJkNlJtVlZhMmhGWVRkT1FXTlRV SEJIVWt4dmMzVTNYek5DVUVwNkNpQWdiMUpxT0VWCiAgRFQxOWtTa3B2T1VKbE1VO WpUemRKVVc5QkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFrWk9MVUl5UTFndFMxSkpVUzB6VFVoTUx UZFRUMUl0V0RWWFNpMQogIERTRkZISWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT Hallam-Baker Expires 6 February 2022 [Page 51] Internet-Draft Mesh Protocol Reference August 2021 2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC BnSUNBZ0lsQjFZbXhwWXlJNklDSTJabWRSUlhaRU9GTkdXalp6YjBWekxYSk5hMVp YYkRGQ1kyMDJOMnMzVAogIFZZemNXeGxSelF5U1haYU4wTk9NMUZMYkRSdkNpQWda RmhIYVZCbk9GVTBORFozYkdwUVFWSkVRbkJrTkZGCiAgQkluMTlmWDE5IiwKICAgI CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQU9LLUk0VFQtM0VVUy00TE1ZLVo 2Sk8tVkVONy1DWDZGIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICIxNEFIUXVV RU53VlhYdWxJN0h4YTFjY2VXYVNTX3FCaGZ5LXR5ZE5GbjdySmtzVmZICiAgTURpe Th2cnJ2ZFYwMEJHdWt0UHFncDg2QzJBV1NhYzlGbkdYd2hOWjNQVjJlZHpzQ3dDX2 UyMWRVb0dRN1gKICBQUEw4ODZ1dzV3a0RqejdOdDhXeEwxRG44dXdwQXBoX3hySU1 NTlNzQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJaWGNkRlg3aTRQWWY0 b0o2TzdfZEx3N1RXRWtyMHZDX3IzX1JjYURkY3ktV3oKICA0RFBicWhDazFWR3lVM FlMc1I2QzZORWNIYTlFeGpCYTVPSW9aYWtnQSJ9XSwKICAgICJDbGllbnROb25jZS I6ICJWR3h4TC1MS1VReXFuX1JwZGo4NlpnIiwKICAgICJQaW5JZCI6ICJBQ0NMLVd KSjYtUUlMWS1JRFFULTY3UlQtTEhHTS1QQTJLIiwKICAgICJQaW5XaXRuZXNzIjog Illod0FpLUl2WVlQMmRNak9kLXBYaW9ScWdJcTBrbndMd25VcU1IdnB2VHVlTE1jN wogIEFUU1hNZEJseE9TWl91OHN6dHFwd3dFWkVaNVJjNFdRQktQM2NBIiwKICAgIC JBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ" ], "ServerNonce":"1PwfBA9kRcN6fLra8ATh1Q", "Witness":"KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN"}} The AcknowledgeConnection message is appended to the Inbound spool of the account to which connection was requested so that the user can approve the request. The ConnectResponse message is returned to the device containing the AcknowledgeConnection message and the profile of the account. { "ConnectResponse":{ "Status":201, "StatusDescription":"Operation completed successfully", "EnvelopedAcknowledgeConnection":[{ "EnvelopeId":"KDKD-2X34-SAB7-R7JD-7P3D-44YE-UXHT", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJLQjNHLU5DMzUtWD ZJVS1CRUtKLVlJUVItSjRHWC1JS0tOIiwKICAiTWVzc2FnZVR5cGUiOiAiQWNrbm9 3bGVkZ2VDb25uZWN0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmpl Y3QiLAogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6NDBaIn0", "SequenceInfo":{ "Index":6, "TreePosition":11822}, "Received":"2021-08-05T16:37:40Z"}, "ewogICJBY2tub3dsZWRnZUNvbm5lY3Rpb24iOiB7CiAgICAiTWVzc2FnZU lkIjogIktCM0ctTkMzNS1YNklVLUJFS0otWUlRUi1KNEdYLUlLS04iLAogICAgIkV udmVsb3BlZFJlcXVlc3RDb25uZWN0aW9uIjogW3sKICAgICAgICAiRW52ZWxvcGVJ ZCI6ICJNRDIyLTYyQVEtUFZWVC1OUFVTLUFUVUMtTVFINC1QV1YyIiwKICAgICAgI CAiQ29udGVudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpaQ0k2SUNKT1FrWT BMVFJRVkVndFZWUlRReTEKICBTV1VoYUxVVlJUVXN0UWxaSU55MU5WVE5HSWl3S0l Hallam-Baker Expires 6 February 2022 [Page 52] Internet-Draft Mesh Protocol Reference August 2021 DQWlUV1Z6YzJGblpWUjVjR1VpT2lBaVVtVnhkV1Z6ZAogIEVOdmJtNWxZM1JwYjI0 aUxBb2dJQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJC iAgc0NpQWdJa055WldGMFpXUWlPaUFpTWpBeU1TMHdPQzB3TlZReE5qb3pOem8wTU ZvaWZRIn0sCiAgICAgICJld29nSUNKU1pYRjFaWE4wUTI5dWJtVmpkR2x2YmlJNkl Ic0tJQ0FnSUNKCiAgTlpYTnpZV2RsU1dRaU9pQWlUa0pHTkMwMFVGUklMVlZVVTBN dFVsbElXaTFGVVUxTExVSldTRGN0VFZVelIKICBpSXNDaUFnSUNBaVFYVjBhR1Z1Z EdsallYUmxaRVJoZEdFaU9pQmJld29nSUNBZ0lDQWdJQ0pGYm5abGJHOQogIHdaVW xrSWpvZ0lrMUJUMHN0U1RSVVZDMHpSVlZUTFRSTVRWa3RXalpLVHkxV1JVNDNMVU5 ZTmtZaUxBb2dJCiAgQ0FnSUNBZ0lDSmthV2NpT2lBaVV6VXhNaUlzQ2lBZ0lDQWdJ Q0FnSWtOdmJuUmxiblJOWlhSaFJHRjBZU0kKICA2SUNKbGQyOW5TVU5LVm1KdGJIa GtWMVpLV2tOSk5rbERTazVSVlRsTVRGVnJNRlpHVVhSTk1GWldWWGt3QwogIGlBZ0 1GUkZNVnBNVm04eVUyczRkRlpyVms5T2VURkVWMFJhUjBscGQwdEpRMEZwVkZkV2V tTXlSbTVhVmxJCiAgMVkwZFZhVTlwUVdsVlNFcDJXbTFzYzFvS0lDQlZVbXhrYld4 cVdsTkpjME5wUVdkSmJVNHdaVk5KTmtsRFMKICBtaGpTRUp6WVZkT2FHUkhiSFppY VRsMFlsY3dkbUl5U25GYVYwNHdTV2wzUzBsRFFRb2dJR2xSTTBwc1dWaAogIFNiRn BEU1RaSlEwbDVUVVJKZUV4VVFUUk1WRUV4VmtSRk1rOXFUVE5QYWxGM1YybEtPU0o 5TEFvZ0lDQWdJCiAgQ0FpWlhkdlowbERTbEZqYlRsdFlWZDRiRkpIVmpKaFYwNXNT V3B2WjJWM2IyZEpRMEZuU1d4Q2VXSXlXZ28KICBnSUhCaVIxWlVZVmRrZFZsWVVqR mpiVlZwVDJsQ04wTnBRV2RKUTBGblNVTktWbHBIV1dsUGFVRnBWRlZHVQogIEZONU 1VcE9SbEpWVEZST1JsWldUWFJPQ2lBZ1JYaE9WMU14WVU1cmNGQk1WbHBHVkdwamR GRXhaekpTYVVsCiAgelEybEJaMGxEUVdkSlEwcFJaRmRLYzJGWFRsRlpXRXBvWWxk V01GcFlTbnBKYW04S0lDQm5aWGR2WjBsRFEKICBXZEpRMEZuU1VOS1VXUlhTbk5oV jA1TVdsaHNSbEV3VWtsSmFtOW5aWGR2WjBsRFFXZEpRMEZuU1VOQlowbAogIHRUbm xrYVVrMlNRb2dJRU5LUmxwRVVUQlBRMGx6UTJsQlowbERRV2RKUTBGblNVTkJhVlZ JVm1saVIyeHFTCiAgV3B2WjBsdVVrVlNWR3h1Vlhrd01sSkdhelZpVmtKR1YxZEdD aUFnVTJOV1NtMVVhbWcyWWxjNGVrOUZPRE4KICBPTWxwSlVqSkZkR0ZHU2xsa01Gb 3hUa1pvYm1KcVZuSk5hMlJSWTFWRlMwbERRbkZPTVZwWVVtdFdiV01LSQogIENBeV JuQllNa3AwVFd4S1RtTXlkek5WUlRoNFZUQkZhV1pZTVRsTVFXOW5TVU5CWjBsclZ uVlpNMG8xWTBoCiAgU2NHSXlOR2xQYVVJM1EybEJaMGxEUVFvZ0lHZEpRMHBXV2tk WmFVOXBRV2xVVlZFeVZta3dNVTVGV2xSTVYKICBGcFNVbFZaZEUxclRrdFNlVEZHV mxab1FreFZOVVJXYXpSMFYwUldTVTU1U1hORENpQWdhVUZuU1VOQlowbAogIERTbE ZrVjBwellWZE9VVmxZU21oaVYxWXdXbGhLZWtscWIyZGxkMjluU1VOQlowbERRV2R KUTBwUlpGZEtjCiAgMkZYVGt4YVdHd0tJQ0JHVVRCU1NVbHFiMmRsZDI5blNVTkJa MGxEUVdkSlEwRm5TVzFPZVdScFNUWkpRMHAKICBaVGtSUk5FbHBkMHRKUTBGblNVT kJaMGxEUVdkSlEwcFJaQW9nSUZkS2MyRlhUV2xQYVVGcFRXMDFUbU5zTwogIFVkVl ZrVjRXVmN4Vm1KVk1UTldla1poWkZaUk1GUnRjR2hYV0VwM1VrUmplVlJITlV4VVZ YTjBZVmhLQ2lBCiAgZ1ZHTXpXa05XYkdSNFkzcFdjbFF6U2xWVGQyOW5TVWRTVVdO cWFEVlphMUV6VFZWdmVFNXRlRmhPYTBwclQKICBGZEtiazR6YUhSUlUwbzVabGd3Y zBNS0lDQnBRV2RKUTBGcFZUSnNibUp0UmpCa1dFcHNTV3B2WjJWM2IyZAogIEpRME ZuU1VOQmFWWlhVbTFKYW05blNXc3hRbFJWYTNSVFZHUlFWWGt4VGxFeFZnb2dJRTV NVm1NelUwVnpkCiAgRTVzUmxSU1V6RlNWMFUxVFV4VlZrdFNNVTFwVEVGdlowbERR V2RKUTBGcFZVaFdhV0pIYkdwVlIwWjVXVmMKICB4YkdSSFZubGpDaUFnZVVrMlNVa HpTMGxEUVdkSlEwRm5TVU5CYVZWSVZtbGlSMnhxVXpKV05WSlZUa1ZUUQogIDBrMl NVaHpTMGxEUVdkSlEwRm5TVU5CWjBsRFNtcGpibGtLSUNCcFQybEJhVkpYVVRCT1J HZHBURUZ2WjBsCiAgRFFXZEpRMEZuU1VOQlowbHNRakZaYlhod1dYbEpOa2xEU20x bFZFNDJZbGRvU21SR1JrdGFSbEpoVmdvZ0kKICBHNUtkV05xVmtaT2JFRjZWREprT mxKdFZsWmhNbWhHV1ZSa1QxRlhUbFJWU0VKSVZXdDRkbU16VlROWWVrNQogIERWVV Z3TmtOcFFXZGlNVXB4VDBWV0NpQWdSRlF4T1d0VGEzQjJUMVZLYkUxVk9XcFVlbVJ Hallam-Baker Expires 6 February 2022 [Page 53] Internet-Draft Mesh Protocol Reference August 2021 LVlZjNVFrbHVNCiAgVGxtVTNkTFNVTkJaMGxEU2tKa1dGSnZXbGMxTUdGWFRtaGtS MngyWW1sSk5ra0tJQ0JJYzB0SlEwRm5TVU4KICBCWjBsc1ZtdGFhVWsyU1VOS1RsR nJXazlNVlVsNVVURm5kRk14U2twVlV6QjZWRlZvVFV4VVpGUlVNVWwwVgogIDBSV1 dGTnBNUW9nSUVSVFJrWklTV2wzUzBsRFFXZEpRMEZuU1d4Q01WbHRlSEJaTVVKb1k yMUdkRnBZVW14CiAgamJrMXBUMmxDTjBOcFFXZEpRMEZuU1VOQlowbHNRakZaQ2lB Z2JYaHdXVEIwYkdWVlZrUlNSV2RwVDJsQ04KICAwTnBRV2RKUTBGblNVTkJaMGxEU VdsWk0wb3lTV3B2WjBsc1p6Qk9SR2RwVEVGdlowbERRV2RKUTBFS0lDQgogIG5TVU 5CWjBsc1FqRlpiWGh3V1hsSk5rbERTVEphYldSU1VsaGFSVTlHVGtkWGFscDZZakJ XZWt4WVNrNWhNCiAgVnBZWWtSR1Exa3lNREpPTW5NelZBb2dJRlpaZW1OWGVHeFNl bEY1VTFoYVlVNHdUazlOTVVaTVlrUlNka04KICBwUVdkYVJtaElZVlpDYms5R1ZUQ k9SRm96WWtkd1VWRldTa1ZSYmtKclRrWkdDaUFnUWtsdU1UbG1XREU1SQogIGl3S0 lDQWdJQ0FnZXdvZ0lDQWdJQ0FnSUNKemFXZHVZWFIxY21Weklqb2dXM3NLSUNBZ0l DQWdJQ0FnSUNBCiAgZ0ltRnNaeUk2SUNKVE5URXlJaXdLSUNBZ0lDQWdJQ0FnSUNB Z0ltdHBaQ0k2SUNKTlFVOUxMVWswVkZRdE0KICAwVlZVeTAwVEUxWkxWbzJTazh0V mtWT055MURXRFpHSWl3S0lDQWdJQ0FnSUNBZ0lDQWdJbk5wWjI1aGRIVgogIHlaU0 k2SUNJeE5FRklVWFZWUlU1M1ZsaFlkV3hKTjBoNFlURmpZMlZYWVZOVFgzRkNhR1o 1TFhSNVpFNUdiCiAgamR5U210elZtWklDaUFnVFVScGVUaDJjbkoyWkZZd01FSkhk V3QwVUhGbmNEZzJRekpCVjFOaFl6bEdia2QKICBZZDJoT1dqTlFWakpsWkhwelEzZ ERYMlV5TVdSVmIwZFJOMWdLSUNCUVVFdzRPRFoxZHpWM2EwUnFlamRPZAogIERoWG VFd3hSRzQ0ZFhkd1FYQm9YM2h5U1UxTlRsTnpRU0o5WFN3S0lDQWdJQ0FnSUNBaVV HRjViRzloWkVSCiAgcFoyVnpkQ0k2SUNKYVdHTmtSbGczYVRSUVdXWTBiMG8yVHpk ZlpFeDNOMVJYUld0eU1IWkRYM0l6WDFKalkKICBVUmtZM2t0VjNvS0lDQTBSRkJpY 1doRGF6RldSM2xWTUZsTWMxSTJRelpPUldOSVlUbEZlR3BDWVRWUFNXOQogIGFZV3 RuUVNKOVhTd0tJQ0FnSUNKRGJHbGxiblJPYjI1alpTSTZJQ0pXUjNoNFRDMU1TMVZ SZVhGdVgxSndaCiAgR280Tmxwbklpd0tJQ0FnSUNKUWFXNUpaQ0k2SUNKQlEwTk1M VmRLU2pZdFVVbE1XUzFKUkZGVUxUWTNVbFEKICB0VEVoSFRTMVFRVEpMSWl3S0lDQ WdJQ0pRYVc1WGFYUnVaWE56SWpvZ0lsbG9kMEZwTFVsMldWbFFNbVJOYQogIGs5a0 xYQllhVzlTY1dkSmNUQnJibmRNZDI1VmNVMUlkbkIyVkhWbFRFMWpOd29nSUVGVVU xaE5aRUpzZUU5CiAgVFdsOTFPSE42ZEhGd2QzZEZXa1ZhTlZKak5GZFJRa3RRTTJO Qklpd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2MKICBtVnpjeUk2SUNKaGJHbGpaVUJsZ UdGdGNHeGxMbU52YlNKOWZRIl0sCiAgICAiU2VydmVyTm9uY2UiOiAiMVB3ZkJBOW tSY042ZkxyYThBVGgxUSIsCiAgICAiV2l0bmVzcyI6ICJLQjNHLU5DMzUtWDZJVS1 CRUtKLVlJUVItSjRHWC1JS0tOIn19", {} ], "EnvelopedProfileAccount":[{ "EnvelopeId":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2", "dig":"S512", "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQzQ0LUlaQzMtSV daVC1WQ1ZaLUwyQUctSEk0RS1MT1YyIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzozMVoifQ"}, "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj ogewogICAgICAiVWRmIjogIk1DNDQtSVpDMy1JV1pULVZDVlotTDJBRy1ISTRFLUx PVjIiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI lB1YmxpYyI6ICJXNXVnRVd5Q3o5ODZQdzd4UFA5LWFwMDlQRnBxZmM5eF9NQjBVcT FiclVwRWcxeWxJYWl0CiAgRTVZYUpJQWVUYl9DYzV5NFlyNUQ2a2dBIn19fSwKICA Hallam-Baker Expires 6 February 2022 [Page 54] Internet-Draft Mesh Protocol Reference August 2021 gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy dmljZVVkZiI6ICJNQkJZLUU0VkEtQ01XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKI CAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ1FYLVBGN0 EtTFkzRy0zWlBJLUFJWU8tTFI1RC1ZRzZXIiwKICAgICAgIlB1YmxpY1BhcmFtZXR lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2 IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICIwQVJFMFZhcHNNcVlmX1Atd EZuRTBGWjJacTJ3bjRlMjF2aUNINFRyaHlnN1EwTjhGWG1iCiAgcFl2XzcyX0wyVk t1bGlpaU9oZGRUMU9BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIjo gewogICAgICAiVWRmIjogIk1DTEotTENGWC1FTkUyLTVOVEYtR0JOVi1NVzNQLVZI U1oiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS 2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIl B1YmxpYyI6ICJHWG1nOHprMHB2VjliODgxSk52Um02OWRPVHVMN295WU53emlRUWx 0V0Y0YVhaTUNUamY4CiAgRU0zZ3RDVTd3SEYwenVGc2QxV2dYOEdBIn19fSwKICAg ICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTURBNS1QW TZBLUJHMkwtN1lONi1FQUtQLU8zUUItQ0c1VCIsCiAgICAgICJQdWJsaWNQYXJhbW V0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImN ydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiWGNITjdBYk1UVzFUTVFP ZDBtWHlBSEc2Mk82ajdZSGdJR2hwMU9hajV4VE9LMnVQekd4TQogIGVDZUZPelgwZ i1ZSlhpakw2aGxfYmFXQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6IHsKIC AgICAgIlVkZiI6ICJNQ0dCLTRLQ0ktQ1AzRy1GSlNELVc3VzItVVlLTy1HTkxVIiw KICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVD REgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsa WMiOiAiY0Exd2NLdG4xZGFqNjA2VUQwUEo4eExxRk4wa09keHlqc0YyUUtyUFp4ZF VZZ1NQUlZSaQogIExzTEpPRWw3Y0lzdHRwYUNGd3VQaURPQSJ9fX19fQ", { "signatures":[{ "alg":"S512", "kid":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2", "signature":"p1UxtlxOGp8wd7oESFQkmqR6uV9s-cW4WtonkwN1 BbH9F1KN6lllLPhnNBhlmstQ06cm7BEYtR6AwG2f1yOM1IjdPFzLmm53MBA-g4GLe bflsg87h_kvT9JVSnHq7MDY6ewMo97Boay7r26qf-Ci4xIA"} ], "PayloadDigest":"gNprAKlPBfHdWXEdD7djEQ8IoJzHAJS-zBlZW6Bj 8xjHqsbEhqbSO4AkIEizON5HsGbMSu_BQl_NPSrKZWS9pw"} ]}} The device generates the witness value and presents it to the user as shown above. 9.1.3. Phase 3: The user synchronizes their pending messages: Hallam-Baker Expires 6 February 2022 [Page 55] Internet-Draft Mesh Protocol Reference August 2021 Alice> message pending MessageID: KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN Connection Request:: MessageID: KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN To: From: Device: MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F Witness: KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN MessageID: NC2L-ZQGP-ER6P-F6GB-LMKJ-DOFI-PO3V Group invitation:: MessageID: NC2L-ZQGP-ER6P-F6GB-LMKJ-DOFI-PO3V To: alice@example.com From: alice@example.com MessageID: NBLG-QNFG-5NRO-K2PT-JIBB-4AVX-X2L6 Confirmation Request:: MessageID: NBLG-QNFG-5NRO-K2PT-JIBB-4AVX-X2L6 To: alice@example.com From: console@example.com Text: start MessageID: NDIB-OGS2-XXZG-D2M2-5YJI-QQXN-2IVO Contact Request:: MessageID: NDIB-OGS2-XXZG-D2M2-5YJI-QQXN-2IVO To: alice@example.com From: bob@example.com PIN: AAKO-AYTU-YH3M-DWOO-SLKU-N7ZD-SKUA Alice> account sync /auto ERROR - An attempt was made to create an object with an existing obje ct identifier The administration device determines that the device connection request is authenticated by a PIN code. The PIN code is retrieved and the message authenticated. This is shown in the PIN registration interation example in section $$$ above. The Cataloged device record is created from the public key values corresponding to the combination of the public keys in the device profile and those defined by the activation: The ActivationDevice and CatalogedDevice records are ??? 9.1.4. Phase 4 The device periodically polls for completion of the connection request using the Complete transaction. To provide a final check on the process, the command line tool presents the UDF of the account profile to which the device has connected if successful: Missing example 40 The completion request specified the device requesting completion: Hallam-Baker Expires 6 February 2022 [Page 56] Internet-Draft Mesh Protocol Reference August 2021 The response contains the information the device requires to complete the connection to the mesh: 9.2. Witness Authenticated The witness authenticated interaction is essentially the same as the Dynamic QR Code (PIN) Authenticated interaction except that mutual authentication is achieved by comparing the witness value computed by the device in the second phase to that computed by the administration device in the third phase. 9.2.1. Phase 1: There are no first phase actions. 9.2.2. Phase 2: Alice enters the connection request on the device to be connected. This specifies the address of the account to which she wishes to connect: Alice2> device request alice@example.com Device UDF = MCV4-LGJA-J6TI-ZJ4D-SXJW-BOK2-HCZL Witness value = BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU 9.2.3. Phase 3: The user reviews their pending messages: Alice> device pending MessageID: BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU Connection Request:: MessageID: BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU To: From: Device: MCV4-LGJA-J6TI-ZJ4D-SXJW-BOK2-HCZL Witness: BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU The administration device receives the AcknowledgeConnection message from the service and verifies that the signature is valid and the witness value correctly computed. The user verifies that the witness value presented in the AcknowledgeConnection message matches the one presented on the device. Since they match, the request is accepted: Alice> device accept BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU /message /web Hallam-Baker Expires 6 February 2022 [Page 57] Internet-Draft Mesh Protocol Reference August 2021 9.2.4. Phase 4 The device completes the connection as before: Alice2> device complete Device UDF = MCV4-LGJA-J6TI-ZJ4D-SXJW-BOK2-HCZL Account = alice@example.com Account UDF = MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2 9.3. Static QR Code Authenticated The Static QR Code Authenticated mode is used to connect devices that have been preconfigured for use with the Mesh with a device configuration identified by a URI typically presented as machine readable QR code on the device itself. The interaction has four phases: Phase 1: Preconfiguration The device to be onboarded is preconfigured with a ProfileDevice and private key information and a DeviceDescription posted to a publication service. This process is typically performed during manufacture. An EARL providing the ability to locate and decrypt the description is printed on the device itself as a QR code. Phase 2: Device description acquisition The administration device acquiring the onboarding device scans the QR code on the device and uses this information to obtain the device description by means of the PollClaim interaction described above. Phase 3: Administration Device Acceptance This phase is performed in the same manner as the Dynamic QR Code (PIN) Authenticated interaction except that the administration device MAY advise the device that a connection request is being made by additional means described in the device description (e.g. WiFi, Bluetooth). Phase 4: Onboarding Device Completion This phase is performed in the same manner as the Dynamic QR Code (PIN) Authenticated interaction except that the administration device requires notice that of the pending connection request. The use of the PollClaim interaction to discover a pending claim for a document was shown in section $$$ above. The claim is authenticated using the key specified in the EARL. Hallam-Baker Expires 6 February 2022 [Page 58] Internet-Draft Mesh Protocol Reference August 2021 9.3.1. Phase 1 The device is prepopulated with a Device description, this is shown in section $$$ of Schema. 9.3.2. Phase 2 The administration device scans the QR code and obtains the Device Description using the Claim transaction as shown in section $$$$. 9.3.3. Phase 3 Tha administration device creates the ActivationDevice and CatalogedDevice records and populates the service as before. 9.3.4. Phase 4 The device polls the publication service until a claim message is returned. This interaction is shown in section $$$$ above. 10. Protocol Schema HTTP Well Known Service Prefix: /.well-known/mmm Every Mesh Portal Service transaction consists of exactly one request followed by exactly one response. Mesh Service transactions MAY cause modification of the data stored in the Mesh Service or the Mesh itself but do not cause changes to the connection state. The protocol itself is thus idempotent. There is no set sequence in which operations are required to be performed. It is not necessary to perform a Hello transaction prior to any other transaction. 10.1. Request Messages A Mesh Portal Service request consists of a payload object that inherits from the MeshRequest class. When using the HTTP binding, the request MUST specify the portal DNS address in the HTTP Host field. 10.1.1. Message: MeshRequest Base class for all request messages. [No fields] Hallam-Baker Expires 6 February 2022 [Page 59] Internet-Draft Mesh Protocol Reference August 2021 10.1.2. Message: MeshRequestUser Base class for all request messages made by a user. Inherits: MeshRequest Account: String (Optional) The fully qualified account name (including DNS address) to which the request is directed. EnvelopedProfileDevice: Enveloped (Optional) Device profile of the device making the request. 10.2. Response Messages A Mesh Portal Service response consists of a payload object that inherits from the MeshResponse class. When using the HTTP binding, the response SHOULD report the Status response code in the HTTP response message. However the response code returned in the payload object MUST always be considered authoritative. 10.2.1. Message: MeshResponse Base class for all response messages. Contains only the status code and status description fields. [No fields] 10.3. Imported Objects The Mesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications and in the DARE Data At Rest Encryption extensions to JOSE. 10.4. Common Structures The following common structures are used in the protocol messages: 10.4.1. Structure: KeyValue Describes a Key/Value structure used to make queries for records matching one or more selection criteria. Key: String (Optional) The data retrieval key. Value: String (Optional) The data value to match. Hallam-Baker Expires 6 February 2022 [Page 60] Internet-Draft Mesh Protocol Reference August 2021 10.4.2. Structure: ConstraintsSelect Specifies constraints to be applied to a search result. These allow a client to limit the number of records returned, the quantity of data returned, the earliest and latest data returned, etc. Container: String (Optional) The container to be searched. IndexMin: Integer (Optional) Only return objects with an index value that is equal to or higher than the value specified. IndexMax: Integer (Optional) Only return objects with an index value that is equal to or lower than the value specified. NotBefore: DateTime (Optional) Only data published on or after the specified time instant is requested. Before: DateTime (Optional) Only data published before the specified time instant is requested. This excludes data published at the specified time instant. PageKey: String (Optional) Specifies a page key returned in a previous search operation in which the number of responses exceeded the specified bounds. When a page key is specified, all the other search parameters except for MaxEntries and MaxBytes are ignored and the service returns the next set of data responding to the earlier query. 10.4.3. Structure: ConstraintsData Specifies constraints on the data to be sent. MaxEntries: Integer (Optional) Maximum number of entries to send. BytesOffset: Integer (Optional) Specifies an offset to be applied to the payload data before it is sent. This allows large payloads to be transferred incrementally. BytesMax: Integer (Optional) Maximum number of payload bytes to send. Header: Boolean (Optional) Return the entry header Payload: Boolean (Optional) Return the entry payload Trailer: Boolean (Optional) Return the entry trailer Hallam-Baker Expires 6 February 2022 [Page 61] Internet-Draft Mesh Protocol Reference August 2021 10.4.4. Structure: PolicyAccount Describes the account creation policy including constraints on account names, whether there is an open account creation policy, etc. Minimum: Integer (Optional) Specifies the minimum length of an account name. Maximum: Integer (Optional) Specifies the maximum length of an account name. InvalidCharacters: String (Optional) A list of characters that the service does not accept in account names. The list of characters MAY not be exhaustive but SHOULD include any illegal characters in the proposed account name. 10.4.5. Structure: ContainerStatus Container: String (Optional) Index: Integer (Optional) Digest: Binary (Optional) 10.4.6. Structure: ContainerUpdate Inherits: ContainerStatus Envelopes: DareEnvelope [0..Many] The entries to be uploaded. 10.5. Transaction: Hello Request: HelloRequest Response: MeshHelloResponse Report service and version information. The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service. The PostConstraints field MAY be used to advise senders of a maximum size of payload that MAY be sent in an initial Post request. 10.5.1. Message: MeshHelloResponse ConstraintsUpdate: ConstraintsData (Optional) Specifies the default Hallam-Baker Expires 6 February 2022 [Page 62] Internet-Draft Mesh Protocol Reference August 2021 data constraints for updates. ConstraintsPost: ConstraintsData (Optional) Specifies the default data constraints for message senders. PolicyAccount: PolicyAccount (Optional) Specifies the account creation policy EnvelopedProfileService: Enveloped (Optional) The enveloped master profile of the service. EnvelopedProfileHost: Enveloped (Optional) The enveloped profile of the host. 10.6. Transaction: BindAccount Request: BindRequest Response: BindResponse Request creation of a new service account or group. Attempt 10.6.1. Message: BindRequest Request binding of an account to a service address. Inherits: MeshRequest AccountAddress: String (Optional) The service account to bind to. EnvelopedProfileAccount: Enveloped (Optional) The signed assertion describing the account. 10.6.2. Message: BindResponse Inherits: MeshResponse Reports the success or failure of a Create transaction. Reason: String (Optional) Text explaining the status of the creation request. URL: String (Optional) A URL to which the user is directed to complete the account creation request. Hallam-Baker Expires 6 February 2022 [Page 63] Internet-Draft Mesh Protocol Reference August 2021 10.7. Transaction: UnbindAccount Request: UnbindRequest Response: UnbindResponse Request deletion of a service account. 10.7.1. Message: UnbindRequest Request creation of a new portal account. The request specifies the requested account identifier and the Mesh profile to be associated with the account. Inherits: MeshRequestUser [No fields] 10.7.2. Message: UnbindResponse Inherits: MeshResponse Reports the success or failure of a Delete transaction. [No fields] 10.8. Transaction: Connect Request: ConnectRequest Response: ConnectResponse Request information necessary to begin making a connection request. 10.8.1. Message: ConnectRequest Inherits: MeshRequest EnvelopedRequestConnection: Enveloped (Optional) The connection request generated by the client Rights: String [0..Many] List of named access rights. 10.8.2. Message: ConnectResponse Inherits: MeshResponse EnvelopedAcknowledgeConnection: Enveloped (Optional) The connection Hallam-Baker Expires 6 February 2022 [Page 64] Internet-Draft Mesh Protocol Reference August 2021 request generated by the client EnvelopedProfileAccount: Enveloped (Optional) The user profile that provides the root of trust for this Mesh 10.9. Transaction: Complete Request: CompleteRequest Response: CompleteResponse 10.9.1. Message: CompleteRequest Inherits: StatusRequest AccountAddress: String (Optional) ResponseID: String (Optional) 10.9.2. Message: CompleteResponse Inherits: MeshResponse EnvelopedRespondConnection: Enveloped (Optional) The signed assertion describing the result of the connect request 10.10. Transaction: Status Request: StatusRequest Response: StatusResponse 10.10.1. Message: StatusRequest Inherits: MeshRequestUser DeviceUDF: String (Optional) ProfileMasterDigest: Binary (Optional) Catalogs: String [0..Many] Spools: String [0..Many] 10.10.2. Message: StatusResponse Inherits: MeshResponse Hallam-Baker Expires 6 February 2022 [Page 65] Internet-Draft Mesh Protocol Reference August 2021 EnvelopedProfileAccount: Enveloped (Optional) The account profile providing the root of trust for this account. EnvelopedCatalogedDevice: Enveloped (Optional) The catalog device entry ContainerStatus: ContainerStatus [0..Many] 10.11. Transaction: Download Request: DownloadRequest Response: DownloadResponse Request objects from the specified container with the specified search criteria. 10.11.1. Message: DownloadRequest Inherits: MeshRequestUser Request objects from the specified container(s). A client MAY request only objects matching specified search criteria be returned and MAY request that only specific fields or parts of the payload be returned. Select: ConstraintsSelect [0..Many] Specifies constraints to be applied to a search result. These allow a client to limit the number of records returned, the quantity of data returned, the earliest and latest data returned, etc. ConstraintsPost: ConstraintsData (Optional) Specifies the data constraints to be applied to the responses. 10.11.2. Message: DownloadResponse Inherits: MeshResponse Return the set of objects requested. Services SHOULD NOT return a response that is disproportionately large relative to the speed of the network connection without a clear indication from the client that it is relevant. A service MAY limit the number of objects returned. A service MAY limit the scope of each response. Updates: ContainerUpdate [0..Many] The updated data Hallam-Baker Expires 6 February 2022 [Page 66] Internet-Draft Mesh Protocol Reference August 2021 10.12. Transaction: Transact Request: TransactRequest Response: TransactResponse Attempt an atomic transaction on the containers and spools associated with an account. 10.12.1. Message: TransactRequest Inherits: MeshRequestUser Upload entries to a container. This request is only valid if it is issued by the owner of the account Updates: ContainerUpdate [0..Many] The data to be updated Accounts: String [0..Many] The account(s) to which the request is directed. Outbound: Enveloped [0..Many] The messages to be sent to other accounts Inbound: Enveloped [0..Many] Messages to be appended to the user's inbound spool. this is typically used to post notifications to the user to mark messages as having been read or responded to. Local: Enveloped [0..Many] Messages to be appended to the user's local spool. This is used to allow connecting devices to collect activation messages before they have connected to the mesh. 10.12.2. Message: TransactResponse Inherits: MeshResponse Response to an upload request. Entries: EntryResponse [0..Many] The responses to the entries. ConstraintsData: ConstraintsData (Optional) If the upload request contains redacted entries, specifies constraints that apply to the redacted entries as a group. Thus the total payloads of all the messages must not exceed the specified value. 10.12.3. Structure: EntryResponse IndexRequest: Integer (Optional) The index value of the entry in the Hallam-Baker Expires 6 February 2022 [Page 67] Internet-Draft Mesh Protocol Reference August 2021 request. IndexContainer: Integer (Optional) The index value assigned to the entry in the container. Result: String (Optional) Specifies the result of attempting to add the entry to a catalog or spool. Valid values for a message are 'Accept', 'Reject'. Valid values for an entry are 'Accept', 'Reject' and 'Conflict'. ConstraintsData: ConstraintsData (Optional) If the entry was redacted, specifies constraints that apply to the redacted entries as a group. Thus the total payloads of all the messages must not exceed the specified value. 10.13. Transaction: Post Request: PostRequest Response: PostResponse Request to post to a spool from an external party. The request and response messages are extensions of the corresponding messages for the Upload transaction. It is expected that additional fields will be added as the need arises. 10.13.1. Message: PostRequest Inherits: MeshRequest Accounts: String [0..Many] The account(s) to which the request is directed. Messages: Enveloped [0..Many] The messages to be sent to the addresses specified in Accounts. 10.13.2. Message: PostResponse Inherits: TransactResponse [No fields] 10.14. Transaction: Claim Request: ClaimRequest Response: ClaimResponse Hallam-Baker Expires 6 February 2022 [Page 68] Internet-Draft Mesh Protocol Reference August 2021 Claim a publication 10.14.1. Message: ClaimRequest Inherits: MeshRequest EnvelopedMessageClaim: Enveloped (Optional) The claim message 10.14.2. Message: ClaimResponse Inherits: MeshResponse CatalogedPublication: CatalogedPublication (Optional) The encrypted device profile 10.15. Transaction: PollClaim Request: PollClaimRequest Response: PollClaimResponse Check party making claim 10.15.1. Message: PollClaimRequest Inherits: MeshRequest PublicationId: String (Optional) The envelope identifier formed from the PublicationId. TargetAccountAddress: String (Optional) Account to which the claim is directed 10.15.2. Message: PollClaimResponse Inherits: MeshResponse EnvelopedMessage: Enveloped (Optional) The claim message 10.15.3. Structure: CryptographicOperation KeyId: String (Optional) The key identifier KeyCoefficient: Binary (Optional) Lagrange coefficient multiplier to be applied to the private key Hallam-Baker Expires 6 February 2022 [Page 69] Internet-Draft Mesh Protocol Reference August 2021 10.15.4. Structure: CryptographicOperationSign Inherits: CryptographicOperation Data: Binary (Optional) The data to sign PartialR: Binary (Optional) Contribution to the R offset. 10.15.5. Structure: CryptographicOperationKeyAgreement Inherits: CryptographicOperation [No fields] 10.15.6. Structure: CryptographicOperationGenerate Inherits: CryptographicOperation [No fields] 10.15.7. Structure: CryptographicOperationShare Inherits: CryptographicOperation Threshold: Integer (Optional) Shares: Integer (Optional) 10.15.8. Structure: CryptographicResult Error: String (Optional) 10.15.9. Structure: CryptographicResultKeyAgreement Inherits: CryptographicResult [No fields] 10.15.10. Structure: CryptographicResultShare Inherits: CryptographicResult [No fields] 10.16. Transaction: Operate Request: OperateRequest Hallam-Baker Expires 6 February 2022 [Page 70] Internet-Draft Mesh Protocol Reference August 2021 Response: OperateResponse Perform a set of cryptographic operations 10.16.1. Message: OperateRequest Inherits: MeshRequest AccountAddress: String (Optional) The service account the capability is bound to 10.16.2. Message: OperateResponse Inherits: MeshResponse [No fields] 11. Security Considerations The security considerations for use and implementation of Mesh services and applications are described in the Mesh Security Considerations guide [draft-hallambaker-mesh-security]. 12. IANA Considerations All the IANA considerations for the Mesh documents are specified in this document 13. Acknowledgements A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture]. 14. Normative References [draft-hallambaker-mesh-architecture] Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: Architecture Guide", Work in Progress, Internet-Draft, draft-hallambaker-mesh-architecture-16, 13 January 2021, . [draft-hallambaker-mesh-schema] Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema Reference", Work in Progress, Internet-Draft, draft- hallambaker-mesh-schema-07, 13 January 2021, . Hallam-Baker Expires 6 February 2022 [Page 71] Internet-Draft Mesh Protocol Reference August 2021 [draft-hallambaker-mesh-security] Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Security Considerations", Work in Progress, Internet- Draft, draft-hallambaker-mesh-security-06, 2 November 2020, . [draft-hallambaker-mesh-udf] Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, Internet-Draft, draft-hallambaker-mesh-udf-12, 13 January 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 15. Informative References [draft-hallambaker-mesh-developer] Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft- hallambaker-mesh-developer-10, 27 July 2020, . [ECMA-262] Ecma International, "ECMAScript(R) 2017 Language Specification", June 2017. Hallam-Baker Expires 6 February 2022 [Page 72]