Mathematical Mesh 3.0 Part V: Protocol Reference
Internet-Draft draft-hallambaker-mesh-protocol
Phillip Hallam-Baker
ThresholdSecrets.com
phill@hallambaker.com
20 April 2022
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.

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.
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.

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.

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].

Defined Terms
The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture].

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.

Implementation Status
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].

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 makes use of Reliable UDP Datagram (RUD) [draft-hallambaker-mesh-rud] for framing and authentication of individual requests and responses. These RUS packets are in turn exchanged over either HTTPS (i.e. a Web Service) or directly over UDP.
Protocol Layering

t

c

t

P

g

l

S

v

C

o

e

S

r

D

e

T

T

U

P

o

a

l

T

n

t

c

h

M

b

a

g

o

l

r

h

r

e

U

e

a

m

L

M

M

o

e

P

P

e

s

i

a

D

i

P

D

T

s

s

s

o

l

S

R

a

H

e

r

c

o

i

P

g

Mesh Services MUST support the HTTPS binding and MAY support the UDP binding.

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.
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.

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.

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.

Protocol Bindings
The protocol binding maps the abstract protocol definition specified in this document to the network protocol format.
- Discovery of network services.
- Construction of the payload data by serializing request and response messages.
- Authentication of the payload data.
- Confidentiality controls to protect against traffic analysis
Currently only one protocol binding is specified: JSON-BCD Application Binding [draft-hallambaker-jsonbcd] over Reliable User Datagram (RUD) [draft-hallambaker-mesh-rud].
JSON-BCD Application Binding specifies the means by which data types such as 'integer' and 'datetime' etc. given in this document are serialized using JSON/JSON-B encoding.
Reliable User Datagram offers a presentation layer over a choice of HTTP or UDP transport.

Mesh Service Operations
The Mesh Service operations are divided into the following functional groups:
Service Description
Describes the service.
Account Management
Operations used to create, reclaim, and delete accounts.
Persistence Store Management
Operations used to synchronize persistence store data across connected devices. [May be replaced in a future revision]
Device Connection
Operations used by devices requesting connection to the account.
Publication
Operations allowing a watched document to be posted to the service and claims made on the document returned to a device.
Cryptographic
Cryptographic operations, including threshold operations performed by the service.
Messaging
Exchange of messages between Mesh Services.

Service Description
The Hello transaction is used to determine the features supported by the service and obtain the service profile.
The request payload only specifies that is is a request for the service description:
{
  "HelloRequest":{}}
The response payload describes the service and the host providing that service:
{
  "MeshHelloResponse":{
    "Status":201,
    "Version":{
      "Major":3,
      "Minor":0,
      "Encodings":[{
          "ID":["application/json"
            ]}
        ]},
    "EnvelopedProfileService":[{
        "EnvelopeId":"MDSK-EUHS-QXGD-LKOF-AVC7-V2RH-LV6Z",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNRFNLLUVVSFMtUV
  hHRC1MS09GLUFWQzctVjJSSC1MVjZaIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVNlcnZpY2UiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAg
  IkNyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzoxNVoifQ"},
      "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJQcm9maWxlU2lnbmF0dX
  JlIjogewogICAgICAiVWRmIjogIk1EU0stRVVIUy1RWEdELUxLT0YtQVZDNy1WMlJ
  ILUxWNloiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVi
  bGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgI
  CAgIlB1YmxpYyI6ICJVdVdEOHF4ZGVxazZweVdrb3o2M3FCcEpQQ2NaT2ItaHlTWV
  FiX0x4NWZHZllPb1U0Z0I3CiAgVjZWYXVBZkctdUlCREJNcWcxUW1jR1FBIn19fSw
  KICAgICJTZXJ2aWNlQXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTURB
  TC1aSTVOLTRVS1otSDZWTC1GMjVLLVBITkYtWlVWQSIsCiAgICAgICJQdWJsaWNQY
  XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC
  AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiZDNibl8tcUVWd0J
  NNjlaOTNLYWJuM01xU25jOUdRRGxGVDJfUmN4NXRWUm1lYl9iank3MQogIHZTUlNr
  M1pQMDREajJjVUJNNEFnci1vQSJ9fX0sCiAgICAiU2VydmljZUVuY3J5cHRpb24iO
  iB7CiAgICAgICJVZGYiOiAiTUE0Sy1FVkNLLTM2T1otVUhTUS1TSExLLTM2TjMtWV
  c3TCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWN
  LZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQ
  dWJsaWMiOiAiUF9vd1dHdDd3ZHR1dmNzR0NQZlFvOHVGNUNGWEcyUlB3Y1RCbEtac
  XgwVklmOWhwTWRleQogIHVBalJNRmVFNV8zblJtMHl3TDZ0a1VRQSJ9fX0sCiAgIC
  AiU2VydmljZVNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQUMzLVlKU1UtNDJ
  GMy1CQjRMLVQ0N0gtVkY2TS00SVhNIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMi
  OiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogI
  kVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiX3BUMGNtdzY2dWFRYmQwUWhFMT
  V5VXRtMVVEc2RvWjF6THRHcnFObkRmVGJoUThxVXFEbAogIHBQRzRmc3pJRmE5dml
  LWUU5MENCQTJFQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MDSK-EUHS-QXGD-LKOF-AVC7-V2RH-LV6Z",
            "signature":"aDhxhPphK2d1smZFTyaCfa-7l0LOty4A0ngIfur5
  gbKwsEozM5iTCZHV0HDZIqqnZ0THTzMpcd6AEwBm6SfRfClq1GjA6Eg_nzJkOWKVI
  v2m0ZWE5RnaIUclvg4lfn7t8NTbof2eryIv9qhR0_uyOgoA"}
          ],
        "PayloadDigest":"LJuCRu0W-vSJP0S2lHpEiW_aKliIb3wsYCpXOB5H
  x8nKOmFzeanUHVWNflPTxwFeoECpDf_-uQ5kI8-61oE_Xw"}
      ]}}
The current revision of the specification is designed for small scale deployments in which the service is provided by a single host. The approach will require revision in future versions to fully support a service being provided by multiple hosts with accounts being transferred between the hosts to allow balancing of load.

Account Management
There are three account management operations:
BindAccount
Create an account bound to a service address.
UnbindAccount
Delete an account bound to a service address
RecoverAccount
[TBS] Reclaim an account using a recovered primary secret.
The BindAccount operation is used to create User and Group accounts. Currently, these account types are distinct. This may change in future releases.

Bind Account
A User Account is bound to a Mesh Service by completing a BindAccount operation with the service.
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 contains all the information needed to create the account:
- The account address
- The account profile
Since there is no Access Catalog until the account is created, the Bind Account request and subsequent requests used to initialize the access catalog for the account MUST be authenticated by the Account Authentication key.
Alice requests creation of the account alice@example.com. The request payload is:
{
  "BindRequest":{
    "AccountAddress":"alice@example.com",
    "EnvelopedProfileAccount":[{
        "EnvelopeId":"MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU1RLUVURUEtSk
  JMMy02VUtFLUxSTlQtREdDMy1PSURGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzoxN1oifQ"},
      "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1BTVEtRVRFQS1KQkwzLTZVS0UtTFJOVC1ER0MzLU9
  JREYiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJuaTg1UWphTTh3VTV2Um9LbXdueEQwRjljNFNLMzAzTWswR2FkNV
  dsSjhoZ0JpWVd3OW9OCiAgem1pMzJzdzhYQW1lcjZVTTBTb1RjMjRBIn19fSwKICA
  gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy
  dmljZVVkZiI6ICJNRFNLLUVVSFMtUVhHRC1MS09GLUFWQzctVjJSSC1MVjZaIiwKI
  CAgICJFc2Nyb3dFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1CWlAtV1pBWi
  1CNktRLU1ZWVAtSDdLRC1WVkJBLTdUNlUiLAogICAgICAiUHVibGljUGFyYW1ldGV
  ycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYi
  OiAiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInRSODVSQ3FXdjgtWDVCazBOV
  TRFVmxqUUZKNTg1Rk5FM1p3eVd6WFNWdEpIaXgwRlo3aloKICBRN3hnOXV1cnc4S0
  9LbDVNMFVXN0xMT0EifX19LAogICAgIkFkbWluaXN0cmF0b3JTaWduYXR1cmUiOiB
  7CiAgICAgICJVZGYiOiAiTUJEVi1YWE5ILTJSVUItUkJNWi01Tkc3LUwzQ0QtM1RI
  ViIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZ
  XlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUH
  VibGljIjogIkhVd040UlZoR2N6RmxPbTJiRGNldnZWWXlkNmdqZHEzM1FxVjhVcTM
  5ZEdhc1J6UW45X1AKICBWZ0NCUklfOE1qaXZlclRLZGFhRUkzMkEifX19LAogICAg
  IkNvbW1vbkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTURQUi1GSlZXLUdLN
  VotMkxKQS1MTVlWLVhTQ0gtSEUyQyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIj
  ogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJ
  YNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiNTVqVWttcW4zZ3dHMGIySHpEVnUz
  SGxmNXNPNkdnVmxqX3ZhWUZ3QUVrc0RjTXkzd3l2VQogIHd0OW9qa2VVS1Q2MzA0R
  HdmcmgtVXc4QSJ9fX0sCiAgICAiQ29tbW9uQXV0aGVudGljYXRpb24iOiB7CiAgIC
  AgICJVZGYiOiAiTUJWSS1FV0xPLUVJN0otT1ZBSy1HR1pILTZZSFctWkpTVSIsCiA
  gICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RI
  IjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiO
  iAiZlRVM1RlQjEtN0s4U1pwbzR0UXhaUHBKQWItX2QzTklkSmhsa3hXYWlab2dKUk
  VLOWFkUAogIGY5S25zNW1xcjExVVRUb0lNaHpmZEphQSJ9fX0sCiAgICAiQ29tbW9
  uU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1BTVAtQlg0Ry1BS0syLVlIUEEt
  SVhKVi1aMktWLVVYQlciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgI
  CAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLA
  ogICAgICAgICAgIlB1YmxpYyI6ICJZNi1EMkRiYktsYVZYdkc1WlF3ZUxkNV9rUDF
  FQ0FDUjQwYkRtcGctWTRLczkyRk5lLXV5CiAgc1dVck1fTG1RS09JUGpqcjVMOE5P
  QkVBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF",
            "signature":"FOqGS7sd-l-iXeW0NnWOIUbmJxw0SLBHk_F4VYya
  8AIu23JVKebgbH-MtSAK_-0FVuXyWcRUdT8AsHeGljsGe7Y9tN4q_NT8tIASs9ZsZ
  a4HXUyAB3vOzMuSO6wi5bHehc-zWhkEPZhvdiBMcizkODYA"}
          ],
        "PayloadDigest":"pbnx3FGeWuZWOrANRD5vo3UYnkZRpHGmpLwSWVJn
  sNZ4SFe4qVn-hfNrZ557hnJhp4aD7EN2p6B7IVNMmuK_9w"}
      ]}}
The response payload currently reports the success or failure of the bind operation:
{
  "BindResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "EnvelopedAccountHostAssignment":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY2NvdW50SG
  9zdEFzc2lnbm1lbnQiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCI
  sCiAgIkNyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzoxN1oifQ"},
      "ewogICJBY2NvdW50SG9zdEFzc2lnbm1lbnQiOiB7CiAgICAiQWNjb3VudE
  FkZGVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiQWNjZXNzRW5jcnlwdCI
  6IHsKICAgICAgIlVkZiI6ICJNQUpZLTY1S1AtQzY3RS1MRlhQLVEzWEktWkhaRi1H
  TkhWIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY
  0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIl
  B1YmxpYyI6ICJIVWVvTEJvWUpqOWVZeDlQd1VMem5NRThvVHQ3R1JyeThBNWhmUTk
  1OUw1UjdQeUlaMEZYCiAgaFNRVk12cVF4aUJtRzlpeGdiNkpMSDRBIn19fX19"
      ]}}
It is likely that a future revisions of the specification will specify the host(s) to which future account service operations are to be directed. This would allow the account management operations to be separated from the account maintenance operations without requiring the traditional tiered architecture in which every interaction with a service is first routed to a host that cannot perform the required action so that it can be directed to the host that can.

Bind Group Account
Mesh Group Accounts are created in the same manner as user accounts except that the ProfileGroup is specified.

Account Recovery
Should all the administration devices be lost, an account MAY be recovered by the process of recovering the profile master secret and using it to access the account through the account authentication key.

Unbind Account
An account registration is deleted using the UnbindAccount transaction.
>>>> Unfinished ProtocolAccountDelete
The request payload:
{
  "UnbindRequest":{
    "Account":"alice@example.com"}}
