Mathematical Mesh 3.0 Part V: Protocol Reference
draft-hallambaker-mesh-protocol-16 draft-hallambaker-mesh-protocol
Phillip Hallam-Baker
ThresholdSecrets.com
phill@hallambaker.com
14 October 2024
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

c

o

S

o

r

a

L

h

S

e

o

e

P

g

e

l

a

g

t

c

R

P

o

e

H

C

M

s

M

T

T

e

h

g

l

m

r

l

t

a

T

U

t

o

r

a

T

o

e

r

i

D

M

s

i

P

D

D

a

n

s

i

U

P

l

S

e

s

b

P

c

v

P

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":{
    "EnvelopedProfileService":[{
        "EnvelopeId":"MBQD-ETXU-HZRW-A26O-WDTR-K7GI-X6JD",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFELUVUWFUtSF
  pSVy1BMjZPLVdEVFItSzdHSS1YNkpEIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVNlcnZpY2UiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAg
  IkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NFoifQ",
        "dig":"S512"},
      "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJTZXJ2aWNlQXV0aGVudG
  ljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTURZSS1JMkJILUhNTDMtSDZZSy1HTll
  XLUpKWEYtTlZESCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAg
  ICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgI
  CAgICAgICJQdWJsaWMiOiAiZ0g2UU15WXg1cWZPUmFOTnZzWnlSODNCTTBhbkVqLV
  ZxQ29MLTZrX0JoZEZZUThRcHJvNQogIDhwMGhyVFJNVExacnJCZFdwanRQS2l1QSJ
  9fX0sCiAgICAiU2VydmljZUVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUE0
  TC1VRTVBLUU0VkctVUdSSy1UVlQyLTNMSEctWTdOViIsCiAgICAgICJQdWJsaWNQY
  XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC
  AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiS1BybjZhUHRSSEd
  MYkkyYUVIeklfZHRQRGdhR01TU0x4a0RfZFdzVEJZVkUxS2ZUM2tBTwogIHFSMjlQ
  ODJDLU5ydFphcG53eFpmRlRnQSJ9fX0sCiAgICAiU2VydmljZVNpZ25hdHVyZSI6I
  HsKICAgICAgIlVkZiI6ICJNQzZMLVQ1UDYtVVpDUS1SUkQ3LVZNSk0tRTJLUS1BWk
  hFIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0t
  leUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQ
  dWJsaWMiOiAieTVhN1hYZG9mX0F6aTh1ZVRkZFNJWng5ZkZnRDdaZlhCVDktTjZlN
  XFlQl9wUXRudXJ5bAogIFJOeGUydzVIckNWOXNZejJqcjN1NFhxQSJ9fX0sCiAgIC
  AiUm9vdFVkZnMiOiBbIllCTGtrWFZRYmRxZWE4MVFWSWtwcHAwRE9CdHRKRmNvVEk
  3VVZld3JldU1CQUozejZuCiAgTW1mMzFGYjRoRnktT0pqWVdoOTVFMHNwTlV2UGpN
  anczTm9wQSJdfX0",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MAJO-JELV-KBW5-VHTL-ZVIF-JCJJ-U2OQ",
            "SignatureKey":{
              "PublicKeyECDH":{
                "crv":"Ed448",
                "Public":"HrzNjtG9zQoqxzKGX1fa5ewkB0g6P7HQfinZuUC
  Y_q4Ke778BqDQPwE8kpSgU7aulAUJIk8Ue-kA"}},
            "signature":"u2U3pzAR-p3SyPylngueVqwseBYnkzJ0cXSsmT5j
  yKqMNKLb6EIhA4Q_m9W4qaj5MfpkFwwI6kQA6Kh59w0zmMrPPfTgPE3mxCJ5qLj4S
  hkMMubJwSb_L4Ef8rqKSZ9vGHdEuTImoU1rFnQAHeorqzsA"}
          ],
        "PayloadDigest":"GpwjTMrI_kI51EPsErCiiBEe3XJXntbI2Xkd4uX-
  sW6Ix81ljSbMDnALW0hua0peCyMOVvBV2iyZb3cRnQh6mA"}
      ],
    "Version":{
      "Major":3,
      "Minor":0,
      "Encodings":[{
          "ID":["application/json"
            ]}
        ]},
    "Status":201}}
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":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFDLTdPSEEtUk
  5CQS1GUkRMLVI0R0ktWVFIQS1ETDM2IiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ",
        "dig":"S512"},
      "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJDb21tb25TaWduYXR1cmUiOi
  B7CiAgICAgICJVZGYiOiAiTUROVC1XVDNHLTM0NkctNEk1VC1ZVjdGLUxUUVgtUFN
  OVCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNL
  ZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiU
  HVibGljIjogIklNeU1vN2ZFeTJ2SHA4c3lRMFZVNFhpdnBKRWhnUVFTWDNqOG12YT
  RIQ19UMDVVbmhRWXEKICBWWnl1dklRRVZvMmR5TUNSbTYwUTNFMEEifX19LAogICA
  gIkFjY291bnRBZGRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIiwKICAgICJTZXJ2
  aWNlVWRmIjogIk1CUUQtRVRYVS1IWlJXLUEyNk8tV0RUUi1LN0dJLVg2SkQiLAogI
  CAgIkVzY3Jvd0VuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNLRC0zTVI2LV
  AyVEUtTTZVNC00TElPLVpUUkctRFpWUyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
  zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
  ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMXZOVUFBcDNyc3pJcGhHOEVzZ
  m9hTzVZNnNaQ24wSGM4ekNnZFFpdllwSkFjRHRta1NzQwogIGVJMmdtRFRDSzZTcl
  MxVWdQdHVZbVR3QSJ9fX0sCiAgICAiQWRtaW5pc3RyYXRvclNpZ25hdHVyZSI6IHs
  KICAgICAgIlVkZiI6ICJNRDJMLTZNN0MtWjNaMy1RM0FMLUpGWUktWklVQy1CS1VS
  IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tle
  UVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdW
  JsaWMiOiAiYkhvS2IwYzEyRjdjaWJNXzNnWmNKWE16T09YNHNuSGdQVndPZlJZazZ
  BUkpPc0dQZW1zZAogIDJCbTBXZm1Ba1JZTzNFUTZmajhfTnpTQSJ9fX0sCiAgICAi
  Q29tbW9uRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVlGLUQ3TEotNUlNU
  C1FVUNHLUhTR0gtN0xTUi1BQVBaIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOi
  B7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg
  0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJjN29vcko4MDhzYzlkNDBLWERoSUhn
  Q1RGejM5TUszSmpPMFE3S191ZkRFR0RLaXdWS2hkCiAgM29QUTQ0UEVxR2p3a3BwN
  09mYmNCYlNBIn19fSwKICAgICJDb21tb25BdXRoZW50aWNhdGlvbiI6IHsKICAgIC
  AgIlVkZiI6ICJNQUZULVNJTkEtU0ZYSS1QQkRZLVdSSEUtTlhZTC1EWFZUIiwKICA
  gICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgi
  OiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6I
  CJYY2dFejl5MmNxc3g0WmViR0VSVGpyTi14ek44M0QtcGN4MDY1MXgtV1VDcVlOcn
  NuelRICiAgNDBDcG9NeHVOLUZucFQ1bV9iME15dUtBIn19fSwKICAgICJSb290VWR
  mcyI6IFsiWUJKUjNqUjJQbGpkWWs1cXhiV2RIWTByVFlFYUZBa0hZM01tc1I4enZO
  MURyMzNSbkwKICBVTDNUaHJHOURNV0JaM1AtOFp5R3p5S2FRWXdlY28yWlV0Y0t3I
  l19fQ",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MAJF-DXRU-OY7F-RXLC-JZVM-LNM5-DWGS",
            "SignatureKey":{
              "PublicKeyECDH":{
                "crv":"Ed448",
                "Public":"9sZGEfYSIoTvVSL0Q5c_Oip_Hi2iOTsl4L3iLwh
  fOv9bA-5nd7PyRooKEsQx-lA7PMAYBewSOmIA"}},
            "signature":"6x3k8AC2jkUQv0jzlUVWJDqP7zcNkKAqvPcAs7Ci
  2jXULjbIFAFCct8GC8Nb8KiD5ljoLAsVHr-AnYcjklyXSHN6Gn_BIZiLiW3Yu5_Ch
  XHspywX-ZGMD6soXJIilOzreauR-_aiUE7Gx0eh3Fje2wEA"}
          ],
        "PayloadDigest":"tXPfbmg_SRmARF_7HLPq-bM6NMO1h1Oa30f_Ag_T
  IRzGKMrmTKtV7XH-h3NIBFGxOQYuD0BproKNEg6uhtG0Mw"}
      ],
    "EnvelopedCallsignBinding":[[{
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDYWxsc2ln
  bkJpbmRpbmciLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgI
  kNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ",
          "dig":"S512"},
        "ewogICJDYWxsc2lnbkJpbmRpbmciOiB7CiAgICAiQ2Fub25pY2FsIjog
  ImFsaWNlQGV4YW1wbGUuY29tIiwKICAgICJEaXNwbGF5IjogImFsaWNlQGV4YW1wb
  GUuY29tIiwKICAgICJQcm9maWxlVWRmIjogIk1CUUMtN09IQS1STkJBLUZSREwtUj
  RHSS1ZUUhBLURMMzYiLAogICAgIlNlcnZpY2VzIjogW3sKICAgICAgICAiUHJlZml
  4IjogIm1tbSJ9XX19",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
              "signature":"-Pp_ckhL8JOcz6YRG466UJn9waIRn8KzCLZv_7
  9OjTnOla3emASatCkLlMDHoppgzVnl3E8oYMuAY0W8MAZopsg5fLDAB7yTUKE1Cgi
  boHAZ2FydtHpKuXMwbh9TxZUUlCA8rj4b91k75jmf7B2sJgsA"}
            ],
          "PayloadDigest":"kLv_SVV9EuL9uUX1T38TUz5GH5z5FyEkJsHMUo
  J_gDeAwsZ_3ZNmJ_cbvrQSH-wYklSjWZ69z8TI-QXeL1XaHg"}
        ]
      ]}}
