Internet-Draft	Mesh Protocol Reference	August 2021
Hallam-Baker	Expires 6 February 2022	[Page]

Workgroup:: Network Working Group
Internet-Draft:: draft-hallambaker-mesh-protocol
Published:: 5 August 2021
Intended Status:: Informational
Expires:: 6 February 2022
Author:: P. M. Hallam-Baker

ThresholdSecrets.com

Mathematical Mesh 3.0 Part V: Protocol Reference

Abstract

The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.¶

[Note to Readers]¶

Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.¶

This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 February 2022.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

▲

1. Introduction

This document describes the Mesh Service protocol supported by Mesh Services, an account-based protocol that facilitates exchange of data between devices connected to a Mesh profile and between Mesh accounts.¶

Mesh Service Accounts support the following services:¶

Provides the master persistence store for the Catalogs and Spools associated with the account.¶
Enables synchronization of Catalogs and Spools with connected devices.¶
Enforces access control on inbound Mesh Messages from other users and other Mesh Services.¶
Authenticates outbound Mesh Messages, certifying that they comply with abuse mitigation policies.¶

A Mesh Profile MAY be bound to multiple Mesh Service Accounts at the same time but only one Mesh Service Account is considered to be authoritative at a time. Users may add or remove Mesh Service Accounts and change the account designated as authoritative at any time.¶

The Mesh Services are build from a very small set of primitives which provide a surprisingly extensive set of capabilities. These primitives are:¶

Hello: Describes the features and options provided by the service and provides a 'null' transaction which MAY be used to establish an authentication ticket without performing any action,¶
CreateAccount, DeleteAccount: Manage the creation and deletion of accounts at the service.¶
Status, Download, Upload: Support synchronization of Mesh containers between the service (Master) and the connected devices (Replicas).¶
Connect: Initiate the process of connecting a device to a Mesh profile from the device itself.¶
Post: Request that a Mesh Message be transferred to one or more Mesh Accounts.¶

Although these functions could in principle be used to replace many if not most existing Internet application protocols, the principal value of any communication protocol lies in the size of the audience it allows them to communicate with. Thus, while the Mesh Messaging service is designed to support efficient and reliable transfer of messages ranging in size from a few bytes to multiple terabytes, the near-term applications of these services will be to applications that are not adequately supported by existing protocols if at all.¶

2. Definitions

This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.¶

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

2.2. Defined Terms

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

2.4. Implementation Status

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

3. Mesh Protocols

The Mesh specifies two separate types of protocol interactions:¶

Mesh Service Protocol: A synchronous protocol supporting interactions between devices and a Mesh Service Host and between Mesh Service hosts.¶
Mesh Messaging Protocol: An asynchronous protocol that supports interactions between devices connected to the same account and between accounts.¶

The Mesh Messaging Protocol uses the Mesh Service Protocol as transport. The Mesh Service Protocol in turn is supported by either the HTTPS binding over TCP or by the Mesh Datagram binding over UDP.¶

Figure 1: Protocol Layering

Mesh Services MUST support the HTTPS binding and MAY support the Mesh Datagram binding.¶

4. Mesh Service

A Mesh Service is a minimally trusted service. In particular a user does not need to trust a Mesh service to protect the confidentiality or integrity of most data stored in the account catalogs and spools.¶

Unless the use of the Mesh Service is highly restricted, a user does need to trust the Mesh Service in certain respects:¶

Data Loss

A service could refuse to respond to requests to download data.¶

Integrity (Stale Data)

The use of Merkle Trees limits but does not eliminate the ability of a Mesh Service to respond to requests with stale data.¶

Messaging

A service could reject requests to post messages to or accept messages from other mesh users.¶

This risk is a necessary consequence of the fact that the Mesh Service Provider is accountable to other Mesh Service Providers for abuse originating from their service.¶

Traffic analysis

A Mesh Service has knowledge of the number of Mesh Messages being sent and received by its users and the addresses to which they are being sent to or received from.¶

The need to trust the Mesh Service in these respects is mitigated by accountability and the user's ability to change Mesh Service providers at any time they choose with minimal inconvenience.¶

It is possible that some of these risks will be reduced in future versions of the Mesh Service Protocol but it is highly unlikely that these can be eliminated entirely without compromising practicality or efficiency.¶

4.1. Data Model

The design of the Mesh Service model followed a quasi-formal approach in which the system was reduced to schemas which could in principle be rendered in a formal development method but without construction of proofs.¶

Like the contents of Mesh Accounts, a Mesh Service may be represented by a collection of catalogs and spools, for example:¶

Account Catalog: Contains the account entries.¶
Incident Spool: Reports of potential abuse¶

Backup of the service MAY be implemented using the same container synchronization mechanism used to synchronize account catalogs and spools.¶

4.2. Partitioning

Mesh Services supporting a large number of accounts or large activity volume MAY partition the account catalog between one or more hosts using the usual tiered service model in which a front-end server receives traffic for any account hosted at the server and routes the request to the back-end service that provides the persistence store for that account.¶

In addition, the Mesh Service Protocol supports a 'direct connection' partitioning model in which devices are given a DNS name which MAY allow for direct connection to the persistence host or to a front-end service offering service that is in some way specific to that account.¶

5. Protocol Bindings

Mesh Service transactions are mapped to an underlying messaging and transport protocol. The following binding¶

Mesh Services MUST support the Web Service binding specified in this document and MAY support the UDP binding currently in development.¶

5.1. DNS Web Service Discovery

The DNS Web Service discovery mechanism is used to discover Mesh Services regardless of the protocol binding .The service name, DNS prefix and and .well-known service suffix are specified as follows:¶

Service Name: mmm¶
DNS Prefix: _mmm._tcp¶
Well Known service suffix: /.well-known/mmm¶

5.2. Web Service Protocol Binding

The Web Service Protocol binding makes use of the most widely deployed and used protocols:¶

Discovery: DNS Service discovery¶
Transport: TLS¶
Application: HTTP¶
Presentation: DARE Message¶
Encoding: JSON, JSON-B¶

The chief limitations of the Web Service Protocol Binding are that the use of TCP based transport results in unsatisfactory latency for some applications and that the HTTP application layer only serves to allow a host to support multiple services on the same TCP/IP port.¶

5.2.1. Transport Security

Mesh Services MUST offer TLS transport and MAY offer non TLS transport. MESH clients SHOULD use TLS transport when connecting to a MESH service.¶

TLS version 1.3 [RFC8446] or higher MUST be supported. Client authentication SHOULD NOT be used.¶

5.2.2. HTTP Message Binding

All messages are exchanged as HTTP POST transactions. Support for and use of HTTP/1.1 [RFC7230] is REQUIRED. Services MAY support HTTP/2.¶

In contrast to other approaches to the design of Web Services, the only use made of the HTTP transport is to distinguish between different services on the same host using the Host header and .well-known convention and for message framing. No use is made of the URI request line to identify commands, nor are the caching or proxy capabilities of HTTP made use of.¶

5.2.3. Request

The HTTP request MAY contain any valid HTTP header specified in [RFC7230].¶

Request Line URI: /well-known/<service> (unless overridden using a TXT path attribute)¶
Request Line Method: POST¶
Host: Header: <domain>¶
Content-Encoding: As specified in section yy below.¶
Content-Type: As specified in section zz below.¶
Content-Length or Transfer-Encoding: As specified in [RFC7230].¶
Payload: The content payload as specified in section XX below.¶

[No dump of the binding yet]

~~~~

5.2.4. Response

The response MAY contain any HTTP response header but since JWB services do not make use of HTTP caching and messages are not intended to be modified by HTTP intermediaries, only a limited number of headers have significance:¶

Response Code: The HTTP response code. This is processed as described in section zz below.¶
Content-Type: As specified in section zz below.¶
Content-Length or Transfer-Encoding: As specified in [RFC7230].¶
Cache-Control: Since the only valid HTTP method for a JWB request is POST, JWB responses are not cacheable. The use of the cache-control header is therefore unnecessary. However, experience suggests that reviewers find it easier to understand protocol specifications if they are reminded of the fact that caching is neither supported nor desired.¶

[No dump of the binding yet]

~~~~

5.3. DARE Message Encapsulation

The payload of the HTTP requests and responses is a DARE Message whose payload contains the Mesh Service request or response.¶

The DARE Message encapsulation is used to authenticate the request or response data. The form of the authentication depending on the credentials available to the sender at the time the request is made.¶

Mesh Service MUST support the use of Mutually Authenticated Key Exchange [draft-hallambaker-mesh-security] to establish the Master Key used for authentication of requests and responses.¶

Requests and Responses MUST be authenticated. Requests and Responses MUST be encrypted if the transport is not encrypted and MAY be encrypted otherwise.¶

5.3.1. Null Authentication

Null Authentication MAY be used to make a Hello Request.¶

The Null Authentication mechanism MUST NOT be used for any Mesh Service request or response other than a Hello request.¶

Since the Mutually Authenticated key exchange requires both parties to know the public key of the other, it is not possible for a client to authenticate itself to the service until it has obtained the service public key. One means by which the client MAY obtain the service public key is by requesting the service return the credential in a Hello transaction.¶

5.3.2. Device Authentication

Device Authentication is used in two circumstances¶

When requesting creation of an account¶
When a device is requesting connection to a profile.¶

5.3.3. Profile Authentication

Profile Authentication has the same form as Device Authentication except that the client provides its Device Connection Assertion as part of the request:¶

5.3.4. Ticket Authentication

Ticket Authentication is used after a device has obtained an authentication ticket from a service. The ticket is returned in the response to a previous Profile Authentication exchange.¶

5.4. Payload Encoding

The Dare Message payload of a Hello request MUST be encoded in JSON encoding. The payload of all other requests MUST be in either JSON encoding or one of the encodings advertised as being accepted in a Hello response from the Service. Services MUST accept JSON encoding and MAY support the JSON-B or JSON-C encodings as specified in this document. Services MUST generate a response that is compatible with the DARE Message Content-Type specified in the request.¶

JSON was originally developed to provide a serialization format for the JavaScript programming language [ECMA-262]. While this approach is generally applicable to the type systems of scripting programming languages, it is less well matched to the richer type systems of modern object oriented programming languages such as Java and C#.¶

Working within a subset of the capabilities of JSON allows a Web Service protocol to be accessed with equal ease from either platform type. The following capabilities of JSON are avoided:¶

The ability to use arbitrary strings as field names.¶

The use of JSON objects to define maps directly¶

The following data field types are used:¶

Integer: Integer values are encoded as JSON number values.¶
String: Test strings are encoded as JSON text strings.¶
Boolean: Boolean values are encoded as JSON 'false', 'true' or 'null' tokens according to value.¶
Sequence: Sequences of data items that are encoded as JSON arrays¶
Object of known type: Objects whose type is known to the receiver are encoded as JSON objects¶
Object of variable type: Objects whose type is not known to the receiver are encoded as JSON objects containing a single field whose name describes the type of the object value and whose value contains the value.¶
Binary Data: Byte sequences are converted to BASE64-url encoding [RFC4648] and encoded as JSON string values.¶
Date Time: Date Time values are converted to Internet time format as described in [RFC3339] and encoded as JSON string values.¶

5.5. Error handling and response codes

It is possible for an error to occur at any of the three layers in the Web Service binding:¶

Service Layer¶

HTTP Layer¶

Transport Layer¶

Services SHOULD always attempt to return error codes at the highest level possible. However, it is clearly impossible for a connection that is refused at the Transport layer to return an error code at the HTTP layer. It is however possible for a HTTP layer error response to contain a content body.¶

In the case that a response contains both a HTTP response code and a well-formed payload containing a response, the payload response SHALL have precedence.¶

6. Key Establishment Protocol

The key establishment protocol is the mechanism used to establish an authentication context between a Mesh Client and a Mesh Host.¶

The key establishment protocol runs in parallel with regular Mesh communications. Each key establishment message consists of three segments:¶

Plaintext KEP¶
Encrypted KEP¶
Payload + Padding¶

When using HTTP transport, the ability of the client to respond to a packet sent by the host has already been established. When using UDP transport, amplification and resource denial attacks are possible.¶

6.1. Processes

6.1.1. Start = initial -> Begin | cloaked -> Begin

Depending on the discovery process, the client begins the connection establishment protocol with either the initial or cloaked message.¶

If the client has the Service credential, it MAY use either the initial or cloaked message to initiate the connection.¶
Otherwise, the initial message is used.¶

When using UDP transport, amplification the client MUST pad the initial and cloaked messages to the MTA and the host MUST reject messages that lack the required padding.¶

6.1.2. Begin = challenge -> Present | complete -> WaitClient | refused -> Stop

From the Host point of view, the initial and cloaked messages are equivalent.¶

The host MAY refuse the connection request by returning the refused event. In this case the key establishment is aborted.¶

Otherwise, the host either completes the connection request immediately or presents the client with a challenge to protect against resource exhaustion attacks.¶

6.1.3. Present = represent -> Begin

If the host presents a challenge, the client responds with the represent event containing the response to the challenge. This MAY involve a proof of work test to demonstrate that the client has performed a certain degree of work before the host commits resources to the public key operations.¶

6.1.4. WaitClient = request -> WaitService

A client that has reached the WaitClient state has established a ticket and shared secret. These are then used to enhance all further requests.¶

6.1.5. WaitService = response -> WaitClient | refused -> Stop

A host that has reached the WaitClient state has established a ticket and shared secret. These are then used to enhance all further responses.¶

6.2. Client Events

6.2.1. Initial

Client knows¶

Service DNS (Direct or from callsign)¶

Client presents¶

Client ephemeral key¶
Account Profile¶
Device Connection¶
Payload is plaintext¶

6.2.2. Cloaked

Encrypted version of the Initial request.¶

Client knows¶

Service DNS with Host key (Direct or from callsign)¶

Client presents¶

Client ephemeral key¶
Account Profile¶
Device Connection¶
Payload is plaintext¶

6.2.3. Present

6.2.4. Request

6.3. Server Events

6.3.1. Challenge

6.3.2. Complete

6.3.3. Response

6.3.4. Refused

7. Mesh Service Transactions

7.1. Service Description

The Hello transaction is used to determine the features supported by the service and obtain the service credentials¶

The request payload:¶

{
  "HelloRequest":{}}

The response payload:¶

{
  "MeshHelloResponse":{
    "Status":201,
    "Version":{
      "Major":3,
      "Minor":0,
      "Encodings":[{
          "ID":["application/json"
            ]}
        ]},
    "EnvelopedProfileService":[{
        "EnvelopeId":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkJZLUU0VkEtQ0
  1XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVNlcnZpY2UiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAg
  IkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"},
      "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJQcm9maWxlU2lnbmF0dX
  JlIjogewogICAgICAiVWRmIjogIk1CQlktRTRWQS1DTVdGLTUyVDctRVNMQS1QR05
  ULUNOTlgiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVi
  bGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgI
  CAgIlB1YmxpYyI6ICJKNDlrcGhHMGJZTFlrSXRDZm5jeURNOWFUcWpBUGd6Ql9Wen
  pjQU5VYjU5a0hfdUxuM1hBCiAgcFpCWVRmelI4NlFuN1hvMm5xX215NFlBIn19fSw
  KICAgICJTZXJ2aWNlQXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNE
  Ui1NSEtLLVRVN0otRDZORi1TR000LTZTRlAtWlNYNiIsCiAgICAgICJQdWJsaWNQY
  XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC
  AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAicjI3YVNLOWZkUEJ
  hZ2ExLWJmZE8zX0JVQlp6R1JWSHBwcGVfY05KM2NPRmYxQ3I4dGt2bAogIHZoQjhw
  eldjZ09mQndlUTJKYWU1bFRLQSJ9fX0sCiAgICAiU2VydmljZUVuY3J5cHRpb24iO
  iB7CiAgICAgICJVZGYiOiAiTUM3NS03TUtMLVpWQUktWEw2NC01UlpDLUxBWFMtNj
  NGVyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWN
  LZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQ
  dWJsaWMiOiAibHlmbXdvY2xwVm5KVTNPbVVwYmlVVm53YWljUXJEalc0OHRVZ1JYW
  DdFNEZ5am9iZ212bAogIDJvVTlrQ3ZmY1JrNWRzdG1xSDhEUHBhQSJ9fX0sCiAgIC
  AiU2VydmljZVNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ080LU1CTkwtWlR
  MSi1KNURCLUQ3SUYtTk9GUC03QTZWIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMi
  OiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogI
  kVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAielB1M1pNdTZZYjlvZHlnaExCb3
  ZwMWE4T0c1eUUzdzQ3ei12ZEFLNUlaVkZHaEpPVEVmRwogIGZxTjFMTEFGU2hQXzl
  iekxuZG1qTklJQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX",
            "signature":"GXYGhu6H4ZOuZiayoRy94x6WnIJiHhYHGvmD1Mzp
  Td9rqAHYspxMo-l6SyheWNccwzqP3Ps3v-AAg7P3SF-Dt8zyoRYYgS8Mwg3MavHlQ
  TJbAiyq1fruykJddR1EkB1FAxWayl73usHTWO_ffBauqiMA"}
          ],
        "PayloadDigest":"tf1ucBynDXcgOCrUO9HubDJLozl39Imevt14slRR
  PCRFoQRMOc1vvyMfDrPMcmAUmZN6nv34yLooay3-HMF1jg"}
      ],
    "EnvelopedProfileHost":[{
        "EnvelopeId":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkZDLUozQkMtRV
  FURC1VUVBNLVVSQlAtRlJDQS1WSEIzIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZUhvc3QiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"},
      "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1CRkMtSjNCQy1FUVRELVVRUE0tVVJCUC1GUkNBLVZ
  IQjMiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJkMU5BS3FoNTJWUVRnZm9lWlZHbWpoX3VrNk9PWFFZcXJvRFlwMW
  5fdWIxblBrQk9qbTVyCiAgMkg2VGotdlFTbmtuQ0U5OVJRTDl0cUtBIn19fSwKICA
  gICJFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1ENUotQzNRUy1USUpTLTdN
  SUItVjZZNi1HV0hFLVRLQUkiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKI
  CAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OC
  IsCiAgICAgICAgICAiUHVibGljIjogIm52REpzV0dXNGtSUWFZeEM4Z3NJQ0E0bnp
  4Zm0yTnVBeVprU1lwYnhJVHcxMU1ULUtONFYKICBuNmR1QXFheFptbnktNm81clFv
  TnFKMkEifX19LAogICAgIlNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ1ZGL
  TY1R1AtQjVTWC1TRlY2LUVZVFItUlJYUS01Qk0zIiwKICAgICAgIlB1YmxpY1Bhcm
  FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA
  iY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAic2o0ejN5TTlpZEkw
  bEZ4d0NhRjZFckFwSHpaQ0ltdGhLVnhuYk5FQWVSRDRUSGZPRmNwTwogIHlQMXkwR
  DROcEZlaDZlZmdERVBLY2VlQSJ9fX0sCiAgICAiQXV0aGVudGljYXRpb24iOiB7Ci
  AgICAgICJVZGYiOiAiTUFRWi1OV0lZLUdDN0ktQ1E2SS1HTUEzLU1CNEYtUllBWCI
  sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF
  Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiVTFYNWtKRU55NDYwTzZ5VEdIY3FzMkFBMXphU2Ffbm4yR3FxRHBxcENtRE
  RZREhHMWVEUwogIDZKSGR1QmNkTVlZeWdteUdRbncyRjRDQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3",
            "signature":"zIbCIREQXwu5GBXdPKHZmO5dkJ3h-Jta65FYKLy8
  lQrNp2yLPN_ox5QHlp-tkw8fnFsIe3IMQIgAOOWqpdJejQGLhiymClaz7BPEQlsEt
  o0q-pwH2iBiHoPiMv65YOaZPzblW2X4j3BsCt4I2StEciAA"}
          ],
        "PayloadDigest":"njYw-Th6easiJpjiAz6pz9rsb8xxhZTO5UaXM8_P
  P75IfULeBhkki3773VDhqL71EIAwvIfktFRF0G50CxKm3A"}
      ]}}

