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