The response payload currently reports the success or failure of the bind operation:
{
  "BindResponse":{
    "EnvelopedAccountHostAssignment":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY2NvdW50SG
  9zdEFzc2lnbm1lbnQiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCI
  sCiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ"},
      "ewogICJBY2NvdW50SG9zdEFzc2lnbm1lbnQiOiB7CiAgICAiQWNjb3VudE
  FkZGVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiQWNjZXNzRW5jcnlwdCI
  6IHsKICAgICAgIlVkZiI6ICJNREVULTI2TkItNUdSVi1KT1dELUhKNkQtNldVTi1K
  TFdFIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY
  0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIl
  B1YmxpYyI6ICJlSzVIN29wbXU3VzgwY1ZtUWdzLXVQT3FUUURTbTI2Z0hFanU0SHB
  FLWRBR0lEczNaMFg2CiAgMlZsaWtzZktZT3NQN0FFbkE5d2VJN1dBIn19fSwKICAg
  ICJFbnZlbG9wZWRQcm9maWxlU2VydmljZSI6IFt7CiAgICAgICAgIkVudmVsb3BlS
  WQiOiAiTUJRRC1FVFhVLUhaUlctQTI2Ty1XRFRSLUs3R0ktWDZKRCIsCiAgICAgIC
  AgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWkNJNklDSk5RbEZ
  FTFVWVVdGVXRTRnBTVnkxCiAgQk1qWlBMVmRFVkZJdFN6ZEhTUzFZTmtwRUlpd0tJ
  Q0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBWTmxjblpwWTJVaUxBb
  2dJQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQQ
  ogIGdJa055WldGMFpXUWlPaUFpTWpBeU5DMHhNQzB4TkZReE16b3hNRG8wTkZvaWZ
  RIiwKICAgICAgICAiZGlnIjogIlM1MTIifSwKICAgICAgImV3b2dJQ0pRY205bWFX
  eGxVMlZ5ZG1salpTSTZJSHNLSUNBZ0lDSlRaWEoyYVdObFFYVjBhR1YKICB1ZEdsa
  llYUnBiMjRpT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUFpVFVSWlNTMUpNa0pJTFVoTl
  RETXRTRFpaUwogIHkxSFRsbFhMVXBLV0VZdFRsWkVTQ0lzQ2lBZ0lDQWdJQ0pRZFd
  Kc2FXTlFZWEpoYldWMFpYSnpJam9nZXdvCiAgZ0lDQWdJQ0FnSUNKUWRXSnNhV05M
  WlhsRlEwUklJam9nZXdvZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2SUNKWU4KICBEUTRJa
  XdLSUNBZ0lDQWdJQ0FnSUNKUWRXSnNhV01pT2lBaVowZzJVVTE1V1hnMWNXWlBVbU
  ZPVG5aeldubAogIFNPRE5DVFRCaGJrVnFMVlp4UTI5TUxUWnJYMEpvWkVaWlVUaFJ
  jSEp2TlFvZ0lEaHdNR2h5VkZKTlZFeGFjCiAgbkpDWkZkd2FuUlFTMmwxUVNKOWZY
  MHNDaUFnSUNBaVUyVnlkbWxqWlVWdVkzSjVjSFJwYjI0aU9pQjdDaUEKICBnSUNBZ
  0lDSlZaR1lpT2lBaVRVRTBUQzFWUlRWQkxVVTBWa2N0VlVkU1N5MVVWbFF5TFROTV
  NFY3RXVGRPVgogIGlJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWp
  vZ2V3b2dJQ0FnSUNBZ0lDSlFkV0pzYVdOCiAgTFpYbEZRMFJJSWpvZ2V3b2dJQ0Fn
  SUNBZ0lDQWdJbU55ZGlJNklDSllORFE0SWl3S0lDQWdJQ0FnSUNBZ0kKICBDSlFkV
  0pzYVdNaU9pQWlTMUJ5YmpaaFVIUlNTRWRNWWtreVlVVklla2xmWkhSUVJHZGhSMD
  FUVTB4NGEwUgogIGZaRmR6VkVKWlZrVXhTMlpVTTJ0QlR3b2dJSEZTTWpsUU9ESkR
  MVTV5ZEZwaGNHNTNlRnBtUmxSblFTSjlmCiAgWDBzQ2lBZ0lDQWlVMlZ5ZG1salpW
  TnBaMjVoZEhWeVpTSTZJSHNLSUNBZ0lDQWdJbFZrWmlJNklDSk5ReloKICBNTFZRM
  VVEWXRWVnBEVVMxU1VrUTNMVlpOU2swdFJUSkxVUzFCV2toRklpd0tJQ0FnSUNBZ0
  lsQjFZbXhwWQogIDFCaGNtRnRaWFJsY25NaU9pQjdDaUFnSUNBZ0lDQWdJbEIxWW1
  4cFkwdGxlVVZEUkVnaU9pQjdDaUFnSUNBCiAgZ0lDQWdJQ0FpWTNKMklqb2dJa1Zr
  TkRRNElpd0tJQ0FnSUNBZ0lDQWdJQ0pRZFdKc2FXTWlPaUFpZVRWaE4KICAxaFlaR
  zltWDBGNmFUaDFaVlJrWkZOSlduZzVaa1puUkRkYVpsaENWRGt0VGpabE5YRmxRbD
  l3VVhSdWRYSgogIDViQW9nSUZKT2VHVXlkelZJY2tOV09YTlplakpxY2pOMU5GaHh
  RU0o5Zlgwc0NpQWdJQ0FpVW05dmRGVmtaCiAgbk1pT2lCYklsbENUR3RyV0ZaUllt
  UnhaV0U0TVZGV1NXdHdjSEF3UkU5Q2RIUktSbU52VkVrM1ZWWmxkM0oKICBsZFUxQ
  1FVb3plalp1Q2lBZ1RXMW1NekZHWWpSb1Jua3RUMHBxV1Zkb09UVkZNSE53VGxWMl
  VHcE5hbmN6VAogIG05d1FTSmRmWDAiLAogICAgICB7CiAgICAgICAgInNpZ25hdHV
  yZXMiOiBbewogICAgICAgICAgICAiYWxnIjogIkVENDQ4IiwKICAgICAgICAgICAg
  ImtpZCI6ICJNQUpPLUpFTFYtS0JXNS1WSFRMLVpWSUYtSkNKSi1VMk9RIiwKICAgI
  CAgICAgICAgIlNpZ25hdHVyZUtleSI6IHsKICAgICAgICAgICAgICAiUHVibGljS2
  V5RUNESCI6IHsKICAgICAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICA
  gICAgICAgICAgIlB1YmxpYyI6ICJIcnpOanRHOXpRb3F4ektHWDFmYTVld2tCMGc2
  UDdIUWZpblp1VUNZX3E0S2U3NzhCcURRCiAgUHdFOGtwU2dVN2F1bEFVSklrOFVlL
  WtBIn19LAogICAgICAgICAgICAic2lnbmF0dXJlIjogInUyVTNwekFSLXAzU3lQeW
  xuZ3VlVnF3c2VCWW5rekowY1hTc21UNWp5S3FNTktMYjYKICBFSWhBNFFfbTlXNHF
  hajVNZnBrRnd3STZrUUE2S2g1OXcwem1NclBQZlRnUEUzbXhDSjVxTGo0U2hrTU11
  YgogIEp3U2JfTDRFZjhycUtTWjl2R0hkRXVUSW1vVTFyRm5RQUhlb3JxenNBIn1dL
  AogICAgICAgICJQYXlsb2FkRGlnZXN0IjogIkdwd2pUTXJJX2tJNTFFUHNFckNpaU
  JFZTNYSlhudGJJMlhrZDR1WC1zVzZJeAogIDgxbGpTYk1EbkFMVzBodWEwcGVDeU1
  PVnZCVjJpeVpiM2NSblFoNm1BIn1dfX0"
      ],
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}
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:
{
  "DownloadRequest":{
    "MaxResults":-1,
    "DeviceUDF":"MBQO-4TTM-QOTS-MKEG-XQTU-XNFM-WUWM",
    "CatalogedDeviceDigest":"MC2F-2ZAT-4BRE-QDDE-HBQQ-3H7O-PB",
    "Select":[{
        "Store":"Credential",
        "IndexMin":3},
      {
        "Store":"Contact",
        "IndexMin":3},
      {
        "Store":"Task",
        "IndexMin":1},
      {
        "Store":"Bookmark",
        "IndexMin":1},
      {
        "Store":"Network",
        "IndexMin":1},
      {
        "Store":"Application",
        "IndexMin":1},
      {
        "Store":"Device",
        "IndexMin":3},
      {
        "Store":"Access",
        "IndexMin":3},
      {
        "Store":"Document",
        "IndexMin":1},
      {
        "Store":"Publication",
        "IndexMin":1},
      {
        "Store":"Inbound",
        "IndexMin":3},
      {
        "Store":"Outbound",
        "IndexMin":1},
      {
        "Store":"Local",
        "IndexMin":2}
      ]}}
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:
{
  "DownloadResponse":{
    "Updates":[{
        "Envelopes":[[{
              "enc":"A256CBC",
              "Salt":"fYUwUF5YTfAeOgSewpXy_A",
              "recipients":[{
                  "kid":"MDFG-UKLG-VUPZ-XAY3-BDMH-FI35-RW3Y",
                  "epk":{
                    "PublicKeyECDH":{
                      "crv":"X448",
                      "Public":"iwbMN5lNb1LLgLYYTt-1xchZIOKm_Xt8x
  229dTEuZaDGfo0V1VLU19rYyWqPAif3wzWkzyFR7UmA"}},
                  "wmk":"0skSKfeeG4EaXByENg1R4wuXgNrWJ8nFkjpND1Wf
  sGntFaADEp-knw"}
                ],
              "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICI6ZnRwLmV4
  YW1wbGUuY29tIiwKICAiRXZlbnQiOiAiVXBkYXRlIn0",
              "SequenceInfo":{
                "Index":3,
                "TreePosition":1137},
              "Received":"2024-10-14T13:10:46Z",
              "PayloadDigest":"M5x4gqPlFJCU1hAeHkcwuahGWSKDj7sIkn
  _nkD6QtVAmWj5sjPJqsHAbaS7wIa868nZesxO9xHg3H2qs3aAZPQ",
              "ApexDigest":"NcSyijJ8HTa7RoYotCszOoMrNtSjGMx7DhkNd
  nrIvkJzyUwVU-UmbZBHhhfJ_sb7bZ34aSVbSjh8smDsEoPLSA",
              "dig":"S512"},
            "Yu50_fuQ4RhYOlOjCENjKFmKjcWcnb08of_ZaW5Kg1KovLyN5bsa
  x3TH9EKsQ50AuJ_bp6xXlhYY0arhBudTm4G7oPc8TYRdCMw4-bs4iGGu8zFoXCAex
  6eC9_LJbyTw20DmFIzCt6Jdpos2oQZ6GyT-x8PCxImuOzToiP6x2O4",
            {}
            ]
          ],
        "Store":"Credential"},
      {
        "Envelopes":[
          ],
        "Store":"Contact"},
      {
        "Envelopes":[
          ],
        "Store":"Task"},
      {
        "Envelopes":[
          ],
        "Store":"Bookmark"},
      {
        "Envelopes":[
          ],
        "Store":"Network"},
      {
        "Envelopes":[
          ],
        "Store":"Application"},
      {
        "Envelopes":[
          ],
        "Store":"Device"},
      {
        "Envelopes":[
          ],
        "Store":"Access"},
      {
        "Envelopes":[
          ],
        "Store":"Document"},
      {
        "Envelopes":[
          ],
        "Store":"Publication"},
      {
        "Envelopes":[
          ],
        "Store":"Inbound"},
      {
        "Envelopes":[
          ],
        "Store":"Outbound"},
      {
        "Envelopes":[
          ],
        "Store":"Local"}
      ],
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}
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:
The response contains the requested envelope:
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":[{
        "Envelopes":[[{
              "enc":"A256CBC",
              "kid":"EBQH-FCIB-JKQT-746V-FE2I-IEEI-GMEC",
              "Salt":"WsdkI2icQX-czV4twcrQSQ",
              "recipients":[{
                  "kid":"MDZV-J4CB-QLA5-K6GU-GGP2-OAXS-3FB6",
                  "epk":{
                    "PublicKeyECDH":{
                      "crv":"X448",
                      "Public":"nNKy3ud25ZOHhOpIoCREUMru72r9RPny4
  8Tg_yw7JELHYek0nEgUiVgYJiVUweGMmPL0HC-KdY4A"}},
                  "wmk":"LLtDyCCrKdEbVEzohPLP2Q_ZxMLz9qv2dXLBiaB2
  XVkFHt-Jxa9rgw"}
                ],
              "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQUNMLTVM
  WFktS1hGNC00MzJCLVhDWkEtV1RGNC1RUDVRIiwKICAiRXZlbnQiOiAiTmV3In0",
              "SequenceInfo":{
                "Index":1,
                "TreePosition":0},
              "PayloadDigest":"jus6Cpy4Fk_4HN2oW7xhkBSv6Ah-cAImeN
  rmBbcQy4heAkyzHiOouwUNiy1ek-eh68q2zgEwaqWAxVUutj9sMQ",
              "ApexDigest":"rY8d41_tcAvacoZ7x5NI2GmM9R33bPgWN_uTc
  VuKD6cuj6aTFqwdY2nCSRiyE6Pw_lpUIdiDEWz6XmdQh33Z3A",
              "dig":"S512"},
            "lzE4p_C7tj1-0YCg1J__UUvK-WqDtWDCOvsm4MN0y95R8-XpbgEi
  888BlNOnp6d1pvNNKHtxtNzO9_yOMKTAur3B6a1nag1-x35DddfV-8Ho9DjSAoMGh
  NWZ6I336ggTSHMOWLJXbqxBYCUrnBHMZn7ZWADU0IoqzE4VXsODflmYQihY2sPQMO
  iiHM07WD_r"
            ]
          ],
        "Store":"Bookmark"}
      ]}}
The response reports successful completion:
{
  "TransactResponse":{
    "Bitmask":"AAEAAA",
    "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":"MBRN-LSG3-IBIK-2RUK-U4TO-HOZK-7ZJP",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkFNLUlCRzctNE
  lNMi1VTks2LU5RT1EtSEZTUi00TEJEIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo1NloifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJBY2NvdW50QWRkcm
  VzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiQXV0aGVudGljYXRlZERhdGE
  iOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1CUUQtQ09ERS1YTVdKLVFIRTMt
  MktIWi1VS0tGLVRWVkYiLAogICAgICAgICJDb250ZW50TWV0YURhdGEiOiAiZXdvZ
  0lDSlZibWx4ZFdWSlpDSTZJQ0pOUWxGRUxVTlBSRVV0V0UxWFNpMQogIFJTRVV6TF
  RKTFNGb3RWVXRMUmkxVVZsWkdJaXdLSUNBaVRXVnpjMkZuWlZSNWNHVWlPaUFpVUh
  KdlptbHNaCiAgVVJsZG1salpTSXNDaUFnSW1OMGVTSTZJQ0poY0hCc2FXTmhkR2x2
  Ymk5dGJXMHZiMkpxWldOMElpd0tJQ0EKICBpUTNKbFlYUmxaQ0k2SUNJeU1ESTBMV
  EV3TFRFMFZERXpPakV3T2pVMldpSjkiLAogICAgICAgICJkaWciOiAiUzUxMiJ9LA
  ogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V3b2dJQ0FnSWtWdVk
  zSjVjSFJwYjI0aU9pQgogIDdDaUFnSUNBZ0lDSlZaR1lpT2lBaVRVTkVXaTFGUVRN
  M0xWQlFURUV0VmpWQ1VpMHpObFJRTFU1TFJFSXROCiAgRFJYVlNJc0NpQWdJQ0FnS
  UNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2V3b2dJQ0FnSUNBZ0lDSlFkV0oKIC
  BzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSUNBZ0lDQWdJbU55ZGlJNklDSllORFE
  0SWl3S0lDQWdJQ0FnSQogIENBZ0lDSlFkV0pzYVdNaU9pQWljbTVSUm5GWlpUSXRZ
  alUxUWtveU5IZG5SRFl0ZVdkWmQyUlVWblp1YkhsCiAgalNIUlRTVFJ0TldRNWRHM
  WpMVmxKTjJKYVRnb2dJRWRPTTFod2RGZG9XVGhXWm1WUFMzUnlVMjE2Vld0SFEKIC
  BTSjlmWDBzQ2lBZ0lDQWlVMmxuYm1GMGRYSmxJam9nZXdvZ0lDQWdJQ0FpVldSbUl
  qb2dJazFEUTBndFZWQgogIEpUQzFYUzBsR0xVRk5OVlV0U0ZSTVJpMHpNMVJNTFZa
  SU4xUWlMQW9nSUNBZ0lDQWlVSFZpYkdsalVHRnlZCiAgVzFsZEdWeWN5STZJSHNLS
  UNBZ0lDQWdJQ0FpVUhWaWJHbGpTMlY1UlVORVNDSTZJSHNLSUNBZ0lDQWdJQ0EKIC
  BnSUNKamNuWWlPaUFpUldRME5EZ2lMQW9nSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk
  2SUNKblRYbDFPSFZuWQogIG10T01rZFFaRzEwT0VvMldrUXhZM000VW5oT2NEWmxS
  MWRpV0dwVmFuUjVTMUl5UWtkSVlrOXRkbU5XQ2lBCiAgZ2RYbzVjMDlJV2tGTmVWV
  kRVVkJ0WVRCd1FVcG5SR2RCSW4xOWZTd0tJQ0FnSUNKQmRYUm9aVzUwYVdOaGQKIC
  BHbHZiaUk2SUhzS0lDQWdJQ0FnSWxWa1ppSTZJQ0pOUVZCSUxUWXpObEV0TjBaTFZ
  TMUdNMGhLTFV4UVEwTQogIHRXa3RWUnkxWlZ6WTBJaXdLSUNBZ0lDQWdJbEIxWW14
  cFkxQmhjbUZ0WlhSbGNuTWlPaUI3Q2lBZ0lDQWdJCiAgQ0FnSWxCMVlteHBZMHRsZ
  VVWRFJFZ2lPaUI3Q2lBZ0lDQWdJQ0FnSUNBaVkzSjJJam9nSWxnME5EZ2lMQW8KIC
  BnSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk2SUNJdGJEZHBPV3gyTTNacmVWWkdORzV
  TVHpaRlNFdFhSVXMwTAogIFUxbk5HUnNSV3BxTTFaaFZHeHFjVGR3YUZsclNuaHFW
  bkV5Q2lBZ1UyOHpTVWx6WTFaU01rUkNPRkEzZWxkCiAgTk1sQjNibGRCSW4xOWZTd
  0tJQ0FnSUNKU2IyOTBWV1JtY3lJNklGc2lXVXRQVkZveVRVRktZazkwVEVWU2EKIC
  BXZFJMVXB4VjFOVmVVRnlNMTlXZUd4MVdtMXFZVnBOYUhSc1dGRmlkbEp0VmpJS0l
  DQnhlVlpLVTFCWFJ5MQogIE9USEJ0YjNNeFFreFBNMWN3TmpRMFJsQjZZM2swVFdj
  d04zcEpJbDE5ZlEiLAogICAgICB7CiAgICAgICAgInNpZ25hdHVyZXMiOiBbewogI
  CAgICAgICAgICAiYWxnIjogIkVENDQ4IiwKICAgICAgICAgICAgImtpZCI6ICJNQ1
  JaLUdaM0QtQUFTMy1ITEpNLUlSUkktQ0Q0Si1WRlNKIiwKICAgICAgICAgICAgIlN
  pZ25hdHVyZUtleSI6IHsKICAgICAgICAgICAgICAiUHVibGljS2V5RUNESCI6IHsK
  ICAgICAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAgICAgI
  lB1YmxpYyI6ICJEMDlsTlpYVWNCcS1uN2V1QmduZEVfbkozeFk1bDBGRVFIZmdwZD
  NCNGFtVjNmWWhsYk42CiAgQWRoVGRrRElGTGVETnZJaUJpb3ptVVVBIn19LAogICA
  gICAgICAgICAic2lnbmF0dXJlIjogIkQ1RHhCZEhmRS1XaTYtTFlXSVB6SVJPMlFk
  clE1VlBXb0h1RlRBblA5em9qQ0tfXzYKICBkTjZpWUtpc0NUMWRSRFhJR3dpQ2UtV
  HJVdUExNExycTBibWpvTko1MEY1Z2hFTnFPbFR6ZkR6WFY4QmpXegogIFBRTDBhZ1
  9WV3BOM0phaVUwSFJnVFZ2a3VnUlhwQUVFLUJaZFBHQzhBIn1dLAogICAgICAgICJ
  QYXlsb2FkRGlnZXN0IjogIlhSWmZNUjA5MENuN2xEQ21HWTJnT01TX2NHaUUyYzhk
  NkpMaF8zM1RKMHh4ZgogIFdXdlFFa3l1cDdyZ1FNcFdaTnFJRkVXQlFaRTJPZ040S
  2IwZ2JRSGJ3In1dLAogICAgIkNsaWVudE5vbmNlIjogIlB5X003eGxvNXJMQjhhdE
  VwQ0NRaUEiLAogICAgIlBpbklkIjogIkFBS1UtTUpLVy1HUkRTLVMzWkktRE9OSC1
  ENlVTLTRSRVciLAogICAgIlBpbldpdG5lc3MiOiAiY3FlZDMzclJvQzRmSG5WVGp6
  cmVvYV94NUJMS3BMbWhZNWpJZnhCZUNPRGdicUpjCiAgbGh5Q1dtb1ozMG9OS2NHd
  TR0RXZQN3d2c2xVOGg0aU1vYlNSTmciLAogICAgIk1lc3NhZ2VJZCI6ICJOQkFNLU
  lCRzctNElNMi1VTks2LU5RT1EtSEZTUi00TEJEIn19"
      ],
    "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":{
    "EnvelopedAcknowledgeConnection":[{
        "EnvelopeId":"MDU6-DXWG-L3TO-TDYK-VNXN-7ZIR-IOSW",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJBNkozLUVWVTUtUU
  dCTS1XSTRaLUhZVUMtT05IUC1PM1ZDIiwKICAiTWVzc2FnZVR5cGUiOiAiQWNrbm9
  3bGVkZ2VDb25uZWN0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmpl
  Y3QiLAogICJDcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NTZaIn0"},
      "ewogICJBY2tub3dsZWRnZUNvbm5lY3Rpb24iOiB7CiAgICAiRW52ZWxvcG
[encoded data, 5525 characters]
  PTkhQLU8zVkMifX0"
      ],
    "EnvelopedProfileAccount":[{
        "EnvelopeId":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFDLTdPSEEtUk
  5CQS1GUkRMLVI0R0ktWVFIQS1ETDM2IiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ",
        "dig":"S512"},
      "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJDb21tb25TaWduYXR1cmUiOi
  B7CiAgICAgICJVZGYiOiAiTUROVC1XVDNHLTM0NkctNEk1VC1ZVjdGLUxUUVgtUFN
  OVCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNL
  ZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICAiU
  HVibGljIjogIklNeU1vN2ZFeTJ2SHA4c3lRMFZVNFhpdnBKRWhnUVFTWDNqOG12YT
  RIQ19UMDVVbmhRWXEKICBWWnl1dklRRVZvMmR5TUNSbTYwUTNFMEEifX19LAogICA
  gIkFjY291bnRBZGRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIiwKICAgICJTZXJ2
  aWNlVWRmIjogIk1CUUQtRVRYVS1IWlJXLUEyNk8tV0RUUi1LN0dJLVg2SkQiLAogI
  CAgIkVzY3Jvd0VuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNLRC0zTVI2LV
  AyVEUtTTZVNC00TElPLVpUUkctRFpWUyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJ
  zIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6
  ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMXZOVUFBcDNyc3pJcGhHOEVzZ
  m9hTzVZNnNaQ24wSGM4ekNnZFFpdllwSkFjRHRta1NzQwogIGVJMmdtRFRDSzZTcl
  MxVWdQdHVZbVR3QSJ9fX0sCiAgICAiQWRtaW5pc3RyYXRvclNpZ25hdHVyZSI6IHs
  KICAgICAgIlVkZiI6ICJNRDJMLTZNN0MtWjNaMy1RM0FMLUpGWUktWklVQy1CS1VS
  IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tle
  UVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdW
  JsaWMiOiAiYkhvS2IwYzEyRjdjaWJNXzNnWmNKWE16T09YNHNuSGdQVndPZlJZazZ
  BUkpPc0dQZW1zZAogIDJCbTBXZm1Ba1JZTzNFUTZmajhfTnpTQSJ9fX0sCiAgICAi
  Q29tbW9uRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVlGLUQ3TEotNUlNU
  C1FVUNHLUhTR0gtN0xTUi1BQVBaIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOi
  B7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg
  0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJjN29vcko4MDhzYzlkNDBLWERoSUhn
  Q1RGejM5TUszSmpPMFE3S191ZkRFR0RLaXdWS2hkCiAgM29QUTQ0UEVxR2p3a3BwN
  09mYmNCYlNBIn19fSwKICAgICJDb21tb25BdXRoZW50aWNhdGlvbiI6IHsKICAgIC
  AgIlVkZiI6ICJNQUZULVNJTkEtU0ZYSS1QQkRZLVdSSEUtTlhZTC1EWFZUIiwKICA
  gICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgi
  OiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6I
  CJYY2dFejl5MmNxc3g0WmViR0VSVGpyTi14ek44M0QtcGN4MDY1MXgtV1VDcVlOcn
  NuelRICiAgNDBDcG9NeHVOLUZucFQ1bV9iME15dUtBIn19fSwKICAgICJSb290VWR
  mcyI6IFsiWUJKUjNqUjJQbGpkWWs1cXhiV2RIWTByVFlFYUZBa0hZM01tc1I4enZO
  MURyMzNSbkwKICBVTDNUaHJHOURNV0JaM1AtOFp5R3p5S2FRWXdlY28yWlV0Y0t3I
  l19fQ",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MAJF-DXRU-OY7F-RXLC-JZVM-LNM5-DWGS",
            "SignatureKey":{
              "PublicKeyECDH":{
                "crv":"Ed448",
                "Public":"9sZGEfYSIoTvVSL0Q5c_Oip_Hi2iOTsl4L3iLwh
  fOv9bA-5nd7PyRooKEsQx-lA7PMAYBewSOmIA"}},
            "signature":"6x3k8AC2jkUQv0jzlUVWJDqP7zcNkKAqvPcAs7Ci
  2jXULjbIFAFCct8GC8Nb8KiD5ljoLAsVHr-AnYcjklyXSHN6Gn_BIZiLiW3Yu5_Ch
  XHspywX-ZGMD6soXJIilOzreauR-_aiUE7Gx0eh3Fje2wEA"}
          ],
        "PayloadDigest":"tXPfbmg_SRmARF_7HLPq-bM6NMO1h1Oa30f_Ag_T
  IRzGKMrmTKtV7XH-h3NIBFGxOQYuD0BproKNEg6uhtG0Mw"}
      ],
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

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":"MDDD-KNM4-KUZH-QVC4-KWLI-5NBW-T54I"}}
The response payload:
{
  "CompleteResponse":{
    "EnvelopedRespondConnection":[{
        "EnvelopeId":"MAXJ-OILL-BOXO-U6UW-C7T5-ONQV-PY7R",
        "enc":"A256CBC",
        "Salt":"XnZVi9-npm0l29WsKI7Leg",
        "recipients":[{
            "kid":"MCDZ-EA37-PPLA-V5BR-36TP-NKDB-44WU",
            "epk":{
              "PublicKeyECDH":{
                "crv":"X448",
                "Public":"wS0AFAueGZ5yW7naIw6aoRiXzlJi0WscQOMf2md
  18fxRLQSO9dVGcPXJBKf7r7F9jOmX3E5SC62A"}},
            "wmk":"Ve5H9q2D9v4TqVlWRIYP57loyBwVuXjMHN1LRq0j-m_8fX
  42Aav5tA"}
          ],
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNRERELUtOTTQtS1
  VaSC1RVkM0LUtXTEktNU5CVy1UNTRJIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVzcG9
  uZENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo1NloifQ",
        "SequenceInfo":{
          "Index":3,
          "TreePosition":449},
        "Received":"2024-10-14T13:10:56Z"},
      "xMjsh-u3PRAtFIo8z66UN-y-dmUHrd1HXfTWvLNg2QiUIEd_SM8FxrWJZo
[encoded data, 32760 characters]
  5Im22na_ekwAhqLWyoTYXilE3kpbkRXFPJ6TYOLb3vpFOBl0azqUVyNNI",
      {}
      ],
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

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":{
    "PublicationId":"EBQJ-VQU2-NBCP-XCDF-PFWE-J5H4-BR26",
    "ServiceAuthenticate":"AAF3-24BG-U75Y-3GT3-K6NG-KXWE-QCWA",
    "DeviceAuthenticate":"AD7A-4KSW-37QZ-JGT7-SKGV-KZH2-36C3",
    "MessageId":"NB4P-XQDR-JVO4-MD6R-47BZ-G6ED-J543",
    "Sender":"alice@example.com",
    "Recipient":"maker@example.com"}}
The message is signed by the claimant to make a RequestClaim to the service:
{
  "ClaimRequest":{
    "EnvelopedMessageClaim":[{
        "EnvelopeId":"MCET-4P2O-3PEK-4PCH-7HGM-N5RL-M36D",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQjRQLVhRRFItSl
  ZPNC1NRDZSLTQ3QlotRzZFRC1KNTQzIiwKICAiTWVzc2FnZVR5cGUiOiAiTWVzc2F
  nZUNsYWltIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJD
  cmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NThaIn0",
        "dig":"S512"},
      "ewogICJNZXNzYWdlQ2xhaW0iOiB7CiAgICAiUHVibGljYXRpb25JZCI6IC
  JFQlFKLVZRVTItTkJDUC1YQ0RGLVBGV0UtSjVINC1CUjI2IiwKICAgICJTZXJ2aWN
  lQXV0aGVudGljYXRlIjogIkFBRjMtMjRCRy1VNzVZLTNHVDMtSzZORy1LWFdFLVFD
  V0EiLAogICAgIkRldmljZUF1dGhlbnRpY2F0ZSI6ICJBRDdBLTRLU1ctMzdRWi1KR
  1Q3LVNLR1YtS1pIMi0zNkMzIiwKICAgICJNZXNzYWdlSWQiOiAiTkI0UC1YUURSLU
  pWTzQtTUQ2Ui00N0JaLUc2RUQtSjU0MyIsCiAgICAiU2VuZGVyIjogImFsaWNlQGV
  4YW1wbGUuY29tIiwKICAgICJSZWNpcGllbnQiOiAibWFrZXJAZXhhbXBsZS5jb20i
  fX0",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
            "signature":"z03VvboD_IvshEuYEuRalFRGERvq1vHOJIWJzPNU
  gwLURsGLxxtfjE_1JtNWYe8kndOhVJo9_46A_Vx2DiAZ4ngzzYXoSpqAFgz7Ejqd5
  s1B7K1ehk5ToIK0oYOGoQ--npioQHEccyfUrQalwe76zx4A"}
          ],
        "PayloadDigest":"aobSWyLEGCMF0JbRdOst2LQPvpXI3ZVd45r3sjaV
  uO0FwMNtiiCGmjArENV3rVarWEAwLGBVYhVnpqw-S43pXw"}
      ]}}
The publication is found and the claim is accepted, the publication is returned in the response.
{
  "ClaimResponse":{
    "CatalogedPublication":{
      "Id":"EBQJ-VQU2-NBCP-XCDF-PFWE-J5H4-BR26",
      "Authenticator":"ECMR-LTTI-XRTX-EXOY-K7U4-WHBZ-B6RQ-EECF-S44N
-ZACS-OPFF-73UN-WOHB-U",
      "EnvelopedData":[{
          "enc":"A256CBC",
          "kid":"EBQL-OM6D-RFHG-GGS3-DROH-6PLS-MU3G",
          "Salt":"Y5tvWUmCqp4z2DDdAWa_tw",
          "recipients":[{
              "kid":"EBQJ-VQU2-NBCP-XCDF-PFWE-J5H4-BR26",
              "wmk":"YfJu1nJPXW1hRH7eDes_N9LMAXai-3hjO9uUKvFpC2MY
  vZQllFjIhw"}
            ]},
        "6HQDAIDsWjnl6nkYcLwyXpNcxXCgsEq1S9E9M2FiLYImPgefjo4baMQL
  fQWa_Al9yjHLNSziOPidvQ-tpk-PmhrtwzAC4-9FC7AHPyicqzTk3dtsRLigqi9mL
  VW02h1zrJnTR8sHkt_WO4_FrmkqLHeTsZlqXm9No78UINGHt_ntffBd2NPwfiejkV
  l6X5DA_CxwPZdFS3cOUORyJjgMCKcrbast50u2rGieT9nBCGAxqMffwK5T35eRGKS
  OLh-92hXRF0K6yM1RBkXCTpCFdz807NnJPXiY1kwPwjptPVwTNsTgAXMl-IqGuaM5
  Qglj4thR-OnQgDui_T51VAKBaICGjYbsGsq9XfJlrrQf9VJIVQ42C3REPaE1a07wI
  USLrjKxEgT9K13Y9BrP47rI43Z-75rC60C0nA5gzFQSlOtRt8LdcN_sX-JN_maY7M
  hZCVYdehKxUgAUqCt5MHuliQA4atczYIyDbUy2o31xj5vUtL0cX7MSIDu3F26P3w0
  jVwDeNW1HfCs33_kqQHzLATr6vTwsgFkwhrq_DGbkJhGAiZjGfG-9s4CEckUUByDr
  Qu-umCAsnIWHPeLywTFiOtE9t7oPD_C1oIzf0MG0Jxl4CCS23X59lIrQzba1a7tXs
  6oCJtSsPqLVdIHzOW0pK96725VLPnBHwo2DcjM4aWHLqr1dk5WGrSNBgeT_y6hH2y
  pE6xfeh57oTxCX8S0ThzKrm7nnVWVxBKE9YEyWJExEBqJEbiTeQqk0RwhLcgb1ECN
  DHuwIe9FWwfJOltyI1bja65EzBKiJrHLF1mjJEZIlTfLzzH-49Mf4zO9N6pdO_MmG
  VJJw_WvZZ-aBHoGLtP6SLLbAFPizSX_-io_eqIzmAnDLVZUJXNpHpUad87tX7gSJj
  J4J83E9vD1sA9BYzwRZiX6aRpaUxn-8Q2Af9Po4_mOjZPMtwwWrk883Wpz23WiIxf
  pVOPVazd95pqCdrQXLRQbTE-xa8ZI5uPz3vtNdiNy5I7gMYzANoU764CAWjVap8Fi
  dQBlALt2rEJ6fG87ulmYcmP-D3aeh9Cs-0r3mBlNWZnlf7y7yjfKRGmQRC6QyPToL
  kdg6bXAxpf7Mxao28VCcClTKsdr5IxknIZiarsi6lqOgYvYS2hbC2fnuSU6cRRAUH
  7EIVS--7nDLYtDAZAoS1ZEkAbc4R6Qq5LeDTbW3I9UwjhY5d0wKeQh_6MBzU4wUAV
  2kLDaOFId5PEYJMXdo2OwKTv6IGMEx7umcM0TReGp8-uqElp2Fp7VZGzzeCI4g0_C
  FsO3aY_uyHBYLZq9JiHgDG7decs0YxOzHmpiYaMqgCNkfJNTsbJ1sCUdTXabUM5Tp
  JB2UO6uetpl_oOoA-vKGcQMnzMIh2S-mm2NsVkZktDinBjnwb_X3EyPVBUybKj8RC
  K4RN5clEXb7l-ddQqIxNZlxUd5o3XyICYMGSPvq9DiXktnpnH9bQDhHrdB4_r_3u3
  XENxlytln3p5Cwk37pJyQTYGknmLtmyNFGWo_RVUZCivnT5OEgkUm1FkTdH9xZ_WF
  JwEs7Yxt9pRQQKFj2AtcB0DqeGtOvJc1eg1z51xe-Le8tkBlQzz4XS58HDrNnrlw9
  QSaoUCEP2sO_8M2SgCNBkeFQO0EAf0pdAClJUy52xyTqSJo_FsjJkE0h1wnSxxFd4
  SMRiGpbpGh1VxzrWgM_3txrjk8Sp7OQqzN3kquc2OS86PuZfDOBEsq_-gr2pLNGGH
  xxZ4EW82TUgynRBohITHmYwGfisUx0YWtWR2ZhlS-KyvFaNCE6hdN2BwOtdsfouOO
  xjjOZfwiOxFx0MMkN2WSoocXxS1HudynfI23J5FWfJRhWpsDXfcOznZ2kAB014Kj5
  MF42ZusxrHlRTnHQG3OmfcW6NnoyjOPXjiGk-CgHVI-P2xZi77xbr9okZlW7QmNvE
  ZZtgYZosLWc9QdLEnR17S8hScjgDC06ByRvVHKocSs-CdwtjfjXBAXitJRkNryzPr
  NOaYMLGhrMLeMA1X3eVfyB0zEyN6rEndnNwquqzevvV-J-p6hfuVVAkEK1ya7Suo_
  j_vDOXtuX2mBr0l0DkkdgYlJcrLX7Slb6G40vVDZPmd2aQbB3ZGExTEL9Zlczp7T5
  2fuK75lnbn9Osd50BnuSZ_LBGmpDNp2IxPqz7nel7wMEZW0zEyw_RAGqrzWLasi4t
  GovT0VNI4oc-h46I6e09eY83RoUwVNfgy9WSCR2Fb1fubqURgTkoOdptFAVy2Efel
  gRaWoaSnnz8xo8Pt2JAb1zRiWDgBrICe4QelPRlokNrAORCMBL2_GgWd_gv9h5Hrl
  gumJOmUiae8Iar7Gh08VzlYwk5JqA3xX6ooy2rnTKTJjKb9UdeApxooHvMnwxdnK9
  A9LT5vbKYIQEcyOm6A3pcesJIUy5CF9fHsOvh-tS4Hg86xRoq1O6UEInwAJ7P5l5s
  9Yh9Ge6EIq7JoffWFADCD0TN2MqrACBDdsbblE2TeC5nRJqKvGRv35j0PUVxCozb5
  tEpj__CbXzJs4PrtCeu96npz6JTXesUIYNuvQD-7MkHjuAI7A-P4KrER14mjfftwi
  G6TlF9CMAhCTmDcFg21g7xtk_Ku6CA_diXU7dcjHyXzy0nECoTPzyJYBkoy22RLpu
  K65JbMR8cpDjB5hyYkiuDtVGRGcGpWWdq0qJPaXwIl2rmEHnjzzOyKovXFJyzEhmY
  m5jYwHbRhtBAUl3zZ5A5xHKi05OyDeiOESC7gJaISHPi0cWxIRc7hZ0VZ0n2asMi2
  kW5ddh4MyLSD4qIwgCB5QC8CdTOoG2mM4PLgmJ1bLhi7Wkr7ndAPD4TA5FyPUD8L8
  LjolfOQWwJfSe6UknbDYcRnUHVRp689OwzIPMHV00fxkK7ZCbL-Kcg8ea9oaZ-s5v
  _mkv7KMCed3B7V38FokYxuw1dVZODgxthk2nahCZ-cxAkgqgPDIuTrITIeqeykJiF
  UZRAldM_781GmMr-p_8HS25QVht"
        ]},
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}
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":"EBQJ-VQU2-NBCP-XCDF-PFWE-J5H4-BR26",
    "TargetAccountAddress":"maker@example.com"}}
The response returns the latest claim made as signed message:
{
  "PollClaimResponse":{
    "EnvelopedMessage":[{
        "EnvelopeId":"MDNB-MBUA-NUS2-B7D3-6FIZ-OAPG-D4L5",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQjRQLVhRRFItSl
  ZPNC1NRDZSLTQ3QlotRzZFRC1KNTQzIiwKICAiTWVzc2FnZVR5cGUiOiAiTWVzc2F
  nZUNsYWltIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJD
  cmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NThaIn0",
        "SequenceInfo":{
          "Index":1,
          "TreePosition":0},
        "Received":"2024-10-14T13:10:58Z",
        "signatures":[{
            "alg":"ED448",
            "kid":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
            "signature":"z03VvboD_IvshEuYEuRalFRGERvq1vHOJIWJzPNU
  gwLURsGLxxtfjE_1JtNWYe8kndOhVJo9_46A_Vx2DiAZ4ngzzYXoSpqAFgz7Ejqd5
  s1B7K1ehk5ToIK0oYOGoQ--npioQHEccyfUrQalwe76zx4A"}
          ],
        "PayloadDigest":"aobSWyLEGCMF0JbRdOst2LQPvpXI3ZVd45r3sjaV
  uO0FwMNtiiCGmjArENV3rVarWEAwLGBVYhVnpqw-S43pXw",
        "dig":"S512"},
      "ewogICJNZXNzYWdlQ2xhaW0iOiB7CiAgICAiUHVibGljYXRpb25JZCI6IC
  JFQlFKLVZRVTItTkJDUC1YQ0RGLVBGV0UtSjVINC1CUjI2IiwKICAgICJTZXJ2aWN
  lQXV0aGVudGljYXRlIjogIkFBRjMtMjRCRy1VNzVZLTNHVDMtSzZORy1LWFdFLVFD
  V0EiLAogICAgIkRldmljZUF1dGhlbnRpY2F0ZSI6ICJBRDdBLTRLU1ctMzdRWi1KR
  1Q3LVNLR1YtS1pIMi0zNkMzIiwKICAgICJNZXNzYWdlSWQiOiAiTkI0UC1YUURSLU
  pWTzQtTUQ2Ui00N0JaLUc2RUQtSjU0MyIsCiAgICAiU2VuZGVyIjogImFsaWNlQGV
  4YW1wbGUuY29tIiwKICAgICJSZWNpcGllbnQiOiAibWFrZXJAZXhhbXBsZS5jb20i
  fX0",
      {}
      ],
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

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":{
        "GranteeUdf":"bob@example.com",
        "EnvelopedKeyShare":[{
            "enc":"A256CBC",
            "kid":"EBQH-2PZ5-HTKM-HC3Y-N6YT-VQ3A-ZZCR",
            "Salt":"H00N80phHkIfP95CI5ZlZw",
            "recipients":[{
                "kid":"MDET-26NB-5GRV-JOWD-HJ6D-6WUN-JLWE",
                "epk":{
                  "PublicKeyECDH":{
                    "crv":"X448",
                    "Public":"MDbm9mOsQDWbtNQahw0CnoIFuZpoVsj8gtZ
  8F-yN11ioJnoxCz9S_v_mIDFOWiZAqy0a5I3YTjOA"}},
                "wmk":"p2KrCgM3HliVXkJLugonLHpT8ZPxxBWm1jZxOOWkBp
  8uxIAXFySoeA"}
              ],
            "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJLZXlEYX
  RhIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmVhdGV
  kIjogIjIwMjQtMTAtMTRUMTM6MTA6NTVaIn0"},
          "wsXytUHUeYC6ko5uTPalgTsmTG1car6vZIbVPUcbgS81xAawr1wwAr
  ytRIJE2Ji3FbY4pQA8RRdzBAuxAbSTZIIvsCic3nYQ8wuxyX3JWkUPtuHj-5G4R3W
  o2TVHS2BQUywYgnCHOcfTaPLr2O1arDQ3fo401dYeJtFSPiOexmwjsghD_KXILmBA
  tUTZnp6UPI0yQd90Qmxs6QonkHgYwY8pmCoLJxebyf80C0teU4u5O8I1t0Nxlw1oH
  8Z6zgB-0K8u8lmf0h0IwxZRLnGjMAivV8D1n9SIYMZEnYzpItXu5zxf8z_RV15GO5
  d9qy3SRtPOlGSZXI3Xn_CRk9dt6jUbpGl-NCbqXAweA71x1dgTMXcDozHbL0UQhHH
  ZZlq8crxgfGAGr1PBHFc8Wg4yDxU_JLzwz3V2r7RnnMXfJsgE2-F-SZVYTtpZQ5LW
  DiuEMF5UR6wxz7cdd4hY-z2CjoydhrWmBBOCGgn7wwzd6XkvMg02trFAYM63psNr1
  YWh8qvI1rtx1h8DVKErp-2w2x64Hc1Tf7gW7eExGoFHG8nIWfEpJ28arPLoD0Z2tE
  5xAZ6UmlY3zYjU_rTmf62qhjNVdag5qu_YPilWHlD4oHvGh67e04QUOnzLR-UoScy
  BSdF1u6_HxenHJ46NV4mbzmZV2KvQw9Y7aMDLeR3gufmRR2Tr9nuKhQnO3zWSE68p
  VXIRxz5rVmo_fYtg3PrcdQ"
          ],
        "Id":"MBNJ-RWYE-WXIY-ETHX-RIVA-RKHM-Q7QC",
        "Active":true}}}}
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":{
          "PublicKey":{
            "PublicKeyECDH":{
              "crv":"X448",
              "Public":"ZoSHmhH63m5wJqoaS3V0-B3KN2WL29IsJWdRDyIaT
  -glv5ZhlHZq0gN0_qWhpYt8yZYm0St0P9aA"}},
          "KeyId":"MBNJ-RWYE-WXIY-ETHX-RIVA-RKHM-Q7QC"}}
      ]}}
The service checks to see if the request is authorized and if so, performs the operation and returns the result:
{
  "OperateResponse":{
    "Results":[{
        "CryptographicResultKeyAgreement":{
          "KeyAgreement":{
            "KeyAgreementECDH":{
              "Curve":"X448",
              "Result":"9iLvBSWGWu_iAvqdLxB8D-0yNFhNDe8it5FMZ4J7Q
  w6y25Z_oP4GTB9mxMucGukzeF0V0HiQeU4A"}}}}
      ],
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}
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

i

e
  '

b

M

S

P

S

l

o
  '

M

i

c

A

l

s

o

b

c

B

s

P

A

e

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":{
    "Account":"alice@example.com",
    "Expires":"2024-10-15T13:10:56Z",
    "Automatic":true,
    "SaltedPin":"ABYY-PTS3-HOUO-E3VH-TOCJ-GFJI-XPHS",
    "Action":"Device",
    "Roles":["threshold"
      ],
    "MessageId":"AAKU-MJKW-GRDS-S3ZI-DONH-D6US-4REW"}}

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":{
    "References":[{
        "MessageId":"AAKU-MJKW-GRDS-S3ZI-DONH-D6US-4REW",
        "ResponseId":"MDDD-KNM4-KUZH-QVC4-KWLI-5NBW-T54I",
        "Relationship":"Closed"}
      ],
    "MessageId":"NARB-QXHR-HQFR-PCAS-D3L6-YGJX-LXCL"}}
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":{
    "Reply":true,
    "Subject":"alice@example.com",
    "PIN":"AB3A-ETHW-4RGL-GEYG-KEAP-TLEM-UKDQ",
    "AuthenticatedData":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250YWN0UG
  Vyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmV
  hdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NDlaIn0",
        "dig":"S512"},
      "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkNvbW1vbk5hbWVzIjogW2
[encoded data, 4615 characters]
  mJvYkBleGFtcGxlLmNvbSJ9fV19fQ",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MBOE-XGDX-ZTVE-T4MA-QJIN-7ZW5-EUU3",
            "signature":"AS3_3bTTS5t7txywPXMdENgK5g4P2Ulcoyhu9gL2
  I4FGaEdjeEuGJbIIDqNcCl3xq0Wk4ATnBIqAAXtRTtEfx1UOveTRvbS77VhMq8Hz6
  VU83pwUWfdpGWtKUgTVOuMLVggT199OfZ42ItIIA3w_ogEA"}
          ],
        "PayloadDigest":"KaXz5nh1C7D_t2XInJ6tHMXDU5oz4B3EfPJpGzzT
  FQVdNpo3LcvYm7oHhh9wM72GQ_fcd0o9HOEF8xmv74Mblw"}
      ],
    "MessageId":"NAJJ-X5FX-POHN-TTR4-3TXK-KTE7-3KKM",
    "Sender":"bob@example.com",
    "Recipient":"alice@example.com"}}
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 14

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":{
    "Text":"start",
    "MessageId":"NAZG-5KBV-D32X-O24L-XTYS-26GV-FC6Z",
    "Sender":"console@example.com",
    "Recipient":"alice@example.com"}}
Alice accepts the request and returns the following response:
{
  "ResponseConfirmation":{
    "Request":[{
        "EnvelopeId":"MCDS-ZYU5-TXDG-FAHW-BAVA-VFRM-XOXD",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQVpHLTVLQlYtRD
  MyWC1PMjRMLVhUWVMtMjZHVi1GQzZaIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbmZpcm1hdGlvbiIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0
  IiwKICAiQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjUyWiJ9",
        "SequenceInfo":{
          "Index":7,
          "TreePosition":6211},
        "Received":"2024-10-14T13:10:52Z",
        "signatures":[{
            "alg":"ED448",
            "kid":"MDMO-SHNV-SDLR-GGIH-W2MA-QTNA-OQUG",
            "signature":"4oOI79pmsbJKxPfdZZgm0h60ZN9Ec5dSXtyBtLHk
  4tKfxRMy-s4JlBO1SZ4xsRzkPkjh_bozL2IAiil1f6F8Kva5UMDMwOs1E363x5zfs
  4ttnMz9KjHD_LSNiG5S7iwMh4XF6-GB-s-ge1a7Cf4TqjwA"}
          ],
        "PayloadDigest":"5oqE8QWpLfTmxhs4GpDS6_Od2dd8PcdDMfI9bgoN
  NrYNnZaNwOI_oloD2i2k65_ENqyBTdM8TLlkc-TtywwwqQ",
        "dig":"S512"},
      "ewogICJSZXF1ZXN0Q29uZmlybWF0aW9uIjogewogICAgIlRleHQiOiAic3
  RhcnQiLAogICAgIk1lc3NhZ2VJZCI6ICJOQVpHLTVLQlYtRDMyWC1PMjRMLVhUWVM
  tMjZHVi1GQzZaIiwKICAgICJTZW5kZXIiOiAiY29uc29sZUBleGFtcGxlLmNvbSIs
  CiAgICAiUmVjaXBpZW50IjogImFsaWNlQGV4YW1wbGUuY29tIn19",
      {}
      ],
    "Accept":true,
    "MessageId":"MDRR-IKIO-BXGJ-Y2QA-ZLJI-YDA2-HC4I",
    "Sender":"alice@example.com",
    "Recipient":"console@example.com"}}

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=ADE7-U5DR-2YNJ-XKVX-4RUE-SVL5-5I
 (Expires=2024-10-15T13:10:56Z)

The registration of this PIN value was shown earlier in section $$$
The URI containing the account address and PIN is:
mcd://alice@example.com/ADE7-U5DR-2YNJ-XKVX-4RUE-SVL5-5I

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 ^
    ADE7-U5DR-2YNJ-XKVX-4RUE-SVL5-5I
   Device UDF = MBQD-CODE-XMWJ-QHE3-2KHZ-UKKF-TVVF
   Witness value = A6J3-EVU5-QGBM-WI4Z-HYUC-ONHP-O3VC

The device generates a RequestConnect message as follows:
{
  "RequestConnection":{
    "AccountAddress":"alice@example.com",
    "AuthenticatedData":[{
        "EnvelopeId":"MBQD-CODE-XMWJ-QHE3-2KHZ-UKKF-TVVF",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFELUNPREUtWE
  1XSi1RSEUzLTJLSFotVUtLRi1UVlZGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU2WiJ9",
        "dig":"S512"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIkVuY3J5cHRpb24iOiB7Ci
  AgICAgICJVZGYiOiAiTUNEWi1FQTM3LVBQTEEtVjVCUi0zNlRQLU5LREItNDRXVSI
  sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF
  Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAicm5RRnFZZTItYjU1QkoyNHdnRDYteWdZd2RUVnZubHljSHRTSTRtNWQ5dG
  1jLVlJN2JaTgogIEdOM1hwdFdoWThWZmVPS3RyU216VWtHQSJ9fX0sCiAgICAiU2l
  nbmF0dXJlIjogewogICAgICAiVWRmIjogIk1DQ0gtVVBJTC1XS0lGLUFNNVUtSFRM
  Ri0zM1RMLVZIN1QiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgI
  CAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogIC
  AgICAgICAgIlB1YmxpYyI6ICJnTXl1OHVnYmtOMkdQZG10OEo2WkQxY3M4UnhOcDZ
  lR1diWGpVanR5S1IyQkdIYk9tdmNWCiAgdXo5c09IWkFNeVVDUVBtYTBwQUpnRGdB
  In19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVBIL
  TYzNlEtN0ZLVS1GM0hKLUxQQ0MtWktVRy1ZVzY0IiwKICAgICAgIlB1YmxpY1Bhcm
  FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA
  iY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICItbDdpOWx2M3ZreVZG
  NG5STzZFSEtXRUs0LU1nNGRsRWpqM1ZhVGxqcTdwaFlrSnhqVnEyCiAgU28zSUlzY
  1ZSMkRCOFA3eldNMlB3bldBIn19fSwKICAgICJSb290VWRmcyI6IFsiWUtPVFoyTU
  FKYk90TEVSaWdRLUpxV1NVeUFyM19WeGx1Wm1qYVpNaHRsWFFidlJtVjIKICBxeVZ
  KU1BXRy1OTHBtb3MxQkxPM1cwNjQ0RlB6Y3k0TWcwN3pJIl19fQ",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MCRZ-GZ3D-AAS3-HLJM-IRRI-CD4J-VFSJ",
            "SignatureKey":{
              "PublicKeyECDH":{
                "crv":"Ed448",
                "Public":"D09lNZXUcBq-n7euBgndE_nJ3xY5l0FEQHfgpd3
  B4amV3fYhlbN6AdhTdkDIFLeDNvIiBiozmUUA"}},
            "signature":"D5DxBdHfE-Wi6-LYWIPzIRO2QdrQ5VPWoHuFTAnP
  9zojCK__6dN6iYKisCT1dRDXIGwiCe-TrUuA14Lrq0bmjoNJ50F5ghENqOlTzfDzX
  V8BjWzPQL0ag_VWpN3JaiU0HRgTVvkugRXpAEE-BZdPGC8A"}
          ],
        "PayloadDigest":"XRZfMR090Cn7lDCmGY2gOMS_cGiE2c8d6JLh_33T
  J0xxfWWvQEkyup7rgQMpWZNqIFEWBQZE2OgN4Kb0gbQHbw"}
      ],
    "ClientNonce":"Py_M7xlo5rLB8atEpCCQiA",
    "PinId":"AAKU-MJKW-GRDS-S3ZI-DONH-D6US-4REW",
    "PinWitness":"cqed33rRoC4fHnVTjzreoa_x5BLKpLmhY5jIfxBeCODgbqJ
  clhyCWmoZ30oNKcGu4tEvP7wvslU8h4iMobSRNg",
    "MessageId":"NBAM-IBG7-4IM2-UNK6-NQOQ-HFSR-4LBD"}}
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":{
    "EnvelopedRequestConnection":[{
        "EnvelopeId":"MBRN-LSG3-IBIK-2RUK-U4TO-HOZK-7ZJP",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkFNLUlCRzctNE
  lNMi1VTks2LU5RT1EtSEZTUi00TEJEIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo1NloifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJBY2NvdW50QWRkcm
  VzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiQXV0aGVudGljYXRlZERhdGE
  iOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1CUUQtQ09ERS1YTVdKLVFIRTMt
  MktIWi1VS0tGLVRWVkYiLAogICAgICAgICJDb250ZW50TWV0YURhdGEiOiAiZXdvZ
  0lDSlZibWx4ZFdWSlpDSTZJQ0pOUWxGRUxVTlBSRVV0V0UxWFNpMQogIFJTRVV6TF
  RKTFNGb3RWVXRMUmkxVVZsWkdJaXdLSUNBaVRXVnpjMkZuWlZSNWNHVWlPaUFpVUh
  KdlptbHNaCiAgVVJsZG1salpTSXNDaUFnSW1OMGVTSTZJQ0poY0hCc2FXTmhkR2x2
  Ymk5dGJXMHZiMkpxWldOMElpd0tJQ0EKICBpUTNKbFlYUmxaQ0k2SUNJeU1ESTBMV
  EV3TFRFMFZERXpPakV3T2pVMldpSjkiLAogICAgICAgICJkaWciOiAiUzUxMiJ9LA
  ogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V3b2dJQ0FnSWtWdVk
  zSjVjSFJwYjI0aU9pQgogIDdDaUFnSUNBZ0lDSlZaR1lpT2lBaVRVTkVXaTFGUVRN
  M0xWQlFURUV0VmpWQ1VpMHpObFJRTFU1TFJFSXROCiAgRFJYVlNJc0NpQWdJQ0FnS
  UNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2V3b2dJQ0FnSUNBZ0lDSlFkV0oKIC
  BzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSUNBZ0lDQWdJbU55ZGlJNklDSllORFE
  0SWl3S0lDQWdJQ0FnSQogIENBZ0lDSlFkV0pzYVdNaU9pQWljbTVSUm5GWlpUSXRZ
  alUxUWtveU5IZG5SRFl0ZVdkWmQyUlVWblp1YkhsCiAgalNIUlRTVFJ0TldRNWRHM
  WpMVmxKTjJKYVRnb2dJRWRPTTFod2RGZG9XVGhXWm1WUFMzUnlVMjE2Vld0SFEKIC
  BTSjlmWDBzQ2lBZ0lDQWlVMmxuYm1GMGRYSmxJam9nZXdvZ0lDQWdJQ0FpVldSbUl
  qb2dJazFEUTBndFZWQgogIEpUQzFYUzBsR0xVRk5OVlV0U0ZSTVJpMHpNMVJNTFZa
  SU4xUWlMQW9nSUNBZ0lDQWlVSFZpYkdsalVHRnlZCiAgVzFsZEdWeWN5STZJSHNLS
  UNBZ0lDQWdJQ0FpVUhWaWJHbGpTMlY1UlVORVNDSTZJSHNLSUNBZ0lDQWdJQ0EKIC
  BnSUNKamNuWWlPaUFpUldRME5EZ2lMQW9nSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk
  2SUNKblRYbDFPSFZuWQogIG10T01rZFFaRzEwT0VvMldrUXhZM000VW5oT2NEWmxS
  MWRpV0dwVmFuUjVTMUl5UWtkSVlrOXRkbU5XQ2lBCiAgZ2RYbzVjMDlJV2tGTmVWV
  kRVVkJ0WVRCd1FVcG5SR2RCSW4xOWZTd0tJQ0FnSUNKQmRYUm9aVzUwYVdOaGQKIC
  BHbHZiaUk2SUhzS0lDQWdJQ0FnSWxWa1ppSTZJQ0pOUVZCSUxUWXpObEV0TjBaTFZ
  TMUdNMGhLTFV4UVEwTQogIHRXa3RWUnkxWlZ6WTBJaXdLSUNBZ0lDQWdJbEIxWW14
  cFkxQmhjbUZ0WlhSbGNuTWlPaUI3Q2lBZ0lDQWdJCiAgQ0FnSWxCMVlteHBZMHRsZ
  VVWRFJFZ2lPaUI3Q2lBZ0lDQWdJQ0FnSUNBaVkzSjJJam9nSWxnME5EZ2lMQW8KIC
  BnSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk2SUNJdGJEZHBPV3gyTTNacmVWWkdORzV
  TVHpaRlNFdFhSVXMwTAogIFUxbk5HUnNSV3BxTTFaaFZHeHFjVGR3YUZsclNuaHFW
  bkV5Q2lBZ1UyOHpTVWx6WTFaU01rUkNPRkEzZWxkCiAgTk1sQjNibGRCSW4xOWZTd
  0tJQ0FnSUNKU2IyOTBWV1JtY3lJNklGc2lXVXRQVkZveVRVRktZazkwVEVWU2EKIC
  BXZFJMVXB4VjFOVmVVRnlNMTlXZUd4MVdtMXFZVnBOYUhSc1dGRmlkbEp0VmpJS0l
  DQnhlVlpLVTFCWFJ5MQogIE9USEJ0YjNNeFFreFBNMWN3TmpRMFJsQjZZM2swVFdj
  d04zcEpJbDE5ZlEiLAogICAgICB7CiAgICAgICAgInNpZ25hdHVyZXMiOiBbewogI
  CAgICAgICAgICAiYWxnIjogIkVENDQ4IiwKICAgICAgICAgICAgImtpZCI6ICJNQ1
  JaLUdaM0QtQUFTMy1ITEpNLUlSUkktQ0Q0Si1WRlNKIiwKICAgICAgICAgICAgIlN
  pZ25hdHVyZUtleSI6IHsKICAgICAgICAgICAgICAiUHVibGljS2V5RUNESCI6IHsK
  ICAgICAgICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgICAgICAgI
  lB1YmxpYyI6ICJEMDlsTlpYVWNCcS1uN2V1QmduZEVfbkozeFk1bDBGRVFIZmdwZD
  NCNGFtVjNmWWhsYk42CiAgQWRoVGRrRElGTGVETnZJaUJpb3ptVVVBIn19LAogICA
  gICAgICAgICAic2lnbmF0dXJlIjogIkQ1RHhCZEhmRS1XaTYtTFlXSVB6SVJPMlFk
  clE1VlBXb0h1RlRBblA5em9qQ0tfXzYKICBkTjZpWUtpc0NUMWRSRFhJR3dpQ2UtV
  HJVdUExNExycTBibWpvTko1MEY1Z2hFTnFPbFR6ZkR6WFY4QmpXegogIFBRTDBhZ1
  9WV3BOM0phaVUwSFJnVFZ2a3VnUlhwQUVFLUJaZFBHQzhBIn1dLAogICAgICAgICJ
  QYXlsb2FkRGlnZXN0IjogIlhSWmZNUjA5MENuN2xEQ21HWTJnT01TX2NHaUUyYzhk
  NkpMaF8zM1RKMHh4ZgogIFdXdlFFa3l1cDdyZ1FNcFdaTnFJRkVXQlFaRTJPZ040S
  2IwZ2JRSGJ3In1dLAogICAgIkNsaWVudE5vbmNlIjogIlB5X003eGxvNXJMQjhhdE
  VwQ0NRaUEiLAogICAgIlBpbklkIjogIkFBS1UtTUpLVy1HUkRTLVMzWkktRE9OSC1
  ENlVTLTRSRVciLAogICAgIlBpbldpdG5lc3MiOiAiY3FlZDMzclJvQzRmSG5WVGp6
  cmVvYV94NUJMS3BMbWhZNWpJZnhCZUNPRGdicUpjCiAgbGh5Q1dtb1ozMG9OS2NHd
  TR0RXZQN3d2c2xVOGg0aU1vYlNSTmciLAogICAgIk1lc3NhZ2VJZCI6ICJOQkFNLU
  lCRzctNElNMi1VTks2LU5RT1EtSEZTUi00TEJEIn19"
      ],
    "ServerNonce":"w0zST52oIkf29KzfHGQ78g",
    "Witness":"A6J3-EVU5-QGBM-WI4Z-HYUC-ONHP-O3VC",
    "MessageId":"A6J3-EVU5-QGBM-WI4Z-HYUC-ONHP-O3VC"}}
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: A6J3-EVU5-QGBM-WI4Z-HYUC-ONHP-O3VC
        Connection Request::
        MessageID: A6J3-EVU5-QGBM-WI4Z-HYUC-ONHP-O3VC
        To:  From:
        Device:  MBQD-CODE-XMWJ-QHE3-2KHZ-UKKF-TVVF
        Witness: A6J3-EVU5-QGBM-WI4Z-HYUC-ONHP-O3VC
MessageID: NCX7-ADC5-L2CD-W5IY-SFT4-NX2U-XZQL
MessageID: NAZG-5KBV-D32X-O24L-XTYS-26GV-FC6Z
        Confirmation Request::
        MessageID: NAZG-5KBV-D32X-O24L-XTYS-26GV-FC6Z
        To: alice@example.com From: console@example.com
        Text: start
MessageID: NANN-LZ5N-6AHO-AOBD-VD6I-X7C3-GJHY
MessageID: NBCN-N55H-QYZX-F2TB-U5R3-2T6B-5W47
MessageID: NDHA-E73C-WZUG-QCMR-5IPX-52JV-WYX6
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":{
    "Result":"Accept",
    "CatalogedDevice":{
      "DeviceUdf":"MBQD-CODE-XMWJ-QHE3-2KHZ-UKKF-TVVF",
      "EnvelopedProfileUser":[{
          "EnvelopeId":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
          "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFDLTdPSEEt
  Uk5CQS1GUkRMLVI0R0ktWVFIQS1ETDM2IiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZ
  mlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIk
  NyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ",
          "dig":"S512"},
        "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJDb21tb25TaWduYXR1cmUi
  OiB7CiAgICAgICJVZGYiOiAiTUROVC1XVDNHLTM0NkctNEk1VC1ZVjdGLUxUUVgtU
  FNOVCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW
  NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA
  iUHVibGljIjogIklNeU1vN2ZFeTJ2SHA4c3lRMFZVNFhpdnBKRWhnUVFTWDNqOG12
  YTRIQ19UMDVVbmhRWXEKICBWWnl1dklRRVZvMmR5TUNSbTYwUTNFMEEifX19LAogI
  CAgIkFjY291bnRBZGRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIiwKICAgICJTZX
  J2aWNlVWRmIjogIk1CUUQtRVRYVS1IWlJXLUEyNk8tV0RUUi1LN0dJLVg2SkQiLAo
  gICAgIkVzY3Jvd0VuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNLRC0zTVI2
  LVAyVEUtTTZVNC00TElPLVpUUkctRFpWUyIsCiAgICAgICJQdWJsaWNQYXJhbWV0Z
  XJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydi
  I6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMXZOVUFBcDNyc3pJcGhHOEV
  zZm9hTzVZNnNaQ24wSGM4ekNnZFFpdllwSkFjRHRta1NzQwogIGVJMmdtRFRDSzZT
  clMxVWdQdHVZbVR3QSJ9fX0sCiAgICAiQWRtaW5pc3RyYXRvclNpZ25hdHVyZSI6I
  HsKICAgICAgIlVkZiI6ICJNRDJMLTZNN0MtWjNaMy1RM0FMLUpGWUktWklVQy1CS1
  VSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0t
  leUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQ
  dWJsaWMiOiAiYkhvS2IwYzEyRjdjaWJNXzNnWmNKWE16T09YNHNuSGdQVndPZlJZa
  zZBUkpPc0dQZW1zZAogIDJCbTBXZm1Ba1JZTzNFUTZmajhfTnpTQSJ9fX0sCiAgIC
  AiQ29tbW9uRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVlGLUQ3TEotNUl
  NUC1FVUNHLUhTR0gtN0xTUi1BQVBaIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMi
  OiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogI
  lg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJjN29vcko4MDhzYzlkNDBLWERoSU
  hnQ1RGejM5TUszSmpPMFE3S191ZkRFR0RLaXdWS2hkCiAgM29QUTQ0UEVxR2p3a3B
  wN09mYmNCYlNBIn19fSwKICAgICJDb21tb25BdXRoZW50aWNhdGlvbiI6IHsKICAg
  ICAgIlVkZiI6ICJNQUZULVNJTkEtU0ZYSS1QQkRZLVdSSEUtTlhZTC1EWFZUIiwKI
  CAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDRE
  giOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI
  6ICJYY2dFejl5MmNxc3g0WmViR0VSVGpyTi14ek44M0QtcGN4MDY1MXgtV1VDcVlO
  cnNuelRICiAgNDBDcG9NeHVOLUZucFQ1bV9iME15dUtBIn19fSwKICAgICJSb290V
  WRmcyI6IFsiWUJKUjNqUjJQbGpkWWs1cXhiV2RIWTByVFlFYUZBa0hZM01tc1I4en
  ZOMURyMzNSbkwKICBVTDNUaHJHOURNV0JaM1AtOFp5R3p5S2FRWXdlY28yWlV0Y0t
  3Il19fQ",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MAJF-DXRU-OY7F-RXLC-JZVM-LNM5-DWGS",
              "SignatureKey":{
                "PublicKeyECDH":{
                  "crv":"Ed448",
                  "Public":"9sZGEfYSIoTvVSL0Q5c_Oip_Hi2iOTsl4L3iL
  whfOv9bA-5nd7PyRooKEsQx-lA7PMAYBewSOmIA"}},
              "signature":"6x3k8AC2jkUQv0jzlUVWJDqP7zcNkKAqvPcAs7
  Ci2jXULjbIFAFCct8GC8Nb8KiD5ljoLAsVHr-AnYcjklyXSHN6Gn_BIZiLiW3Yu5_
  ChXHspywX-ZGMD6soXJIilOzreauR-_aiUE7Gx0eh3Fje2wEA"}
            ],
          "PayloadDigest":"tXPfbmg_SRmARF_7HLPq-bM6NMO1h1Oa30f_Ag
  _TIRzGKMrmTKtV7XH-h3NIBFGxOQYuD0BproKNEg6uhtG0Mw"}
        ],
      "EnvelopedProfileDevice":[{
          "EnvelopeId":"MBQD-CODE-XMWJ-QHE3-2KHZ-UKKF-TVVF",
          "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFELUNPREUt
  WE1XSi1RSEUzLTJLSFotVUtLRi1UVlZGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZ
  mlsZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKIC
  AiQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU2WiJ9",
          "dig":"S512"},
        "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIkVuY3J5cHRpb24iOiB7
  CiAgICAgICJVZGYiOiAiTUNEWi1FQTM3LVBQTEEtVjVCUi0zNlRQLU5LREItNDRXV
  SIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZX
  lFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJ
  saWMiOiAicm5RRnFZZTItYjU1QkoyNHdnRDYteWdZd2RUVnZubHljSHRTSTRtNWQ5
  dG1jLVlJN2JaTgogIEdOM1hwdFdoWThWZmVPS3RyU216VWtHQSJ9fX0sCiAgICAiU
  2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1DQ0gtVVBJTC1XS0lGLUFNNVUtSF
  RMRi0zM1RMLVZIN1QiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICA
  gICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAog
  ICAgICAgICAgIlB1YmxpYyI6ICJnTXl1OHVnYmtOMkdQZG10OEo2WkQxY3M4UnhOc
  DZlR1diWGpVanR5S1IyQkdIYk9tdmNWCiAgdXo5c09IWkFNeVVDUVBtYTBwQUpnRG
  dBIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVB
  ILTYzNlEtN0ZLVS1GM0hKLUxQQ0MtWktVRy1ZVzY0IiwKICAgICAgIlB1YmxpY1Bh
  cmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgI
  CAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICItbDdpOWx2M3ZreV
  ZGNG5STzZFSEtXRUs0LU1nNGRsRWpqM1ZhVGxqcTdwaFlrSnhqVnEyCiAgU28zSUl
  zY1ZSMkRCOFA3eldNMlB3bldBIn19fSwKICAgICJSb290VWRmcyI6IFsiWUtPVFoy
  TUFKYk90TEVSaWdRLUpxV1NVeUFyM19WeGx1Wm1qYVpNaHRsWFFidlJtVjIKICBxe
  VZKU1BXRy1OTHBtb3MxQkxPM1cwNjQ0RlB6Y3k0TWcwN3pJIl19fQ",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MCRZ-GZ3D-AAS3-HLJM-IRRI-CD4J-VFSJ",
              "SignatureKey":{
                "PublicKeyECDH":{
                  "crv":"Ed448",
                  "Public":"D09lNZXUcBq-n7euBgndE_nJ3xY5l0FEQHfgp
  d3B4amV3fYhlbN6AdhTdkDIFLeDNvIiBiozmUUA"}},
              "signature":"D5DxBdHfE-Wi6-LYWIPzIRO2QdrQ5VPWoHuFTA
  nP9zojCK__6dN6iYKisCT1dRDXIGwiCe-TrUuA14Lrq0bmjoNJ50F5ghENqOlTzfD
  zXV8BjWzPQL0ag_VWpN3JaiU0HRgTVvkugRXpAEE-BZdPGC8A"}
            ],
          "PayloadDigest":"XRZfMR090Cn7lDCmGY2gOMS_cGiE2c8d6JLh_3
  3TJ0xxfWWvQEkyup7rgQMpWZNqIFEWBQZE2OgN4Kb0gbQHbw"}
        ],
      "EnvelopedConnectionService":[{
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0
  aW9uU2VydmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKI
  CAiQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU2WiJ9",
          "dig":"S512"},
        "e7QRQ29ubmVjdGlvblNlcnZpY2V7tApQcm9maWxlVWRmgCJNQlFDLTdP
  SEEtUk5CQS1GUkRMLVI0R0ktWVFIQS1ETDM2tA5BdXRoZW50aWNhdGlvbnu0A1VkZ
  oAiTURPNS1YTkpPLUxDUVctR1pTSy1RMklKLU4zQk4tQ0JDN7QQUHVibGljUGFyYW
  1ldGVyc3u0DVB1YmxpY0tleUVDREh7tANjcnaABFg0NDi0BlB1YmxpY4g5tfcoRrH
  -moXof3ppxP-1rsXnpnEc37YXEQumpfPz-MS_fTyxbhajFi1bpr5dZQjrPqCVVWMP
  FmiAfX19fX0",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
              "signature":"9TrTu8tVJ2f9e7_PgVQD2O9JwsxrEyzjTWyqoV
  rlqW1NA4EKkPcPnnMKFFMflbte38rYUSIngUUApFwe2RFaBD_9p3gDpEJgXjQyHyj
  cHn6gu8iOP0WMwUiAgNQCJLJLXxw_zYpIjwIlDUoYA5eaLzkA"}
            ],
          "PayloadDigest":"oEuqftV2yGBBO-zcHdLaZlE24EedCob55acnhS
  mU_3hmwB5GGwKkAaEc3arbl8LlFvw8qcOx4DEmbn2e0l_ETQ"}
        ],
      "EnvelopedConnectionDevice":[{
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0
  aW9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogI
  CJDcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NTZaIn0",
          "dig":"S512"},
        "e7QQQ29ubmVjdGlvbkRldmljZXu0BVJvbGVzW4AJdGhyZXNob2xkXbQJ
  U2lnbmF0dXJle7QDVWRmgCJNQk43LTJWUkotVjc3Ry1CTzJaLVNSVDItUEtZSy1GS
  ExQtBBQdWJsaWNQYXJhbWV0ZXJze7QNUHVibGljS2V5RUNESHu0A2NydoAFRWQ0ND
  i0BlB1YmxpY4g5mHAKd6yWYjepjbjcF5AE3_mVB3NCLhPL_g_UIwgI5j9GvARZLzs
  drWAngOGTv7M6R_WM2IrWl3GAfX19tApFbmNyeXB0aW9ue7QDVWRmgCJNQjVILVlZ
  QVEtTUtLVC01SkNNLUZXUkwtSElKMi02TjdPtBBQdWJsaWNQYXJhbWV0ZXJze7QNU
  HVibGljS2V5RUNESHu0A2NydoAEWDQ0OLQGUHVibGljiDk0NPeEx6n3ELUk1MYr0r
  3nSo-qxXfvvn35g2S5sxZqo8uMquHzzA1PWaVNF5bharNF__kWmerQxYB9fX20ClB
  yb2ZpbGVVZGaAIk1CUUMtN09IQS1STkJBLUZSREwtUjRHSS1ZUUhBLURMMza0DkF1
  dGhlbnRpY2F0aW9ue7QDVWRmgCJNRE81LVhOSk8tTENRVy1HWlNLLVEySUotTjNCT
  i1DQkM3tBBQdWJsaWNQYXJhbWV0ZXJze7QNUHVibGljS2V5RUNESHu0A2NydoAEWD
  Q0OLQGUHVibGljiDm19yhGsf6aheh_emnE_7WuxeemcRzfthcRC6al8_P4xL99PLF
  uFqMWLVumvl1lCOs-oJVVYw8WaIB9fX19fQ",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
              "signature":"yYwmrYVkddU86Hm99yKb4QlqVqr1Rw4vAdaztF
  l8FRG3tCO77sMc5vMLcSJTkdK-FOGOrQRk11iAGZ5ZEgLMFJn-QRpSmcbBLeel6lD
  SUJQRkjVUavbCxej4RKJoMOJbzuBmZdvsreHynZdbk7p7fzIA"}
            ],
          "PayloadDigest":"CsqBGYf0fzZ8YE4nzhUuuvfL0lGsaAkNFKCUhf
  1YsIwCxuDQY_zZjVcOEgFsVeUggfmm_spXiahBMaDM7zz2fA"}
        ],
      "EnvelopedActivationAccount":[{
          "enc":"A256CBC",
          "kid":"EBQM-YIA4-PNBW-ECVY-NBBW-CT2Z-WUX2",
          "Salt":"kugd4f-D2t7K2ESGjW7J9A",
          "recipients":[{
              "kid":"MCDZ-EA37-PPLA-V5BR-36TP-NKDB-44WU",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"fH2svl6_uVYsor6k0kzRFZEfAXWOAedsri-XL
  9YRzAQsN_l_M9DzmRWxbvDsLC0fztCVsvfTsN-A"}},
              "wmk":"JNEdtBna70N_7MINkiCfkRdXRfqGXo3d6QXoPyoRkUqp
  N3bSxdYJKA"}
            ],
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0
  aW9uQWNjb3VudCIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKI
  CAiQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU2WiJ9",
          "dig":"S512"},
        "-fy3XJD_nkzc5E0amfUxXyd9iv9ucViLMp8hOhrMSEBDOCwPybwnY-hS
  wNA6-DwlMZ1q8tfpTmjJizv6Mkf4PRkYE4qOJJTDbxtS6lNMvBJhBvcKgMDoeAnVf
  Y7x9BomZLlERwo6BMH9WavqiMshfLEC9RJ4BSfjfMcp5-P_5qZ_fRAutzAOB_vsEA
  97F0SmzjM7Mjdk0M0iVtR2F4UH-FEEgQFdAmoYwSFV3bXCWRkYRD0y-B_4kWqBXvL
  1-SM2",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
              "signature":"arywkmG5iJUxfP4MHIMgcmXyDk8nWzsh6RUz8Q
  CiGo60E2JqqRtaZscxTlYaEsEMR0Ugs-AH8cKAD7f__RB4DxiUuWORY11txAmfpIR
  2NwLnIsQ0S65x5dauAJ5mFY0QTDucNfXGDaCU8V4UlDIn-QcA"}
            ],
          "WitnessValue":"4KPjB1dl0OVeugi6FxuDd2l76-tOdwQ-3KVVWqo
  Ai0g",
          "PayloadDigest":"XFmB2PVKxowqhjsTobBlWcqL6lxrrmrTPbmgC2
  acKwBiF-8IQFVAep1nSCYX-FXTibvVJYhov1JbEVNriE0pBQ"}
        ],
      "EnvelopedActivationCommon":[{
          "enc":"A256CBC",
          "kid":"EBQJ-A3RO-PE4X-7LMM-QSPW-EMFA-HGDX",
          "Salt":"RImEmW_A-Z5v3zqz_aYesQ",
          "recipients":[{
              "kid":"MB5H-YYAQ-MKKT-5JCM-FWRL-HIJ2-6N7O",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"dDyHxC6UbAhRoN3dYsK8Sq-UAqA_wwA01zolu
  b1zuhKOAY_TB7RNhjcNYK7_DIGoitWQVVOKM0SA"}},
              "wmk":"Hx1gKmlhsjVZdRqKAgkmnOPwrI2HpEuK7zVEmiGeGj-p
  K3ay4x28Nw"}
            ],
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0
  aW9uQ29tbW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogI
  CJDcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NTZaIn0",
          "dig":"S512"},
        "4dJQ5E39vl5VRFBsQ5u30C_8Yg8V3J1wS_8-sZIU2ElTVOr_5WbK0_oi
[encoded data, 8580 characters]
  V5L8fGCsSWVGWqNn3rhwBiNgIw",
        {
          "signatures":[{
              "alg":"ED448",
              "kid":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
              "signature":"gHExk7IRqx_fSpaKOp_X1HLy88WStnwZWO17k9
  MekufjE7eaooRRDluULSK0DIvXbbfKC3hVlsgATCTqb5l68NkFhluvJ2z2MS7M2-h
  aRhY3Foa_5fMQdWC7--nkWF11jCh9eD_pXgaOIx0t17vVTT4A"}
            ],
          "WitnessValue":"rlT1c19N3iBlMXIAMd6bcobgDnH2Uv1m-C7VV90
  Gnyk",
          "PayloadDigest":"LudFo4aZ5eOUbOhCRQ119Oe_5JJRye2FSlSkOM
  WSC4tJUmYeuYDyxAQxf82re75Zgps7wMnww5QwjCto-9WdRQ"}
        ],
      "ApplicationEntries":[{
          "ApplicationEntrySsh":{
            "EnvelopedActivation":[{
                "enc":"A256CBC",
                "kid":"EBQH-IPF2-DRYU-N2VS-VMAI-MRHF-IZKT",
                "Salt":"eJdGrdqLp8RcPEEEXCgkmg",
                "recipients":[{
                    "kid":"MB5H-YYAQ-MKKT-5JCM-FWRL-HIJ2-6N7O",
                    "epk":{
                      "PublicKeyECDH":{
                        "crv":"X448",
                        "Public":"TFp8dAMe5wkLifcl5S3OgP3e8JPEBUx
  WRg1geI9NbXygTZWWTssJNlrE358qdw0RxjA-agAsScWA"}},
                    "wmk":"G7hWogNaI5S4osEN_QLNA5k8VEPRuoDSM3NF3t
  lBqtw8g7OypHpYQw"}
                  ],
                "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3
  RpdmF0aW9uQXBwbGljYXRpb25Tc2giLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1
  tL29iamVjdCIsCiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo1NloifQ"},
              "GHk2FJEAip3mtk9ruFfCQ79sa63GkE9nWZ6WqngeJ4_kXRR7d0
  4ZME3CZGfwTmveMT5qEw4WKWwj2r0nKHm9dFJpwp0BSY8-6kozVbzAM2gPW9CrLYI
  KoRBT_dxjst8KzusT8gNADy5Bw4-l-AB7ucnmzZiQkFDxM-zOi6KoTepieRUAtxXn
  OTUfkpGGnOAx8nAQfyYxQ5ShLHxXMdJs28am4vj7XMC9t7L10c9ioZGfVTFLfCxEl
  LjvUVff2xX9tnLwRYRaCthdX39m3ld1fBkV1ARkGF5yqQPTtrUuVggLaOwTr4EG9W
  UZAi2gSgNUrP8vBnkt5oEbZlO7de8h_X0DQRAENjnaz8xLM6Ns44k3YoMzF8ItbhK
  KwPUIM63rAatd8qTNXfKw-sguZnWKZnENeqlKvu6DayHUMFTEESUQBoYdSFv6QiHd
  jFqCQ19sHw2mnhRKqKhKCaViwWPk__dYjh8YlU4Ws8Ip-XGzfhOHh61VVzZdZ-aUO
  Uo-Mwomod1muK4FIgNmnijrbrE7lQJgkAbiUKtlm16Zj4h4fKNnqg59ujtupv6dxS
  1hYEhDKZCMNtUwunz3kgX91S2wNL5B8sfHOs4h95OKJi9UNyvzOHGtrFZyyXu1cbf
  O8XvxSpp2EwqgJOUZL0nwFwK8UQ_1HPk6n6J_MbZ-zanADPMGjpdOUUxPYw5QO16V
  QQ-XinI0hrfv7YHlwwc8578Wg-Kf2sfpdZ3h2QUd3G-FSCgHyCt9Uqdpd1JAPrNOM
  eTplzJ-MDMhi6wTdUvY1O3GhZPJWfLtUtZthcQkrmF5yrIkmSdwQzziRR2FibF9Vn
  YfjlHL7AEBwfEoFV3QBTTMxEZQYd5-CCHMUIB32Qq25uihYPJxdswF7_7k6cxX0E0
  FvtjCbiewiPwXyZNL25w20tnFVZOYdG90CTQ_yaj7YqocH27tSDv9pMuY0f5G1Iln
  6gEyiZHsOSeE_p6J5KboO5uLfGOHMOaCLkNaYtFoB3e7mDnkATCRWZMnf06uQfgwt
  imUhI2JN0XZt7cJ8Jp4wWfzJLbtFH6FMlx8MA1HQrr30smK_gteZkewYvq6Uiuy5A
  DQi6lOqPt2HMxpoLKUK26jSGx9Vz46vjMz-R1XNO4MIVXwnMSxZVK4auHUoNMFbWC
  amTLdH-h18dNqO1b3NIjjC7QW5JImu14g_r3eYY7gr7zRihm6AumYRuPyZXF58n1v
  NeHXfjKUAa-rCfuh5q-vOpc9UvGnPW6ouV7jvDiZURV84prtnK_UltoBV9KvvCrhB
  GoSJvFh-RbfIKW2vaS9AlxBrpe9YbBe07ZZNM2YPkTiljkJ7-_7VDg7rRpRLssnRS
  Y6XHwIEAh7ZsG4weOk9SoZwX_DEJK2svpuGexyelMHHiFU2DDDg1D0zWJQDk2SzFy
  gqA6SO-P6DzZe4N5u9bFcIrM_hRJY7BDV0ww4SkvvYV680C3LI_918m0CnxwaJDPq
  HDa4fhYAQsXEZeHMXF5B8PMqnfeypU1gl3npN3u2phl1jUwBlqFZhwS6X3EnEGQbN
  IJsUhvwjohFWO1elxX2WjRtyOLSrRHl4FFu3S1ZkBvEl5TN5Ho6zu32EQLlI07cw1
  0Gl-dA7TpI7lPMvkcW1pEEBWd59iLixBnPSrq1KkrJb-Vyl-Bo05W2v5Qzna_af_l
  J9FHwWatugiKb18QyFrhL6Kjo8tZScGjadDUdlwUC_d_r6YJMQY2yX0YBkuei14UX
  Zholy8JpUbLfa0gNs-WdFQCoinq4CAFdxfNikKlSVXPnF_sUEtKZiDG3SQ8jBOC-K
  6YrT3caFRK2K0_wyhHC7HzooZSk89DR9pG0g1Kx3LE_E-6H38fyPOD-Y38JfmMa7w
  KjYhYNuYF1LfgD5dGk29Azq8KIHII8il7V82PvFKJt9RodreotvpGkEk56PxN27UX
  fIQVY8XgnsEbWWkmICPF__BEzDVK_6L3EJzyHMNGQMb9jwmVnklorDvv2KlxOMbCj
  pXlRg47-KcKxmqv8Kz_TMYs2HZVaHunrLsJRqIKTABXROVKl26sJXoV410cvMtb7f
  Z0a8_Nif8Hogvg30JaXg7-y88gbq87ZeYF5pLqjHQXO-RNrFZZWXZKOwhl9pk2Hx1
  eu0D1xj87HqPF3RUspLtTf6GSGOhrGURhEsd-Vu9EqkPI_A0FRhYRIAlkIO3LJTlJ
  1lWxC3fcWSdFNI9rHdl4oLzvfHMayRmCpkPRd9cFT7qvZ2ZNFsY84V5bWph1xPvWy
  sgSDXASnfAoaIY02bhuvCe6qaYtltPKxnYQFxisIaiBS1RNqR6gtVsvD0qJPBG1oT
  I-6Pk2yNLILS9U5-Z5hPAR8crXPlz__sOO-aDN-aWndm8IS7H-rODbLk_wg1QfLLS
  HCVjNml7qe21YaYfEgaRoe5lh4NuzXskRKpW5Sk1Yz7sghjv2MSgSj0NgpWkQTfYt
  mUic1RC8isRCKOpB8hj8jgVEiQYoeBmM76fYIBdX_9hehXtEclGwK5_qii-pQ5tqR
  zEqRrd3ULZ4O0aeJeEoNXG74Hzytj9TpfkvU1R5ZHgtnkS97WIe9ACaDBHpvmcYxc
  ou-IAmt6MP5HhbK45FtMteC8WqZQGrhdmCGW0_m7N0R81MJDirmcI9nP9ZRPAWooK
  mdhuiUX8B4XO52r7PpP46PAB9gWo2rh16VapCslRPbYXWxsiOT99RYn_YVBTJaUvK
  mWbELtOWCHY0rQKAO3W-yUlzLZAwX_fDa9P8R2tFdwuzdJ8OkyVWueNjn1kA2_UKQ
  oVTNe5jt7J7JszsKqHJ2UcCi5Oi03u05JX8NKgNajg9VqNpQUrySPmrFg6WY7hHXa
  lgz0icVrKEOtGpJQJtf2neengXBNnO8RedkmiEjETolHc_2h8su_eB45-DBYCXr7O
  qIRw8mMExFvyowMe_MeH7u8kpZX3t8bPD9M46xcOq2RF657j2Yr-0AKm2SRFLFMT5
  n1J0l0Hk2va0TLVv3csLGHzl14BNXIbUhEWVe-Bns3RZflOM74JXS_jqYz419hEP_
  MV3njzmVsTxfSVzMOizoLGyf8dfetSvpSyOXi5AVx8sege_Pp3TLx2AlxpofpVILM
  9a6JCetP4vMdImjrvuIgcRPlaO1NjXZ_lPPlQYKYEN8FLVtPCQJsuM5kPZLGdp9sm
  Aeg-2AFf_oAZ_YxLTitkrfmVPb2so14gWi9i6-ptznY2ffH9UAFRpcAzDz13bRTMe
  43slJvh3X0hqI0XxwSh1jq3pZe7YgOv8z2zsrMoXEN_UrE0xFlDal5cm1G2fI7K5Q
  6nx6y84XKlE93BMZ7rJeUXi9Vu3x"
              ],
            "Identifier":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77"}}
        ]},
    "MessageId":"MDDD-KNM4-KUZH-QVC4-KWLI-5NBW-T54I"}}

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 = MBQD-CODE-XMWJ-QHE3-2KHZ-UKKF-TVVF
   Account = alice@example.com
   Account UDF = MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36
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":"MDDD-KNM4-KUZH-QVC4-KWLI-5NBW-T54I"}}
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: MBQK-36BF-K7RS-UDWD-PVC3-CVMR-BJCP
File: EBH3-DT6M-G2WA-EF7E-DA42-DN55-7E.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":{
    "EnvelopedConnectionDevice":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
  DcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NThaIn0",
        "dig":"S512"},
      "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIlNpZ25hdHVyZSI6IH
  sKICAgICAgIlVkZiI6ICJNRFY1LUVJQ0ktSk5GVi0zNUs3LUlQREctNkNWNy1OU1Y
  1IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl
  eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd
  WJsaWMiOiAiQVVPMUIyR1RLNGZjSk9rUFlNN0RJa3VDT2s0SWNJbHFzTGZuQVlnQS
  1BQ0dhZmNvUFZCdQogIEJDSGYzR2JDMEx2bHBiS2cwNmliREh5QSJ9fX0sCiAgICA
  iRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQkZGLUVTUDMtVk5YWS1EWUhM
  LTVNSkktVjRLNy1WN1dOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgI
  CAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLA
  ogICAgICAgICAgIlB1YmxpYyI6ICJMd2oxNlE3QmNraWU3ZU9jMG85NXJYbGZ6enh
  rSDFFTGVCMGxlLURJdklxemVpeHlocjZhCiAgTjRTSV94Vzh6eGwxSGVSclRKN1lh
  Uy1BIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ
  kZGLUVTUDMtVk5YWS1EWUhMLTVNSkktVjRLNy1WN1dOIiwKICAgICAgIlB1YmxpY1
  BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICA
  gICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJMd2oxNlE3QmNr
  aWU3ZU9jMG85NXJYbGZ6enhrSDFFTGVCMGxlLURJdklxemVpeHlocjZhCiAgTjRTS
  V94Vzh6eGwxSGVSclRKN1lhUy1BIn19fX19",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MD66-B7Q7-HWEB-UAF6-PWNM-YVBH-HXE7",
            "signature":"T5q8Ygyj3aM5tDzUmjoFMAVdGasi0PF1SZlgFYCl
  3kCT5_NZrd5iuGcJetwaq0bINEJHDjUppQuAdbpe8eZPlJBtTo8EBksurd04sqf1U
  NIokTq5HA-eXh45bjPkOGjwZmBBO46LlyQDG_kq-6roUw0A"}
          ],
        "PayloadDigest":"CQupHrY2ASmhF8QOcXCnjid4nC6wlVlUk9cxmIUc
  MGC1_YLhJwc7wpE-EfoDCcmkTtRCPmwq1tmdX88VClLkSw"}
      ],
    "EnvelopedConnectionService":[{
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uU2VydmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICA
  iQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU4WiJ9",
        "dig":"S512"},
      "ewogICJDb25uZWN0aW9uU2VydmljZSI6IHsKICAgICJBdXRoZW50aWNhdG
  lvbiI6IHsKICAgICAgIlVkZiI6ICJNQkZGLUVTUDMtVk5YWS1EWUhMLTVNSkktVjR
  LNy1WN1dOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1
  YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgI
  CAgIlB1YmxpYyI6ICJMd2oxNlE3QmNraWU3ZU9jMG85NXJYbGZ6enhrSDFFTGVCMG
  xlLURJdklxemVpeHlocjZhCiAgTjRTSV94Vzh6eGwxSGVSclRKN1lhUy1BIn19fX1
  9",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MD66-B7Q7-HWEB-UAF6-PWNM-YVBH-HXE7",
            "signature":"4FkfmdMX6sWMQ5zskF7V_1UsoBTBKVVQtYigF41m
  MGOx1_yTQtpDs1lnqxmBt6yAtjfUvv1NsG2AdYx425rJ5-lryqyud6m-MNoTCUeWW
  wuO0jGMpaw2PyjFUFh62_k5fGDzZVgqx-larLbwVf6vFQsA"}
          ],
        "PayloadDigest":"z4aP8rSa_WxiufLZcZmhBbJd-3OCz70GX4gIkH0y
  U4LCO8QdoX-4iAbwfwylksQDTtNbKmVfxQam4MCT-2oKZw"}
      ],
    "PrivateKey":{
      "PrivateKeyUDF":{
        "PrivateValue":"ZAAQ-AUKH-YPXV-5NTI-ZVIK-4Q2D-EFAP-UR7Y-5XX
N-EDXE-HX3O-LYFS-BJOU-CMQE",
        "KeyType":"MeshProfileDevice",
        "RootSignAlgorithms":["ED448"
          ]}},
    "ConnectUri":"mcd://maker@example.com/EBH3-DT6M-G2WA-EF7E-DA42-
DN55-7E",
    "EnvelopedProfileDevice":[{
        "EnvelopeId":"MBQK-36BF-K7RS-UDWD-PVC3-CVMR-BJCP",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFLLTM2QkYtSz
  dSUy1VRFdELVBWQzMtQ1ZNUi1CSkNQIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU4WiJ9",
        "dig":"S512"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIkVuY3J5cHRpb24iOiB7Ci
  AgICAgICJVZGYiOiAiTUJGRi1FU1AzLVZOWFktRFlITC01TUpJLVY0SzctVjdXTiI
  sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF
  Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiTHdqMTZRN0Jja2llN2VPYzBvOTVyWGxmenp4a0gxRUxlQjBsZS1ESXZJcX
  plaXh5aHI2YQogIE40U0lfeFc4enhsMUhlUnJUSjdZYVMtQSJ9fX0sCiAgICAiU2l
  nbmF0dXJlIjogewogICAgICAiVWRmIjogIk1EVjUtRUlDSS1KTkZWLTM1SzctSVBE
  Ry02Q1Y3LU5TVjUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgI
  CAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogIC
  AgICAgICAgIlB1YmxpYyI6ICJBVU8xQjJHVEs0ZmNKT2tQWU03RElrdUNPazRJY0l
  scXNMZm5BWWdBLUFDR2FmY29QVkJ1CiAgQkNIZjNHYkMwTHZscGJLZzA2aWJESHlB
  In19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVZHL
  VlXWVYtMlVXNy1MU1QzLUFQQkctUkw3SC1ONTMzIiwKICAgICAgIlB1YmxpY1Bhcm
  FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA
  iY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJyRlZGUi1jTDZjdWNU
  U3JmRm4xNDZYVE9kMWgzSkdBM0hrQ0VlYkNzaUEzT3dWQXBkN2ZsCiAgZ0Z4Zlh0d
  lkzVXRpNmlRd1RTdmVFWmtBIn19fSwKICAgICJSb290VWRmcyI6IFsiWU5lVGVBYk
  l4NVdSdEN4Q3llbnBqYWJKVlJuOERUbGF1SFBUZFFUYnRJOEFHblY1bk8KICBWM1l
  PWENlRFlRZTk5VnFIcWZwYi10MFZxSjI5blZKRW1yUEpNIl19fQ",
      {
        "signatures":[{
            "alg":"ED448",
            "kid":"MDLZ-G6AG-ZDDZ-LENU-FRBM-T2PJ-RWTM",
            "SignatureKey":{
              "PublicKeyECDH":{
                "crv":"Ed448",
                "Public":"WPX0CBEOzgJWHVJqiyTAr4MrieFJQYzdutZML5-
  MnHsfF7KfRmGxsUR9eppBIKTFhzLaRhd06XmA"}},
            "signature":"s1AVL-omThJqK3LTFXtg58xvRBZoeansc39u4rqT
  iKRHKrCQx-11PG9b0Vq-VC_MRWxbCwZenawAo4fBnNnpNvtbNGUaALlFVvLK5nPZV
  O6nY6gA_i3ID9ZrUTxYJz0lbj-ZTIt6NZOGxTJX4yxJiC8A"}
          ],
        "PayloadDigest":"OrZNsRzLz7olETFljSpKbdG1bNjj5MBr-ireuPK6
  Sn9-ARWs4E3Xk2_HvrHA7cySavkX6anRBSGzQ5uYty0_Ow"}
      ]}}
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 ^
    mcd://maker@example.com/EBH3-DT6M-G2WA-EF7E-DA42-DN55-7E /web

Phase 4
The device polls the publication service until a claim message is returned.
Alice4> meshman device complete
   Device UDF = MBQK-36BF-K7RS-UDWD-PVC3-CVMR-BJCP
   Account = alice@example.com
   Account UDF = MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36

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.
Capability: String (Optional)
The identifier of the capability under which access is claimed.
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.
Store: 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: StoreStatus
Store: String (Optional)
Index: Integer (Optional)
Digest: Binary (Optional)
In a status response, the apex digest value of the store whose status is reported.

Structure: StoreUpdate
Inherits: StoreStatus
Envelopes: DareEnvelope [0..Many]
The entries to be uploaded.
Partial: Boolean (Optional)
If false, the store update does not contain the last index entry in the store.
FinalIndex: Integer (Optional)
If the value Partial is true, this value MUST specify the index value of the last entry in the store.

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: MeshHelloRequest
CallsignBinding: CallsignBinding (Optional)
Contains a proposed callsign binding to the account.

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.
CallsignBinding: CallsignBinding (Optional)
If the request specifies a callsign binding, returns a proposed binding for the requested callsign.

Transaction: BindAccount
Request: BindRequest
Response: BindResponse
Request binding of an account to the service. This method is called during account creation and binding.
The operation is called Bind rather than Create because the account is created by the user, not the service.

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.
EnvelopedCallsignBinding: Enveloped [0..Many]
Contains one or more bindings of a callsign to 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.
EnvelopedAccountHostAssignment: Enveloped (Optional)
The enveloped assignment describing how the client should discover the host and encrypt data to it.

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
EnvelopedAccountHostAssignment: Enveloped (Optional)
The enveloped assignment describing how the client should discover the host and encrypt data to it.

Transaction: Status
Request: StatusRequest
Response: StatusResponse

Message: StatusRequest
Inherits: MeshRequestUser
DeviceUDF: String (Optional)
CatalogedDeviceDigest: String (Optional)
Catalogs: String [0..Many]
Spools: String [0..Many]
Services: String [0..Many]
DeviceStatus: Boolean (Optional)

Message: StatusResponse
Inherits: MeshResponse
Bitmask: Binary (Optional)
EnvelopedProfileAccount: Enveloped (Optional)
The account profile providing the root of trust for this account.
EnvelopedCatalogedDevice: Enveloped (Optional)
The catalog device entry
CatalogedDeviceDigest: String (Optional)
StoreStatus: StoreStatus [0..Many]
EnvelopedAccountHostAssignment: Enveloped (Optional)
The enveloped assignment describing how the client should discover the host and encrypt data to it.
Services: ServiceAccessToken [0..Many]
A series of access tokens for the requested services.
DeviceStatuses: DeviceStatus [0..Many]

Structure: DeviceStatus
Id: String (Optional)
Status: String (Optional)
Comment: String (Optional)
LastConnected: DateTime (Optional)

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.
MaxResults: Integer (Optional)
The maximum number of results to be returned.
DeviceUDF: String (Optional)
CatalogedDeviceDigest: String (Optional)
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: StoreUpdate [0..Many]
The updated data
CatalogedDeviceDigest: String (Optional)
EnvelopedCatalogedDevice: Enveloped (Optional)
The catalog device entry. This is only returned if the

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: StoreUpdate [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.
Bitmask: Binary (Optional)
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: PublicRead
Request: PublicRequest
Response: DownloadResponse
Request objects from the specified container with the specified search criteria.

Message: PublicRequest
Inherits: DownloadRequest
Request download from a public store (which may be encrypted).
[No fields]

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
28 June 2023
Internet-Draft draft-hallambaker-mesh-architecture-22
[draft-hallambaker-mesh-rud]

Mathematical Mesh 3.0 Part VI: Reliable User Datagram
Phillip Hallam-Baker
ThresholdSecrets.com
28 June 2023
Internet-Draft draft-hallambaker-mesh-rud-03
[draft-hallambaker-jsonbcd]

Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D
Phillip Hallam-Baker
28 June 2023
Internet-Draft draft-hallambaker-jsonbcd-24
[draft-hallambaker-mesh-udf]

Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.
Phillip Hallam-Baker
ThresholdSecrets.com
28 June 2023
Internet-Draft draft-hallambaker-mesh-udf-18
[draft-hallambaker-mesh-schema]

Mathematical Mesh 3.0 Part IV: Schema Reference
Phillip Hallam-Baker
ThresholdSecrets.com
28 June 2023
Internet-Draft draft-hallambaker-mesh-schema-12
[draft-hallambaker-mesh-security]

Mathematical Mesh 3.0 Part IX Security Considerations
Phillip Hallam-Baker
ThresholdSecrets.com
20 April 2022
Internet-Draft draft-hallambaker-mesh-security-09

Informative References
[draft-hallambaker-mesh-developer]

Mathematical Mesh: Reference Implementation
Phillip Hallam-Baker
28 June 2023
Internet-Draft draft-hallambaker-mesh-developer-11