7.2. Account Creation

7.2.1. Bind User Account

A User Account is bound to a Mesh Service by completing a BindAccount transaction with the service.¶

The BindRequest message specifies the account address and ProfileUser of the account to be serviced.¶

The BindAccount transaction is unique in that it can fail to complete for reasons that are outside the scope of the Mesh specifications. Creation of an account might require payment to be made or authentication of the user's credentials. It is thus quite normal for the result of a CreateRequest to be the account being created in an 'on hold' state which can only be changed out of band.¶

If the request is at least partially successful, a BindResponse message is returned. In the case of partial success, a description of the request status and link to a Web page providing further details MAY be returned.¶

The request payload:¶

{
  "HelloRequest":{}}

The response payload:¶

{
  "MeshHelloResponse":{
    "Status":201,
    "Version":{
      "Major":3,
      "Minor":0,
      "Encodings":[{
          "ID":["application/json"
            ]}
        ]},
    "EnvelopedProfileService":[{
        "EnvelopeId":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkJZLUU0VkEtQ0
  1XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVNlcnZpY2UiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAg
  IkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"},
      "ewogICJQcm9maWxlU2VydmljZSI6IHsKICAgICJQcm9maWxlU2lnbmF0dX
  JlIjogewogICAgICAiVWRmIjogIk1CQlktRTRWQS1DTVdGLTUyVDctRVNMQS1QR05
  ULUNOTlgiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVi
  bGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgI
  CAgIlB1YmxpYyI6ICJKNDlrcGhHMGJZTFlrSXRDZm5jeURNOWFUcWpBUGd6Ql9Wen
  pjQU5VYjU5a0hfdUxuM1hBCiAgcFpCWVRmelI4NlFuN1hvMm5xX215NFlBIn19fSw
  KICAgICJTZXJ2aWNlQXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNE
  Ui1NSEtLLVRVN0otRDZORi1TR000LTZTRlAtWlNYNiIsCiAgICAgICJQdWJsaWNQY
  XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC
  AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAicjI3YVNLOWZkUEJ
  hZ2ExLWJmZE8zX0JVQlp6R1JWSHBwcGVfY05KM2NPRmYxQ3I4dGt2bAogIHZoQjhw
  eldjZ09mQndlUTJKYWU1bFRLQSJ9fX0sCiAgICAiU2VydmljZUVuY3J5cHRpb24iO
  iB7CiAgICAgICJVZGYiOiAiTUM3NS03TUtMLVpWQUktWEw2NC01UlpDLUxBWFMtNj
  NGVyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWN
  LZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQ
  dWJsaWMiOiAibHlmbXdvY2xwVm5KVTNPbVVwYmlVVm53YWljUXJEalc0OHRVZ1JYW
  DdFNEZ5am9iZ212bAogIDJvVTlrQ3ZmY1JrNWRzdG1xSDhEUHBhQSJ9fX0sCiAgIC
  AiU2VydmljZVNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ080LU1CTkwtWlR
  MSi1KNURCLUQ3SUYtTk9GUC03QTZWIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMi
  OiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogI
  kVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAielB1M1pNdTZZYjlvZHlnaExCb3
  ZwMWE4T0c1eUUzdzQ3ei12ZEFLNUlaVkZHaEpPVEVmRwogIGZxTjFMTEFGU2hQXzl
  iekxuZG1qTklJQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBBY-E4VA-CMWF-52T7-ESLA-PGNT-CNNX",
            "signature":"GXYGhu6H4ZOuZiayoRy94x6WnIJiHhYHGvmD1Mzp
  Td9rqAHYspxMo-l6SyheWNccwzqP3Ps3v-AAg7P3SF-Dt8zyoRYYgS8Mwg3MavHlQ
  TJbAiyq1fruykJddR1EkB1FAxWayl73usHTWO_ffBauqiMA"}
          ],
        "PayloadDigest":"tf1ucBynDXcgOCrUO9HubDJLozl39Imevt14slRR
  PCRFoQRMOc1vvyMfDrPMcmAUmZN6nv34yLooay3-HMF1jg"}
      ],
    "EnvelopedProfileHost":[{
        "EnvelopeId":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQkZDLUozQkMtRV
  FURC1VUVBNLVVSQlAtRlJDQS1WSEIzIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZUhvc3QiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzoyOVoifQ"},
      "ewogICJQcm9maWxlSG9zdCI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1CRkMtSjNCQy1FUVRELVVRUE0tVVJCUC1GUkNBLVZ
  IQjMiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJkMU5BS3FoNTJWUVRnZm9lWlZHbWpoX3VrNk9PWFFZcXJvRFlwMW
  5fdWIxblBrQk9qbTVyCiAgMkg2VGotdlFTbmtuQ0U5OVJRTDl0cUtBIn19fSwKICA
  gICJFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1ENUotQzNRUy1USUpTLTdN
  SUItVjZZNi1HV0hFLVRLQUkiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKI
  CAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiWDQ0OC
  IsCiAgICAgICAgICAiUHVibGljIjogIm52REpzV0dXNGtSUWFZeEM4Z3NJQ0E0bnp
  4Zm0yTnVBeVprU1lwYnhJVHcxMU1ULUtONFYKICBuNmR1QXFheFptbnktNm81clFv
  TnFKMkEifX19LAogICAgIlNpZ25hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ1ZGL
  TY1R1AtQjVTWC1TRlY2LUVZVFItUlJYUS01Qk0zIiwKICAgICAgIlB1YmxpY1Bhcm
  FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA
  iY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAic2o0ejN5TTlpZEkw
  bEZ4d0NhRjZFckFwSHpaQ0ltdGhLVnhuYk5FQWVSRDRUSGZPRmNwTwogIHlQMXkwR
  DROcEZlaDZlZmdERVBLY2VlQSJ9fX0sCiAgICAiQXV0aGVudGljYXRpb24iOiB7Ci
  AgICAgICJVZGYiOiAiTUFRWi1OV0lZLUdDN0ktQ1E2SS1HTUEzLU1CNEYtUllBWCI
  sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF
  Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiVTFYNWtKRU55NDYwTzZ5VEdIY3FzMkFBMXphU2Ffbm4yR3FxRHBxcENtRE
  RZREhHMWVEUwogIDZKSGR1QmNkTVlZeWdteUdRbncyRjRDQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBFC-J3BC-EQTD-UQPM-URBP-FRCA-VHB3",
            "signature":"zIbCIREQXwu5GBXdPKHZmO5dkJ3h-Jta65FYKLy8
  lQrNp2yLPN_ox5QHlp-tkw8fnFsIe3IMQIgAOOWqpdJejQGLhiymClaz7BPEQlsEt
  o0q-pwH2iBiHoPiMv65YOaZPzblW2X4j3BsCt4I2StEciAA"}
          ],
        "PayloadDigest":"njYw-Th6easiJpjiAz6pz9rsb8xxhZTO5UaXM8_P
  P75IfULeBhkki3773VDhqL71EIAwvIfktFRF0G50CxKm3A"}
      ]}}

[Future: Consider converting this to a Messaging flow.]¶

7.2.2. Bind Group Account

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

The request payload:¶