The response payload:
{
  "UnbindResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

Account Transfer
Should a user wish to transfer their account to a new service provider, they first use the Bind Account operation to bind the account to the new service provider, then populate the account entry at the new account using the account authentication key.
Only after the new account binding has been completed and is ready for use, is the unbind operation used to delete the account entry at the old service provider.
Future versions of the protocol will elaborate on this mechanism so that the change of address can be signaled to connected devices and parties sending messages to the account.

Account Recovery and Transfer.
Account recovery is necessary in the case that user has lost control of every administration device connected to the account and must re-create the account profile and bind a new set of administrative devices. Account transfer is the process of unbinding an account from one service and rebinding it to a new one.
These capabilities are both critical to the long term success of the Mesh but have been deleted from the current revision of the specification as their implementation is interdependent on the architecture of the callsign registry.
>>>> Unfinished ProtocolAccountRecover
[TBS]

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 32 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.

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.
Alice adds an entry to her bookmark catalog. Before the bookmark can be added, the device synchronizes to the service. The synchronization process begins with a request for the status of all the stores associated with the account that it has access rights for:
{
  "StatusRequest":{
    "CatalogedDeviceDigest":"MBD2-CX3T-MAHB-323R-ZKPE-V23R-4O"}}
If the account has a very large number of stores, the device might only ask for the status of specific stores of interest.
The response specifies the status of each store specifying the index and Merkle tree apex digest values for each:
{
  "StatusResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "ContainerStatus":[{
        "Container":"MMM_Inbound",
        "Index":3},
      {
        "Container":"MMM_Outbound",
        "Index":1,
        "Digest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpLAb2JbsO1YQ
  nJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"},
      {
        "Container":"MMM_Local",
        "Index":2},
      {
        "Container":"MMM_Access",
        "Index":3,
        "Digest":"af-ZCV48K2pp8D8_a7t2Zovpj0Rg083JVQ9FSptSqzHwAwS
  DEv6Q7qd3UJAj5xcHgN8-uixxRM62NP7MDZwZIA"},
      {
        "Container":"MMM_Credential",
        "Index":4,
        "Digest":"xIiGmicJxjUJWEjWM6nqwKIG0Hmotr9pjFxTEFXeCCW1klZ
  VWj4rJv1X4byJvxplJwtGVWYph9YEi0ZMFrNkRw"},
      {
        "Container":"MMM_Device",
        "Index":3,
        "Digest":"AfExhtW64TJvmpW9Lrh5uf8jURFrFTc62FYgffU3IPowOdl
  3HV5gHYxGB-Pucpaco7vowCEqRjqeP5dTMOQzFw"},
      {
        "Container":"MMM_Contact",
        "Index":2,
        "Digest":"VSDUsxoQIIMuSLTVgeEO2QTpGweYanJ86nDrdUMPm0CDX4m
  PVP_8UWAtWdm6HMmpvQ7Pm11pgDUYSNOF72Cofg"},
      {
        "Container":"MMM_Application",
        "Index":1,
        "Digest":"BWJ7_IbH7vcOI-CR-oGpqIXdQz50rPbmGsZvOiL1dqKe9lW
  QJSh5tKElz9TAQRT0EG7G0kOZ2mCqiP_yGZAN3A"},
      {
        "Container":"MMM_Publication",
        "Index":1,
        "Digest":"xDBR1MLSGbMcgX1mjMyT-XEKgTXG8j8v4pNhOfHkZTp_xfm
  3oEWvudSi0dO-varqqX_iwrHFJD9wxWWjfNThAA"},
      {
        "Container":"MMM_Bookmark",
        "Index":1,
        "Digest":"vKaVPfFoa-c_h0XyyLmN5Fb1C0mgFogLo80vb-qu4r0xFUx
  wCJ5qGqObbaxLxK8a7_sSZ88SV8McU1NWl7BS3w"},
      {
        "Container":"MMM_Task",
        "Index":1,
        "Digest":"Od-7rQgE-8X-Dr1oIAgkhuKm5NMc85RIOnFLlJmqskwy3yO
  YoWzorX-aUve1rKPmnBCmbAhDUhHEGo_wUP-kJQ"}
      ]}}
Bug: The current version of the reference code is only returning the digest values for the outbound store.

Download
The download transaction returns a collection of entries from one or more containers associated with the profile.
The service MAY limit the number of entries returned in an individual response for performance reasons.
The previous status operation has reported that a new envelope has been added to the credential store. The device requests this data from the service:
{
  "DownloadRequest":{
    "Select":[{
        "Container":"MMM_Credential",
        "IndexMin":3,
        "IndexMax":4}
      ]}}
The response contains the requested envelope:
{
  "DownloadResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "Updates":[{
        "Container":"MMM_Credential",
        "Envelopes":[[{
              "PayloadDigest":"YPLzDhhS7EN_kZDTvNG5M0SM-FHOzqbbb5
  tpe2QiPcqvMbeL5wG5DixDsKpHyp2Be1-JIzC2svJLMmxThxoKQA",
              "TreeDigest":"xIiGmicJxjUJWEjWM6nqwKIG0Hmotr9pjFxTE
  FXeCCW1klZVWj4rJv1X4byJvxplJwtGVWYph9YEi0ZMFrNkRw",
              "enc":"A256CBC",
              "dig":"S512",
              "Salt":"lUbGQVUnbrUB9k4ZwNQGMA",
              "recipients":[{
                  "kid":"MDG5-EPRO-L3LG-GGFU-WKSG-EXU3-GGAB",
                  "epk":{
                    "PublicKeyECDH":{
                      "crv":"X448",
                      "Public":"NHRQRC52QsQUM8p7-p0Tc9QGm-VcojGal
  1n8tpbVd-H127mYjgGDV5vB7VqMBClC6aVISJTzWE4A"}},
                  "wmk":"cyTvjux3YTmm8XgzUXXI3VBxRFXh3ueSteXaHHFu
  g5EdKpF82OFP8Q"}
                ],
              "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICI6ZnRwLmV4
  YW1wbGUuY29tIiwKICAiRXZlbnQiOiAiVXBkYXRlIiwKICAiRmlyc3QiOiAxLAogI
  CJQcmV2aW91cyI6IDF9",
              "SequenceInfo":{
                "Index":3,
                "TreePosition":825},
              "Received":"2022-04-20T16:17:23Z"},
            "3-njoLi2gG1Bc3eb2vGW5WJ2cHs8D7s-wrvy7L2jEAVHWlBgp4gY
  y4Pi89A70PJy3zsrJohsEw6zuqwGH9ETUmjuNWWq5cgBn2KZfz3dRdmQ8U0zw5E5y
  4qY15v5dyzaN2qh7CTUyQtxupsFhgImGYiOhnqEoCi5udTs1YpC5mg",
            {}
            ]
          ]}
      ]}}
Future: The current implementation of the download operation is limited by the capabilities of the HTTP binding of the RUD transport. A future binding allowing operations that consist of a single request followed by a sequence of responses will allow much greater flexibility.
Future versions of the protocol may support optional filtering criteria so that the service only returns objects matching specific criteria and/or only return certain parts of the selected messages.

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 allows Mesh stores to provide ACID (Atomicity, Consistency, Isolation, Durability) properties to the applications they serve.
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.
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.
The request payload specifies the data to be appended to the stores.
{
  "TransactRequest":{
    "Updates":[{
        "Container":"MMM_Bookmark",
        "Envelopes":[[{
              "PayloadDigest":"nLPqGhIpOzHAKROd7NqK6i2E-_cbliqw9u
  U5RS7LRV7-u2LtLvXjjl3zA0U4SkoiK7lQJxcywO3gS5189D3wnQ",
              "TreeDigest":"-SDCQM4HDOThmLenmg1392iskvEeEDdhactIU
  1D7cc9m25-4LH1eY-qyLo1nijRPL5AtULixbyUOlnpPM9FEZg",
              "dig":"S512",
              "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQVZVLVJI
  RFEtTjdFTC1HUU5CLTdVNzUtQzRUSi0zREtPIiwKICAiRXZlbnQiOiAiTmV3In0",
              "SequenceInfo":{
                "Index":1,
                "TreePosition":0}},
            "ewogICJDYXRhbG9nZWRCb29rbWFyayI6IHsKICAgICJVaWQiOiAi
  TkFWVS1SSERRLU43RUwtR1FOQi03VTc1LUM0VEotM0RLTyIsCiAgICAiVXJpIjogI
  lNpdGVzLjIiLAogICAgIlRpdGxlIjogImh0dHA6Ly93d3cuZXhhbXBsZS5uZXQifX
  0"
            ]
          ]}
      ]}}
The response reports successful completion:
{
  "TransactResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

Device Connection
In order to support the wide range of affordances supported by devices, four device connection interactions are currently specified. The use of these mechanisms is described in [draft-hallambaker-mesh-architecture] and the interactions themselves are described in section ??? following.
Device connection operations are always issued by a device requesting connection to a Mesh account and must therefore be authenticated under the device profile rather than the account profile. Two device connection operations are currently defined:
Connect
Requests connection to the account.
Complete
Polls for completion of a connection request.
Since the second operation is merely polling for completion of the transaction requested by the first, it is likely that these will be combined in a future revision of the specification.

Connect
If the connection request is initiated by the device being connected, the device constructs a RequestConnection message which is posted to the Mesh Service using the Connect operation.
If the Connect operation is accepted (i.e. the service determines it is not abuse), the service constructs an AcknowledgeConnection message which is forwarded to the inbound spool of the account to which connection is requested. The requesting device receives a copy of the AcknowledgeConnection message and the profile of the account it is requesting connection to.
As described in the following section, the AcknowledgeConnection message contains the request details presented by the device and a nonce value generated by the service. This nonce value is used to compute the witness value that will be used for mutual authentication of the device and account.
The connect request is made to the service, not the account. The payload contains the enveloped connection request:
{
  "ConnectRequest":{
    "EnvelopedRequestConnection":[{
        "EnvelopeId":"MBHZ-QYVP-T5DQ-FQAP-AWD4-FLMO-ZZJT",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQ0FBLTdVWUEtVE
  cyQy02WFVDLVVHM0ItNFhHVC1PQklFIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzo1MVoifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi
  AiTkNBQS03VVlBLVRHMkMtNlhVQy1VRzNCLTRYR1QtT0JJRSIsCiAgICAiQXV0aGV
  udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1BQTMtQlFQ
  Wi1XV080LTdRNUItUDdBSC1GWTVDLUFUTUQiLAogICAgICAgICJkaWciOiAiUzUxM
  iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk
  NJNklDSk5RVUV6TFVKUlVGb3RWMWRQTkMwCiAgM1VUVkNMVkEzUVVndFJsazFReTF
  CVkUxRUlpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk
  bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV
  04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeUxUQTBMVEl3VkRFMk9qRT
  NPalV4V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V
  3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK
  VlpHWWlPaUFpVFVGQk15MUNVVkJhTFZkWFR6UXROCiAgMUUxUWkxUU4wRklMVVpaT
  lVNdFFWUk5SQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC
  BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F
  nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli
  R2xqSWpvZ0lrVTFaVXMwY1VrelRWbENlRFY0Y0hSCiAgNlkyNTRjRWhhYm5aTlFXc
  FRibkpJUmpoQmJtSjVjRTR0V1RacFpsVkhibE5mVGxRS0lDQmZhWEZhY21kdGUKIC
  BVUkxSRVJEYVVGWFNrVTBSM0E0VlVFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI
  yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVUZNVnkxUldGZzBMVWxCUkVV
  dFFUUmFXUzFIVWtaV0xUZEdVbFl0Tms1TldpSXNDCiAgaUFnSUNBZ0lDSlFkV0pzY
  VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC
  BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F
  nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpV1VaM1dtSjZSa053Y214RVRrNXFT
  a1ZzT0U1aVVEbEJjVlpsTmpRelFtMU9Ua0YxYjJ0CiAgSVJYVkhlakZXWHpZd1ZIR
  nlVQW9nSUVVM1dWa3RRbFpCVFU4MVVrMVBjVVIzUjNVM1dGOXhRU0o5Zlgwc0MKIC
  BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQ1N
  6VXRTVkkwVXkweVIwdAogIFdMVVpJVWxjdFFrWkpOUzFTVUZKRkxVVkdUMFVpTEFv
  Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS
  UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC
  BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSXdOVzV
  EV0V4d1NqbDFOamgzUQogIDJ0MWRUUktXalZ4VHpSMGQwbzNjVFZqYVdkUE9FSnha
  ek56WDJaMmNYWkxjbDlTZVZrMkNpQWdNVzUzWjJwCiAgSVMyRnpaMDl3V1dGeFkwU
  lhjelk0ZVdkQkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC
  BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJGZE1MVk5NTkVJdFMxZERWeTFYTTFoVkx
  UWkpTMW90VVVaUFZTMQogIEJSVmRhSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G
  dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT
  2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC
  BnSUNBZ0lsQjFZbXhwWXlJNklDSjBkVGMwUVZaTFlVcDFaR1JtTTFKRWNtWjBhV0k
  wYTJWdE9WTjRNR0UzYwogIHpBdFFYVktVek5SYkVoSWMxZDZWbGxXVG1aS0NpQWdS
  MGMzV0Y5Tk4xZEtSbHBFYUZReFRqVTBZVVU0WkZkCiAgQkluMTlmWDE5IiwKICAgI
  CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC
  JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQUEzLUJRUFotV1dPNC03UTVCLVA
  3QUgtRlk1Qy1BVE1EIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICJ2T3VmZENC
  XzlIVDZJOGFhclh2bW1PeU5TbC13LXh5SjlsRGpBRUU3NzY3OTN2bDFMCiAga0VGW
  XNCNWJoNnlkVzZpdGZ4N3d0eUk1aDJBWWFoNEJvc0tCUGVHNXFmSVZYMGJEX0JIek
  gzd21fcFlUaHQKICBwWlJHVWRfQ0xsR0l5cVppLWRqNnByYS1SYXRvQ0RiQmRLSWd
  QQ1RJQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJscmNWZ0FseGl3TTdp
  YWNsbUI0bFFPLWQxcUlZV29pbEdhMkFueEFxVkpPU04KICBIdGM4TkRabkd3VXlnN
  mI2bFpsem9WZ1FSTmdPZEdRYVZxVzZzTmYxUSJ9XSwKICAgICJDbGllbnROb25jZS
  I6ICJnWkZIMUxaTm9BQ20wLXgwdGcyOHlBIiwKICAgICJQaW5JZCI6ICJBQ0tKLUJ
  LQjMtSjc3Qi1HN0haLURGS1MtRTI2TC1OSFhXIiwKICAgICJQaW5XaXRuZXNzIjog
  Imh2Nnh2TlhPc3BBOU1ONFlWa05iNThQNUJ3cjFXQ3k1T0E2Z3RQeHkwTHFQLV9sd
  gogIFJlSFNwMUQ1TXViUHRNWW5yU3JFY0dlYlFyZXZCR0I5Nm5na1pnIiwKICAgIC
  JBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ"
      ],
    "Rights":[
      ]}}
The response payload contains the information the device requires to compute the witness value and to poll for completion. This is a copy of the request acknowledgement and a copy of the profile of the account the device has requested connection to:
{
  "ConnectResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "EnvelopedAcknowledgeConnection":[{
        "EnvelopeId":"MBW3-XXJI-WXLF-QWFQ-TTJ4-EW2D-TXZH",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJIUzIyLVZPNU0tSk
  FHNC1SUVQ0LVJPSFgtUEVSSy1ZWUNXIiwKICAiTWVzc2FnZVR5cGUiOiAiQWNrbm9
  3bGVkZ2VDb25uZWN0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmpl
  Y3QiLAogICJDcmVhdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6NTFaIn0"},
      "ewogICJBY2tub3dsZWRnZUNvbm5lY3Rpb24iOiB7CiAgICAiTWVzc2FnZU
[encoded data, 5525 characters]
  SUVQ0LVJPSFgtUEVSSy1ZWUNXIn19"
      ],
    "EnvelopedProfileAccount":[{
        "EnvelopeId":"MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU1RLUVURUEtSk
  JMMy02VUtFLUxSTlQtREdDMy1PSURGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzoxN1oifQ"},
      "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1BTVEtRVRFQS1KQkwzLTZVS0UtTFJOVC1ER0MzLU9
  JREYiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJuaTg1UWphTTh3VTV2Um9LbXdueEQwRjljNFNLMzAzTWswR2FkNV
  dsSjhoZ0JpWVd3OW9OCiAgem1pMzJzdzhYQW1lcjZVTTBTb1RjMjRBIn19fSwKICA
  gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy
  dmljZVVkZiI6ICJNRFNLLUVVSFMtUVhHRC1MS09GLUFWQzctVjJSSC1MVjZaIiwKI
  CAgICJFc2Nyb3dFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1CWlAtV1pBWi
  1CNktRLU1ZWVAtSDdLRC1WVkJBLTdUNlUiLAogICAgICAiUHVibGljUGFyYW1ldGV
  ycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYi
  OiAiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInRSODVSQ3FXdjgtWDVCazBOV
  TRFVmxqUUZKNTg1Rk5FM1p3eVd6WFNWdEpIaXgwRlo3aloKICBRN3hnOXV1cnc4S0
  9LbDVNMFVXN0xMT0EifX19LAogICAgIkFkbWluaXN0cmF0b3JTaWduYXR1cmUiOiB
  7CiAgICAgICJVZGYiOiAiTUJEVi1YWE5ILTJSVUItUkJNWi01Tkc3LUwzQ0QtM1RI
  ViIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZ
  XlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiUH
  VibGljIjogIkhVd040UlZoR2N6RmxPbTJiRGNldnZWWXlkNmdqZHEzM1FxVjhVcTM
  5ZEdhc1J6UW45X1AKICBWZ0NCUklfOE1qaXZlclRLZGFhRUkzMkEifX19LAogICAg
  IkNvbW1vbkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTURQUi1GSlZXLUdLN
  VotMkxKQS1MTVlWLVhTQ0gtSEUyQyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIj
  ogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJ
  YNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiNTVqVWttcW4zZ3dHMGIySHpEVnUz
  SGxmNXNPNkdnVmxqX3ZhWUZ3QUVrc0RjTXkzd3l2VQogIHd0OW9qa2VVS1Q2MzA0R
  HdmcmgtVXc4QSJ9fX0sCiAgICAiQ29tbW9uQXV0aGVudGljYXRpb24iOiB7CiAgIC
  AgICJVZGYiOiAiTUJWSS1FV0xPLUVJN0otT1ZBSy1HR1pILTZZSFctWkpTVSIsCiA
  gICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RI
  IjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiO
  iAiZlRVM1RlQjEtN0s4U1pwbzR0UXhaUHBKQWItX2QzTklkSmhsa3hXYWlab2dKUk
  VLOWFkUAogIGY5S25zNW1xcjExVVRUb0lNaHpmZEphQSJ9fX0sCiAgICAiQ29tbW9
  uU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1BTVAtQlg0Ry1BS0syLVlIUEEt
  SVhKVi1aMktWLVVYQlciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgI
  CAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLA
  ogICAgICAgICAgIlB1YmxpYyI6ICJZNi1EMkRiYktsYVZYdkc1WlF3ZUxkNV9rUDF
  FQ0FDUjQwYkRtcGctWTRLczkyRk5lLXV5CiAgc1dVck1fTG1RS09JUGpqcjVMOE5P
  QkVBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF",
            "signature":"FOqGS7sd-l-iXeW0NnWOIUbmJxw0SLBHk_F4VYya
  8AIu23JVKebgbH-MtSAK_-0FVuXyWcRUdT8AsHeGljsGe7Y9tN4q_NT8tIASs9ZsZ
  a4HXUyAB3vOzMuSO6wi5bHehc-zWhkEPZhvdiBMcizkODYA"}
          ],
        "PayloadDigest":"pbnx3FGeWuZWOrANRD5vo3UYnkZRpHGmpLwSWVJn
  sNZ4SFe4qVn-hfNrZ557hnJhp4aD7EN2p6B7IVNMmuK_9w"}
      ]}}

Complete
The complete operation is used to complete the binding of a device to the account regardless of whether the operation is initiated by the administration device or the connecting device.
The complete request is made to the service, not the account. The payload specifies the account the device is requesting completion for and the identifier of the completion message.
{
  "CompleteRequest":{
    "AccountAddress":"alice@example.com",
    "ResponseID":"MCXK-BPYI-YM5Y-N4LL-SFZV-FXIC-AHX2"}}
The response payload:
{
  "CompleteResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "EnvelopedRespondConnection":[{
        "EnvelopeId":"MDAB-RJHV-L6YJ-MMJQ-7NMX-KEC3-OV7F",
        "enc":"A256CBC",
        "Salt":"O8Uj4gwarhvGVXtHSZILuw",
        "recipients":[{
            "kid":"MALW-QXX4-IADE-A4ZY-GRFV-7FRV-6NMZ",
            "epk":{
              "PublicKeyECDH":{
                "crv":"X448",
                "Public":"esrl5mubQKc6CuEwUCfddN8mPL6y-Zgbqto_mWt
  RVOCd5aUdaH4GYAs11vS10ghxl0Tx46VA4CqA"}},
            "wmk":"lnwh_VDch144FOT3VBuOr4GqxSKP_ibMl5GzjpsdYnV-DH
  g_RgFEjg"}
          ],
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQ1hLLUJQWUktWU
  01WS1ONExMLVNGWlYtRlhJQy1BSFgyIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVzcG9
  uZENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzo1MloifQ",
        "SequenceInfo":{
          "Index":3,
          "TreePosition":426},
        "Received":"2022-04-20T16:17:52Z"},
      "i2vnt33aAT5G2z1GpX34VU2Za7xBLIuh89Pb2igJgnMreLANZgTCLxeiH7
[encoded data, 33345 characters]
  p_nnhNR-C7yY0kx1Rqmz6DkXcfLrq6lMLWkaClz-8629VKLg",
      {}
      ]}}

Publication
[Future: Consider eliminating this mechanism entirely and instead using messaging flows. The means of achieving this should become better apparent when the problem of publishing large messages via a pull mechanism is considered.]
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. There are two operations:
Claim
Post a claim to a published document
PollClaim
Check to see if a claim has been posted.
Content is published by appending an entry to an account's Publication catalog by means of a Transact operation. 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 catalog 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.
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.

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.
{
  "MessageClaim":{
    "MessageId":"NAFD-ZIB6-VLZD-QO4O-6C5N-YII5-VLJJ",
    "Sender":"alice@example.com",
    "Recipient":"maker@example.com",
    "PublicationId":"EBQL-I4TF-ITF3-X4I3-QCHK-WK32-347R",
    "ServiceAuthenticate":"ADKJ-W4NY-ZRLB-PUSC-3OSI-UADE-SCJW",
    "DeviceAuthenticate":"ADSB-J6YC-B5R6-VJIA-GULG-LZIP-AEUO"}}
The message is signed by the claimant to make a RequestClaim to the service:
{
  "ClaimRequest":{
    "EnvelopedMessageClaim":[{
        "EnvelopeId":"MAPR-DUUH-WNG3-DQCP-6RRB-NCVC-2RM4",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQUZELVpJQjYtVk
  xaRC1RTzRPLTZDNU4tWUlJNS1WTEpKIiwKICAiTWVzc2FnZVR5cGUiOiAiTWVzc2F
  nZUNsYWltIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJD
  cmVhdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6NTdaIn0"},
      "ewogICJNZXNzYWdlQ2xhaW0iOiB7CiAgICAiTWVzc2FnZUlkIjogIk5BRk
  QtWklCNi1WTFpELVFPNE8tNkM1Ti1ZSUk1LVZMSkoiLAogICAgIlNlbmRlciI6ICJ
  hbGljZUBleGFtcGxlLmNvbSIsCiAgICAiUmVjaXBpZW50IjogIm1ha2VyQGV4YW1w
  bGUuY29tIiwKICAgICJQdWJsaWNhdGlvbklkIjogIkVCUUwtSTRURi1JVEYzLVg0S
  TMtUUNISy1XSzMyLTM0N1IiLAogICAgIlNlcnZpY2VBdXRoZW50aWNhdGUiOiAiQU
  RLSi1XNE5ZLVpSTEItUFVTQy0zT1NJLVVBREUtU0NKVyIsCiAgICAiRGV2aWNlQXV
  0aGVudGljYXRlIjogIkFEU0ItSjZZQy1CNVI2LVZKSUEtR1VMRy1MWklQLUFFVU8i
  fX0",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MAMP-BX4G-AKK2-YHPA-IXJV-Z2KV-UXBW",
            "signature":"Fk2oDmBaKXmkf7vnvLHDNH8M6LRYHC1lD6VaypH6
  rgc0_uftuhH12Uitq0fgWMFNbvAyTaSdchKAPizuQisjvI_K5G6VOr8HnTft65UIW
  sFZjsj6vQjVb8j3oa5gCJPFQzbyn9khoO6irBTXGbfIJgAA"}
          ],
        "PayloadDigest":"B8c5TfDXr1GK6CgI8aFEXBWT35NCMN70f3HHreRr
  C5o5dGw04VA8YmUrW4tnSpYdVOBap0tSSQwGV8HnYVkd2w"}
      ]}}
The publication is found and the claim is accepted, the publication is returned in the response.
{
  "ClaimResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "CatalogedPublication":{
      "Id":"EBQL-I4TF-ITF3-X4I3-QCHK-WK32-347R",
      "Authenticator":"ECXL-6FG3-37XK-J6GM-VR2W-4KUI-5BW7-JQRO-CYMW
-PIHF-6FSA-FQ6T-YXKG-K",
      "EnvelopedData":[{
          "enc":"A256CBC",
          "kid":"EBQO-52CW-B4C4-7MLL-5LZT-PJ7Y-Z3O6",
          "Salt":"YwqtqOhssmpR3cH8fZkGYw",
          "recipients":[{
              "kid":"EBQL-I4TF-ITF3-X4I3-QCHK-WK32-347R",
              "wmk":"i0Wx4i67v2s9XeUvtlmgAojKsuBzi_-B4MbLLHhJbVmM
  2FfwzN1YEA"}
            ]},
        "zpvCTGxohUkssrMsznDdzinzW-ioixuVZfdG_XqtFac38vFixkhZbhJH
  xGJIxFGRBOwEzF-rNu9bPHDacsXru3SnkYIQL9jw1Nx2ipOOduys0MijUJ99sUhhm
  JhW8mqzUroU_uh7yum8twTBK71eZIMX3FZxFnse5QeeD1KOadqcDV0hXNi2QAmEvp
  CZNTKiRroE1jxFv9PiVbdvvWXC8eIVTYqHrn3T9edfLxil819vubbDWJXz_DxI6JL
  QCX9MJTnZ7_6_AWBFyi9D3lzKdYOWbsOu8zJGotEpi9YXDGnPOojqmCPdyzEdIsUZ
  JIld_KuOv6fYa4wZ3AlTilSgbmAQG4KMYiV2a8Od0o2Uoqvi8yujAEv5qxl1A1Zk5
  i-K1ZxFHiAw5te9M5eCyEx34AONGIExXegDu1EAg_A14FCKhyKyn6bpvJOjR2RHZh
  84CgwiHZvVEtxTL0nY7r8mghvH3cxTzfW8nF9cS8-MwhhYNSdIXCcGkRl1FhyM5P6
  GRh_RODqm1QmlgBuJjLdaaEHYlaxRBqaT6jI8c2SlvAZAFfn3JxIErLU8r_gTW3G6
  KPn_JUqcRFVlRrQJcV-8uuTn6y7Sdv6RsXnJDQNlE0rAsb6jilU1Z-_CUeX6cTyAl
  UPb-TXlZsjWplTIlSrX65jCYasfcVnrC9ibIiU6zQBxYLOvTdVi6dTiuQ_OHJ8FbB
  mxtHFJwfjxoNqiuemwZ1yC-jGtaaFgDcAjp1i4AHsZSVUHl2f9hbRPWCTB2WlaXy1
  gohp-x_Ft7mUD4JibMjDUPb1Sxjtk5ZAq6bXWnEz7cEDNR8JgujeU_0RukN3CEvWR
  SyQ-6LWX4svntzUcdffqFmD6MjXnNLxkUgG6bBxmc-caUDRGBEHl-UUxzWY30yVXs
  UcEQCg-9bscVIwYgQFzTKAP4zNXH7lUXGM3p7wf9yRs__GYncfVcDGWsemYHFDGp2
  3ApBI9LEUbhR_h-hIBjSEu61cFCzpC5dQsGLIUv8i-J-nWEt7_OWg3he2FgYn5_2-
  IQ4tF9qGnt2v5wfcfIL60B03hSaDIDnrvDFtXqmz8At6fgZOAFYy9IE9TSXLyhZSq
  88c0nq5293Z5kiz_XgneRLAPhWsHMd609AEarSKq9UJQzj4fF32iIj377XZCwOp87
  RFomBwhCXYwloTAeegJwTDfo3hdUdbWl1DPhj4zpO5Vpzsn3zu1qHjBDRCbzeuYg5
  XVoAKX4Oe6uo9H8UlbmEHNG0vEi47ko8HgZ_M41Xz2TGyrsJxKVkhJK7J8_-RQlrx
  BgXr0Lhkhc3fJY7IVPtJCMw5gUpxbfa5cUqRChYx-RLOusz2IUTgc9c0yXWwZiiAG
  pG_oeTBHnp6_U0FxPzIeP3QjhmQpGgDdd2HLnHcGWkEhhpvqbwaSr8USdYRo0t7CH
  C1Fvjjdn0oICdRQyTpT4n6XuDMcs6DLggrW4BnKFUfuYmv6dIg6Q1o3AM9p3W1-zl
  M3AkPguPkRvW-tnrmMy7liUXzCKdd3Vv2-9i7IaiTBQMZYcnrWuRMFdBA6WkJbgnj
  -Od2EgwZ-Dux4aPB1ra53r49wERYxTTrRSQhW9aSQxHM2YRjIK0NolmAn9zLOLtdK
  lepTqmKmXSMLuHosFxMdlHgDUb3rqL_CmIJ8naiprf8juxLWTw6w0OUlNZYTUWf1v
  TRr_VeeXLHU1lL5Ob-nQyQb66UZw2Lh-iP-VdsdJo7juL4-S_uO5g2bYGBklclF7i
  XMOpxxBiZw7wQ4VVz_B_4RV7twqeAbVPkfe8yCgCYCwogy-x-cf6wMbKdq5w9qFWm
  A9dwHFEt7e8eKAqh0PoQKJhSm2e94UL_wEgvdNrTb_fQuGHxKxpM27T8qBQVRzsrz
  -IGwi1MeUS9vM5N3DXnQYj4cO5j5aZSQR37sJfjrtkNC7vNguVDu5PRCcWWCr8J3z
  aJlMW5XaS4QXMEeZzzKYmOr6ZBJ6CAVVwBudsM7M5Y-mc1qAIe6pkUEngLOOP-OBm
  Rt1Oj0ZH0-HlpeRfaB0TBJe67M397xOi9d39uP5CjDUqvTbsQzf7_Kh8BDGxtXjSZ
  UZqGr4UU80x9UuNgmdkLppxz7EjIWQ6qsp9xE9sX9cMxE3uRNlB-xFgRdiEHbbAfj
  cyOr2UUbR4YMrXNDHs5szAMyAXuwJbzDGvlXmDuMyDW4sVstmcuVoRs-uM8Y157o4
  wsg_XbSL5u6H3Z6QXP7vPN6oyHc3lqMkFRU5sHR9zRpgCCSi2YmWU609HGUBPYj1H
  hSi-bkg5T7zA_pnsRWRNIDPSrEHDadXBxs7YDyMxkPQ2ML3j-7zGi8rz46eyV4sAb
  T8xOAiCfzLfjrJtGaXO04PYLXRdxD-bWeTPORtAUIXukkbCoCfMxfDd3JKDR-QvTO
  OUhOTnO-9yWnlJucrFpE5syujJz6awo95ZULiayBGPY0QxnnNOH3CER_cTb7DjSwF
  i_gcTE3q1dtyQAexMj7tj-h30qjEjt3j-72_2pw-gTY_akNJeyc6iTfcJsa4ldI0V
  A_m-ErjTpWA6AkiJ61hfLg4KZai3RiWPQWOHvNGQGX4TC3lCwNto_sJO7vjjKFfEl
  Eb2GuVgiuFcBCcOWBWE9LTBs5EAYNcwCPeG0dXv73GBuTupnJvZWHLhw4lRCV4ju4
  OqhsrkOR7fGnXsPDJrvlrlvYQsJUblfiBjGUN9UJy_Vgd5eAvNWLMonk2oyxpJCXw
  NOO5nNVtzplH3PE1ZzhR_YjbEg1gXUWkPRpETpKMXDfjVe1Y6Wh2x4boRtzRMls_V
  J-Y1yrHSuYex-xOkN0GcEou_0t_gGtHIkjEu1-kIu74osRiEV4cvBQEJH2V1r-B5Q
  VjUmdAVWsODhtp_yH87KYCksKqwYITOIqaUWHUThg-R0tD94urJ0wHFlxNFRcxZvC
  ZKr9EuxtmWQq9lVr9UGQzZqL09-ddnuNru6LFDPgjOT4bfCTy32mtIj7vhwZ47BWm
  4BrOKA0GNghJziGNFXwsZz1ZPjv3Cy_knTA23osoygx6i0khg"
        ]}}}
The device waiting to be connected uses the PollClaim transaction to receive notification of a claim having been posted.

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:
{
  "PollClaimRequest":{
    "PublicationId":"EBQL-I4TF-ITF3-X4I3-QCHK-WK32-347R",
    "TargetAccountAddress":"maker@example.com"}}
The response returns the latest claim made as signed message:
{
  "PollClaimResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "EnvelopedMessage":[{
        "PayloadDigest":"B8c5TfDXr1GK6CgI8aFEXBWT35NCMN70f3HHreRr
  C5o5dGw04VA8YmUrW4tnSpYdVOBap0tSSQwGV8HnYVkd2w",
        "EnvelopeId":"MDLZ-5ED3-2Z6P-XJXW-THGA-Q37Z-F6VL",
        "dig":"S512",
        "signatures":[{
            "alg":"S512",
            "kid":"MAMP-BX4G-AKK2-YHPA-IXJV-Z2KV-UXBW",
            "signature":"Fk2oDmBaKXmkf7vnvLHDNH8M6LRYHC1lD6VaypH6
  rgc0_uftuhH12Uitq0fgWMFNbvAyTaSdchKAPizuQisjvI_K5G6VOr8HnTft65UIW
  sFZjsj6vQjVb8j3oa5gCJPFQzbyn9khoO6irBTXGbfIJgAA"}
          ],
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQUZELVpJQjYtVk
  xaRC1RTzRPLTZDNU4tWUlJNS1WTEpKIiwKICAiTWVzc2FnZVR5cGUiOiAiTWVzc2F
  nZUNsYWltIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJD
  cmVhdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6NTdaIn0",
        "SequenceInfo":{
          "Index":1,
          "TreePosition":0},
        "Received":"2022-04-20T16:17:57Z"},
      "ewogICJNZXNzYWdlQ2xhaW0iOiB7CiAgICAiTWVzc2FnZUlkIjogIk5BRk
  QtWklCNi1WTFpELVFPNE8tNkM1Ti1ZSUk1LVZMSkoiLAogICAgIlNlbmRlciI6ICJ
  hbGljZUBleGFtcGxlLmNvbSIsCiAgICAiUmVjaXBpZW50IjogIm1ha2VyQGV4YW1w
  bGUuY29tIiwKICAgICJQdWJsaWNhdGlvbklkIjogIkVCUUwtSTRURi1JVEYzLVg0S
  TMtUUNISy1XSzMyLTM0N1IiLAogICAgIlNlcnZpY2VBdXRoZW50aWNhdGUiOiAiQU
  RLSi1XNE5ZLVpSTEItUFVTQy0zT1NJLVVBREUtU0NKVyIsCiAgICAiRGV2aWNlQXV
  0aGVudGljYXRlIjogIkFEU0ItSjZZQy1CNVI2LVZKSUEtR1VMRy1MWklQLUFFVU8i
  fX0",
      {}
      ]}}

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 Access catalog, the request MUST meet the authentication criteria specified by the catalog entry. These typically include the request being authenticated by a specific key.Key Agreement
CryptographicOperationKeyAgreement is used to request a threshold key agreement operation on a specified public key.
Alice added Bob to groupw@example.com as a member. This resulted in Bob receiving the invitation described in section ??? and the following access entry being added to the Access catalog of the group account:
{
  "CatalogedAccess":{
    "Capability":{
      "CapabilityDecryptServiced":{
        "Id":"MAPK-LBYY-2G6S-7Y2F-7KWO-KZQC-2IEW",
        "Active":true,
        "GranteeUdf":"bob@example.com",
        "EnvelopedKeyShare":[{
            "enc":"A256CBC",
            "kid":"EBQA-LO4N-N2FL-U23L-SKWO-POAW-VDLW",
            "Salt":"FXW3PsFesjcC6fDC3dHHMg",
            "recipients":[{
                "kid":"MAJY-65KP-C67E-LFXP-Q3XI-ZHZF-GNHV",
                "epk":{
                  "PublicKeyECDH":{
                    "crv":"X448",
                    "Public":"CcZftsANqPybF3CXKG4neCPC5mLKeBaFIwv
  tkGBThR8QlqtAp0Gr-XevcrOlbqxhKP2kfxQQyxuA"}},
                "wmk":"VAR6_ezf8hgETm61CJ4CUOw66l_f8YKwG65_GYE96W
  5b_VeZNoOiHQ"}
              ],
            "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJLZXlEYX
  RhIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmVhdGV
  kIjogIjIwMjItMDQtMjBUMTY6MTc6NDlaIn0"},
          "5HYVc-1SfcKj29O6UyNv_CptjRl-gy3hjp42VUdTi032r7Yamt4xmE
  hByPQgpVetmoFayOWc9V8GILPMbrQ8LO8OwHD35Fio_OfX1PLe8or5AuBylbF9y9f
  3S25QD9WupYJJN0L2m8hbia3LLbU-BcVSrmI0OjB7tkeEgp6vmboTGv9QQxSSrMTQ
  5v8Le6dtJhuUqwyj7JJA76oBWk8ZzibJ6hQLT1v5owABTPMxq1fGNRv2RgDtz4tpy
  deUBq5Gp9B0WKSKBCfOGFzNcunXbA5AbXWkORK4s07fZ42EsWiwkrncFRQqKTvomX
  37CHtJo4kJkoyhbQWAwcLHaeo5DQrWBHJq6p2evWH4Z0gW_ZB9f3UiuW3jEOj-wvG
  mYI5Mfo0Y5YEqy8iuOmo2KI3qDTAfWE_PID-4V2IWKhGibz7mqOy8pFMBUZXySwmY
  w-M8Wti61wlST10kPaivW-0hS86MWGYlfzrVP3GqWkqNfHBuI-1iHwe3nNz2npsI0
  Z3QnYr5VB-Q-ifkQZrYiTkPLKNAf_rR0-2le4lVBMasJJpk3cISt2V27RqxglrzX4
  nSh0abD-7jBuAr-h7dH4abak2zkcQWqqe1bVjSfQ8OS6on4auWb4ZmJHY_cBCz3Br
  wTer6j-0r1UWTtQg0V4SuEDLaR0VCqrQhiLgEdLENBzESJqa1x0vQHQeciteoBDa_
  CdQCdzPUYycikRI778ElNg"
          ]}}}}
The private key (in this case a key share) is encrypted under the service key.
To make use of the access entry, a request is made that specifies the key share to be operated on and the public key parameters to perform the agreement with.
The request payload:
{
  "OperateRequest":{
    "AccountAddress":"groupw@example.com",
    "Operations":[{
        "CryptographicOperationKeyAgreement":{
          "KeyId":"MAPK-LBYY-2G6S-7Y2F-7KWO-KZQC-2IEW",
          "PublicKey":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"7BkA7YrtcC7GrNRvyX0es1xOgNeUmSPFgLPsK8Xy-
  y8kaCqguTYD4BzWGBZi5a6KafeQQV6DwKcA"}}}}
      ]}}
The service checks to see if the request is authorized and if so, performs the operation and returns the result:
{
  "OperateResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "Results":[{
        "CryptographicResultKeyAgreement":{
          "KeyAgreement":{
            "KeyAgreementECDH":{
              "Curve":"X448",
              "Result":"RK_nkdnG2HF8Xm79VfrFpufigvIldNPo16ZIFf4-E
  GJaqRaHIBNVbDs-bTfS30FuJkadIzvfzQwA"}}}}
      ]}}
Future: Currently, the access catalog is encrypted under the service encryption key. It would be better to encrypt the catalog under an encryption key specified by the service during the process of account binding. This would allow a service to assign a unique encryption key to each account and limit access to that key to the hosts servicing that specific account.

Generate Key Shares
Generation of threshold key shares is planned but not currently supported.

Threshold Sign
Threshold signature is planned but not currently supported.

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.
The Mesh Four Corner Messaging Model

B

M

P

M

P

A

e

l

i

c

e
  '

s

b
  '

l

B

o

c

o

A

s

S

S

i

b

The Post transaction is only used to exchange messages between services. The client sends and receives messages through interactions with the outbound and inbound spools of the account.

Sender.
To send a message, the client creates the Mesh Message structure, encapsulates it in a DARE Message and appends the message to the Outbound spool of the account using the Transact operation..
The DARE Message MUST be signed under the account signature key.
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.

Outbound Service
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.
>>>> Unfinished ProtocolPostServiceService
[Not Yet Implemented]
After the message has been sent, the service updates the message status on the outbound spool.
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 taking 4 seconds or more, this indicates that the number of simultaneous transfers being attempted should be reduced. Contrawise, if 90% are completed in less than a second, the number of threads allocated to sending outbound messages might be increased.

Inbound Service
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.

Recipient
Messages are received by synchronizing the outbound spool.

Access Control
[This section to be expanded in future drafts]
Access control is effected through the usual division of authentication and authorization.
Authentication of operation requests is performed by the RUD layer [draft-hallambaker-mesh-rud] .

Direct authorization
Any request authenticated under the profile authentication key is authorized to perform any account operation without restriction.

Access Catalog authentication
If the authentication key presented has a matching Access Catalog entry, the device is authorized to perform operations as specified in that entry.

Message Interactions
Message interactions are asynchronous interactions that occur between devices connected to the same account or between accounts.
All messages are signed by the sender and encrypted under the encryption key of the recipient if this is known to the sender.

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].

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.
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.

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.

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.
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.

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. The message specifies the salted pin value used to verify attempts to use the PIN, the action for which it is authorized. Since this PIN has been issued to authorize a device connection, the roles for which the device are authorized as well. This allows the connection request to be accepted without asking for further input from the user.
{
  "MessagePin":{
    "MessageId":"ACKJ-BKB3-J77B-G7HZ-DFKS-E26L-NHXW",
    "Account":"alice@example.com",
    "Expires":"2022-04-21T16:17:50Z",
    "Automatic":true,
    "SaltedPin":"AAV6-EBKF-JIUO-B2UV-UQX7-OKHB-OAAX",
    "Action":"Device",
    "Roles":["threshold"
      ]}}

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.
{
  "MessageComplete":{
    "MessageId":"NDM2-SXYM-M65H-CDTB-ROIB-KTKW-IN4R",
    "References":[{
        "MessageId":"ACKJ-BKB3-J77B-G7HZ-DFKS-E26L-NHXW",
        "ResponseId":"MCXK-BPYI-YM5Y-N4LL-SFZV-FXIC-AHX2",
        "Relationship":"Closed"}
      ]}}
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.

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.
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.

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":"NBBX-LUP5-63JW-AJ6G-5UFG-TYWA-Y6IY",
    "Sender":"bob@example.com",
    "Recipient":"alice@example.com",
    "AuthenticatedData":[{
        "dig":"S512",
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250YWN0UG
  Vyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmV
  hdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6MzFaIn0"},
      "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBbewogIC
[encoded data, 4550 characters]
  ICAgICAgICAiUHJvdG9jb2wiOiAibW1tIn1dfV19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MAIY-DC6G-CGKH-H3GN-BL2N-GHVN-5HTG",
            "signature":"yWGvlnNlKnAHGDTgYMZtYe_mGvnmnzupiMneOegh
  KkOW6hZf-vkTR6AkBhmwM7PZH5xlVpdUe00AHIi0ie7deWnL6K5bEhhLiBBGY_ScB
  aVAVqWAkbrfSYehAWvfvCIPyZKzFQYIZ9no0WjGcA-9dSAA"}
          ],
        "PayloadDigest":"eq6Tg7DxnJr8SUf0nchazBLn3FBsYWLvZlAbxW2x
  a_FsQ2kkhx5C8NymLau-Hg9_UaP1NM0eS9Nw2CRRcObbpw"}
      ],
    "Reply":true,
    "Subject":"alice@example.com",
    "PIN":"ADFZ-RDXJ-IICY-KX57-X6LH-ABQY-IBKQ"}}
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.

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.

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.

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.
>>>> Unfinished ProtocolGroupInvite
Missing example 12

Confirmation Interaction
The confirmation interaction consists of a RequestConfirmation message from the initiator followed by a ResponseConfirmation from the responder.
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":"NDBB-CHFG-OWNI-2WWK-RJI2-KMF7-6AW7",
    "Sender":"console@example.com",
    "Recipient":"alice@example.com",
    "Text":"start"}}
Alice accepts the request and returns the following response:
{
  "ResponseConfirmation":{
    "MessageId":"MBO5-GGWR-XOSQ-M6AO-WRP7-CJWT-V6LN",
    "Sender":"alice@example.com",
    "Recipient":"console@example.com",
    "Request":[{
        "EnvelopeId":"MAWU-5FMM-ZN6O-FXE5-TVC4-LO6I-RJ4D",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOREJCLUNIRkctT1
  dOSS0yV1dLLVJKSTItS01GNy02QVc3IiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbmZpcm1hdGlvbiIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0
  IiwKICAiQ3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjM5WiJ9",
        "SequenceInfo":{
          "Index":7,
          "TreePosition":6201},
        "Received":"2022-04-20T16:17:39Z"},
      "ewogICJSZXF1ZXN0Q29uZmlybWF0aW9uIjogewogICAgIk1lc3NhZ2VJZC
  I6ICJOREJCLUNIRkctT1dOSS0yV1dLLVJKSTItS01GNy02QVc3IiwKICAgICJTZW5
  kZXIiOiAiY29uc29sZUBleGFtcGxlLmNvbSIsCiAgICAiUmVjaXBpZW50IjogImFs
  aWNlQGV4YW1wbGUuY29tIiwKICAgICJUZXh0IjogInN0YXJ0In19",
      {}
      ],
    "Accept":true}}

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.
Four connection interactions are currently defined support connection of devices with different 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.
PIN Authenticated
A variation of the Witness Authenticated interaction in which the connection process is initiated by creating a PIN value which is communicated to the device by some out of band means and used to authenticate the connection request.
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. Implementation of this mechanism is identical to the PIN authenticated scheme except that the PIN code is presented to the connecting device by means of a QR code.
Preconfigured (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.
- 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 in [draft-hallambaker-mesh-schema]. 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.

Witness/PIN Authenticated
The witness authenticated, PIN authenticated, and Dynamic QR code interactions all follow a common interaction pattern.
The Dynamic QR Code (PIN) Authenticated interaction comprises four phases as follows:
Phase 1: Issue of PIN credential (PIN and Dynamic QR code only)
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. In the case of the Dynamic QR code interaction, this is a QR code that is scanned by the connecting device.
Phase 2: Onboarding Device Request to Service
The onboarding device creates a RequestConnect message. In the PIN authenticated and Dynamic QR Code interactions, the RequestConnect is authenticated by the Device Authentication key and the PIN issued earlier. In the Witness Authenticated interaction, it is authenticated by the Device Authentication key alone.
The onboarding device presents the RequestConnect message to the service by means of a Connect operation to the service 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 and returned to the connecting device.
Phase 3: Administration Device Acceptance
The account holder authenticates RequestConnect message and uses an administrative device to accept or reject the connection request.
If the RequestConnect message has been authenticated by a PIN code, the connection request can be accepted automatically without additional user interaction.
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 $$$$.
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.

Phase 1:
Alice> meshman account pin /threshold
PIN=ADFR-TEQU-3HJD-IRND-P4TS-CRBD-NI
 (Expires=2022-04-21T16:17:50Z)

The registration of this PIN value was shown earlier in section $$$
The URI containing the account address and PIN is:
mcu://alice@example.com/ADFR-TEQU-3HJD-IRND-P4TS-CRBD-NI

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> meshman device request alice@example.com /pin ^
    ADFR-TEQU-3HJD-IRND-P4TS-CRBD-NI
   Device UDF = MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD
   Witness value = HS22-VO5M-JAG4-RQT4-ROHX-PERK-YYCW

The device generates a RequestConnect message as follows:
{
  "RequestConnection":{
    "MessageId":"NCAA-7UYA-TG2C-6XUC-UG3B-4XGT-OBIE",
    "AuthenticatedData":[{
        "EnvelopeId":"MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQUEzLUJRUFotV1
  dPNC03UTVCLVA3QUgtRlk1Qy1BVE1EIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjUxWiJ9"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm
  UiOiB7CiAgICAgICJVZGYiOiAiTUFBMy1CUVBaLVdXTzQtN1E1Qi1QN0FILUZZNUM
  tQVRNRCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs
  aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI
  CAiUHVibGljIjogIkU1ZUs0cUkzTVlCeDV4cHR6Y254cEhabnZNQWpTbnJIRjhBbm
  J5cE4tWTZpZlVHblNfTlQKICBfaXFacmdteURLRERDaUFXSkU0R3A4VUEifX19LAo
  gICAgIkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUFMVy1RWFg0LUlBREUt
  QTRaWS1HUkZWLTdGUlYtNk5NWiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjoge
  wogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYND
  Q4IiwKICAgICAgICAgICJQdWJsaWMiOiAiWUZ3WmJ6RkNwcmxETk5qSkVsOE5iUDl
  BcVZlNjQzQm1OTkF1b2tIRXVHejFWXzYwVHFyUAogIEU3WVktQlZBTU81Uk1PcUR3
  R3U3WF9xQSJ9fX0sCiAgICAiU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1CS
  zUtSVI0Uy0yR0tWLUZIUlctQkZJNS1SUFJFLUVGT0UiLAogICAgICAiUHVibGljUG
  FyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICA
  gICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICIwNW5DWExwSjl1
  Njh3Q2t1dTRKWjVxTzR0d0o3cTVjaWdPOEJxZzNzX2Z2cXZLcl9SeVk2CiAgMW53Z
  2pIS2FzZ09wWWFxY0RXczY4eWdBIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IH
  sKICAgICAgIlVkZiI6ICJNRFdMLVNMNEItS1dDVy1XM1hVLTZJS1otUUZPVS1BRVd
  aIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl
  eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1Y
  mxpYyI6ICJ0dTc0QVZLYUp1ZGRmM1JEcmZ0aWI0a2VtOVN4MGE3czAtQXVKUzNRbE
  hIc1d6VllWTmZKCiAgR0c3WF9NN1dKRlpEaFQxTjU0YUU4ZFdBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD",
            "signature":"vOufdCB_9HT6I8aarXvmmOyNSl-w-xyJ9lDjAEE7
  76793vl1LkEFYsB5bh6ydW6itfx7wtyI5h2AYah4BosKBPeG5qfIVX0bD_BHzH3wm
  _pYThtpZRGUd_CLlGIyqZi-dj6pra-RatoCDbBdKIgPCTIA"}
          ],
        "PayloadDigest":"lrcVgAlxiwM7iaclmB4lQO-d1qIYWoilGa2AnxAq
  VJOSNHtc8NDZnGwUyg6b6lZlzoVgQRNgOdGQaVqW6sNf1Q"}
      ],
    "ClientNonce":"gZFH1LZNoACm0-x0tg28yA",
    "PinId":"ACKJ-BKB3-J77B-G7HZ-DFKS-E26L-NHXW",
    "PinWitness":"hv6xvNXOspA9MN4YVkNb58P5Bwr1WCy5OA6gtPxy0LqP-_l
  vReHSp1D5MubPtMYnrSrEcGebQrevBGB96ngkZg",
    "AccountAddress":"alice@example.com"}}
The service receives the conenct request and authenticates the message under the device key. The service cannot authenticate the message under the PIN code because that is not know to the service as the service cannot decrypt the local spool.
Having authenticated the connect request, the service generates a random nonce value. The random nonce together with the device and account profiles are used to calculate the witness value.
The AcknowledgeConnection message is created by the service:
{
  "AcknowledgeConnection":{
    "MessageId":"HS22-VO5M-JAG4-RQT4-ROHX-PERK-YYCW",
    "EnvelopedRequestConnection":[{
        "EnvelopeId":"MBHZ-QYVP-T5DQ-FQAP-AWD4-FLMO-ZZJT",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQ0FBLTdVWUEtVE
  cyQy02WFVDLVVHM0ItNFhHVC1PQklFIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzo1MVoifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi
  AiTkNBQS03VVlBLVRHMkMtNlhVQy1VRzNCLTRYR1QtT0JJRSIsCiAgICAiQXV0aGV
  udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1BQTMtQlFQ
  Wi1XV080LTdRNUItUDdBSC1GWTVDLUFUTUQiLAogICAgICAgICJkaWciOiAiUzUxM
  iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk
  NJNklDSk5RVUV6TFVKUlVGb3RWMWRQTkMwCiAgM1VUVkNMVkEzUVVndFJsazFReTF
  CVkUxRUlpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk
  bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV
  04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeUxUQTBMVEl3VkRFMk9qRT
  NPalV4V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V
  3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK
  VlpHWWlPaUFpVFVGQk15MUNVVkJhTFZkWFR6UXROCiAgMUUxUWkxUU4wRklMVVpaT
  lVNdFFWUk5SQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC
  BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F
  nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli
  R2xqSWpvZ0lrVTFaVXMwY1VrelRWbENlRFY0Y0hSCiAgNlkyNTRjRWhhYm5aTlFXc
  FRibkpJUmpoQmJtSjVjRTR0V1RacFpsVkhibE5mVGxRS0lDQmZhWEZhY21kdGUKIC
  BVUkxSRVJEYVVGWFNrVTBSM0E0VlVFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI
  yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVUZNVnkxUldGZzBMVWxCUkVV
  dFFUUmFXUzFIVWtaV0xUZEdVbFl0Tms1TldpSXNDCiAgaUFnSUNBZ0lDSlFkV0pzY
  VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC
  BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F
  nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpV1VaM1dtSjZSa053Y214RVRrNXFT
  a1ZzT0U1aVVEbEJjVlpsTmpRelFtMU9Ua0YxYjJ0CiAgSVJYVkhlakZXWHpZd1ZIR
  nlVQW9nSUVVM1dWa3RRbFpCVFU4MVVrMVBjVVIzUjNVM1dGOXhRU0o5Zlgwc0MKIC
  BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQ1N
  6VXRTVkkwVXkweVIwdAogIFdMVVpJVWxjdFFrWkpOUzFTVUZKRkxVVkdUMFVpTEFv
  Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS
  UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC
  BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSXdOVzV
  EV0V4d1NqbDFOamgzUQogIDJ0MWRUUktXalZ4VHpSMGQwbzNjVFZqYVdkUE9FSnha
  ek56WDJaMmNYWkxjbDlTZVZrMkNpQWdNVzUzWjJwCiAgSVMyRnpaMDl3V1dGeFkwU
  lhjelk0ZVdkQkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC
  BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJGZE1MVk5NTkVJdFMxZERWeTFYTTFoVkx
  UWkpTMW90VVVaUFZTMQogIEJSVmRhSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G
  dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT
  2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC
  BnSUNBZ0lsQjFZbXhwWXlJNklDSjBkVGMwUVZaTFlVcDFaR1JtTTFKRWNtWjBhV0k
  wYTJWdE9WTjRNR0UzYwogIHpBdFFYVktVek5SYkVoSWMxZDZWbGxXVG1aS0NpQWdS
  MGMzV0Y5Tk4xZEtSbHBFYUZReFRqVTBZVVU0WkZkCiAgQkluMTlmWDE5IiwKICAgI
  CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC
  JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQUEzLUJRUFotV1dPNC03UTVCLVA
  3QUgtRlk1Qy1BVE1EIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICJ2T3VmZENC
  XzlIVDZJOGFhclh2bW1PeU5TbC13LXh5SjlsRGpBRUU3NzY3OTN2bDFMCiAga0VGW
  XNCNWJoNnlkVzZpdGZ4N3d0eUk1aDJBWWFoNEJvc0tCUGVHNXFmSVZYMGJEX0JIek
  gzd21fcFlUaHQKICBwWlJHVWRfQ0xsR0l5cVppLWRqNnByYS1SYXRvQ0RiQmRLSWd
  QQ1RJQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJscmNWZ0FseGl3TTdp
  YWNsbUI0bFFPLWQxcUlZV29pbEdhMkFueEFxVkpPU04KICBIdGM4TkRabkd3VXlnN
  mI2bFpsem9WZ1FSTmdPZEdRYVZxVzZzTmYxUSJ9XSwKICAgICJDbGllbnROb25jZS
  I6ICJnWkZIMUxaTm9BQ20wLXgwdGcyOHlBIiwKICAgICJQaW5JZCI6ICJBQ0tKLUJ
  LQjMtSjc3Qi1HN0haLURGS1MtRTI2TC1OSFhXIiwKICAgICJQaW5XaXRuZXNzIjog
  Imh2Nnh2TlhPc3BBOU1ONFlWa05iNThQNUJ3cjFXQ3k1T0E2Z3RQeHkwTHFQLV9sd
  gogIFJlSFNwMUQ1TXViUHRNWW5yU3JFY0dlYlFyZXZCR0I5Nm5na1pnIiwKICAgIC
  JBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ"
      ],
    "ServerNonce":"TxNcq2rNIK8BgGbwmyCcBw",
    "Witness":"HS22-VO5M-JAG4-RQT4-ROHX-PERK-YYCW"}}
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.
The device generates the witness value, verifies it against the value provided by the server and presents it to the user as seen in the console example above.

Phase 3:
The user synchronizes their pending messages:
Alice> meshman message pending
MessageID: HS22-VO5M-JAG4-RQT4-ROHX-PERK-YYCW
        Connection Request::
        MessageID: HS22-VO5M-JAG4-RQT4-ROHX-PERK-YYCW
        To:  From:
        Device:  MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD
        Witness: HS22-VO5M-JAG4-RQT4-ROHX-PERK-YYCW
MessageID: NDBB-CHFG-OWNI-2WWK-RJI2-KMF7-6AW7
        Confirmation Request::
        MessageID: NDBB-CHFG-OWNI-2WWK-RJI2-KMF7-6AW7
        To: alice@example.com From: console@example.com
        Text: start
Alice> meshman account sync /auto

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.
Bug: This command is currently showing superflous pending messages due to the failure to clear messages processed in earlier examples.
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.
This is returned to the onboarding device by wrapping it in a RespondConnection message posted to the local spool of the account.
{
  "RespondConnection":{
    "MessageId":"MCXK-BPYI-YM5Y-N4LL-SFZV-FXIC-AHX2",
    "Result":"Accept",
    "CatalogedDevice":{
      "DeviceUdf":"MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD",
      "EnvelopedProfileUser":[{
          "EnvelopeId":"MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF",
          "dig":"S512",
          "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU1RLUVURUEt
  SkJMMy02VUtFLUxSTlQtREdDMy1PSURGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZ
  mlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIk
  NyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzoxN1oifQ"},
        "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJl
  IjogewogICAgICAiVWRmIjogIk1BTVEtRVRFQS1KQkwzLTZVS0UtTFJOVC1ER0MzL
  U9JREYiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibG
  ljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICA
  gIlB1YmxpYyI6ICJuaTg1UWphTTh3VTV2Um9LbXdueEQwRjljNFNLMzAzTWswR2Fk
  NVdsSjhoZ0JpWVd3OW9OCiAgem1pMzJzdzhYQW1lcjZVTTBTb1RjMjRBIn19fSwKI
  CAgICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2
  VydmljZVVkZiI6ICJNRFNLLUVVSFMtUVhHRC1MS09GLUFWQzctVjJSSC1MVjZaIiw
  KICAgICJFc2Nyb3dFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1CWlAtV1pB
  Wi1CNktRLU1ZWVAtSDdLRC1WVkJBLTdUNlUiLAogICAgICAiUHVibGljUGFyYW1ld
  GVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcn
  YiOiAiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInRSODVSQ3FXdjgtWDVCazB
  OVTRFVmxqUUZKNTg1Rk5FM1p3eVd6WFNWdEpIaXgwRlo3aloKICBRN3hnOXV1cnc4
  S09LbDVNMFVXN0xMT0EifX19LAogICAgIkFkbWluaXN0cmF0b3JTaWduYXR1cmUiO
  iB7CiAgICAgICJVZGYiOiAiTUJEVi1YWE5ILTJSVUItUkJNWi01Tkc3LUwzQ0QtM1
  RIViIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWN
  LZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAi
  UHVibGljIjogIkhVd040UlZoR2N6RmxPbTJiRGNldnZWWXlkNmdqZHEzM1FxVjhVc
  TM5ZEdhc1J6UW45X1AKICBWZ0NCUklfOE1qaXZlclRLZGFhRUkzMkEifX19LAogIC
  AgIkNvbW1vbkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTURQUi1GSlZXLUd
  LNVotMkxKQS1MTVlWLVhTQ0gtSEUyQyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJz
  IjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6I
  CJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiNTVqVWttcW4zZ3dHMGIySHpEVn
  UzSGxmNXNPNkdnVmxqX3ZhWUZ3QUVrc0RjTXkzd3l2VQogIHd0OW9qa2VVS1Q2MzA
  0RHdmcmgtVXc4QSJ9fX0sCiAgICAiQ29tbW9uQXV0aGVudGljYXRpb24iOiB7CiAg
  ICAgICJVZGYiOiAiTUJWSS1FV0xPLUVJN0otT1ZBSy1HR1pILTZZSFctWkpTVSIsC
  iAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0
  RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWM
  iOiAiZlRVM1RlQjEtN0s4U1pwbzR0UXhaUHBKQWItX2QzTklkSmhsa3hXYWlab2dK
  UkVLOWFkUAogIGY5S25zNW1xcjExVVRUb0lNaHpmZEphQSJ9fX0sCiAgICAiQ29tb
  W9uU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1BTVAtQlg0Ry1BS0syLVlIUE
  EtSVhKVi1aMktWLVVYQlciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICA
  gICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgi
  LAogICAgICAgICAgIlB1YmxpYyI6ICJZNi1EMkRiYktsYVZYdkc1WlF3ZUxkNV9rU
  DFFQ0FDUjQwYkRtcGctWTRLczkyRk5lLXV5CiAgc1dVck1fTG1RS09JUGpqcjVMOE
  5PQkVBIn19fX19",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF",
              "signature":"FOqGS7sd-l-iXeW0NnWOIUbmJxw0SLBHk_F4VY
  ya8AIu23JVKebgbH-MtSAK_-0FVuXyWcRUdT8AsHeGljsGe7Y9tN4q_NT8tIASs9Z
  sZa4HXUyAB3vOzMuSO6wi5bHehc-zWhkEPZhvdiBMcizkODYA"}
            ],
          "PayloadDigest":"pbnx3FGeWuZWOrANRD5vo3UYnkZRpHGmpLwSWV
  JnsNZ4SFe4qVn-hfNrZ557hnJhp4aD7EN2p6B7IVNMmuK_9w"}
        ],
      "EnvelopedProfileDevice":[{
          "EnvelopeId":"MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD",
          "dig":"S512",
          "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQUEzLUJRUFot
  V1dPNC03UTVCLVA3QUgtRlk1Qy1BVE1EIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZ
  mlsZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKIC
  AiQ3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjUxWiJ9"},
        "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1
  cmUiOiB7CiAgICAgICJVZGYiOiAiTUFBMy1CUVBaLVdXTzQtN1E1Qi1QN0FILUZZN
  UMtQVRNRCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdW
  JsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICA
  gICAiUHVibGljIjogIkU1ZUs0cUkzTVlCeDV4cHR6Y254cEhabnZNQWpTbnJIRjhB
  bmJ5cE4tWTZpZlVHblNfTlQKICBfaXFacmdteURLRERDaUFXSkU0R3A4VUEifX19L
  AogICAgIkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUFMVy1RWFg0LUlBRE
  UtQTRaWS1HUkZWLTdGUlYtNk5NWiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjo
  gewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJY
  NDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiWUZ3WmJ6RkNwcmxETk5qSkVsOE5iU
  DlBcVZlNjQzQm1OTkF1b2tIRXVHejFWXzYwVHFyUAogIEU3WVktQlZBTU81Uk1PcU
  R3R3U3WF9xQSJ9fX0sCiAgICAiU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1
  CSzUtSVI0Uy0yR0tWLUZIUlctQkZJNS1SUFJFLUVGT0UiLAogICAgICAiUHVibGlj
  UGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgI
  CAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICIwNW5DWExwSj
  l1Njh3Q2t1dTRKWjVxTzR0d0o3cTVjaWdPOEJxZzNzX2Z2cXZLcl9SeVk2CiAgMW5
  3Z2pIS2FzZ09wWWFxY0RXczY4eWdBIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6
  IHsKICAgICAgIlVkZiI6ICJNRFdMLVNMNEItS1dDVy1XM1hVLTZJS1otUUZPVS1BR
  VdaIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
  tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB
  1YmxpYyI6ICJ0dTc0QVZLYUp1ZGRmM1JEcmZ0aWI0a2VtOVN4MGE3czAtQXVKUzNR
  bEhIc1d6VllWTmZKCiAgR0c3WF9NN1dKRlpEaFQxTjU0YUU4ZFdBIn19fX19",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD",
              "signature":"vOufdCB_9HT6I8aarXvmmOyNSl-w-xyJ9lDjAE
  E776793vl1LkEFYsB5bh6ydW6itfx7wtyI5h2AYah4BosKBPeG5qfIVX0bD_BHzH3
  wm_pYThtpZRGUd_CLlGIyqZi-dj6pra-RatoCDbBdKIgPCTIA"}
            ],
          "PayloadDigest":"lrcVgAlxiwM7iaclmB4lQO-d1qIYWoilGa2Anx
  AqVJOSNHtc8NDZnGwUyg6b6lZlzoVgQRNgOdGQaVqW6sNf1Q"}
        ],
      "EnvelopedConnectionAddress":[{
          "dig":"S512"},
        "e7QRQ29ubmVjdGlvbkFkZHJlc3N7tA5BdXRoZW50aWNhdGlvbnu0EFB1
  YmxpY1BhcmFtZXRlcnN7tA1QdWJsaWNLZXlFQ0RIe7QDY3J2gARYNDQ4tAZQdWJsa
  WOIOSNDtOvoZdilp0s3BTEoNwiSeNFDS6fgsm1L562PMYIp9BvcFfw3bmZ5u3e56H
  OMu23pigwo4Xw5AH19fbQHQWNjb3VudIARYWxpY2VAZXhhbXBsZS5jb219fQ",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBDV-XXNH-2RUB-RBMZ-5NG7-L3CD-3THV",
              "signature":"lOsc7e_m2hYgaUEGWInfYztPwhpICudfCGR1H2
  UpRV0KH0SwVpYTnIWX-IuYXMo995PmWEDtYUiAjNmxO-rcC2BhHIW_BGU4YAtVZI8
  cNAgvHOFmDe_wHzEoHce8OruvdQ-lbcZd_fuVjkdHundi1h4A"}
            ]}
        ],
      "EnvelopedConnectionService":[{
          "dig":"S512",
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0
  aW9uU2VydmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKI
  CAiQ3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjUyWiJ9"},
        "e7QRQ29ubmVjdGlvblNlcnZpY2V7tA5BdXRoZW50aWNhdGlvbnu0A1Vk
  ZoAiTUQ0TS1FTEozLUVNN0ItVlZGRC1KRFBCLTdHT1AtT1FJS7QQUHVibGljUGFyY
  W1ldGVyc3u0DVB1YmxpY0tleUVDREh7tANjcnaABFg0NDi0BlB1YmxpY4g5I0O06-
  hl2KWnSzcFMSg3CJJ40UNLp-CybUvnrY8xgin0G9wV_DduZnm7d7noc4y7bemKDCj
  hfDkAfX19fX0",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBDV-XXNH-2RUB-RBMZ-5NG7-L3CD-3THV",
              "signature":"wzlcBCqylNLld9M66FWuY2qaUmUarO7Yam6ERb
  iZ0A-Ugo4CALcEVTKLkM8TCy1wApS4mtYJaYAALgDjm-swIPwu2XW1yBWJG-RnLEQ
  ydgSh6d0q6Rt3owHgYKDtzrSiJ_byiDUC7BtdDgz9RSqkbQ8A"}
            ],
          "PayloadDigest":"vYf454z3M4ZljOqIwzvMaVDSbyD-kQ3FZJRD6C
  T_oYFy7fryxi-JQTp9rWU2h8UcsjgA1VS8jeF7ZY3cjYl2Uw"}
        ],
      "EnvelopedConnectionDevice":[{
          "dig":"S512",
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0
  aW9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogI
  CJDcmVhdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6NTJaIn0"},
        "e7QQQ29ubmVjdGlvbkRldmljZXu0DkF1dGhlbnRpY2F0aW9ue7QDVWRm
  gCJNRDRNLUVMSjMtRU03Qi1WVkZELUpEUEItN0dPUC1PUUlLtBBQdWJsaWNQYXJhb
  WV0ZXJze7QNUHVibGljS2V5RUNESHu0A2NydoAEWDQ0OLQGUHVibGljiDkjQ7Tr6G
  XYpadLNwUxKDcIknjRQ0un4LJtS-etjzGCKfQb3BX8N25mebt3uehzjLtt6YoMKOF
  8OQB9fX20BVJvbGVzW4AJdGhyZXNob2xkXbQJU2lnbmF0dXJle7QDVWRmgCJNQkFD
  LTVSVU4tNVpZSC1CWVJILVJGTE0tT01NSi1ZTUZStBBQdWJsaWNQYXJhbWV0ZXJze
  7QNUHVibGljS2V5RUNESHu0A2NydoAFRWQ0NDi0BlB1YmxpY4g5qTxrxXDgAwIc2r
  ULk3yjVLsqjDv6cd3CoPyhfB2g2yS9mG2BYN3cHptX-5wjgPksRW2lrLGSt2UAfX1
  9tApFbmNyeXB0aW9ue7QDVWRmgCJNQllQLTJRTkctSUkzNC1NVkJKLUUzREQtSk1V
  Uy1LUlUztBBQdWJsaWNQYXJhbWV0ZXJze7QNUHVibGljS2V5RUNESHu0A2NydoAEW
  DQ0OLQGUHVibGljiDn4tysVgdXulShZAzpKeVaEPT6YI9YrlRwCMN0xnx8czTX8Zx
  73E6j5muo-DFWjZRmvT5f_Ma-m_YB9fX19fQ",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBDV-XXNH-2RUB-RBMZ-5NG7-L3CD-3THV",
              "signature":"xm5EIDcUvKJkP3cpdiV85mPygKSW4C_4P440Fw
  oOgzA-Y1IPxh1n_uYmx1Rr6FH7SrTDAZgkgcQAIl17pmwnTt6z-14iolJjKanphGO
  W9ukYzFqJhISIH9IqS0YZFYAxAR04zgZRnVzgX-wPPDFmVzcA"}
            ],
          "PayloadDigest":"k8kjkIqoYDGcg-kLa6UkLuIEP1bL15gkmUUCf7
  bMYXYbC-LcymtnjLMqiUOpWjXPlPCwZkeG6iUmvd3OZoktuw"}
        ],
      "EnvelopedActivationAccount":[{
          "enc":"A256CBC",
          "dig":"S512",
          "kid":"EBQP-6TAN-BTZW-ASDU-VEC6-MFRR-IJWG",
          "Salt":"tXA2e3ZNixmurZ-it2J6KA",
          "recipients":[{
              "kid":"MALW-QXX4-IADE-A4ZY-GRFV-7FRV-6NMZ",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"-QKmVKReKKmKkvdonFRJAnEGvT1Qgp8e0_qZq
  -UE0GkEi8zglCyuJ0ai8nKlRedPLagxu_HodpWA"}},
              "wmk":"XzQkcZcOZtfC3N1gWPL3pHVc7Qt_hUHjxRD8xioD0qk_
  O5XaBG_xNg"}
            ],
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0
  aW9uQWNjb3VudCIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKI
  CAiQ3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjUyWiJ9"},
        "E0DRm1t6ESGAXqKtSTn93qShYVVWCBcH1mlGJNasyCsIU8UQukuGP-ih
  V3MeXe9bgq-0_E4yH-53437MTWM_uF33wjPTBexXgvr7w0pM4rZ7YVKOmyJ2vo5-x
  PgAAePJwfRCbsyvGIsyN8YW-c8PifFkWntFh4Es_cWnKw-tXjeMcdWjtu1KJxekNQ
  Cl1wxiMk7HIthQtCQwk2A-JWXQWaXCgOmKtjcl-1V4hR52jpUSiYuLNsRXbXJAkrN
  rZFaG",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBDV-XXNH-2RUB-RBMZ-5NG7-L3CD-3THV",
              "signature":"nay6TKbcxU0VmQ7rJVoN_m89pMMlpnKl1lC_-N
  OzKT2mZDPgr7Q5MNwXWigJOngiHcpb_YH2hsuAsVpmwHem5gcuJ378S9UOwKXmgxg
  WKLwkDsAEr3IRqd0LTF0yWqwJ7RpVo-BokZR9xDg0JJxbhyUA",
              "witness":"8cKBTOqU3sGJf_4c7OrpCwar8KKIu6nnw2cvXf3a
  Uzw"}
            ],
          "PayloadDigest":"pDEQGRMpuD0EDYGR_-oxzvovyaQG_uZA9nqexr
  5e8pC1Ha0yu_4pxuQQhAJep2SEfVR2Zs4vqcgsnFY8O5D_3A"}
        ],
      "EnvelopedActivationCommon":[{
          "enc":"A256CBC",
          "dig":"S512",
          "kid":"EBQA-ZOOA-J2XX-OHXS-NQHE-ILCE-25HL",
          "Salt":"He9EoaV4uTzQ25Nsg_ln8Q",
          "recipients":[{
              "kid":"MBYP-2QNG-II34-MVBJ-E3DD-JMUS-KRU3",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"GxSFbVOVBE0DIipxDZtGHwxcX8GSewnZPexv0
  ceJMTZEgU1etKaS34ZQ5xzgNvnMLo5sw0xl__uA"}},
              "wmk":"gkANisn2V3yx3tvibNs7qix0IqlQKuRUaHDp-VNBxbr_
  u9u_4ZdnAw"}
            ],
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0
  aW9uQ29tbW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogI
  CJDcmVhdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6NTJaIn0"},
        "9oiSbsWFv4Si3bH3IBrWJGWRf7lVk9eiGoPh2exMS7FRERkTdonOFcp_
[encoded data, 8515 characters]
  F1U63-GJQDgWkTD0Jqowzt5mOTw",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBDV-XXNH-2RUB-RBMZ-5NG7-L3CD-3THV",
              "signature":"X7i49SUdqSGL6_Iu5bVAoDVUS1lAiyn333jJJc
  0P1FNomX2omaYKrpepbsJcYQNXSDkakyPEg_CApF7k07eQvfwKEAhPVtES_NZo4aD
  jK_gtVXa8FY3aqbFrgatOK1PbMcUWOt4qTe--xyJIKhXN2TgA",
              "witness":"p1ZkuXKyRwrlhoSERIoqHGiZ512xE-bOHHVqRqGd
  A5w"}
            ],
          "PayloadDigest":"oWCi5hMAs9B_Jdl23UlB94HG4nmT0F0W-qbvhk
  uV2jULzRUDGFbY3Zz2y2er9QTYCPBCXSV4857a_dgxHMI8ew"}
        ],
      "ApplicationEntries":[{
          "ApplicationEntrySsh":{
            "Identifier":"MCXP-WQVY-RTKQ-ZU6P-VOM4-7U6K-FHXH",
            "EnvelopedActivation":[{
                "enc":"A256CBC",
                "kid":"EBQK-TT6L-J6RL-A3QS-7JY7-HN2D-WI5W",
                "Salt":"muuRM8Csu8YVGXKPgdBskA",
                "recipients":[{
                    "kid":"MBYP-2QNG-II34-MVBJ-E3DD-JMUS-KRU3",
                    "epk":{
                      "PublicKeyECDH":{
                        "crv":"X448",
                        "Public":"pY-ltrx_QDrhpB2nYek4X9G5CLO3u15
  mcqPAbABxFYRZ83lPtMDLGXmo-FFgqe_gN8per0enFOeA"}},
                    "wmk":"mM9Xh0EF5h1q1GwGnK-GK7gblurWYGJ3k4tE2X
  pc8WmMK7ELsOPW_g"}
                  ],
                "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3
  RpdmF0aW9uQXBwbGljYXRpb25Tc2giLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1
  tL29iamVjdCIsCiAgIkNyZWF0ZWQiOiAiMjAyMi0wNC0yMFQxNjoxNzo1MloifQ"},
              "9ie5X_tfEyaX1ndBhH8gPr5TZQlt14MSGgYJR0AUcrBCXYzBYR
  Q_RiekTzkhluV00luMJ60-fjdzkpOyx_0yXr_ClQkn0M6_FAOt8m2zNZPeURJlFsh
  jGDKyne_c243dcLEskczb1TVkxYhBgrYaykksDENRGAy_gH6vXTFV2DFg1N02UVhP
  j-xQ4pcMrqEpWYYPwAT-N8jWezoOnz2-crO5HW-L3qXB2bzdUcomcq82aO7PQdeBI
  oxHmeeMwdWLV9_tXTm6jsUuGyvvQcXbiQZ9uybTboSyb4Tp2fXyHHjfKL8yPtedXP
  _CAqKdwmZ1ogj0p_O6IzPgUBVQBfxhFi73MgDbkcftON5JS0MNn-YNWkF3Sb-UtJS
  2sttpYOX0M6fZfC1-OFCffuSdEs9KxggxOG3xqmhVcHI4OKVF4hzO21AeocmnmW_0
  FyGrYjNozvXKrSYCvdKshHj1ZqqiWVT3xtQsaVr9FF5_IaMaXfFvwHSQei0p6_B3m
  71r_kciGKO2YyoAoyle0rJuIt4enovfPNpm0f29yhe1-lBY0Hhe6Wf7hSK9NffQc2
  TaBXYWPnDRVlqy_HuEW2MS8jt2NGbFULFsqPpcv22eIuB6K6HefzXlvA_IuYla0So
  JBE2Lyd-Nvpp_6YNOpeWvESFnwbE7rBUcmKrtDSZUp5Hi_XPZ1Sj2h2MYmEvwcDfT
  W8bmS7KJR_EvLglnSp8AnnTTfzqO2XnR5aHVNIgyN5mBqiexLE2W4mGD5FfYvypsp
  ARqjCPjZxUMoZXuqFjx10HSdkBALXoDz1hynK0LkdPL9tjlhnm6sSkJYj8xnfamm3
  qO9BNmponRL_3DQXoPGDkkvwRhWHNCnuC8yQJ8JLN0E9o0Vw6sQX9lQpStMaLbom_
  4zvj9rd4Tl-4EyakDiQgb0x6_c8MaNCs7J_GWX_SVbZcdexx-Hm4aCgwZ3jGbSJZs
  2KKAZmHma3E8N5N8n4wXlHoC6cfA0-y2_3hm39LcKYKJ6YfIqBDJIwdL0vzTLq9qZ
  JT7p6ypBxEnHPTIfFbuHmBGKvzMvHTlLQ_IUr0g6Eyxw1LxKBSSI8FPb2h556_O-1
  hNK-ck6lfEe3JWfsniQuqZTXPrfpduwERLOXanZ-_ysE7Cqd7rh5aAp59GBqWAqpF
  meE4iRYJl6AkEy0wacBsAUJwqoAX4lZK3TU3ChJ0Zh3RemmO6ymxJhHdweb70lvSj
  U60goICoXxuRHuGrrcFfY9SbU3Wae6ykbfsRKY7xJGNkchSkSt7JgsInvhdqn8cSr
  KpMgZqrBAb2tKffghOToS9k4txQsLLeYtmmvWK92bRVbvIy_xvEBC5t0c9q8amGd3
  yMkPa71b8fHOd3rRiA8oXLQhrRCpt1t-aPV0xadtYsRl2MbgW8uQst6zhmlWy3XFF
  UfP7l_mWwWr5-RMMp7oEk-Bnts0v6sELpPiOMVHAUvukCPZMdiOiItcZxGshGk27N
  BsJBNwfPUCpSdvvSzjscnWJgZj2L0iOh1Lb5V0ONMrfdhO9IGa4SXs1dNjsgLqW_0
  zi5fYNYNuAm6cr7658dgt43HWXVC_1o9Hz5jdfmpUD6rMyyCc77c-VIVibFLi5yRs
  MWHFVtUu6mW58VJtXz9LRTfaUVKa2dnb4kRU5Bj8O38dTYhXrSrIuPIV4RWyUPMnw
  jCgd9A2TPSqo3NrH11bHgDOHM1peyx1W4lIDyncV4AbSr20YoW6l3ib84YE5uDAPB
  KTb_v3Dy6-dD-7wcjUmI4Q-uXt289kdHqQdw_AbK8Y1uP8fYZSk87kPo9fpE5vR8y
  DHRrRSprsCGBA2s82-7X3nxZ8AqaN3JvAttT2LzMmTW15ITmW70tBjttzlCvuwGE3
  Y1iNHTZFmhRCvLmbzDuMQbhzTXvxmrT4ivY71XVVshjAsHjcv0ss8mSz3CIZWcq_7
  ujoV9fKfu12CwP2FQDiLHb-uvqu25j5rB3mmLQdtBvLc34Nw3qCMUCmmLBvbG2TCd
  i-tOPZARgSRyMWH29zFIC8VCt6hOpj_e_CTZ5qVlDRUNvRtHeDJ8aSOIDrT30lWQa
  7QsdrUTzTo7m4SZ0pftrmavB0s_ImyLP1yGYSL0_PDntuz9aZVQt7LYlwBYm7FP0F
  QDI3FyF7eX6j4HFj2aIT9ZKc-rXGdYJg2GcKwvftIAis_fIuREm5U5JdZp58sB3gg
  NdOpZkN7vBKu6lgMznuldJYUdLZHkMf3-mfNue5dzyAI8TjhOmVxavGxk3sphqHqU
  5zEpL8rhvgGgL7Mveww78tlVni8OhsoYWywwZ9Q9Nwg8BWMHVssMmWxqCOZda-7zw
  o_2uWlhXw4sSp5Bodz2PXBBQDahQPboLQJLWZad7_Ds7Uq-YERfrTp5oL5O5PIF4O
  TXW9eal1qKPYnoohFSUmZYmKtpQ78ul3v0-PYXQywmKeet6EzcgM2txIQh6ceSuP0
  hTMbVXjt0yB3RV5pX3rjtTeqg8hFmEEyKO_0i30nNxh62sdRBzE-mmfc3N3KQqIha
  sRFB31q9V2iifcD26C5mnQTIDnQ2nV_w4DHAudXhko-nJHouAeGhCMNa05I2dhu3x
  4kM2nUDgX6_RHM4dokC0q2SKZZubE27GrC1eDf8RDpKHi1uby_Rkw9q0oCdsLIsW4
  fLCJSvEpMzzS4YqP77ePINAiBNTSOAR_L9dpqkGuGcCL4DykWiA0rGmmnTaw7UG3t
  iVNS7bBdoKdcqORjUlEfVv3AvEZ08k8KZQYB_oA5IoXj0D1G2JHSqYocFIHcvSbqO
  07Mehz6FqBUF4YcbVKIp_QkG8nCuinD_AwPhtNb_EFN0MM3jaEuDVE0XhIfAHnKrk
  BXC6n3_Qprj-nuBxo_Cf-egFPia_gSjbb1PvoFpxATbPlkY_J6Ihv7b6N19MX8gUx
  HwwdCYLtTwHm8vWlKF0N2qGh_VObwrf0YZaJUkd-yaIOknlOrRw0MjytMsi_SEw_-
  9D4Jn6jkdJzbyQD06CX-tPeNGnelVZfJR7X7SGCDC4_ues5Ait9OH1uZT1J_Z58bZ
  HPHqT3S_GawAVwDN6h7A-VZnELXY279obT2uQ4mSjfLnKvM19qREiJxM7vJELYHfb
  DLi2WxX8oR5dYmhgZfAaCRFlO8dcXoZc1aMwthDm_tvq96ZMqTG-KeBr7Br8VHFgK
  Ji_GDWm6y41EDfw0WxQ_m-7sOCKclct-i5om1X3A3A49u5Cf0U08NxLqPDDM2H9_b
  7WQfPmY7EfBNesye6AX_0DKqaIbG0Dlhddnx_s5dOizf5TD2kxAlgPz9BD8EUhj3h
  3p9L559Yj9RnHSPvqY2x_xsbxyPx"
              ]}}
        ]}}}

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:
Alice3> meshman device complete
   Device UDF = MAA3-BQPZ-WWO4-7Q5B-P7AH-FY5C-ATMD
   Account = alice@example.com
   Account UDF = MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF
Alice3> meshman account sync

The completion request specifies the witness value for the transaction whose completion is being queried:
{
  "CompleteRequest":{
    "AccountAddress":"alice@example.com",
    "ResponseID":"MCXK-BPYI-YM5Y-N4LL-SFZV-FXIC-AHX2"}}
The Service responds to the complete request by checking to see if an entry has been added to the local spool. If so, this contains the RespondConnection message created by the administration device.

Preconfigured (Static QR Code)
The preconfigured device connection interaction is used to connect devices that lack affordances such as a display or a keyboard. It is also known as the static QR code interaction because a static QR code printed on the device itself is used to connect it to a user's account.
Future: Note that this interaction is likely to be changed substantially in future revisions of the specification and the Claim/PollClaim mechanism removed and replaced with a messaging based approach.
The interaction has five 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 a Claim operation described above as described in the Device Description.
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: Poll Claim Notification
When connected to a network, the preconfigured device periodically attempts to poll the connection sources specified to find out if there is a pending request. If a connection request is posted, the device decrypts it to allow it to complete the connection process.
Phase 5: 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 main differences between this connection interaction and the witness/PIN connection interactions are that the device is preconfigured with the device profile at the time of manufacture and the onboarding device MAY be acquiring network configuration information during the connection process.

Phase 1
The manufacturer preconfigures the device
Maker> meshman device preconfig
Device UDF: MBOB-5GVY-Q43B-KODG-UJ3E-LY7V-36UV
File: EBKG-ED3O-HBHK-ZQGS-EX4H-X22S-X4.medk

This results in the creation of a primary secret which is used to compute a ProfileDevice and corresponding connection records signed by the manufacturer's administrator key.
The data is combined to create a DevicePreconfiguration record that is provisioned to the firmware of the device being preconfigured.
{
  "DevicePreconfigurationPrivate":{
    "EnvelopedProfileDevice":[{
        "EnvelopeId":"MBOB-5GVY-Q43B-KODG-UJ3E-LY7V-36UV",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQk9CLTVHVlktUT
  QzQi1LT0RHLVVKM0UtTFk3Vi0zNlVWIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjU3WiJ9"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm
  UiOiB7CiAgICAgICJVZGYiOiAiTUJPQi01R1ZZLVE0M0ItS09ERy1VSjNFLUxZN1Y
  tMzZVViIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs
  aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI
  CAiUHVibGljIjogIkZXaWlfWUV0VERYNUt6ZUQtLW44QW5LcWlFUFQzODN6YWZPOW
  VFREt0QjNjc2pMa2VaV2UKICBXMjNhQlEtd01pZFVNLVZGX1VsYTFtSUEifX19LAo
  gICAgIkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNLMi1PRlNZLUNBUEot
  RVpVNS1LTzM3LUlJTkMtNkhYTCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjoge
  wogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYND
  Q4IiwKICAgICAgICAgICJQdWJsaWMiOiAiNkNwVFVfWlp1QWE3bENOYkE4ZUs4c2h
  EeUdsQy05YldXckwteFQybTFZNjcwZVpFVzI1NwogIHR2SnREVDFLSTN3aXotaXB0
  bjFBVHBhQSJ9fX0sCiAgICAiU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1CS
  DYtUEQyNy02Tjc2LVIyNTctQlUzTS1CUUpYLVFEQlMiLAogICAgICAiUHVibGljUG
  FyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICA
  gICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJXV0xIN0hjb0Vl
  SzdhRzMtYWdMdHI2UlltWTJnYWtiekNyWm00aWppWERGbXhWVFJIamJlCiAgaUItV
  1dLOS1JVDQydW5OaHRXRmxPdXdBIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IH
  sKICAgICAgIlVkZiI6ICJNQlRKLU9CNEYtQVlIRC1YQzRJLUpaTkctTUJaVS1ISTN
  HIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl
  eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1Y
  mxpYyI6ICJWd0hYcHQxdmZKV21zNUNjazluc2dlam92WkxOa1ctcEFxalpHdkdWNW
  5lb0UtcnVyZWJDCiAgaTdYLTR3bnhxbXV4RkxIVHF5cFdJRjhBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBOB-5GVY-Q43B-KODG-UJ3E-LY7V-36UV",
            "signature":"m10FQkPJzhAR2Cg2VfPzvSUt3XyQh0yjgqggXSep
  nwz3NpDWrH6TZLNeO0Gq-moqahTzGn_ZW8aA6vuiuiqtDMy_avBf0g31nDpFyRDk6
  9D5qXBh8Br-4utT_Zxyzz3S2i63FGczDekAZTwZTQoQwTUA"}
          ],
        "PayloadDigest":"-irGyEMwNtkfLTM8Ygprqww7Lr41K_2Recre2O2H
  DP5CyC4VklJfYiDMR8822Sp5oALA-2aqQjDzJKKEt50nhA"}
      ],
    "EnvelopedConnectionDevice":[{
        "dig":"S512",
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
  DcmVhdGVkIjogIjIwMjItMDQtMjBUMTY6MTc6NTdaIn0"},
      "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkF1dGhlbnRpY2F0aW
  9uIjogewogICAgICAiVWRmIjogIk1DSzItT0ZTWS1DQVBKLUVaVTUtS08zNy1JSU5
  DLTZIWEwiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVi
  bGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OCIsCiAgICAgICAgI
  CAiUHVibGljIjogIjZDcFRVX1padUFhN2xDTmJBOGVLOHNoRHlHbEMtOWJXV3JMLX
  hUMm0xWTY3MGVaRVcyNTcKICB0dkp0RFQxS0kzd2l6LWlwdG4xQVRwYUEifX19LAo
  gICAgIlNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQkg2LVBEMjctNk43Ni1S
  MjU3LUJVM00tQlFKWC1RREJTIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7C
  iAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkND
  Q4IiwKICAgICAgICAgICJQdWJsaWMiOiAiV1dMSDdIY29FZUs3YUczLWFnTHRyNlJ
  ZbVkyZ2FrYnpDclptNGlqaVhERm14VlRSSGpiZQogIGlCLVdXSzktSVQ0MnVuTmh0
  V0ZsT3V3QSJ9fX0sCiAgICAiRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ
  0syLU9GU1ktQ0FQSi1FWlU1LUtPMzctSUlOQy02SFhMIiwKICAgICAgIlB1YmxpY1
  BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICA
  gICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICI2Q3BUVV9aWnVB
  YTdsQ05iQThlSzhzaER5R2xDLTliV1dyTC14VDJtMVk2NzBlWkVXMjU3CiAgdHZKd
  ERUMUtJM3dpei1pcHRuMUFUcGFBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBGZ-R2AS-DPME-4KOZ-KKF5-WLDO-IBZO",
            "signature":"pe4KEfz7NgyGS4nz7VxBPZNcX04Fnf5EVQXCg4AO
  Z_XDKD3egMEeg5cStZALTB-yOkk44XLobyWAbxbhyeVFif7qZAdZ0hdk-h_o-di3h
  aX-SVPdFpGHXeCeOMaEAfsCOXTb9oSvHqDNLUaRIfq0wiIA"}
          ],
        "PayloadDigest":"oa0Yms70Z_buemEpSstfNdKSVlxUy7NoHKkZv_bA
  9OX9ZJGkB3E4nNBfLG85arEixWQhkxFCwkHLvmInqkjYIQ"}
      ],
    "EnvelopedConnectionService":[{
        "dig":"S512",
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uU2VydmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICA
  iQ3JlYXRlZCI6ICIyMDIyLTA0LTIwVDE2OjE3OjU3WiJ9"},
      "ewogICJDb25uZWN0aW9uU2VydmljZSI6IHsKICAgICJBdXRoZW50aWNhdG
  lvbiI6IHsKICAgICAgIlVkZiI6ICJNQ0syLU9GU1ktQ0FQSi1FWlU1LUtPMzctSUl
  OQy02SFhMIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1
  YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgI
  CAgIlB1YmxpYyI6ICI2Q3BUVV9aWnVBYTdsQ05iQThlSzhzaER5R2xDLTliV1dyTC
  14VDJtMVk2NzBlWkVXMjU3CiAgdHZKdERUMUtJM3dpei1pcHRuMUFUcGFBIn19fX1
  9",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBGZ-R2AS-DPME-4KOZ-KKF5-WLDO-IBZO",
            "signature":"mGzTozZ5fDt4p9-VSDGwx6b9AUo_YDR9pLwXAj1m
  oN5de75NXuZRdz_ENeTLu1AtEzyYENDaQskAho664biW8I7DuRbNbLJ_AJLXQD99b
  5kiiz1Ljavg1RAdrdfH05TDGHw7eMP5aCEir_o4oS7zjTEA"}
          ],
        "PayloadDigest":"97C6-ryQFiyRF-8NAP9pX7YvJEtcz-hexhvkHgsJ
  2GUEl7yW_-uhclWSu0F7eRrdENFRq8g-qJDXPJTmo8TyEA"}
      ],
    "PrivateKey":{
      "PrivateKeyUDF":{
        "PrivateValue":"ZAAQ-A5KD-OPXN-5E7X-ZXRU-CRYP-B2N2-G6FY-MCO
H-GAIH-72GR-EZXO-LQIM-Z5GA",
        "KeyType":"MeshProfileDevice"}},
    "ConnectUri":"mcu://maker@example.com/EBKG-ED3O-HBHK-ZQGS-EX4H-
X22S-X4"}}
An EARL is created specifying the means by which an administration device can acquire the information required to complete a connection to the device:
QR = {Connect.ConnectEARL}
The preconfigured ProfileDevice is encrypted under the encryption key and published to the location key derived from the EARL.

Phase 2 & 3
The administration device scans the QR code and obtains the Device Description using the Claim operation as shown in section $$$$. The administration device creates the ActivationDevice and CatalogedDevice records and populates the service as before.
Alice> meshman account connect ^
    mcu://maker@example.com/EBKG-ED3O-HBHK-ZQGS-EX4H-X22S-X4 /web

Phase 4
The device polls the publication service until a claim message is returned.
Alice4> meshman device complete
   Device UDF = MBOB-5GVY-Q43B-KODG-UJ3E-LY7V-36UV
   Account = alice@example.com
   Account UDF = MAMQ-ETEA-JBL3-6UKE-LRNT-DGC3-OIDF

Phase 5
Having been advised that an account has published a claim to bind to it, the device posts a connection Complete request to the specified account and completes the connection process as before.

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.

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.

Message: MeshRequest
Base class for all request messages.
[No fields]

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.

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.

Message: MeshResponse
Base class for all response messages. Contains only the status code and status description fields.
[No fields]

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.

Common Structures
The following common structures are used in the protocol messages:

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.

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.

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

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.

Structure: ContainerStatus
Container: String (Optional)
Index: Integer (Optional)
Digest: Binary (Optional)

Structure: ContainerUpdate
Inherits: ContainerStatus
Envelopes: DareEnvelope [0..Many]
The entries to be uploaded.

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.

Message: MeshHelloResponse
ConstraintsUpdate: ConstraintsData (Optional)
Specifies the default 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.

Transaction: BindAccount
Request: BindRequest
Response: BindResponse
Request creation of a new service account or group.
Attempt

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.

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.

Transaction: UnbindAccount
Request: UnbindRequest
Response: UnbindResponse
Request deletion of a service account.

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]

Message: UnbindResponse
Inherits: MeshResponse
Reports the success or failure of a Delete transaction.
[No fields]

Transaction: Connect
Request: ConnectRequest
Response: ConnectResponse
Request information necessary to begin making a connection request.

Message: ConnectRequest
Inherits: MeshRequest
EnvelopedRequestConnection: Enveloped (Optional)
The connection request generated by the client
Rights: String [0..Many]
List of named access rights.

Message: ConnectResponse
Inherits: MeshResponse
EnvelopedAcknowledgeConnection: Enveloped (Optional)
The connection request generated by the client
EnvelopedProfileAccount: Enveloped (Optional)
The user profile that provides the root of trust for this Mesh

Transaction: Complete
Request: CompleteRequest
Response: CompleteResponse

Message: CompleteRequest
Inherits: StatusRequest
AccountAddress: String (Optional)
ResponseID: String (Optional)

Message: CompleteResponse
Inherits: MeshResponse
EnvelopedRespondConnection: Enveloped (Optional)
The signed assertion describing the result of the connect request

Transaction: Status
Request: StatusRequest
Response: StatusResponse

Message: StatusRequest
Inherits: MeshRequestUser
DeviceUDF: String (Optional)
ProfileMasterDigest: Binary (Optional)
Catalogs: String [0..Many]
Spools: String [0..Many]

Message: StatusResponse
Inherits: MeshResponse
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]

Transaction: Download
Request: DownloadRequest
Response: DownloadResponse
Request objects from the specified container with the specified search criteria.

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.

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

Transaction: Transact
Request: TransactRequest
Response: TransactResponse
Attempt an atomic transaction on the containers and spools associated with an account.

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.

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.

Structure: EntryResponse
IndexRequest: Integer (Optional)
The index value of the entry in the 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.

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.

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.

Message: PostResponse
Inherits: TransactResponse
[No fields]

Transaction: Claim
Request: ClaimRequest
Response: ClaimResponse
Claim a publication

Message: ClaimRequest
Inherits: MeshRequest
EnvelopedMessageClaim: Enveloped (Optional)
The claim message

Message: ClaimResponse
Inherits: MeshResponse
CatalogedPublication: CatalogedPublication (Optional)
The encrypted device profile

Transaction: PollClaim
Request: PollClaimRequest
Response: PollClaimResponse
Check party making claim

Message: PollClaimRequest
Inherits: MeshRequest
PublicationId: String (Optional)
The envelope identifier formed from the PublicationId.
TargetAccountAddress: String (Optional)
Account to which the claim is directed

Message: PollClaimResponse
Inherits: MeshResponse
EnvelopedMessage: Enveloped (Optional)
The claim message

Structure: CryptographicOperation
KeyId: String (Optional)
The key identifier
KeyCoefficient: Binary (Optional)
Lagrange coefficient multiplier to be applied to the private key

Structure: CryptographicOperationSign
Inherits: CryptographicOperation
Data: Binary (Optional)
The data to sign
PartialR: Binary (Optional)
Contribution to the R offset.

Structure: CryptographicOperationKeyAgreement
Inherits: CryptographicOperation
[No fields]

Structure: CryptographicOperationGenerate
Inherits: CryptographicOperation
[No fields]

Structure: CryptographicOperationShare
Inherits: CryptographicOperation
Threshold: Integer (Optional)
Shares: Integer (Optional)

Structure: CryptographicResult
Error: String (Optional)

Structure: CryptographicResultKeyAgreement
Inherits: CryptographicResult
[No fields]

Structure: CryptographicResultShare
Inherits: CryptographicResult
[No fields]

Transaction: Operate
Request: OperateRequest
Response: OperateResponse
Perform a set of cryptographic operations

Message: OperateRequest
Inherits: MeshRequest
AccountAddress: String (Optional)
The service account the capability is bound to

Message: OperateResponse
Inherits: MeshResponse
[No fields]

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].

IANA Considerations
All the IANA considerations for the Mesh documents are specified in this document

Acknowledgements
A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture].

Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[draft-hallambaker-mesh-architecture]

Mathematical Mesh 3.0 Part I: Architecture Guide
Phillip Hallam-Baker
ThresholdSecrets.com
25 October 2021
Internet-Draft draft-hallambaker-mesh-architecture-19
[draft-hallambaker-mesh-rud]

Mathematical Mesh 3.0 Part VI: Reliable User Datagram
Phillip Hallam-Baker
ThresholdSecrets.com
5 August 2021
Internet-Draft draft-hallambaker-mesh-rud-00
[draft-hallambaker-jsonbcd]

Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D
Phillip Hallam-Baker
5 August 2021
Internet-Draft draft-hallambaker-jsonbcd-21
[draft-hallambaker-mesh-udf]

Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.
Phillip Hallam-Baker
ThresholdSecrets.com
25 October 2021
Internet-Draft draft-hallambaker-mesh-udf-15
[draft-hallambaker-mesh-schema]

Mathematical Mesh 3.0 Part IV: Schema Reference
Phillip Hallam-Baker
ThresholdSecrets.com
25 October 2021
Internet-Draft draft-hallambaker-mesh-schema-09
[draft-hallambaker-mesh-security]

Mathematical Mesh 3.0 Part IX Security Considerations
Phillip Hallam-Baker
ThresholdSecrets.com
20 September 2021
Internet-Draft draft-hallambaker-mesh-security-08

Informative References
[draft-hallambaker-mesh-developer]

Mathematical Mesh: Reference Implementation
Phillip Hallam-Baker
27 July 2020
Internet-Draft draft-hallambaker-mesh-developer-10