{
  "TransactRequest":{
    "Updates":[{
        "Container":"MMM_Member",
        "Envelopes":[[{
              "dig":"S512",
              "policy":{
                "enc":"none",
                "dig":"none",
                "Sealed":true},
              "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24v
  bW1tLWNhdGFsb2cifQ",
              "SequenceInfo":{
                "DataEncoding":"JSON",
                "ContainerType":"Merkle",
                "Index":0}},
            "",
            {
              "PayloadDigest":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_
  SpIdNs6c5H0NE8XYXysP-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg",
              "TreeDigest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpL
  Ab2JbsO1YQnJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"}
            ]
          ]},
      {
        "Container":"MMM_Access",
        "Envelopes":[[{
              "dig":"S512",
              "policy":{
                "enc":"none",
                "dig":"none",
                "Sealed":true},
              "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24v
  bW1tLWNhdGFsb2cifQ",
              "SequenceInfo":{
                "DataEncoding":"JSON",
                "ContainerType":"Merkle",
                "Index":0}},
            "",
            {
              "PayloadDigest":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_
  SpIdNs6c5H0NE8XYXysP-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg",
              "TreeDigest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpL
  Ab2JbsO1YQnJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"}
            ]
          ]},
      {
        "Container":"MMM_Publication",
        "Envelopes":[[{
              "dig":"S512",
              "policy":{
                "enc":"none",
                "dig":"none",
                "Sealed":true},
              "ContentMetaData":"ewogICJjdHkiOiAiYXBwbGljYXRpb24v
  bW1tLWNhdGFsb2cifQ",
              "SequenceInfo":{
                "DataEncoding":"JSON",
                "ContainerType":"Merkle",
                "Index":0}},
            "",
            {
              "PayloadDigest":"z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg_
  SpIdNs6c5H0NE8XYXysP-DGNKHfuwvY7kxvUdBeoGlODJ6-SfaPg",
              "TreeDigest":"FEHy24Y6cLModDXWH31kVc2a3TdhjXPooKHpL
  Ab2JbsO1YQnJolmowXAYHhkOGY0kg3jrKNTjds0myf4Dw1sdg"}
            ]
          ]}
      ]}}

The response payload:¶

{
  "TransactResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

7.2.3. Unbind Account

An account registration is deleted using theUnbindAccount transaction.¶

The request payload:¶

The response payload:¶

7.3. Persistence Store Management

All the state associated with a Mesh profile is stored as a sequence of DARE Messages in a Dare Container. The Mesh Service holding the master copy of the persistence stores and the devices connected to the profile containing complete copies (replicas) or partial copies (redactions).¶

Thus, the only primitive needed to achieve synchronization of the profile state are those required for synchronization of a DARE Container. These steps are:¶

Obtain the status of the catalogs and spools associated with the account.¶
Download catalog and spool updates¶
Upload catalog updates.¶

To ensure a satisfactory user experience, Mesh Messages are intentionally limited in size to 64 KB or less, thus ensuring that an application can retrieve the most recent 100 messages almost instantaneously on a high bandwidth connection and without undue delay on a slower one.¶

7.3.1. Status

The status transaction returns the status of the containers the device is authorized to access for the specified account together with the updated Device Connection Entry if this has been modified since the entry presented to authenticate the request was issued.¶

The request payload:¶

The response payload:¶

7.3.2. Download

The download transaction returns a collection of entries from one or more containers associated with the profile.¶

Optional filtering criteria MAY be specified to only return objects matching specific criteria and/or only return certain parts of the selected messages.¶

The service MAY limit the number of entries returned in an individual response for performance reasons.¶

Obsolete example 1

7.3.3. Conflict Detection

Clients SHOULD check to determine if updates to a container conflict with pending updates on the device waiting to be uploaded. For example, if a contact that the user modified on the device attempting to synchronize was subsequently deleted.¶

The means of resolving such conflicts is not in the scope of this specification.¶

7.3.4. Filtering

Clients may request container updates be filtered to redact catalog entries that have been updated or deleted or spool entries that have been read, deleted or were received before a certain date.¶

7.3.5. Transact

The transact transaction appends envelopes to one or more stores. The operation is atomic, that is either all the changes specified will be made to the stores or none will. This ensures that simultaneous attempts to update a store do not result in race conditions.¶

Each update to a catalog or container specifies the expected container index and apex digest. This provides a strong guarantee of consistency. The service MUST verify each update to check that the Merkle Tree values specified are consistent with the store entries and that the signature on the apex value (if specified) is valid and correct.¶

Services MAY impose limits on the size and number of additions performed in response to a TransactRequest message to ensure that processing time does not degrade performance for other users.¶

Obsolete example 2

7.4. Messaging

Mesh Messaging is an asynchronous messaging service that allows exchange of information between devices connected to a Mesh account and between Mesh users.¶

To enable effective abuse mitigation, Mesh Messaging enforces a four corner communication model in which all outbound and inbound messages pass through a Mesh Service which accredits and authorizes the messages on the user's behalf.¶

Figure 2:

The Post transaction is used for client-service and service-service messaging transactions.¶

Client-Service (Post Transaction)¶

To send a message, the client creates the Mesh Message structure, encapsulates it in a DARE Message and forwards this to its service using a Post transaction.¶

The Post transaction is authenticated to the service by device using the usual means of profile or ticket authentication.¶

The DARE Message MUST be signed under a device signature key accredited by a Device Connection Assertion provided in the message signature block.¶

The request payload:¶

{
  "ConnectRequest":{
    "EnvelopedRequestConnection":[{
        "EnvelopeId":"MCXG-4JUY-HJYA-ZUTD-MOLU-K2V7-6THR",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQjVXLVQzM0EtVF
  hXTi1TVVhVLVFGSjMtTFJZMy1TTEc0IiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzozMVoifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi
  AiTkI1Vy1UMzNBLVRYV04tU1VYVS1RRkozLUxSWTMtU0xHNCIsCiAgICAiQXV0aGV
  udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1DVjQtTEdK
  QS1KNlRJLVpKNEQtU1hKVy1CT0syLUhDWkwiLAogICAgICAgICJkaWciOiAiUzUxM
  iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk
  NJNklDSk5RMVkwTFV4SFNrRXRTalpVU1MxCiAgYVNqUkVMVk5ZU2xjdFFrOUxNaTF
  JUTFwTUlpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk
  bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV
  04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeExUQTRMVEExVkRFMk9qTT
  NPak14V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V
  3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK
  VlpHWWlPaUFpVFVOV05DMU1SMHBCTFVvMlZFa3RXCiAga28wUkMxVFdFcFhMVUpQU
  3pJdFNFTmFUQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC
  BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F
  nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli
  R2xqSWpvZ0luQXRWVlpYYkRaU2FEUmhSazQwUWtzCiAgeldqRkdjMnhpY0Y5cU9YT
  kdOa3BvWTJoVVpsTm5jbVp5T0V4R1JWTnFRazlqWlZnS0lDQTFUbDl6WlZGeE0KIC
  AxQjViWEpJTFhkd2VFMUlTV3RWYzBFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI
  yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVUZSVWkxSU5FRTBMVFJIUXpZ
  dFdqUlpXUzB5V1V3MUxWYzNVakl0VVZwTVNTSXNDCiAgaUFnSUNBZ0lDSlFkV0pzY
  VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC
  BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F
  nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpTUZWc2NrVmxMVXd6YVRCeUxYQm9Z
  VEpyTm1rMVNESlZNMlJSWlZKdmNWOVBaMTlKT0ZwCiAgcFNta3lhbTB6UlRsQ1dsQ
  Xhkd29nSUZoWlNEQlVaRVp3UkZKV0xVSjJWeTAwUVVObVpUQXRRU0o5Zlgwc0MKIC
  BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxRE4
  wZ3ROa1ZHV1MwelRGUgogIEJMVWsxUzBNdFF6ZFlXQzFCU0ZwSUxVbEVOVklpTEFv
  Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS
  UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC
  BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSnhNVzV
  vVlRSSlVXZEdOSGMzYQogIFRWRFFXVjZNR2wyT0RaMFdtcFJOVmw0VmpOSmVUSmpW
  MWQxVjNGdlRuSjFTMFZJTm5ocUNpQWdiRTVPU3pnCiAgMVJIZFZaWFJFZERkR2JHb
  HZXVEJ6YVRKQkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC
  BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlJFTklMVVJIV1VndFdFaEZSUzFQTlVGVUx
  WZE9RVlF0UTFGVFR5MQogIEZURUpMSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G
  dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT
  2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC
  BnSUNBZ0lsQjFZbXhwWXlJNklDSnBVMUJxZEdFNFpHTnJRVkpyVEd4UGR6bHlkRFZ
  UVFZCMVFWaEROVjg1VQogIDJ0dk1FZzBVVVZQYldwWVJtbExUbWR6Wm1wakNpQWdO
  RmMyWldGRGEwUmpSM0oyVDNOTVpXZDFiVlE0ZDIxCiAgQkluMTlmWDE5IiwKICAgI
  CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC
  JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQ1Y0LUxHSkEtSjZUSS1aSjRELVN
  YSlctQk9LMi1IQ1pMIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICJiYjV6aTVQ
  ZzVRcjNqSUtYRUI5SnFkQ1VEVWN3RVowSDBrQ1FuQjVMcjZ2djJsZVJYCiAgbmZve
  mFuZnM2VnhkcFR5MVF2RDB0SmVOLW1BdHBPWHg4bU1mRU50MmZJRjVjbzlCZzYxUk
  lTSXotODJ3cEkKICB4RUl2OEF5Q3NhWHJRZ09rZzZCQ1BXVTBXNUJRWk9ORmlkSG8
  wWndVQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJQV1dkcjBtNE5Pdjc4
  ZjIzcEhQaTBrZzNfRTltZU10bVM4V0NhQS1wQ0M4am8KICB0LVZuN3BGeVNtVFlmV
  XhtbkR1dTAxM0dXVHBtQlk4eWszYkRBY0NtUSJ9XSwKICAgICJDbGllbnROb25jZS
  I6ICJkNU5WMUVlcVlXa20zTEVCeTBqMVBnIiwKICAgICJBY2NvdW50QWRkcmVzcyI
  6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ"
      ]}}

The response payload:¶

{
  "ConnectResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "EnvelopedAcknowledgeConnection":[{
        "EnvelopeId":"MBI4-NKXK-OCSH-URV5-VDUT-PH57-WBDY",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJCVlZMLTJBVFYtMl
  UyUS1WM0FMLUhVNTQtQzU1Si1YWktVIiwKICAiTWVzc2FnZVR5cGUiOiAiQWNrbm9
  3bGVkZ2VDb25uZWN0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmpl
  Y3QiLAogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6MzJaIn0",
        "SequenceInfo":{
          "Index":1,
          "TreePosition":0},
        "Received":"2021-08-05T16:37:32Z"},
      "ewogICJBY2tub3dsZWRnZUNvbm5lY3Rpb24iOiB7CiAgICAiTWVzc2FnZU
  lkIjogIkJWVkwtMkFUVi0yVTJRLVYzQUwtSFU1NC1DNTVKLVhaS1UiLAogICAgIkV
  udmVsb3BlZFJlcXVlc3RDb25uZWN0aW9uIjogW3sKICAgICAgICAiRW52ZWxvcGVJ
  ZCI6ICJNQ1hHLTRKVVktSEpZQS1aVVRELU1PTFUtSzJWNy02VEhSIiwKICAgICAgI
  CAiQ29udGVudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpaQ0k2SUNKT1FqVl
  hMVlF6TTBFdFZGaFhUaTEKICBUVlZoVkxWRkdTak10VEZKWk15MVRURWMwSWl3S0l
  DQWlUV1Z6YzJGblpWUjVjR1VpT2lBaVVtVnhkV1Z6ZAogIEVOdmJtNWxZM1JwYjI0
  aUxBb2dJQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJC
  iAgc0NpQWdJa055WldGMFpXUWlPaUFpTWpBeU1TMHdPQzB3TlZReE5qb3pOem96TV
  ZvaWZRIn0sCiAgICAgICJld29nSUNKU1pYRjFaWE4wUTI5dWJtVmpkR2x2YmlJNkl
  Ic0tJQ0FnSUNKCiAgTlpYTnpZV2RsU1dRaU9pQWlUa0kxVnkxVU16TkJMVlJZVjA0
  dFUxVllWUzFSUmtvekxVeFNXVE10VTB4SE4KICBDSXNDaUFnSUNBaVFYVjBhR1Z1Z
  EdsallYUmxaRVJoZEdFaU9pQmJld29nSUNBZ0lDQWdJQ0pGYm5abGJHOQogIHdaVW
  xrSWpvZ0lrMURWalF0VEVkS1FTMUtObFJKTFZwS05FUXRVMWhLVnkxQ1Qwc3lMVWh
  EV2t3aUxBb2dJCiAgQ0FnSUNBZ0lDSmthV2NpT2lBaVV6VXhNaUlzQ2lBZ0lDQWdJ
  Q0FnSWtOdmJuUmxiblJOWlhSaFJHRjBZU0kKICA2SUNKbGQyOW5TVU5LVm1KdGJIa
  GtWMVpLV2tOSk5rbERTazVSTVZrd1RGVjRTRk5yUlhSVGFscFZVMU14QwogIGlBZ1
  lWTnFVa1ZNVms1WlUyeGpkRkZyT1V4TmFURkpVVEZ3VFVscGQwdEpRMEZwVkZkV2V
  tTXlSbTVhVmxJCiAgMVkwZFZhVTlwUVdsVlNFcDJXbTFzYzFvS0lDQlZVbXhrYld4
  cVdsTkpjME5wUVdkSmJVNHdaVk5KTmtsRFMKICBtaGpTRUp6WVZkT2FHUkhiSFppY
  VRsMFlsY3dkbUl5U25GYVYwNHdTV2wzUzBsRFFRb2dJR2xSTTBwc1dWaAogIFNiRn
  BEU1RaSlEwbDVUVVJKZUV4VVFUUk1WRUV4VmtSRk1rOXFUVE5QYWsxNFYybEtPU0o
  5TEFvZ0lDQWdJCiAgQ0FpWlhkdlowbERTbEZqYlRsdFlWZDRiRkpIVmpKaFYwNXNT
  V3B2WjJWM2IyZEpRMEZuU1d4Q2VXSXlXZ28KICBnSUhCaVIxWlVZVmRrZFZsWVVqR
  mpiVlZwVDJsQ04wTnBRV2RKUTBGblNVTktWbHBIV1dsUGFVRnBWRlZPVgogIDA1RE
  1VMVNNSEJDVEZWdk1sWkZhM1JYQ2lBZ2EyOHdVa014VkZkRmNGaE1WVXBRVTNwSmR
  GTkZUbUZVUTBsCiAgelEybEJaMGxEUVdkSlEwcFJaRmRLYzJGWFRsRlpXRXBvWWxk
  V01GcFlTbnBKYW04S0lDQm5aWGR2WjBsRFEKICBXZEpRMEZuU1VOS1VXUlhTbk5oV
  jA1TVdsaHNSbEV3VWtsSmFtOW5aWGR2WjBsRFFXZEpRMEZuU1VOQlowbAogIHRUbm
  xrYVVrMlNRb2dJRU5LUmxwRVVUQlBRMGx6UTJsQlowbERRV2RKUTBGblNVTkJhVlZ
  JVm1saVIyeHFTCiAgV3B2WjBsdVFYUldWbHBZWWtSYVUyRkVVbWhTYXpRd1VXdHpD
  aUFnZWxkcVJrZGpNbmhwWTBZNWNVOVlUa2QKICBPYTNCdldUSm9WVnBzVG01amJWc
  DVUMFY0UjFKV1RuRlJhemxxV2xablMwbERRVEZVYkRsNldsWkdlRTBLSQogIENBeF
  FqVmlXRXBKVEZoa2QyVkZNVWxUVjNSV1l6QkZhV1pZTVRsTVFXOW5TVU5CWjBsclZ
  uVlpNMG8xWTBoCiAgU2NHSXlOR2xQYVVJM1EybEJaMGxEUVFvZ0lHZEpRMHBXV2tk
  WmFVOXBRV2xVVlVaU1ZXa3hTVTVGUlRCTVYKICBGSklVWHBaZEZkcVVscFhVekI1V
  jFWM01VeFdZek5WYWtsMFZWWndUVk5UU1hORENpQWdhVUZuU1VOQlowbAogIERTbE
  ZrVjBwellWZE9VVmxZU21oaVYxWXdXbGhLZWtscWIyZGxkMjluU1VOQlowbERRV2R
  KUTBwUlpGZEtjCiAgMkZYVGt4YVdHd0tJQ0JHVVRCU1NVbHFiMmRsZDI5blNVTkJa
  MGxEUVdkSlEwRm5TVzFPZVdScFNUWkpRMHAKICBaVGtSUk5FbHBkMHRKUTBGblNVT
  kJaMGxEUVdkSlEwcFJaQW9nSUZkS2MyRlhUV2xQYVVGcFRVWldjMk5yVgogIG14TV
  ZYZDZZVlJDZVV4WVFtOVpWRXB5VG0xck1WTkVTbFpOTWxKU1dsWktkbU5XT1ZCYU1
  UbEtUMFp3Q2lBCiAgZ2NGTnRhM2xoYlRCNlVsUnNRMWRzUVhoa2QyOW5TVVpvV2xO
  RVFsVmFSVnAzVWtaS1YweFZTakpXZVRBd1UKICBWVk9iVnBVUVhSUlUwbzVabGd3Y
  zBNS0lDQnBRV2RKUTBGcFZUSnNibUp0UmpCa1dFcHNTV3B2WjJWM2IyZAogIEpRME
  ZuU1VOQmFWWlhVbTFKYW05blNXc3hSRTR3WjNST2ExWkhWMU13ZWxSR1Vnb2dJRUp
  NVldzeFV6Qk5kCiAgRkY2WkZsWFF6RkNVMFp3U1V4VmJFVk9Wa2xwVEVGdlowbERR
  V2RKUTBGcFZVaFdhV0pIYkdwVlIwWjVXVmMKICB4YkdSSFZubGpDaUFnZVVrMlNVa
  HpTMGxEUVdkSlEwRm5TVU5CYVZWSVZtbGlSMnhxVXpKV05WSlZUa1ZUUQogIDBrMl
  NVaHpTMGxEUVdkSlEwRm5TVU5CWjBsRFNtcGpibGtLSUNCcFQybEJhVkpYVVRCT1J
  HZHBURUZ2WjBsCiAgRFFXZEpRMEZuU1VOQlowbHNRakZaYlhod1dYbEpOa2xEU25o
  TlZ6VnZWbFJTU2xWWFpFZE9TR016WVFvZ0kKICBGUldSRkZYVmpaTlIyd3lUMFJhT
  UZkdGNGSk9WbXcwVm1wT1NtVlVTbXBXTVdReFZqTkdkbFJ1U2pGVE1GWgogIEpUbT
  VvY1VOcFFXZGlSVFZQVTNwbkNpQWdNVkpJWkZaYVdGSkZaRVJrUjJKSGJIWlhWRUo
  2WVZSS1FrbHVNCiAgVGxtVTNkTFNVTkJaMGxEU2tKa1dGSnZXbGMxTUdGWFRtaGtS
  MngyWW1sSk5ra0tJQ0JJYzB0SlEwRm5TVU4KICBCWjBsc1ZtdGFhVWsyU1VOS1RsS
  kZUa2xNVlZKSVYxVm5kRmRGYUVaU1V6RlFUbFZHVlV4V1pFOVJWbEYwVQogIFRGR1
  ZGUjVNUW9nSUVaVVJVcE1TV2wzUzBsRFFXZEpRMEZuU1d4Q01WbHRlSEJaTVVKb1k
  yMUdkRnBZVW14CiAgamJrMXBUMmxDTjBOcFFXZEpRMEZuU1VOQlowbHNRakZaQ2lB
  Z2JYaHdXVEIwYkdWVlZrUlNSV2RwVDJsQ04KICAwTnBRV2RKUTBGblNVTkJaMGxEU
  VdsWk0wb3lTV3B2WjBsc1p6Qk9SR2RwVEVGdlowbERRV2RKUTBFS0lDQgogIG5TVU
  5CWjBsc1FqRlpiWGh3V1hsSk5rbERTbkJWTVVKeFpFZEZORnBIVG5KUlZrcHlWRWQ
  0VUdSNmJIbGtSCiAgRlpVVkZaQ01WRldhRVJPVmpnMVZRb2dJREowZGsxRlp6QlZW
  VlpRWWxkd1dWSnRiRXhVYldSNldtMXdha04KICBwUVdkT1JtTXlXbGRHUkdFd1Vtc
  FNNMG95VkROT1RWcFhaREZpVmxFMFpESXhDaUFnUWtsdU1UbG1XREU1SQogIGl3S0
  lDQWdJQ0FnZXdvZ0lDQWdJQ0FnSUNKemFXZHVZWFIxY21Weklqb2dXM3NLSUNBZ0l
  DQWdJQ0FnSUNBCiAgZ0ltRnNaeUk2SUNKVE5URXlJaXdLSUNBZ0lDQWdJQ0FnSUNB
  Z0ltdHBaQ0k2SUNKTlExWTBMVXhIU2tFdFMKICBqWlVTUzFhU2pSRUxWTllTbGN0U
  Ws5TE1pMUlRMXBNSWl3S0lDQWdJQ0FnSUNBZ0lDQWdJbk5wWjI1aGRIVgogIHlaU0
  k2SUNKaVlqVjZhVFZRWnpWUmNqTnFTVXRZUlVJNVNuRmtRMVZFVldOM1JWb3dTREJ
  yUTFGdVFqVk1jCiAgaloyZGpKc1pWSllDaUFnYm1admVtRnVabk0yVm5oa2NGUjVN
  VkYyUkRCMFNtVk9MVzFCZEhCUFdIZzRiVTEKICBtUlU1ME1tWkpSalZqYnpsQ1p6W
  XhVa2xUU1hvdE9ESjNjRWtLSUNCNFJVbDJPRUY1UTNOaFdISlJaMDlyWgogIHpaQ1
  ExQlhWVEJYTlVKUldrOU9SbWxrU0c4d1duZFZRU0o5WFN3S0lDQWdJQ0FnSUNBaVV
  HRjViRzloWkVSCiAgcFoyVnpkQ0k2SUNKUVYxZGtjakJ0TkU1UGRqYzRaakl6Y0Vo
  UWFUQnJaek5mUlRsdFpVMTBiVk00VjBOaFEKICBTMXdRME00YW04S0lDQjBMVlp1T
  jNCR2VWTnRWRmxtVlhodGJrUjFkVEF4TTBkWFZIQnRRbGs0ZVdzellrUgogIEJZME
  50VVNKOVhTd0tJQ0FnSUNKRGJHbGxiblJPYjI1alpTSTZJQ0prTlU1V01VVmxjVmx
  YYTIwelRFVkNlCiAgVEJxTVZCbklpd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2NtVnpj
  eUk2SUNKaGJHbGpaVUJsZUdGdGNHeGxMbU4KICB2YlNKOWZRIl0sCiAgICAiU2Vyd
  mVyTm9uY2UiOiAiVFRPSlJPMFA0LUxBMlRFVU1TWUw5ZyIsCiAgICAiV2l0bmVzcy
  I6ICJCVlZMLTJBVFYtMlUyUS1WM0FMLUhVNTQtQzU1Si1YWktVIn19",
      {}
      ],
    "EnvelopedProfileAccount":[{
        "EnvelopeId":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQzQ0LUlaQzMtSV
  daVC1WQ1ZaLUwyQUctSEk0RS1MT1YyIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzozMVoifQ"},
      "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1DNDQtSVpDMy1JV1pULVZDVlotTDJBRy1ISTRFLUx
  PVjIiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJXNXVnRVd5Q3o5ODZQdzd4UFA5LWFwMDlQRnBxZmM5eF9NQjBVcT
  FiclVwRWcxeWxJYWl0CiAgRTVZYUpJQWVUYl9DYzV5NFlyNUQ2a2dBIn19fSwKICA
  gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy
  dmljZVVkZiI6ICJNQkJZLUU0VkEtQ01XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKI
  CAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ1FYLVBGN0
  EtTFkzRy0zWlBJLUFJWU8tTFI1RC1ZRzZXIiwKICAgICAgIlB1YmxpY1BhcmFtZXR
  lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2
  IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICIwQVJFMFZhcHNNcVlmX1Atd
  EZuRTBGWjJacTJ3bjRlMjF2aUNINFRyaHlnN1EwTjhGWG1iCiAgcFl2XzcyX0wyVk
  t1bGlpaU9oZGRUMU9BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIjo
  gewogICAgICAiVWRmIjogIk1DTEotTENGWC1FTkUyLTVOVEYtR0JOVi1NVzNQLVZI
  U1oiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS
  2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIl
  B1YmxpYyI6ICJHWG1nOHprMHB2VjliODgxSk52Um02OWRPVHVMN295WU53emlRUWx
  0V0Y0YVhaTUNUamY4CiAgRU0zZ3RDVTd3SEYwenVGc2QxV2dYOEdBIn19fSwKICAg
  ICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTURBNS1QW
  TZBLUJHMkwtN1lONi1FQUtQLU8zUUItQ0c1VCIsCiAgICAgICJQdWJsaWNQYXJhbW
  V0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImN
  ydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiWGNITjdBYk1UVzFUTVFP
  ZDBtWHlBSEc2Mk82ajdZSGdJR2hwMU9hajV4VE9LMnVQekd4TQogIGVDZUZPelgwZ
  i1ZSlhpakw2aGxfYmFXQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6IHsKIC
  AgICAgIlVkZiI6ICJNQ0dCLTRLQ0ktQ1AzRy1GSlNELVc3VzItVVlLTy1HTkxVIiw
  KICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVD
  REgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiY0Exd2NLdG4xZGFqNjA2VUQwUEo4eExxRk4wa09keHlqc0YyUUtyUFp4ZF
  VZZ1NQUlZSaQogIExzTEpPRWw3Y0lzdHRwYUNGd3VQaURPQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2",
            "signature":"p1UxtlxOGp8wd7oESFQkmqR6uV9s-cW4WtonkwN1
  BbH9F1KN6lllLPhnNBhlmstQ06cm7BEYtR6AwG2f1yOM1IjdPFzLmm53MBA-g4GLe
  bflsg87h_kvT9JVSnHq7MDY6ewMo97Boay7r26qf-Ci4xIA"}
          ],
        "PayloadDigest":"gNprAKlPBfHdWXEdD7djEQ8IoJzHAJS-zBlZW6Bj
  8xjHqsbEhqbSO4AkIEizON5HsGbMSu_BQl_NPSrKZWS9pw"}
      ]}}

Service-Service (Post Transaction)¶

The Mesh Service receiving the message from the user's device MAY attempt immediate retransmission or queue it to be sent at a future time. Mesh Services SHOULD forward messages without undue delay.¶

The Post transaction forwarding the message to the destination service carries the same payload as the original request but is authenticated by the service forwarding it. This authentication MAY be my means of either profile or ticket authentication.¶

Missing example 37

Denial of Service Mitigation¶

Services SHOULD implement Denial of Service mitigation strategies including limiting the maximum time taken to complete a transaction and refusing connections from clients that engage in patterns of behavior consistent with abuse.¶

The limitation in message size allows Mesh Services to aggressively time out connections that take too long to complete a transaction. A Mesh Service that hosted on a 10Mb/s link should be able to transfer 20 messages a second. If the service is taking more than 5 seconds to complete a transaction, either the source or the destination service is overloaded or the message itself is an attack.¶

Imposing hard constraints on Mesh Service performance requires deployments to scale and apply resources appropriately. If a service is attempting to transfer 100 messages simultaneously and 40% are taking 4 seconds or more, this indicates that the number of simultaneous transfers being attempted should be reduced. Contrawise, if 90% are completinin less than a second, the number of threads allocated to sending outbound messages might be increased.¶

Access Control¶

The inbound service MUST subject inbound messages to Access Control according to the credentials presented in the DARE Message payload.¶

After verifying the signature and checking that the key is properly accredited in accordance with site policy, the service applies authorization controls taking account of:¶

The accreditation of the sender¶
The accreditation of the transmitting Service¶
The type of Mesh Message being sent¶
User policy as specified in their Contact Catalog¶
Site policy.¶

Service-Client (Synchronization)¶

The final recipient receives the message by synchronizing their device. The message received will be appended to the inbound spool.¶

7.5. Publication

The Publication mechanism allows content to be published through a Mesh Account and retrieved by means of the EARL mechanism described in Uniform Data Fingerprint [draft-hallambaker-mesh-udf]. This mechanism is used in certain flows supported by the Mesh Device Connection and Contact Exchange functions.¶

Content is published by appending an entry to an account's Publication spool. The content may then be retrieved by issuing a claim to the account specifying the publication identifier that is authenticated under the value specified in the EARL.¶

Use of the Publication spool to post content necessarily requires that the content be smaller than the maximum message size imposed by the Mesh Service so that it can be uploaded to the service by means of a Transact transaction.¶

Publication of large data items will require modification of the protocol to support use of a detached message body. Transfer of a detached message body is outside the scope of this document.¶

7.5.1. Claim Transaction

The claim transaction is used to post a claim to a document published by means of an EARL. The claim interaction is used in the Static QR Code connection interaction but MAY be used for other purposes as required by Mesh applications.¶

A claim is made by sending a ClaimRequest message to the service to which the publication is posted. The service responds with a ClaimRespose message specifying the success or failure of the claim.¶

A device is preconfigured during manufacture and a Device Description published to the EARL:¶

The client claiming the publication creates a claim message specifying the resource being claimed and the address of the Mesh account making the claim.¶

Missing example 25

The message is signed by the claimant to make a RequestClaim to the service:¶

The publication is found and the claim is accepted, the publication is returned in the response.¶

The device waiting to be connected uses the PollClaim transaction to receive notification of a claim having been posted.¶

7.5.2. PollClaim Transaction

The PollClaim transaction is used to discover if a claim has been posted to a published document.¶

When an authenticated, authorized request is made, the service responds with the latest claim posted to the publication.¶

The device in the example above periodically polls the service to which the device description is published to find if a claim has been registered.¶

The PollClaimRequest contains the account to which the document is published and the publication ID:¶

The response returns the latest claim made as signed message:¶

7.6. Cryptographic

The Operate transaction is used to perform one or more cryptographic operations using private key material recorded in the Threshold Catalog. Such operations typically represent one part of a threshold key operation divided between the service and a device connected to an account.¶

As with all operations involving the Threshold catalog, the request MUST meet the authentication criteria specified by the catalog entry. These typically include the request being authenticated by a specific key.¶

7.6.1. Generate Key Shares

CryptographicOperationShare is used to request that a private key held by the service to be divided into two or more key shares. One key share is then encrypted under the encryption key of the service and the others are encrypted under public keys specified in the request. These parameters are returned in a CryptographicResultShare.¶

The request payload:¶

{
  "TransactRequest":{
    "Accounts":["bob@example.com"
      ],
    "Outbound":[[{
          "EnvelopeId":"MBVP-H2LE-JMGK-DDAX-2BVN-LJBM-22LP",
          "enc":"A256CBC",
          "kid":"EBQK-CZ5R-DWAD-5VAH-SJ7A-7ZAN-2GE5",
          "Salt":"xfcHvFiUdMEiUarO1C11jg",
          "recipients":[{
              "kid":"MBSO-V6BO-2RKR-GDCI-DWY3-SWXX-WBXO",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"dMDBhYLBN17FW33UCIWepwHeMe5nGGcRZBmfn
  _L933z3AStJPv1k2ryTvzPJtX6Hzk_YJSU-9E6A"}},
              "wmk":"KtkslCXX8DA3GC4YrOJmQo7yAfy7Eg2g7uTRlbn6GfDf
  Z5LQmkUETw"}
            ],
          "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQUVMLVpEWVgt
  NFpVUS1LUFJDLVlDNzctVVNBVi1XSEZNIiwKICAiTWVzc2FnZVR5cGUiOiAiR3Jvd
  XBJbnZpdGF0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLA
  ogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6NDBaIn0"},
        "zMT8ZtPMrikjNcspm6EVshYR1R__pG82CoNG6N91reJwVbH65V5i8ewD
  QwWNeFhnodVD6LjfTA4cNfV5vNl86BMik-TjhkH94iIlCejr5UrxoRQprlOkY_y-T
  blYkKGpV2jaMz15yd9OA1FjyKTT7GFpfo21y1JCh1VHOxBmSHEhYe3Ydm111E_U8B
  jAwjddaT96cVwMs_aAstycWMljTIx7MwUms_mFUeQRa-uuvWZAbtnuM37A8l_ah69
  1b4VdOc5WAhWtYP5Z9R-kD_0gfOwsvxXByFZFzl5ykCWkXHTpoIgBrw8tC9L3GDCS
  mxS0bUn3Py4_FNXyKvSMuRyCpu9kc8VxsN2msdSecS_E1ofZriPKWIl5vD3SZczbs
  cxj-RDtbO0fv6e46ZRz2CzxrHDiRcEdYE1LE_IkFCDqYrLCTGcpCx7ZS5ptjcqAb2
  r67vWay357q8u9RLZUe-fLV-pod_FhGUm8XrmhRZ48c6KFcICinQx9qsXj-Mcr99z
  yyjrBwTFqHNRQ4m73JcqT4jPtswaA83AD96rLcqawtUZxc2bDRrRP80pdA_vGofWa
  kqaP-z_mZBoLkdR_E_eB3JdrHDBOKh2Ku8VqBZhoiIxGF6NtRoVJAwHCXBOFSOV0q
  FUu6X1tVyDXTlmgIgYAvOEpIZzmUtMsAnCYDF4vCxdQVUO3_Mml-owxoiSQcZL3M7
  Fclh88YKxNwuMH9wp2aBFYiSZtKdpWoM_zjmE6U3BW6tWh4umriBksS1dBDodUBVh
  FvSdnSHj20Y8wGQPwiHZ9TtLrm35XFOWw2mqmUvuq3RGhOJBUXr4qLfNCDL_Uvv9G
  ctTPelZ5cOPCclk-893O5sznv7QRoJBmzrffElw2KTJy6uGlsl3iFsZ9JsQTOHjtu
  njQfSWCEB_zRqrbt5T9WKlWSIgvHp_EJakS28UO7HEiiemgS0E-Cp6NHQ92CGqHMX
  ztNvKXN3IaCkroOQbOlq_j9ZefIRwmyb92kMKsxH5tGzWRnC7zvMN9mQS4EQAGlLz
  DOUIUwnNsPyMohwbBML4TY3-TLg4VGpe7T5ikkodYza8VPhykasZrr-kgZ9iptSZR
  G1kro3DSluVytPkVPFzIKDo9h5bE54FQCZAptEftI2zzHpPtOHwyrzR1lQDDtI_XE
  TefFDEq6Mlvj1Zu3bciJBGvxLfQl4W-tbxgu3AUuRUviZMXcMq_TUPsDauGDJtN-6
  h7cRYGw8J4N3JZFSJRDZi4wN8TkKtJLR9u0Mt4LBvoqMTeBf-u-ZT_WGgSsVLIRPW
  LbUObeUXl-nqdQkAQPQ1Fnarv3hdUDOK-PZORfgr_MgT7-I0ErapcHjAoYIPKNbq5
  ukw_SJgRXYL9MFyUL5FQO9ee8IS1vPgGCwFrgE7EI7IgeTlhjmBrro9BkQTxfoppz
  hy4R90HAW0eTzUpCue0X-gNccn0NbI5iqeH1MehfEV1MHSSDV1aOQ1KaE4okZKKUj
  yddN9iPGL-VRlNjswm2tsq3TDVlfFXodN5IDNh6eK_KXDBv70NDNrM3fu9iH0H5km
  WAoEEdfzZeGHNcDG8aFE8rlX6_-wJuDDuPUTX1iozNXCMvTs_M46u3DVfEqTlZvRc
  Ky96QiZHp1lQQsLBnE8UcoQGXwL9FEgWl-R6G7FyVANC0vyWOokNg70tAb40rKzZX
  7a9pr0PMxQuv4KBBwN-r96hjoK4n2Yu86savenQUocrz931L_M3dmjq3cpnxj2x4r
  0AgMuxQKZJirEOfLl1fq0xsS1k1FwVN1GxcuFeXZFLeBv685qPF3eV1Ha546pLw-E
  nnPRzLPRHyHfU5aWCZAeU6ygwpVwNhMPtE_9vQDKLvArBvNW4Jafz-kisYIW7wnVU
  R33-PsKVf0-PxjvdNLjZ9VrACTqK--6ANUpvKjICv6Vxk_M08htaJqUnsxLPa7L4P
  5GmN1m4EVRpJByvcJLcqI43RXep2vO8BOxLnD1WuQ21L8uEg4usy1lFVbIIvIlaDJ
  e_EMtx1n9jN17GORRkOA8tB59TM-XoCSnTmgAwuMByjdZ0J3gj8smooSETJAZHK8u
  rDYS8fSc-zEWrqfPlg5tLu8r9jXaCHJkT_g1hJMUHTZ5Uj3qTou9W7G3FM8aCxGkF
  iGC8G9h3PIv4YvWDlB77CEU1dco_oEjMwZZNbF3bAKkhgW5Du0rcx_7MMeDJNV0j1
  Jfh41_2d5bKi7-2pyLZ6NZI0EK5bUrqHtdnlmW2XIMBactW9-vD-mXOislFWWOluu
  5czJuLyjnmJRRQeV3jLO6A0FP__HKc9OGwVhqeAN7c-2pylOnWYyObFTvLMxeyVCb
  kdl6Q2QfpRLXO68mb-xwk4JbYWjY3APKTJp-y2jC8czwo_eW1glt-CVmSpLbBUSSl
  Y4Gn5HomLTHAnHTWAWBgZ54YQf_gsb9VF4UAVmNNE8D5fXvBXcwz4hBlALI7J4Dgh
  BcFqO2wvSiobYByolAMjaa9G4bIDgAEqa10F589SRfE1cVe1qbmYT0-c8uX1FUD2R
  R2sRXy4dvHu_tlaLhfPP-RMMaDi7cW39NKmNtHRNvv2h1RcIOPSBMe77wIMR7cDy5
  PrtjA0d_NAf5Xrj8YsFbuxx0yItnvge8ZOpM-y8Yq5qr_roNYlJLSLxiF6F7bReiy
  LNjqC_MmgzWztz96giKQZlZmWgPdOpFj7kDOtk3ruJn6RCF7-fvAx_-pa5Yc99bHW
  zwfFnLW6Il0bnAgmXibf13klh4iQ1Rid7ZU-TG6c21uQgsdl1bSJBCEdSS7pJSmj6
  laHTWLAdo-UYcPuiNLbxbnUwqLja0OLNccmvnZ0GRdRSOOuwbrqYKomI_3gVadKN9
  nUh-24Rtu65PGJEsuTSVj24WH9hMgxV2E_i03CxV6QyhmF-vgejl1gSELrYsXlxBB
  kXOa2-rMwj89fveTIYScNWj1iuxePvyCHK2QcIMj84DeoIUDVpsrreU7XgVKggCwH
  pag7jXvLgqYHZcHWkybOKnMLZ5kVy6qGMPTMaPpxdfBwnGglLy7TTmkwqms5BxGBi
  EiUEm_-fcKg3IZmQv5p91xzK30VaUadjqq7EJ3LcuvSEHKqz7r_5m0UsrNaJOO4WD
  y5igSBwzfOpmyiYPZzRQ5MAp14KUDfZGOtyY7fKPY3Iq9ajz166fwcIxS3HAhskIW
  YYK8p-4PRvr0GIue2FLyBhH3-RLuK_EHxEfLsbAw83OSIDo1Ne4SUO99sMRNj7ZNB
  ovY_e4giibi7cEZbxVP5XKIJi0PilJ1h0V6npB9K7lCw6fybROeTDQfb8MW26G3rJ
  Gya0yJuVUHqnzLLATYhzMJvwpthFvxzdn3Kuv6_XTUqbyRs7IgPXW7D-HhEbOhU4s
  uhcX6juMtlwWnzjq65VzgxINzFXYh03CewZ9edz6_LlqRRTfTSRvoDJOf67hrVssc
  tFXcL3CQWs_Nka66Y3QiJHrTwNZenDR-JG8GL0B40Sy-9tBrhJNyqrb7J5YTs8rfN
  V_PggOt0EKgDFfXtKETHu1A5CZ2mtB_cRR133XCDNP8ecnJ8yW-b9UN1f4sMi8zMi
  gmQ1oFDTt_dcCaV6hafw8-n6bZ9k4oW6UmgXw5slQbIBcyXX2wpLMJ3UNJswswMIj
  xF_Ez-jabaIqSDwIANCuXJ-TteQnu4b_aXfeJdYHv0dbWqA8bgYcYLJ118-uH8QHC
  CwGyoGg5zIqwCpRV8VVXXN1laxK1eGbnINvLwbZXaJY4M6dZ4k3nGpV7ixDx8hELM
  9d9EewmHp6ZSQ5IJ6imk6KpfVxdr9pws4FOXqtkrJihUjYOjiVrvZLJK8EbzpXKKS
  yA7qpoCWDjhLfTRqDutTOVCmqtQkM1v6LSbqfqL_MY6DIlJ93-I9zB7aVH2tvXRiP
  8PskHGhcRYnKSMgqyKcrIY7mS4DXLtJ0O7yZ5V7cFgxv9KzK11C71jy-eK5lKx11I
  aAC-bJEzudOysYaXB44JKPNafKohU3CRWnV6C66j4kl1HMT7rxzgF5U7GwcajlzvX
  hOEg-DJ7PRekhrFQjJ-czoeWD-Jkw1iBgxTTvoDoxT08c9YiFgPEy_0cGshI7woxQ
  cl6xIw44Akk07nlMNkQffkX2B4kshbDHWzKmxpLAGYwdTPQI98vjsSqzjEvpQ5YgD
  njuLyCJzaKb3eBVG4K-FIfXFVW5-U_WaU8zAYpm2bHneCLQMI--AE4j0z7YANoBQL
  YaCNjW8KhBwfjmFjwF3IywHP_-9nQL6BDFhGmYAemTgGbiUQ51fFYNQ0qMbfDjEAC
  _-j87FWRg2IINsGFdzf80i42KBTbQ"
        ]
      ]}}

The response payload:¶

{
  "TransactResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully"}}

7.6.2. Key Agreement

CryptographicOperationKeyAgreement is used to request a threshold key agreement operation on a specified public key.¶

The request payload:¶

The response payload:¶

7.6.3. Sign

Threshold signature is not currently supported.¶

8. Message Interactions

Message interactions are asynchronous interactions that occur between devices connected to the same account or between accounts.¶

All messages are signed by the sender and encrypted under the encryption key of the recipient if this is known to the sender.¶

8.1. Message PIN Interaction

The Message PIN Interaction is used to register and validate PIN codes used to authenticate certain transactions. This interaction allows a PIN code issued by one device to be consumed by another allowing for greater convenience in managing devices or contact exchange.¶

For example, Alice might delegate the PIN code issue privilege to her mobile device without delegating the administration privilege to that device. This would allow Alice to use her mobile device to initiate the connection of a large number of devices to her Mesh as her house is being built and approve them later using her administrative device.¶

Use of the Message PIN interaction is optional. An application that issues a PIN code to authenticate a message MAY store the PIN value within the application without persisting it to external storage.¶

Derivation of the SaltedPin, MessageId and Witness values from their respective inputs is described in the Schema Reference [draft-hallambaker-mesh-schema].¶

8.1.1. Registration

To register a PIN code to an Account, a device:¶

Generates the PIN code value¶
Calculates the SaltedPin value for the specified Action¶
Calculates the PinId binding the specified SaltedPin to the Account.¶
Creates and signs MessagePin containing the SaltedPin , Action and Account values with the MessageId value PinId.¶
Appends the MessagePin value to the Administration Spool of the Account.¶

Note that this construction provides limited protection against forgery attacks by a party with access to the MessagePin. A party with such access can use it to construct the witness value required to authenticate a request.¶

PIN Code values consist of an opaque sequence of octets represented as a UDF nonce value. Codes are presented in canonical UDF form, i.e. Base32 encoding separated into groups of 4 characters. The PIN value is converted to binary form for calculation of the SaltedPin, thus ensuring that the canonical form of the PIN value is used.¶

8.1.2. Authentication

The PIN Code value is passed out of band to a user who will enter it into a device to authenticate a request made to the issuer.¶

A request that MAY be validated by means of a PIN is a subclass of MessagePinValidated and contains the following fields:¶

AuthenticatedData: A DARE Envelope containing the data that is authenticated.¶
ClientNonce: A nonce value used to prevent certain replay attacks.¶
PinId: Digest value binding the SaltedPin to the Account.¶
PinWitness: Witness value calculated as KDF (Device.UDF + AccountAddress, ClientNonce)¶

The device uses the PIN code and Action identifier corresponding to the desired request to calculate the SaltedPin value in the same manner as during registration. This value is then used to calculate the PinId and PinWitness values.¶

8.1.3. Validation

The PIN code is validated by performing the steps of:¶

Calculating the SaltedPin value from the PIN code and Action¶
Calculating PinId from SaltedPin and Account¶
Retrieving a MessagePin from the Administration spool with the MessageId PinId.¶
Calculating the PinWitness value from SaltedPin, ClientNonce and AuthenticatedData and checking this matches the value specified in the message.¶
Performing the requested action.¶
Posting a Complete message to the Administration Spool of the Account marking the PIN code as used.¶

This process can fail at multiple points resulting in different error results:¶

PinInvalid: No PIN code is specified, the Pin code indicates an unsupported algorithm or the calculated PinWitness does not match the one specified by the request.¶
PinUsed: The PIN code has been used previously.¶
PinExpired: The PIN code is no longer valid.¶

Note that in the case that an attempt is made to reuse a PIN, it is not automatically the case that the first use of the PIN was the one that was valid and only the second attempt was invalid. Implementations SHOULD alert the user to the attempted re-use so that this possibility can be considered and appropriate action taken.¶

8.1.4. Example

Alice connects a device using a QR code presented by her administrative device.¶

The administration device creates a PIN code and records it to the Local spool:¶

{
  "MessagePin":{
    "MessageId":"ACCL-WJJ6-QILY-IDQT-67RT-LHGM-PA2K",
    "Account":"alice@example.com",
    "Expires":"2021-08-06T16:37:40Z",
    "Automatic":true,
    "SaltedPin":"ADBB-JTKR-RGGL-ACEM-TW6E-ZFY6-NQXF",
    "Action":"Device"}}

This pin value is used to authenticate the connection request from the device:¶

{
  "RequestConnection":{
    "MessageId":"NBF4-4PTH-UTSC-RYHZ-EQMK-BVH7-MU3F",
    "AuthenticatedData":[{
        "EnvelopeId":"MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQU9LLUk0VFQtM0
  VVUy00TE1ZLVo2Sk8tVkVONy1DWDZGIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDIxLTA4LTA1VDE2OjM3OjQwWiJ9"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm
  UiOiB7CiAgICAgICJVZGYiOiAiTUFPSy1JNFRULTNFVVMtNExNWS1aNkpPLVZFTjc
  tQ1g2RiIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs
  aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI
  CAiUHVibGljIjogInRERTlnUy02RFk5bVBFWWFScVJmTjh6bW8zOE83N2ZIR2EtaF
  JYd0Z1NFhnbjVrMkdQcUEKICBqN1ZXRkVmc2FpX2JtMlJNc2w3UE8xU0EifX19LAo
  gICAgIkVuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUQ2Vi01NEZTLTZRRUYt
  MkNKRy1FVVhBLU5DVk4tWDVINyIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjoge
  wogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJYND
  Q4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMm5Ncl9GUVExYW1VbU13VzFadVQ0Tmp
  hWXJwRDcyTG5LTUstaXJTc3ZCVldxczVrT3JUSwogIGRQcjh5YkQ3MUoxNmxXNkJk
  LWJnN3htQSJ9fX0sCiAgICAiU2lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1BT
  UktSTdPUy1NQ1VNLVc3SEstNlFTRS1RWE5MLUVKR1MiLAogICAgICAiUHVibGljUG
  FyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICA
  gICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJmeTN6bWhJdFFK
  ZFRaVnJucjVFNlAzT2d6RmVVa2hFYTdOQWNTUHBHUkxvc3U3XzNCUEp6CiAgb1JqO
  EVDT19kSkpvOUJlMU9jTzdJUW9BIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IH
  sKICAgICAgIlVkZiI6ICJNQkZOLUIyQ1gtS1JJUS0zTUhMLTdTT1ItWDVXSi1DSFF
  HIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl
  eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1Y
  mxpYyI6ICI2ZmdRRXZEOFNGWjZzb0VzLXJNa1ZXbDFCY202N2s3TVYzcWxlRzQySX
  ZaN0NOM1FLbDRvCiAgZFhHaVBnOFU0NDZ3bGpQQVJEQnBkNFFBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F",
            "signature":"14AHQuUENwVXXulI7Hxa1cceWaSS_qBhfy-tydNF
  n7rJksVfHMDiy8vrrvdV00BGuktPqgp86C2AWSac9FnGXwhNZ3PV2edzsCwC_e21d
  UoGQ7XPPL886uw5wkDjz7Nt8WxL1Dn8uwpAph_xrIMMNSsA"}
          ],
        "PayloadDigest":"ZXcdFX7i4PYf4oJ6O7_dLw7TWEkr0vC_r3_RcaDd
  cy-Wz4DPbqhCk1VGyU0YLsR6C6NEcHa9ExjBa5OIoZakgA"}
      ],
    "ClientNonce":"VGxxL-LKUQyqn_Rpdj86Zg",
    "PinId":"ACCL-WJJ6-QILY-IDQT-67RT-LHGM-PA2K",
    "PinWitness":"YhwAi-IvYYP2dMjOd-pXioRqgIq0knwLwnUqMHvpvTueLMc
  7ATSXMdBlxOSZ_u8sztqpwwEZEZ5Rc4WQBKP3cA",
    "AccountAddress":"alice@example.com"}}

The administration device can now use the PIN Identifier to retreive the MessagePIN from the Local spool and use it to verify the request.¶

8.2. Completion Interaction

Completion messages are dummy messages that are added to a Mesh Spool to mark a change the status of messages previously posted. Any message that is in the inbound spool and has not been erased or redacted MAY be marked as read, unread or deleted. Any message in the outbound spool MAY be marked as sent, received or deleted.¶

Services MAY erase or redact messages in accordance with local site policy. Since messages are not removed from the spool on being marked deleted, they may be undeleted by marking them as read or unread. Marking a message deleted MAY make it more likely that the message will be removed if the sequence is subsequently purged.¶

After using the PIN code to authenticate connection of a device in the previous example, the corresponding MessagePin is marked as having been used by appending a completion message to the Local spool.¶

Missing example 32

The completion message is added to the spool in the same upload transaction that adds the device to the device catalog. This ensures that both operations occur or neither occurs.¶

8.3. Contact Exchange Interaction

The contact exchange interaction is used to support unilateral or mutual exchange of contact information. Contact exchange has three functions in the Mesh:¶

To exchange public key information to allow encryption of messages sent to and verification of signatures on messages sent from the contact subject.¶
To exchange contact information allowing use of other communication protocols (e.g. telephone, SMS, xmpp, SMTP, OpenPGP, S/MIME, etc).¶
To request that the recipient grant privileges to accept certain types of messages from the contact subject.¶

Registration of the subject's contact information in a registry service eliminates the need for the first of these functions but not the other two. To prevent abuse, every Mesh Message is subject to access control and a Mesh service will only accept a message from a sender if there is an entry in the Threshold Catalog of the account that expressly permits delivery of messages of the specified type that are authenticated by an authorized signature key.¶

The communication of unsolicited information afforded by the contact exchange interaction is deliberately limited so that a majority of users can accept contact exchange requests without prior authorization. It is however likely that some users will receive a considerable volume of requests forcing them to require contact requests be authorized through some form of third party accreditation.¶

8.3.1. Remote

The Remote Contact Exchange transaction consists of a sequence of MessageContact messages sent from the initiator to the responder, responder to the initiator, etc. While there is in principle no limit on the number of messages exchanged, most exchanges will be completed in three exchanges or less:¶

Initiator to Responder: Contains Initiator contact data without authentication context from the exchange.¶
Responder to Initiator (optional): Contains Responder contact data authenticated under a PIN challenge presented in the previous message.¶
Initiator to Responder (optional): Contains Initiator contact data authenticated under a PIN challenge presented in the previous message.¶

Each message provides the recipient with additional information which MAY motivate the recipient to provide additional contact information to the sender.¶

{
  "MessageContact":{
    "MessageId":"NDIB-OGS2-XXZG-D2M2-5YJI-QQXN-2IVO",
    "Sender":"bob@example.com",
    "Recipient":"alice@example.com",
    "AuthenticatedData":[{
        "dig":"S512",
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250YWN0UG
  Vyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmV
  hdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6MzVaIn0"},
      "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBbewogIC
  AgICAgICJVZGYiOiAiTUE2SS1NSjVaLTdCQk8tVEVCQS1IUUY2LUxOUjYtNzJTRiI
  sCiAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3JrQWRk
  cmVzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJib2JAZXhhbXBsZS5jb20iL
  AogICAgICAgICJFbnZlbG9wZWRQcm9maWxlQWNjb3VudCI6IFt7CiAgICAgICAgIC
  AgICJFbnZlbG9wZUlkIjogIk1BNkktTUo1Wi03QkJPLVRFQkEtSFFGNi1MTlI2LTc
  yU0YiLAogICAgICAgICAgICAiZGlnIjogIlM1MTIiLAogICAgICAgICAgICAiQ29u
  dGVudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpaQ0k2SUNKTlFUWkpMVTFLT
  lZvdE4wSkNUeTEKICBVUlVKQkxVaFJSall0VEU1U05pMDNNbE5HSWl3S0lDQWlUV1
  Z6YzJGblpWUjVjR1VpT2lBaVVISnZabWxzWgogIFZWelpYSWlMQW9nSUNKamRIa2l
  PaUFpWVhCd2JHbGpZWFJwYjI0dmJXMXRMMjlpYW1WamRDSXNDaUFnSWtOCiAgeVpX
  RjBaV1FpT2lBaU1qQXlNUzB3T0Mwd05WUXhOam96Tnpvek5Wb2lmUSJ9LAogICAgI
  CAgICAgImV3b2dJQ0pRY205bWFXeGxWWE5sY2lJNklIc0tJQ0FnSUNKUWNtOW1hV3
  gKICBsVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQk5ra3R
  UVW8xV2kwM1FrSlBMVlJGUQogIGtFdFNGRkdOaTFNVGxJMkxUY3lVMFlpTEFvZ0lD
  QWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzCiAgS0lDQWdJQ0FnSUNBa
  VVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjbllpT2lBaV
  IKICBXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSjJhRTU2U2p
  kUGJFOTFTMmN6WVVReGFVNAogIDVXVEJNVXpWb1EyWTBaMFJDU1RrelVWSnlWa1ZK
  VERBeFRYRk9ZV2xyY0VkTkNpQWdXbXN5ZG1KU1N6ZENhCiAgbFJ5ZW1oWGJEVlhlV
  1ZTTFhsQkluMTlmU3dLSUNBZ0lDSkJZMk52ZFc1MFFXUmtjbVZ6Y3lJNklDSmliMk
  oKICBBWlhoaGJYQnNaUzVqYjIwaUxBb2dJQ0FnSWxObGNuWnBZMlZWWkdZaU9pQWl
  UVUpDV1MxRk5GWkJMVU5OVgogIDBZdE5USlVOeTFGVTB4QkxWQkhUbFF0UTA1T1dD
  SXNDaUFnSUNBaVFXTmpiM1Z1ZEVWdVkzSjVjSFJwYjI0CiAgaU9pQjdDaUFnSUNBZ
  0lDSlZaR1lpT2lBaVRVSlRUeTFXTmtKUExUSlNTMUl0UjBSRFNTMUVWMWt6TFZOWF
  cKICBGZ3RWMEpZVHlJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWp
  vZ2V3b2dJQ0FnSUNBZ0lDSgogIFFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0Fn
  SUNBZ0lDQWdJbU55ZGlJNklDSllORFE0SWl3S0lDQWdJCiAgQ0FnSUNBZ0lDSlFkV
  0pzYVdNaU9pQWlabVZFTUVScFpqQm1TVlp0VEZCclRUUjVhakp6WmtveGNFRmhPWE
  4KICBVVjBGTk5sY3hWa0pGTmxodmVFMUVXRzVET0hoaVZ3b2dJRU5HUmxwaWMyWTJ
  XVkI0ZEZCTVZVOHhTR2s1VAogIEZkbFFTSjlmWDBzQ2lBZ0lDQWlRV1J0YVc1cGMz
  UnlZWFJ2Y2xOcFoyNWhkSFZ5WlNJNklIc0tJQ0FnSUNBCiAgZ0lsVmtaaUk2SUNKT
  lJGcFlMVVJTTmxndFZUTkhRUzFGVWtkQ0xWbzJTMDB0TlZwQlNTMVZURkZVSWl3S0
  kKICBDQWdJQ0FnSWxCMVlteHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUN
  BZ0lsQjFZbXhwWTB0bGVVVgogIERSRWdpT2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oy
  SWpvZ0lrVmtORFE0SWl3S0lDQWdJQ0FnSUNBZ0lDSlFkCiAgV0pzYVdNaU9pQWllR
  3M0U0hONVZIcHFUbEpDTmtod00wVnBjbWwzUVRBeUxYUmpTazk1TjNkdVVtRkNaR0
  oKICBPYm5vdFEyMUxlVGRFVFZOS1ZBb2dJRlJ5TTBaQmR6TmFjR2xWYm1GWFpETm5
  kbkpTWlc5WlFTSjlmWDBzQwogIGlBZ0lDQWlRV05qYjNWdWRFRjFkR2hsYm5ScFky
  RjBhVzl1SWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxCiAgRVUwd3RRa1JUUmkxU
  1JrUlRMVXBMTkVVdFdFMVRTeTFhV0VKUUxVaEJUa1FpTEFvZ0lDQWdJQ0FpVUhWaW
  IKICBHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJ
  WNVJVTkVTQ0k2SUhzS0lDQQogIGdJQ0FnSUNBZ0lDSmpjbllpT2lBaVdEUTBPQ0lz
  Q2lBZ0lDQWdJQ0FnSUNBaVVIVmliR2xqSWpvZ0lraE9iCiAgVkpPYW5NMVJrbFRPV
  lJPYUdGVlZqUllUa2RxT0VwdFoyTnFUWE5aT1dkcGJHeE9SRk4yT1RWQ2FXcGZTV3
  gKICAxVHpjS0lDQnBSSEpoUjJKTGJUWXlSamQ1UXpGblEycHdTMGRHTkVFaWZYMTl
  MQW9nSUNBZ0lrRmpZMjkxYgogIG5SVGFXZHVZWFIxY21VaU9pQjdDaUFnSUNBZ0lD
  SlZaR1lpT2lBaVRVUlRReTFWVFVaVExWcFdXVlV0VERRCiAgM1JpMVpSRkZVTFVOR
  FJETXRVRVpITnlJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2
  UKICB3b2dJQ0FnSUNBZ0lDSlFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSUN
  BZ0lDQWdJbU55ZGlJNklDSgogIEZaRFEwT0NJc0NpQWdJQ0FnSUNBZ0lDQWlVSFZp
  Ykdsaklqb2dJa3R5UW5GR1YxSTRkbmgyY1hBNGNVeFliCiAgMWsyWmpBMlYxWnNNe
  kZ2VmxKVVYzcGlWVlk1YWxWbFprOTFORTh3Y0RCUWMxOEtJQ0JRVkdacVMxUnFiRF
  EKICB0YkhGT2VuSmtSWGM0Ylc4NFkwRWlmWDE5ZlgwIiwKICAgICAgICAgIHsKICA
  gICAgICAgICAgInNpZ25hdHVyZXMiOiBbewogICAgICAgICAgICAgICAgImFsZyI6
  ICJTNTEyIiwKICAgICAgICAgICAgICAgICJraWQiOiAiTUE2SS1NSjVaLTdCQk8tV
  EVCQS1IUUY2LUxOUjYtNzJTRiIsCiAgICAgICAgICAgICAgICAic2lnbmF0dXJlIj
  ogIko1RnhqcmlUWHZ5a2VwNTY5Y0EtTE9rUkc5UkR4RUttMVJIX09tM3F3RnVZS0J
  PUFAKICBvVVRFQmphR29YdTEtS2NTemVHTm5oakMxSUFiWDVqNE9DYUpmcWJnRTAt
  b1NZVUlmYnF5YUY1T0c0UTRhVAogIG5PWHVwZlAzaFNxNzZQdWVrT3lfYUttSEZCd
  zBCMFZVOHZJVzlOVGtBIn1dLAogICAgICAgICAgICAiUGF5bG9hZERpZ2VzdCI6IC
  JONjdKOFNSbFpVbUgxQzdhQk9iSGxzVHp3SlBkZjlBZEVzY19TLXloSVJ3eFgKICB
  hS3Q5Q1drSFhicE12ZXRVdXVZMi1jdkJLRmVmLVRhYVo3czZHVXRoQSJ9XSwKICAg
  ICAgICAiUHJvdG9jb2xzIjogW3sKICAgICAgICAgICAgIlByb3RvY29sIjogIm1tb
  SJ9XX1dfX0",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MDSC-UMFS-ZVYU-L47F-YDQT-CCD3-PFG7",
            "signature":"FM74a48A3IDF2nPouls7KkMJhwCqIgmrqInktSf9
  zfSfWlIG4V4gtWFWo1Ga7FLJiZULqs_fgLeAsP95OCpARbF41EITbm6XMBxUBVhhd
  LIymr4qDMl6SSJNlTaXtf6YUvtxs31SKD2Rza5F_6wr7A4A"}
          ],
        "PayloadDigest":"z05L3W6dkgu8p8U-5g58pWp7jBNRAmbv-7Dt5w98
  e12lzHM3Uo-EDBtiC7Lq24C-BjeZG_Jx5VIHa9Xf0N5EzA"}
      ],
    "Reply":true,
    "Subject":"alice@example.com",
    "PIN":"AAKO-AYTU-YH3M-DWOO-SLKU-N7ZD-SKUA"}}

The Mesh Contact Exchange transaction does not provide for validation of the contact information beyond the binding to the Mesh Account Address used to perform the exchange.¶

8.3.2. PIN

Contact exchange requests MAY be authenticated by a PIN code. Initial contact exchange requests SHOULD include a PIN code value that can be used to authenticate a response (if given). PIN codes MAY also be exchanged out of band.¶

A MessageContact authenticated by means of a PIN code is authenticated as described in the PIN Interaction section above.¶

8.3.3. EARL

A MessageContact message MAY be published as an EARL. This allows contact data to be presented to the recipient on a printed document such as a business card in machine readable format such as a QR code.¶

8.4. Group Invitation

The GroupInvitation interaction is used to invite a recipient to join a Mesh Group. The interaction is essentially a form of contact exchange except that a sender SHOULD NOT send group invitations unless there is an existing relationship. Thus the 'first trust' issues intrinsic to the contact exchange interaction do not apply.¶

The message specifies the group name and the contact entry for the group. The contact entry includes the CapabilityDecryptServiced used to decrypt messages sent to the group when combined with information provided by the threshold service for the group.¶

Receipt of a GroupInvitation message does not require a response.¶

{
  "GroupInvitation":{
    "MessageId":"NAEL-ZDYX-4ZUQ-KPRC-YC77-USAV-WHFM",
    "Sender":"alice@example.com",
    "Recipient":"bob@example.com",
    "Contact":{
      "ContactPerson":{
        "Anchors":[{
            "Udf":"MCTZ-HSH7-NUNV-MQ3Z-XNJ6-XGB3-VBPX",
            "Validation":"Self"}
          ],
        "NetworkAddresses":[{
            "Address":"groupw@example.com",
            "EnvelopedProfileAccount":[{
                "EnvelopeId":"MCTZ-HSH7-NUNV-MQ3Z-XNJ6-XGB3-VBPX",
                "dig":"S512",
                "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQ1RaLU
  hTSDctTlVOVi1NUTNaLVhOSjYtWEdCMy1WQlBYIiwKICAiTWVzc2FnZVR5cGUiOiA
  iUHJvZmlsZUdyb3VwIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3Qi
  LAogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6MzlaIn0"},
              "ewogICJQcm9maWxlR3JvdXAiOiB7CiAgICAiUHJvZmlsZVNpZ2
  5hdHVyZSI6IHsKICAgICAgIlVkZiI6ICJNQ1RaLUhTSDctTlVOVi1NUTNaLVhOSjY
  tWEdCMy1WQlBYIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAg
  IlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgI
  CAgICAgICJQdWJsaWMiOiAiZ0VQZEg3T0duUjJIdUtrUjJMTWY3YmlfcUxibm01a3
  FaTzFRNEcxS01DQ19VMXh3ZUZyVAogIFd5QmFsc3Vtd20zVjFpQ2c0RFpFalBpQSJ
  9fX0sCiAgICAiQWNjb3VudEFkZHJlc3MiOiAiZ3JvdXB3QGV4YW1wbGUuY29tIiwK
  ICAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ0hVLVE0V
  FAtR0UyWS02RE5VLVVZRUYtUDNCRi1MWlRCIiwKICAgICAgIlB1YmxpY1BhcmFtZX
  RlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J
  2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJyczJRbjJfTTY0WVRFaUR6
  MkxGenUwN1RiZ0t4VUtvTzRWMjR4NEpUY09MQ3JTMGFRSHNZCiAgVUtyRWlqUmNkd
  nVNYS1oSzhxOEtwVDhBIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1BRFotNzdESC1LV0JNLTVWWUQtSkYyQy1UQ1FWLVF
  XUjQiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJLb2p3Zm1MTnhXUHY2aUJWQ20yc0ltZmxmVDF3ZDJBaWFkWU5iRU
  hFRWlWQkc2dEQ2bzQ5CiAgYTUzNWRxZnBjNTI4OHF1OTh6YktNNVdBIn19fX19",
              {
                "signatures":[{
                    "alg":"S512",
                    "kid":"MCTZ-HSH7-NUNV-MQ3Z-XNJ6-XGB3-VBPX",
                    "signature":"aYkUH6X9_o8SlGtHGHlbUF5Eo-9fbtt0
  EiDHE6UOcSM74-_kaJEsNjBqDoobQFY2wa9_ZKLAxLIAsaboaM4J0eLO2LwY0sLEn
  56Hqnomtr9RrSdd3T94RsL9d5VbltUmbm9lri6DbEdTcbApWTIiijsA"}
                  ],
                "PayloadDigest":"7QnIkdUEegnV-m6hHDZ-uxunsQi6WVv9
  lSgKiAFBtZe4pW1XSIwjx--hdhszoqjDEV3d8R0cIdfrAIl705eGcw"}
              ],
            "Protocols":[{
                "Protocol":"mmm"}
              ],
            "Capabilities":[{
                "CapabilityDecryptPartial":{
                  "Id":"MCHU-Q4TP-GE2Y-6DNU-UYEF-P3BF-LZTB",
                  "KeyData":{
                    "Udf":"NBDJ-WYQO-UIEH-OVLK-B3UM-J5TN-AQ3P",
                    "PrivateParameters":{
                      "PrivateKeyECDH":{
                        "crv":"X448z",
                        "Private":"LvKfwJ0uKLkQiW9XdxDmNZOFc-cnAK
  aKnTDHzDrwa1-mIk3mc0gotskRzBZrfjhgphB9KZhs_Bk"}}},
                  "SubjectId":"MCHU-Q4TP-GE2Y-6DNU-UYEF-P3BF-LZTB",
                  "ServiceId":"NBDJ-WYQO-UIEH-OVLK-B3UM-J5TN-AQ3P",
                  "ServiceAddress":"groupw@example.com"}}
              ]}
          ]}}}}

8.5. Confirmation Interaction

The confirmation interaction consists of a RequestConfirmation message from the initiator followed by a ResponseConfirmation from the responder.¶

The RequestConfirmation message specifies the action that is requested.¶

The ResponseConfirmation message contains the enveloped RequestConfirmation message signed by the initiator and the disposition of the responder, Accept = true if the request is accepted and Accept = false otherwise.¶

The service sends out the following request:¶

{
  "RequestConfirmation":{
    "MessageId":"NBLG-QNFG-5NRO-K2PT-JIBB-4AVX-X2L6",
    "Sender":"console@example.com",
    "Recipient":"alice@example.com",
    "Text":"start"}}

Alice accepts the request and returns the following response:¶

{
  "ResponseConfirmation":{
    "MessageId":"MDKO-2LBI-LVRI-6F7K-FSQC-NYLV-E76L",
    "Sender":"alice@example.com",
    "Recipient":"console@example.com",
    "Request":[{
        "EnvelopeId":"MAHP-YGCF-WQAV-CSRH-Y6GA-AAP3-VKLY",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkxHLVFORkctNU
  5STy1LMlBULUpJQkItNEFWWC1YMkw2IiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbmZpcm1hdGlvbiIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0
  IiwKICAiQ3JlYXRlZCI6ICIyMDIxLTA4LTA1VDE2OjM3OjM4WiJ9",
        "SequenceInfo":{
          "Index":4,
          "TreePosition":6201},
        "Received":"2021-08-05T16:37:38Z"},
      "ewogICJSZXF1ZXN0Q29uZmlybWF0aW9uIjogewogICAgIk1lc3NhZ2VJZC
  I6ICJOQkxHLVFORkctNU5STy1LMlBULUpJQkItNEFWWC1YMkw2IiwKICAgICJTZW5
  kZXIiOiAiY29uc29sZUBleGFtcGxlLmNvbSIsCiAgICAiUmVjaXBpZW50IjogImFs
  aWNlQGV4YW1wbGUuY29tIiwKICAgICJUZXh0IjogInN0YXJ0In19",
      {}
      ],
    "Accept":true}}

9. Device Connection Interactions

Connection of a device to a Mesh Account combines synchronous and asynchronous elements and therefore uses a combination of Mesh Service Protocol and Mesh Messaging interactions.¶

Three connection interactions are currently defined support connection of devices with difference affordances:¶

Witness Authenticated: For connecting devices that provide data entry and display affordances and are connected to a network. The account the device is to be connected to is entered into the device which displays a witness code. This code is then compared with a code displayed on the administration device to authenticate the request, after which both devices can complete the interaction.¶
Dynamic QR Code (PIN) Authenticated: For connecting devices that provide a camera affordance. The user sets the administration device into 'add device' mode, causing a QR code to be displayed. The QR code is scanned by the device being connected after which both devices can complete the interaction.¶
Static QR Code Authenticated: For connecting devices that have been preconfigured with a device profile identified by means of a QR Code containing an EARL. The QR code is scanned by the administration device after which both devices can complete the interaction.¶

Each of these interactions provide strong mutual authentication with minimal user effort.¶

The witness authenticated connection interaction is intended for use in cases in which the device is already connected to a network. The QR code interactions are intended to provide support for acquisition of networking capabilities as part of the connection process. These functions are not currently specified. The Static QR Code Authenticated interaction is intended to support Internet of Things (IoT) devices which provide minimal interaction affordances.¶

In each case, the objectives of the device connection interaction are the same:¶

Mutually authenticate the onboarding device and the Mesh such that the connection interaction only completes if both sides acquire the authentic profile of the other.¶
To provision the onboarding device with the Mesh ProfileAccount, and an ActivationDevice and ConnectionDevice record allowing the device to interact as a member of the Mesh with the set of rights specified by the user.¶
To create a CataloguedDevice record and append it to the Device catalog of the account to allow the device to be managed within that account.¶
(optional) to acquire networking capabilities to allow the above to be completed.¶

The connection of the device to the Mesh Account is achieved through the creation of the ActivationDevice, ConnectionDevice and CataloguedDevice records described earlier. These are created by the administration device in the third phase of each of the connection interactions described below and acquired by the onboarding device in the fourth phase.¶

9.1. Dynamic QR Code (PIN) Authenticated

The Dynamic QR Code (PIN) Authenticated interaction comprises four phases as follows:¶

Phase 1: Issue of PIN credential

A PIN code is created and registered with the PIN Registration interaction described earlier and transmitted to the user by an out of band communication (e.g. a QR code that is scanned by the device).¶

Phase 2: Onboarding Device Request to Service

The onboarding device performs a Connect transaction on a host servicing the account. This results in the exchange of the account and device profiles and the computation of a witness value from the two profile fingerprints and two nonce values specified by the onboarding device and the service.¶

An AcknowledgeConnection message is posted to the Inbound spool of the account.¶

Phase 3: Administration Device Acceptance

The account holder accepts or rejects the connection request from a device that has been granted administration capability.¶

Phase 4: Onboarding Device Completion

The onboarding device periodically polls the service for acceptance of the request by the administration device using the Complete transaction.¶

The use of the PIN code to authenticate the request message is shown in $$$$.¶

The PIN code MAY be presented to the onboarding device in any format accepted by the device. Administration MAY support presentation of the account address PIN code as a URI code. Administration devices SHOULD support presentation of the account address PIN code as a QR code containing the corresponding URI.¶

9.1.1. Phase 1:

Alice> account pin
PIN=AAJP-KPYV-NSB4-GIYL-AM
 (Expires=2021-08-06T16:37:40Z)

The registration of this PIN value was shown earlier in section $$$¶

The URI containing the account address and PIN is:¶

mcu://alice@example.com/AAJP-KPYV-NSB4-GIYL-AM

9.1.2. Phase 2:

The onboarding device scans the QR code to obtain the account address and PIN code. The PIN code is used to authenticate a connection request:¶

Alice3> device request alice@example.com /pin AAJP-KPYV-NSB4-GIYL-AM
   Device UDF = MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F
   Witness value = KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN

The device issues a connection request to the service corresponding to the account. This specifies the device profile, the account to which the device is to be connected and the client nonce value:¶

{
  "ConnectRequest":{
    "EnvelopedRequestConnection":[{
        "EnvelopeId":"MD22-62AQ-PVVT-NPUS-ATUC-MQH4-PWV2",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkY0LTRQVEgtVV
  RTQy1SWUhaLUVRTUstQlZINy1NVTNGIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzo0MFoifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi
  AiTkJGNC00UFRILVVUU0MtUllIWi1FUU1LLUJWSDctTVUzRiIsCiAgICAiQXV0aGV
  udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1BT0stSTRU
  VC0zRVVTLTRMTVktWjZKTy1WRU43LUNYNkYiLAogICAgICAgICJkaWciOiAiUzUxM
  iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk
  NJNklDSk5RVTlMTFVrMFZGUXRNMFZWVXkwCiAgMFRFMVpMVm8yU2s4dFZrVk9OeTF
  EV0RaR0lpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk
  bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV
  04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeExUQTRMVEExVkRFMk9qTT
  NPalF3V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V
  3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK
  VlpHWWlPaUFpVFVGUFN5MUpORlJVTFRORlZWTXROCiAgRXhOV1MxYU5rcFBMVlpGV
  GpjdFExZzJSaUlzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC
  BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F
  nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli
  R2xqSWpvZ0luUkVSVGxuVXkwMlJGazViVkJGV1dGCiAgU2NWSm1Uamg2Ylc4ek9FO
  DNOMlpJUjJFdGFGSllkMFoxTkZobmJqVnJNa2RRY1VFS0lDQnFOMVpYUmtWbWMKIC
  AyRnBYMkp0TWxKTmMydzNVRTh4VTBFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI
  yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVVEyVmkwMU5FWlRMVFpSUlVZ
  dE1rTktSeTFGVlZoQkxVNURWazR0V0RWSU55SXNDCiAgaUFnSUNBZ0lDSlFkV0pzY
  VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC
  BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F
  nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpTW01TmNsOUdVVkV4WVcxVmJVMTNW
  ekZhZFZRMFRtcGhXWEp3UkRjeVRHNUxUVXN0YVhKCiAgVGMzWkNWbGR4Y3pWclQzS
  lVTd29nSUdSUWNqaDVZa1EzTVVveE5teFhOa0prTFdKbk4zaHRRU0o5Zlgwc0MKIC
  BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQlR
  Va3RTVGRQVXkxTlExVgogIE5MVmMzU0VzdE5sRlRSUzFSV0U1TUxVVktSMU1pTEFv
  Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS
  UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC
  BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSm1lVE4
  2YldoSmRGRktaRlJhVgogIG5KdWNqVkZObEF6VDJkNlJtVlZhMmhGWVRkT1FXTlRV
  SEJIVWt4dmMzVTNYek5DVUVwNkNpQWdiMUpxT0VWCiAgRFQxOWtTa3B2T1VKbE1VO
  WpUemRKVVc5QkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC
  BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFrWk9MVUl5UTFndFMxSkpVUzB6VFVoTUx
  UZFRUMUl0V0RWWFNpMQogIERTRkZISWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G
  dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT
  2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC
  BnSUNBZ0lsQjFZbXhwWXlJNklDSTJabWRSUlhaRU9GTkdXalp6YjBWekxYSk5hMVp
  YYkRGQ1kyMDJOMnMzVAogIFZZemNXeGxSelF5U1haYU4wTk9NMUZMYkRSdkNpQWda
  RmhIYVZCbk9GVTBORFozYkdwUVFWSkVRbkJrTkZGCiAgQkluMTlmWDE5IiwKICAgI
  CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC
  JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQU9LLUk0VFQtM0VVUy00TE1ZLVo
  2Sk8tVkVONy1DWDZGIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICIxNEFIUXVV
  RU53VlhYdWxJN0h4YTFjY2VXYVNTX3FCaGZ5LXR5ZE5GbjdySmtzVmZICiAgTURpe
  Th2cnJ2ZFYwMEJHdWt0UHFncDg2QzJBV1NhYzlGbkdYd2hOWjNQVjJlZHpzQ3dDX2
  UyMWRVb0dRN1gKICBQUEw4ODZ1dzV3a0RqejdOdDhXeEwxRG44dXdwQXBoX3hySU1
  NTlNzQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJaWGNkRlg3aTRQWWY0
  b0o2TzdfZEx3N1RXRWtyMHZDX3IzX1JjYURkY3ktV3oKICA0RFBicWhDazFWR3lVM
  FlMc1I2QzZORWNIYTlFeGpCYTVPSW9aYWtnQSJ9XSwKICAgICJDbGllbnROb25jZS
  I6ICJWR3h4TC1MS1VReXFuX1JwZGo4NlpnIiwKICAgICJQaW5JZCI6ICJBQ0NMLVd
  KSjYtUUlMWS1JRFFULTY3UlQtTEhHTS1QQTJLIiwKICAgICJQaW5XaXRuZXNzIjog
  Illod0FpLUl2WVlQMmRNak9kLXBYaW9ScWdJcTBrbndMd25VcU1IdnB2VHVlTE1jN
  wogIEFUU1hNZEJseE9TWl91OHN6dHFwd3dFWkVaNVJjNFdRQktQM2NBIiwKICAgIC
  JBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ"
      ]}}

The service generates the service nonce value and uses it to create the AcknowledgeConnection message.¶

{
  "AcknowledgeConnection":{
    "MessageId":"KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN",
    "EnvelopedRequestConnection":[{
        "EnvelopeId":"MD22-62AQ-PVVT-NPUS-ATUC-MQH4-PWV2",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJOQkY0LTRQVEgtVV
  RTQy1SWUhaLUVRTUstQlZINy1NVTNGIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWV
  zdENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIs
  CiAgIkNyZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzo0MFoifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOi
  AiTkJGNC00UFRILVVUU0MtUllIWi1FUU1LLUJWSDctTVUzRiIsCiAgICAiQXV0aGV
  udGljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlkIjogIk1BT0stSTRU
  VC0zRVVTLTRMTVktWjZKTy1WRU43LUNYNkYiLAogICAgICAgICJkaWciOiAiUzUxM
  iIsCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKWk
  NJNklDSk5RVTlMTFVrMFZGUXRNMFZWVXkwCiAgMFRFMVpMVm8yU2s4dFZrVk9OeTF
  EV0RaR0lpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxk
  bWxqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV
  04wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJeExUQTRMVEExVkRFMk9qTT
  NPalF3V2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V
  3b2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNK
  VlpHWWlPaUFpVFVGUFN5MUpORlJVTFRORlZWTXROCiAgRXhOV1MxYU5rcFBMVlpGV
  GpjdFExZzJSaUlzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KIC
  BnZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0F
  nSUNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmli
  R2xqSWpvZ0luUkVSVGxuVXkwMlJGazViVkJGV1dGCiAgU2NWSm1Uamg2Ylc4ek9FO
  DNOMlpJUjJFdGFGSllkMFoxTkZobmJqVnJNa2RRY1VFS0lDQnFOMVpYUmtWbWMKIC
  AyRnBYMkp0TWxKTmMydzNVRTh4VTBFaWZYMTlMQW9nSUNBZ0lrVnVZM0o1Y0hScGI
  yNGlPaUI3Q2lBZ0lDQQogIGdJQ0pWWkdZaU9pQWlUVVEyVmkwMU5FWlRMVFpSUlVZ
  dE1rTktSeTFGVlZoQkxVNURWazR0V0RWSU55SXNDCiAgaUFnSUNBZ0lDSlFkV0pzY
  VdOUVlYSmhiV1YwWlhKeklqb2dld29nSUNBZ0lDQWdJQ0pRZFdKc2FXTkxaWGwKIC
  BGUTBSSUlqb2dld29nSUNBZ0lDQWdJQ0FnSW1OeWRpSTZJQ0pZTkRRNElpd0tJQ0F
  nSUNBZ0lDQWdJQ0pRZAogIFdKc2FXTWlPaUFpTW01TmNsOUdVVkV4WVcxVmJVMTNW
  ekZhZFZRMFRtcGhXWEp3UkRjeVRHNUxUVXN0YVhKCiAgVGMzWkNWbGR4Y3pWclQzS
  lVTd29nSUdSUWNqaDVZa1EzTVVveE5teFhOa0prTFdKbk4zaHRRU0o5Zlgwc0MKIC
  BpQWdJQ0FpVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxQlR
  Va3RTVGRQVXkxTlExVgogIE5MVmMzU0VzdE5sRlRSUzFSV0U1TUxVVktSMU1pTEFv
  Z0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljCiAgeUk2SUhzS0lDQWdJQ0FnS
  UNBaVVIVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjblkKIC
  BpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSm1lVE4
  2YldoSmRGRktaRlJhVgogIG5KdWNqVkZObEF6VDJkNlJtVlZhMmhGWVRkT1FXTlRV
  SEJIVWt4dmMzVTNYek5DVUVwNkNpQWdiMUpxT0VWCiAgRFQxOWtTa3B2T1VKbE1VO
  WpUemRKVVc5QkluMTlmU3dLSUNBZ0lDSkJkWFJvWlc1MGFXTmhkR2x2YmlJNkkKIC
  BIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFrWk9MVUl5UTFndFMxSkpVUzB6VFVoTUx
  UZFRUMUl0V0RWWFNpMQogIERTRkZISWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21G
  dFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZCiAgbXhwWTB0bGVVVkRSRWdpT
  2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0lDQWdJQ0EKIC
  BnSUNBZ0lsQjFZbXhwWXlJNklDSTJabWRSUlhaRU9GTkdXalp6YjBWekxYSk5hMVp
  YYkRGQ1kyMDJOMnMzVAogIFZZemNXeGxSelF5U1haYU4wTk9NMUZMYkRSdkNpQWda
  RmhIYVZCbk9GVTBORFozYkdwUVFWSkVRbkJrTkZGCiAgQkluMTlmWDE5IiwKICAgI
  CAgewogICAgICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgImFsZyI6IC
  JTNTEyIiwKICAgICAgICAgICAgImtpZCI6ICJNQU9LLUk0VFQtM0VVUy00TE1ZLVo
  2Sk8tVkVONy1DWDZGIiwKICAgICAgICAgICAgInNpZ25hdHVyZSI6ICIxNEFIUXVV
  RU53VlhYdWxJN0h4YTFjY2VXYVNTX3FCaGZ5LXR5ZE5GbjdySmtzVmZICiAgTURpe
  Th2cnJ2ZFYwMEJHdWt0UHFncDg2QzJBV1NhYzlGbkdYd2hOWjNQVjJlZHpzQ3dDX2
  UyMWRVb0dRN1gKICBQUEw4ODZ1dzV3a0RqejdOdDhXeEwxRG44dXdwQXBoX3hySU1
  NTlNzQSJ9XSwKICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJaWGNkRlg3aTRQWWY0
  b0o2TzdfZEx3N1RXRWtyMHZDX3IzX1JjYURkY3ktV3oKICA0RFBicWhDazFWR3lVM
  FlMc1I2QzZORWNIYTlFeGpCYTVPSW9aYWtnQSJ9XSwKICAgICJDbGllbnROb25jZS
  I6ICJWR3h4TC1MS1VReXFuX1JwZGo4NlpnIiwKICAgICJQaW5JZCI6ICJBQ0NMLVd
  KSjYtUUlMWS1JRFFULTY3UlQtTEhHTS1QQTJLIiwKICAgICJQaW5XaXRuZXNzIjog
  Illod0FpLUl2WVlQMmRNak9kLXBYaW9ScWdJcTBrbndMd25VcU1IdnB2VHVlTE1jN
  wogIEFUU1hNZEJseE9TWl91OHN6dHFwd3dFWkVaNVJjNFdRQktQM2NBIiwKICAgIC
  JBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSJ9fQ"
      ],
    "ServerNonce":"1PwfBA9kRcN6fLra8ATh1Q",
    "Witness":"KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN"}}

The AcknowledgeConnection message is appended to the Inbound spool of the account to which connection was requested so that the user can approve the request. The ConnectResponse message is returned to the device containing the AcknowledgeConnection message and the profile of the account.¶

{
  "ConnectResponse":{
    "Status":201,
    "StatusDescription":"Operation completed successfully",
    "EnvelopedAcknowledgeConnection":[{
        "EnvelopeId":"KDKD-2X34-SAB7-R7JD-7P3D-44YE-UXHT",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJLQjNHLU5DMzUtWD
  ZJVS1CRUtKLVlJUVItSjRHWC1JS0tOIiwKICAiTWVzc2FnZVR5cGUiOiAiQWNrbm9
  3bGVkZ2VDb25uZWN0aW9uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmpl
  Y3QiLAogICJDcmVhdGVkIjogIjIwMjEtMDgtMDVUMTY6Mzc6NDBaIn0",
        "SequenceInfo":{
          "Index":6,
          "TreePosition":11822},
        "Received":"2021-08-05T16:37:40Z"},
      "ewogICJBY2tub3dsZWRnZUNvbm5lY3Rpb24iOiB7CiAgICAiTWVzc2FnZU
  lkIjogIktCM0ctTkMzNS1YNklVLUJFS0otWUlRUi1KNEdYLUlLS04iLAogICAgIkV
  udmVsb3BlZFJlcXVlc3RDb25uZWN0aW9uIjogW3sKICAgICAgICAiRW52ZWxvcGVJ
  ZCI6ICJNRDIyLTYyQVEtUFZWVC1OUFVTLUFUVUMtTVFINC1QV1YyIiwKICAgICAgI
  CAiQ29udGVudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpaQ0k2SUNKT1FrWT
  BMVFJRVkVndFZWUlRReTEKICBTV1VoYUxVVlJUVXN0UWxaSU55MU5WVE5HSWl3S0l
  DQWlUV1Z6YzJGblpWUjVjR1VpT2lBaVVtVnhkV1Z6ZAogIEVOdmJtNWxZM1JwYjI0
  aUxBb2dJQ0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJC
  iAgc0NpQWdJa055WldGMFpXUWlPaUFpTWpBeU1TMHdPQzB3TlZReE5qb3pOem8wTU
  ZvaWZRIn0sCiAgICAgICJld29nSUNKU1pYRjFaWE4wUTI5dWJtVmpkR2x2YmlJNkl
  Ic0tJQ0FnSUNKCiAgTlpYTnpZV2RsU1dRaU9pQWlUa0pHTkMwMFVGUklMVlZVVTBN
  dFVsbElXaTFGVVUxTExVSldTRGN0VFZVelIKICBpSXNDaUFnSUNBaVFYVjBhR1Z1Z
  EdsallYUmxaRVJoZEdFaU9pQmJld29nSUNBZ0lDQWdJQ0pGYm5abGJHOQogIHdaVW
  xrSWpvZ0lrMUJUMHN0U1RSVVZDMHpSVlZUTFRSTVRWa3RXalpLVHkxV1JVNDNMVU5
  ZTmtZaUxBb2dJCiAgQ0FnSUNBZ0lDSmthV2NpT2lBaVV6VXhNaUlzQ2lBZ0lDQWdJ
  Q0FnSWtOdmJuUmxiblJOWlhSaFJHRjBZU0kKICA2SUNKbGQyOW5TVU5LVm1KdGJIa
  GtWMVpLV2tOSk5rbERTazVSVlRsTVRGVnJNRlpHVVhSTk1GWldWWGt3QwogIGlBZ0
  1GUkZNVnBNVm04eVUyczRkRlpyVms5T2VURkVWMFJhUjBscGQwdEpRMEZwVkZkV2V
  tTXlSbTVhVmxJCiAgMVkwZFZhVTlwUVdsVlNFcDJXbTFzYzFvS0lDQlZVbXhrYld4
  cVdsTkpjME5wUVdkSmJVNHdaVk5KTmtsRFMKICBtaGpTRUp6WVZkT2FHUkhiSFppY
  VRsMFlsY3dkbUl5U25GYVYwNHdTV2wzUzBsRFFRb2dJR2xSTTBwc1dWaAogIFNiRn
  BEU1RaSlEwbDVUVVJKZUV4VVFUUk1WRUV4VmtSRk1rOXFUVE5QYWxGM1YybEtPU0o
  5TEFvZ0lDQWdJCiAgQ0FpWlhkdlowbERTbEZqYlRsdFlWZDRiRkpIVmpKaFYwNXNT
  V3B2WjJWM2IyZEpRMEZuU1d4Q2VXSXlXZ28KICBnSUhCaVIxWlVZVmRrZFZsWVVqR
  mpiVlZwVDJsQ04wTnBRV2RKUTBGblNVTktWbHBIV1dsUGFVRnBWRlZHVQogIEZONU
  1VcE9SbEpWVEZST1JsWldUWFJPQ2lBZ1JYaE9WMU14WVU1cmNGQk1WbHBHVkdwamR
  GRXhaekpTYVVsCiAgelEybEJaMGxEUVdkSlEwcFJaRmRLYzJGWFRsRlpXRXBvWWxk
  V01GcFlTbnBKYW04S0lDQm5aWGR2WjBsRFEKICBXZEpRMEZuU1VOS1VXUlhTbk5oV
  jA1TVdsaHNSbEV3VWtsSmFtOW5aWGR2WjBsRFFXZEpRMEZuU1VOQlowbAogIHRUbm
  xrYVVrMlNRb2dJRU5LUmxwRVVUQlBRMGx6UTJsQlowbERRV2RKUTBGblNVTkJhVlZ
  JVm1saVIyeHFTCiAgV3B2WjBsdVVrVlNWR3h1Vlhrd01sSkdhelZpVmtKR1YxZEdD
  aUFnVTJOV1NtMVVhbWcyWWxjNGVrOUZPRE4KICBPTWxwSlVqSkZkR0ZHU2xsa01Gb
  3hUa1pvYm1KcVZuSk5hMlJSWTFWRlMwbERRbkZPTVZwWVVtdFdiV01LSQogIENBeV
  JuQllNa3AwVFd4S1RtTXlkek5WUlRoNFZUQkZhV1pZTVRsTVFXOW5TVU5CWjBsclZ
  uVlpNMG8xWTBoCiAgU2NHSXlOR2xQYVVJM1EybEJaMGxEUVFvZ0lHZEpRMHBXV2tk
  WmFVOXBRV2xVVlZFeVZta3dNVTVGV2xSTVYKICBGcFNVbFZaZEUxclRrdFNlVEZHV
  mxab1FreFZOVVJXYXpSMFYwUldTVTU1U1hORENpQWdhVUZuU1VOQlowbAogIERTbE
  ZrVjBwellWZE9VVmxZU21oaVYxWXdXbGhLZWtscWIyZGxkMjluU1VOQlowbERRV2R
  KUTBwUlpGZEtjCiAgMkZYVGt4YVdHd0tJQ0JHVVRCU1NVbHFiMmRsZDI5blNVTkJa
  MGxEUVdkSlEwRm5TVzFPZVdScFNUWkpRMHAKICBaVGtSUk5FbHBkMHRKUTBGblNVT
  kJaMGxEUVdkSlEwcFJaQW9nSUZkS2MyRlhUV2xQYVVGcFRXMDFUbU5zTwogIFVkVl
  ZrVjRXVmN4Vm1KVk1UTldla1poWkZaUk1GUnRjR2hYV0VwM1VrUmplVlJITlV4VVZ
  YTjBZVmhLQ2lBCiAgZ1ZHTXpXa05XYkdSNFkzcFdjbFF6U2xWVGQyOW5TVWRTVVdO
  cWFEVlphMUV6VFZWdmVFNXRlRmhPYTBwclQKICBGZEtiazR6YUhSUlUwbzVabGd3Y
  zBNS0lDQnBRV2RKUTBGcFZUSnNibUp0UmpCa1dFcHNTV3B2WjJWM2IyZAogIEpRME
  ZuU1VOQmFWWlhVbTFKYW05blNXc3hRbFJWYTNSVFZHUlFWWGt4VGxFeFZnb2dJRTV
  NVm1NelUwVnpkCiAgRTVzUmxSU1V6RlNWMFUxVFV4VlZrdFNNVTFwVEVGdlowbERR
  V2RKUTBGcFZVaFdhV0pIYkdwVlIwWjVXVmMKICB4YkdSSFZubGpDaUFnZVVrMlNVa
  HpTMGxEUVdkSlEwRm5TVU5CYVZWSVZtbGlSMnhxVXpKV05WSlZUa1ZUUQogIDBrMl
  NVaHpTMGxEUVdkSlEwRm5TVU5CWjBsRFNtcGpibGtLSUNCcFQybEJhVkpYVVRCT1J
  HZHBURUZ2WjBsCiAgRFFXZEpRMEZuU1VOQlowbHNRakZaYlhod1dYbEpOa2xEU20x
  bFZFNDJZbGRvU21SR1JrdGFSbEpoVmdvZ0kKICBHNUtkV05xVmtaT2JFRjZWREprT
  mxKdFZsWmhNbWhHV1ZSa1QxRlhUbFJWU0VKSVZXdDRkbU16VlROWWVrNQogIERWVV
  Z3TmtOcFFXZGlNVXB4VDBWV0NpQWdSRlF4T1d0VGEzQjJUMVZLYkUxVk9XcFVlbVJ
  LVlZjNVFrbHVNCiAgVGxtVTNkTFNVTkJaMGxEU2tKa1dGSnZXbGMxTUdGWFRtaGtS
  MngyWW1sSk5ra0tJQ0JJYzB0SlEwRm5TVU4KICBCWjBsc1ZtdGFhVWsyU1VOS1RsR
  nJXazlNVlVsNVVURm5kRk14U2twVlV6QjZWRlZvVFV4VVpGUlVNVWwwVgogIDBSV1
  dGTnBNUW9nSUVSVFJrWklTV2wzUzBsRFFXZEpRMEZuU1d4Q01WbHRlSEJaTVVKb1k
  yMUdkRnBZVW14CiAgamJrMXBUMmxDTjBOcFFXZEpRMEZuU1VOQlowbHNRakZaQ2lB
  Z2JYaHdXVEIwYkdWVlZrUlNSV2RwVDJsQ04KICAwTnBRV2RKUTBGblNVTkJaMGxEU
  VdsWk0wb3lTV3B2WjBsc1p6Qk9SR2RwVEVGdlowbERRV2RKUTBFS0lDQgogIG5TVU
  5CWjBsc1FqRlpiWGh3V1hsSk5rbERTVEphYldSU1VsaGFSVTlHVGtkWGFscDZZakJ
  XZWt4WVNrNWhNCiAgVnBZWWtSR1Exa3lNREpPTW5NelZBb2dJRlpaZW1OWGVHeFNl
  bEY1VTFoYVlVNHdUazlOTVVaTVlrUlNka04KICBwUVdkYVJtaElZVlpDYms5R1ZUQ
  k9SRm96WWtkd1VWRldTa1ZSYmtKclRrWkdDaUFnUWtsdU1UbG1XREU1SQogIGl3S0
  lDQWdJQ0FnZXdvZ0lDQWdJQ0FnSUNKemFXZHVZWFIxY21Weklqb2dXM3NLSUNBZ0l
  DQWdJQ0FnSUNBCiAgZ0ltRnNaeUk2SUNKVE5URXlJaXdLSUNBZ0lDQWdJQ0FnSUNB
  Z0ltdHBaQ0k2SUNKTlFVOUxMVWswVkZRdE0KICAwVlZVeTAwVEUxWkxWbzJTazh0V
  mtWT055MURXRFpHSWl3S0lDQWdJQ0FnSUNBZ0lDQWdJbk5wWjI1aGRIVgogIHlaU0
  k2SUNJeE5FRklVWFZWUlU1M1ZsaFlkV3hKTjBoNFlURmpZMlZYWVZOVFgzRkNhR1o
  1TFhSNVpFNUdiCiAgamR5U210elZtWklDaUFnVFVScGVUaDJjbkoyWkZZd01FSkhk
  V3QwVUhGbmNEZzJRekpCVjFOaFl6bEdia2QKICBZZDJoT1dqTlFWakpsWkhwelEzZ
  ERYMlV5TVdSVmIwZFJOMWdLSUNCUVVFdzRPRFoxZHpWM2EwUnFlamRPZAogIERoWG
  VFd3hSRzQ0ZFhkd1FYQm9YM2h5U1UxTlRsTnpRU0o5WFN3S0lDQWdJQ0FnSUNBaVV
  HRjViRzloWkVSCiAgcFoyVnpkQ0k2SUNKYVdHTmtSbGczYVRSUVdXWTBiMG8yVHpk
  ZlpFeDNOMVJYUld0eU1IWkRYM0l6WDFKalkKICBVUmtZM2t0VjNvS0lDQTBSRkJpY
  1doRGF6RldSM2xWTUZsTWMxSTJRelpPUldOSVlUbEZlR3BDWVRWUFNXOQogIGFZV3
  RuUVNKOVhTd0tJQ0FnSUNKRGJHbGxiblJPYjI1alpTSTZJQ0pXUjNoNFRDMU1TMVZ
  SZVhGdVgxSndaCiAgR280Tmxwbklpd0tJQ0FnSUNKUWFXNUpaQ0k2SUNKQlEwTk1M
  VmRLU2pZdFVVbE1XUzFKUkZGVUxUWTNVbFEKICB0VEVoSFRTMVFRVEpMSWl3S0lDQ
  WdJQ0pRYVc1WGFYUnVaWE56SWpvZ0lsbG9kMEZwTFVsMldWbFFNbVJOYQogIGs5a0
  xYQllhVzlTY1dkSmNUQnJibmRNZDI1VmNVMUlkbkIyVkhWbFRFMWpOd29nSUVGVVU
  xaE5aRUpzZUU5CiAgVFdsOTFPSE42ZEhGd2QzZEZXa1ZhTlZKak5GZFJRa3RRTTJO
  Qklpd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2MKICBtVnpjeUk2SUNKaGJHbGpaVUJsZ
  UdGdGNHeGxMbU52YlNKOWZRIl0sCiAgICAiU2VydmVyTm9uY2UiOiAiMVB3ZkJBOW
  tSY042ZkxyYThBVGgxUSIsCiAgICAiV2l0bmVzcyI6ICJLQjNHLU5DMzUtWDZJVS1
  CRUtKLVlJUVItSjRHWC1JS0tOIn19",
      {}
      ],
    "EnvelopedProfileAccount":[{
        "EnvelopeId":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQzQ0LUlaQzMtSV
  daVC1WQ1ZaLUwyQUctSEk0RS1MT1YyIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMS0wOC0wNVQxNjozNzozMVoifQ"},
      "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1DNDQtSVpDMy1JV1pULVZDVlotTDJBRy1ISTRFLUx
  PVjIiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJXNXVnRVd5Q3o5ODZQdzd4UFA5LWFwMDlQRnBxZmM5eF9NQjBVcT
  FiclVwRWcxeWxJYWl0CiAgRTVZYUpJQWVUYl9DYzV5NFlyNUQ2a2dBIn19fSwKICA
  gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy
  dmljZVVkZiI6ICJNQkJZLUU0VkEtQ01XRi01MlQ3LUVTTEEtUEdOVC1DTk5YIiwKI
  CAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ1FYLVBGN0
  EtTFkzRy0zWlBJLUFJWU8tTFI1RC1ZRzZXIiwKICAgICAgIlB1YmxpY1BhcmFtZXR
  lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2
  IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICIwQVJFMFZhcHNNcVlmX1Atd
  EZuRTBGWjJacTJ3bjRlMjF2aUNINFRyaHlnN1EwTjhGWG1iCiAgcFl2XzcyX0wyVk
  t1bGlpaU9oZGRUMU9BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIjo
  gewogICAgICAiVWRmIjogIk1DTEotTENGWC1FTkUyLTVOVEYtR0JOVi1NVzNQLVZI
  U1oiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS
  2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIl
  B1YmxpYyI6ICJHWG1nOHprMHB2VjliODgxSk52Um02OWRPVHVMN295WU53emlRUWx
  0V0Y0YVhaTUNUamY4CiAgRU0zZ3RDVTd3SEYwenVGc2QxV2dYOEdBIn19fSwKICAg
  ICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTURBNS1QW
  TZBLUJHMkwtN1lONi1FQUtQLU8zUUItQ0c1VCIsCiAgICAgICJQdWJsaWNQYXJhbW
  V0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImN
  ydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiWGNITjdBYk1UVzFUTVFP
  ZDBtWHlBSEc2Mk82ajdZSGdJR2hwMU9hajV4VE9LMnVQekd4TQogIGVDZUZPelgwZ
  i1ZSlhpakw2aGxfYmFXQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6IHsKIC
  AgICAgIlVkZiI6ICJNQ0dCLTRLQ0ktQ1AzRy1GSlNELVc3VzItVVlLTy1HTkxVIiw
  KICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVD
  REgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiY0Exd2NLdG4xZGFqNjA2VUQwUEo4eExxRk4wa09keHlqc0YyUUtyUFp4ZF
  VZZ1NQUlZSaQogIExzTEpPRWw3Y0lzdHRwYUNGd3VQaURPQSJ9fX19fQ",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2",
            "signature":"p1UxtlxOGp8wd7oESFQkmqR6uV9s-cW4WtonkwN1
  BbH9F1KN6lllLPhnNBhlmstQ06cm7BEYtR6AwG2f1yOM1IjdPFzLmm53MBA-g4GLe
  bflsg87h_kvT9JVSnHq7MDY6ewMo97Boay7r26qf-Ci4xIA"}
          ],
        "PayloadDigest":"gNprAKlPBfHdWXEdD7djEQ8IoJzHAJS-zBlZW6Bj
  8xjHqsbEhqbSO4AkIEizON5HsGbMSu_BQl_NPSrKZWS9pw"}
      ]}}

The device generates the witness value and presents it to the user as shown above.¶

9.1.3. Phase 3:

The user synchronizes their pending messages:¶

Alice> message pending
MessageID: KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN
        Connection Request::
        MessageID: KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN
        To:  From:
        Device:  MAOK-I4TT-3EUS-4LMY-Z6JO-VEN7-CX6F
        Witness: KB3G-NC35-X6IU-BEKJ-YIQR-J4GX-IKKN
MessageID: NC2L-ZQGP-ER6P-F6GB-LMKJ-DOFI-PO3V
        Group invitation::
        MessageID: NC2L-ZQGP-ER6P-F6GB-LMKJ-DOFI-PO3V
        To: alice@example.com From: alice@example.com
MessageID: NBLG-QNFG-5NRO-K2PT-JIBB-4AVX-X2L6
        Confirmation Request::
        MessageID: NBLG-QNFG-5NRO-K2PT-JIBB-4AVX-X2L6
        To: alice@example.com From: console@example.com
        Text: start
MessageID: NDIB-OGS2-XXZG-D2M2-5YJI-QQXN-2IVO
        Contact Request::
        MessageID: NDIB-OGS2-XXZG-D2M2-5YJI-QQXN-2IVO
        To: alice@example.com From: bob@example.com
        PIN: AAKO-AYTU-YH3M-DWOO-SLKU-N7ZD-SKUA
Alice> account sync /auto
ERROR - An attempt was made to create an object with an existing obje
ct identifier

The administration device determines that the device connection request is authenticated by a PIN code. The PIN code is retrieved and the message authenticated. This is shown in the PIN registration interation example in section $$$ above.¶

The Cataloged device record is created from the public key values corresponding to the combination of the public keys in the device profile and those defined by the activation:¶

The ActivationDevice and CatalogedDevice records are ???¶

9.1.4. Phase 4

The device periodically polls for completion of the connection request using the Complete transaction.¶

To provide a final check on the process, the command line tool presents the UDF of the account profile to which the device has connected if successful:¶

Missing example 40

The completion request specified the device requesting completion:¶

The response contains the information the device requires to complete the connection to the mesh:¶

9.2. Witness Authenticated

The witness authenticated interaction is essentially the same as the Dynamic QR Code (PIN) Authenticated interaction except that mutual authentication is achieved by comparing the witness value computed by the device in the second phase to that computed by the administration device in the third phase.¶

9.2.1. Phase 1:

There are no first phase actions.¶

9.2.2. Phase 2:

Alice enters the connection request on the device to be connected. This specifies the address of the account to which she wishes to connect:¶

Alice2> device request alice@example.com
   Device UDF = MCV4-LGJA-J6TI-ZJ4D-SXJW-BOK2-HCZL
   Witness value = BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU

9.2.3. Phase 3:

The user reviews their pending messages:¶

Alice> device pending
MessageID: BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU
        Connection Request::
        MessageID: BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU
        To:  From:
        Device:  MCV4-LGJA-J6TI-ZJ4D-SXJW-BOK2-HCZL
        Witness: BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU

The administration device receives the AcknowledgeConnection message from the service and verifies that the signature is valid and the witness value correctly computed.¶

The user verifies that the witness value presented in the AcknowledgeConnection message matches the one presented on the device. Since they match, the request is accepted:¶

Alice> device accept BVVL-2ATV-2U2Q-V3AL-HU54-C55J-XZKU /message /web

9.2.4. Phase 4

The device completes the connection as before:¶

Alice2> device complete
   Device UDF = MCV4-LGJA-J6TI-ZJ4D-SXJW-BOK2-HCZL
   Account = alice@example.com
   Account UDF = MC44-IZC3-IWZT-VCVZ-L2AG-HI4E-LOV2

9.3. Static QR Code Authenticated

The Static QR Code Authenticated mode is used to connect devices that have been preconfigured for use with the Mesh with a device configuration identified by a URI typically presented as machine readable QR code on the device itself.¶

The interaction has four phases:¶

Phase 1: Preconfiguration: The device to be onboarded is preconfigured with a ProfileDevice and private key information and a DeviceDescription posted to a publication service. This process is typically performed during manufacture. An EARL providing the ability to locate and decrypt the description is printed on the device itself as a QR code.¶
Phase 2: Device description acquisition: The administration device acquiring the onboarding device scans the QR code on the device and uses this information to obtain the device description by means of the PollClaim interaction described above.¶
Phase 3: Administration Device Acceptance: This phase is performed in the same manner as the Dynamic QR Code (PIN) Authenticated interaction except that the administration device MAY advise the device that a connection request is being made by additional means described in the device description (e.g. WiFi, Bluetooth).¶
Phase 4: Onboarding Device Completion: This phase is performed in the same manner as the Dynamic QR Code (PIN) Authenticated interaction except that the administration device requires notice that of the pending connection request.¶

The use of the PollClaim interaction to discover a pending claim for a document was shown in section $$$ above. The claim is authenticated using the key specified in the EARL.¶

9.3.1. Phase 1

The device is prepopulated with a Device description, this is shown in section $$$ of Schema.¶

9.3.2. Phase 2

The administration device scans the QR code and obtains the Device Description using the Claim transaction as shown in section $$$$.¶

9.3.3. Phase 3

Tha administration device creates the ActivationDevice and CatalogedDevice records and populates the service as before.¶

9.3.4. Phase 4

The device polls the publication service until a claim message is returned. This interaction is shown in section $$$$ above.¶

10. Protocol Schema

HTTP Well Known Service Prefix: /.well-known/mmm

Every Mesh Portal Service transaction consists of exactly one request followed by exactly one response. Mesh Service transactions MAY cause modification of the data stored in the Mesh Service or the Mesh itself but do not cause changes to the connection state. The protocol itself is thus idempotent. There is no set sequence in which operations are required to be performed. It is not necessary to perform a Hello transaction prior to any other transaction.¶

10.1. Request Messages

A Mesh Portal Service request consists of a payload object that inherits from the MeshRequest class. When using the HTTP binding, the request MUST specify the portal DNS address in the HTTP Host field.¶

10.1.1. Message: MeshRequest

Base class for all request messages.¶

[No fields]¶

10.1.2. Message: MeshRequestUser

Base class for all request messages made by a user.¶

Inherits: MeshRequest
Account: String (Optional): The fully qualified account name (including DNS address) to which the request is directed.¶
EnvelopedProfileDevice: Enveloped (Optional): Device profile of the device making the request.¶

10.2. Response Messages

A Mesh Portal Service response consists of a payload object that inherits from the MeshResponse class. When using the HTTP binding, the response SHOULD report the Status response code in the HTTP response message. However the response code returned in the payload object MUST always be considered authoritative.¶

10.2.1. Message: MeshResponse

Base class for all response messages. Contains only the status code and status description fields.¶

[No fields]¶

10.3. Imported Objects

The Mesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications and in the DARE Data At Rest Encryption extensions to JOSE.¶

10.4. Common Structures

The following common structures are used in the protocol messages:¶

10.4.1. Structure: KeyValue

Describes a Key/Value structure used to make queries for records matching one or more selection criteria.¶

Key: String (Optional): The data retrieval key.¶
Value: String (Optional): The data value to match.¶

10.4.2. Structure: ConstraintsSelect

Specifies constraints to be applied to a search result. These allow a client to limit the number of records returned, the quantity of data returned, the earliest and latest data returned, etc.¶

Container: String (Optional)

The container to be searched.¶

IndexMin: Integer (Optional)

Only return objects with an index value that is equal to or higher than the value specified.¶

IndexMax: Integer (Optional)

Only return objects with an index value that is equal to or lower than the value specified.¶

NotBefore: DateTime (Optional)

Only data published on or after the specified time instant is requested.¶

Before: DateTime (Optional)

Only data published before the specified time instant is requested. This excludes data published at the specified time instant.¶

PageKey: String (Optional)

Specifies a page key returned in a previous search operation in which the number of responses exceeded the specified bounds.¶

When a page key is specified, all the other search parameters except for MaxEntries and MaxBytes are ignored and the service returns the next set of data responding to the earlier query.¶

10.4.3. Structure: ConstraintsData

Specifies constraints on the data to be sent.¶

MaxEntries: Integer (Optional): Maximum number of entries to send.¶
BytesOffset: Integer (Optional): Specifies an offset to be applied to the payload data before it is sent. This allows large payloads to be transferred incrementally.¶
BytesMax: Integer (Optional): Maximum number of payload bytes to send.¶
Header: Boolean (Optional): Return the entry header¶
Payload: Boolean (Optional): Return the entry payload¶
Trailer: Boolean (Optional): Return the entry trailer¶

10.4.4. Structure: PolicyAccount

Describes the account creation policy including constraints on account names, whether there is an open account creation policy, etc.¶

Minimum: Integer (Optional): Specifies the minimum length of an account name.¶
Maximum: Integer (Optional): Specifies the maximum length of an account name.¶
InvalidCharacters: String (Optional): A list of characters that the service does not accept in account names. The list of characters MAY not be exhaustive but SHOULD include any illegal characters in the proposed account name.¶

10.4.5. Structure: ContainerStatus

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

10.4.6. Structure: ContainerUpdate

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

10.5. Transaction: Hello

Request: HelloRequest
Response: MeshHelloResponse

Report service and version information.¶

The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service.¶

The PostConstraints field MAY be used to advise senders of a maximum size of payload that MAY be sent in an initial Post request.¶

10.5.1. Message: MeshHelloResponse

ConstraintsUpdate: ConstraintsData (Optional): Specifies the default data constraints for updates.¶
ConstraintsPost: ConstraintsData (Optional): Specifies the default data constraints for message senders.¶
PolicyAccount: PolicyAccount (Optional): Specifies the account creation policy¶
EnvelopedProfileService: Enveloped (Optional): The enveloped master profile of the service.¶
EnvelopedProfileHost: Enveloped (Optional): The enveloped profile of the host.¶

10.6. Transaction: BindAccount

Request: BindRequest
Response: BindResponse

Request creation of a new service account or group.¶

Attempt¶

10.6.1. Message: BindRequest

Request binding of an account to a service address.¶

Inherits: MeshRequest
AccountAddress: String (Optional): The service account to bind to.¶
EnvelopedProfileAccount: Enveloped (Optional): The signed assertion describing the account.¶

10.6.2. Message: BindResponse

Inherits: MeshResponse

Reports the success or failure of a Create transaction.¶

Reason: String (Optional): Text explaining the status of the creation request.¶
URL: String (Optional): A URL to which the user is directed to complete the account creation request.¶

10.7. Transaction: UnbindAccount

Request: UnbindRequest
Response: UnbindResponse

Request deletion of a service account.¶

10.7.1. Message: UnbindRequest

Request creation of a new portal account. The request specifies the requested account identifier and the Mesh profile to be associated with the account.¶

Inherits: MeshRequestUser

[No fields]¶

10.7.2. Message: UnbindResponse

Inherits: MeshResponse

Reports the success or failure of a Delete transaction.¶

[No fields]¶

10.8. Transaction: Connect

Request: ConnectRequest
Response: ConnectResponse

Request information necessary to begin making a connection request.¶

10.8.1. Message: ConnectRequest

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

10.8.2. Message: ConnectResponse

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

10.9. Transaction: Complete

Request: CompleteRequest
Response: CompleteResponse

10.9.1. Message: CompleteRequest

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

10.9.2. Message: CompleteResponse

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

10.10. Transaction: Status

Request: StatusRequest
Response: StatusResponse

10.10.1. Message: StatusRequest

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

10.10.2. Message: StatusResponse

Inherits: MeshResponse
EnvelopedProfileAccount: Enveloped (Optional): The account profile providing the root of trust for this account.¶
EnvelopedCatalogedDevice: Enveloped (Optional): The catalog device entry¶
ContainerStatus: ContainerStatus [0..Many]

10.11. Transaction: Download

Request: DownloadRequest
Response: DownloadResponse

Request objects from the specified container with the specified search criteria.¶

10.11.1. Message: DownloadRequest

Inherits: MeshRequestUser

Request objects from the specified container(s).¶

A client MAY request only objects matching specified search criteria be returned and MAY request that only specific fields or parts of the payload be returned.¶

Select: ConstraintsSelect [0..Many]: Specifies constraints to be applied to a search result. These allow a client to limit the number of records returned, the quantity of data returned, the earliest and latest data returned, etc.¶
ConstraintsPost: ConstraintsData (Optional): Specifies the data constraints to be applied to the responses.¶

10.11.2. Message: DownloadResponse

Inherits: MeshResponse

Return the set of objects requested.¶

Services SHOULD NOT return a response that is disproportionately large relative to the speed of the network connection without a clear indication from the client that it is relevant. A service MAY limit the number of objects returned. A service MAY limit the scope of each response.¶

Updates: ContainerUpdate [0..Many]: The updated data¶

10.12. Transaction: Transact

Request: TransactRequest
Response: TransactResponse

Attempt an atomic transaction on the containers and spools associated with an account.¶

10.12.1. Message: TransactRequest

Inherits: MeshRequestUser

Upload entries to a container. This request is only valid if it is issued by the owner of the account¶

Updates: ContainerUpdate [0..Many]: The data to be updated¶
Accounts: String [0..Many]: The account(s) to which the request is directed.¶
Outbound: Enveloped [0..Many]: The messages to be sent to other accounts¶
Inbound: Enveloped [0..Many]: Messages to be appended to the user's inbound spool. this is typically used to post notifications to the user to mark messages as having been read or responded to.¶
Local: Enveloped [0..Many]: Messages to be appended to the user's local spool. This is used to allow connecting devices to collect activation messages before they have connected to the mesh.¶

10.12.2. Message: TransactResponse

Inherits: MeshResponse

Response to an upload request.¶

Entries: EntryResponse [0..Many]: The responses to the entries.¶
ConstraintsData: ConstraintsData (Optional): If the upload request contains redacted entries, specifies constraints that apply to the redacted entries as a group. Thus the total payloads of all the messages must not exceed the specified value.¶

10.12.3. Structure: EntryResponse

IndexRequest: Integer (Optional): The index value of the entry in the request.¶
IndexContainer: Integer (Optional): The index value assigned to the entry in the container.¶
Result: String (Optional): Specifies the result of attempting to add the entry to a catalog or spool. Valid values for a message are 'Accept', 'Reject'. Valid values for an entry are 'Accept', 'Reject' and 'Conflict'.¶
ConstraintsData: ConstraintsData (Optional): If the entry was redacted, specifies constraints that apply to the redacted entries as a group. Thus the total payloads of all the messages must not exceed the specified value.¶

10.13. Transaction: Post

Request: PostRequest
Response: PostResponse

Request to post to a spool from an external party. The request and response messages are extensions of the corresponding messages for the Upload transaction. It is expected that additional fields will be added as the need arises.¶

10.13.1. Message: PostRequest

Inherits: MeshRequest
Accounts: String [0..Many]: The account(s) to which the request is directed.¶
Messages: Enveloped [0..Many]: The messages to be sent to the addresses specified in Accounts.¶

10.13.2. Message: PostResponse

Inherits: TransactResponse

[No fields]¶

10.14. Transaction: Claim

Request: ClaimRequest
Response: ClaimResponse

Claim a publication¶

10.14.1. Message: ClaimRequest

Inherits: MeshRequest
EnvelopedMessageClaim: Enveloped (Optional): The claim message¶

10.14.2. Message: ClaimResponse

Inherits: MeshResponse
CatalogedPublication: CatalogedPublication (Optional): The encrypted device profile¶

10.15. Transaction: PollClaim

Request: PollClaimRequest
Response: PollClaimResponse

Check party making claim¶

10.15.1. Message: PollClaimRequest

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

10.15.2. Message: PollClaimResponse

Inherits: MeshResponse
EnvelopedMessage: Enveloped (Optional): The claim message¶

10.15.3. Structure: CryptographicOperation

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

10.15.4. Structure: CryptographicOperationSign

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

10.15.5. Structure: CryptographicOperationKeyAgreement

Inherits: CryptographicOperation

[No fields]¶

10.15.6. Structure: CryptographicOperationGenerate

Inherits: CryptographicOperation

[No fields]¶

10.15.7. Structure: CryptographicOperationShare

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

10.15.8. Structure: CryptographicResult

Error: String (Optional)

10.15.9. Structure: CryptographicResultKeyAgreement

Inherits: CryptographicResult

[No fields]¶

10.15.10. Structure: CryptographicResultShare

Inherits: CryptographicResult

[No fields]¶

10.16. Transaction: Operate

Request: OperateRequest
Response: OperateResponse

Perform a set of cryptographic operations¶

10.16.1. Message: OperateRequest

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

10.16.2. Message: OperateResponse

Inherits: MeshResponse

[No fields]¶

[draft-hallambaker-mesh-architecture]: Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: Architecture Guide", Work in Progress, Internet-Draft, draft-hallambaker-mesh-architecture-16, 13 January 2021, <https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-architecture-16>.
[draft-hallambaker-mesh-schema]: Hallam-Baker, P., "Mathematical Mesh 3.0 Part IV: Schema Reference", Work in Progress, Internet-Draft, draft-hallambaker-mesh-schema-07, 13 January 2021, <https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-schema-07>.
[draft-hallambaker-mesh-security]: Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Security Considerations", Work in Progress, Internet-Draft, draft-hallambaker-mesh-security-06, 2 November 2020, <https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-security-06>.
[draft-hallambaker-mesh-udf]: Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, Internet-Draft, draft-hallambaker-mesh-udf-12, 13 January 2021, <https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-udf-12>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339]: Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.
[RFC4648]: Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC7230]: Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/rfc/rfc7230>.
[RFC8446]: Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

15. Informative References

[draft-hallambaker-mesh-developer]: Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft-hallambaker-mesh-developer-10, 27 July 2020, <https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-developer-10>.
[ECMA-262]: Ecma International, "ECMAScript(R) 2017 Language Specification", June 2017.

Document	Document type	This is an older version of an Internet-Draft whose latest revision state is "Expired".
	Select version	00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
	Compare versions
	Author	Phillip Hallam-Baker
	RFC stream	(None)
	Other formats	txt html xml pdf bibtex bibxml