Network Working Group P. Hallam-Baker
Internet-Draft April 4, 2019
Intended status: Informational
Expires: October 6, 2019
Mathematical Mesh Part V: Protocol Reference
draft-hallambaker-mesh-protocol-00
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.
This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html
[1] .
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 October 6, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Hallam-Baker Expires October 6, 2019 [Page 1]
Internet-Draft Mesh Protocol Reference April 2019
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Related Specifications . . . . . . . . . . . . . . . . . 4
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5
3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Transaction . . . . . . . . . . . . . . . . . . . . 5
4.1. Connection Establishment . . . . . . . . . . . . . . . . 5
4.2. Account Management . . . . . . . . . . . . . . . . . . . 5
4.3. Device Connection . . . . . . . . . . . . . . . . . . . . 5
4.4. Container Synchronization . . . . . . . . . . . . . . . . 5
4.4.1. User Experience Considerations . . . . . . . . . . . 5
4.4.2. Status Transaction . . . . . . . . . . . . . . . . . 5
4.4.3. Download Transaction . . . . . . . . . . . . . . . . 5
4.4.4. Upload Transaction . . . . . . . . . . . . . . . . . 6
4.5. Message Exchange . . . . . . . . . . . . . . . . . . . . 6
4.5.1. Client-Service (Post Transaction) . . . . . . . . . . 6
4.5.2. Service-Service (Post Transaction) . . . . . . . . . 6
4.5.3. Service-Client (Synchronization) . . . . . . . . . . 6
4.6. Mesh Service . . . . . . . . . . . . . . . . . . . . . . 7
4.6.1. Catalogs . . . . . . . . . . . . . . . . . . . . . . 7
4.6.2. Spools . . . . . . . . . . . . . . . . . . . . . . . 7
4.6.3. Partitioning . . . . . . . . . . . . . . . . . . . . 7
4.6.4. Backup . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 7
5.1. HTTPS Presentation . . . . . . . . . . . . . . . . . . . 8
5.2. DARE Message Encapsulation . . . . . . . . . . . . . . . 8
5.2.1. Device Authentication . . . . . . . . . . . . . . . . 8
5.2.2. Profile Authentication . . . . . . . . . . . . . . . 8
5.2.3. Ticket Authentication . . . . . . . . . . . . . . . . 8
5.3. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 8
5.4. JSON-B Encoding . . . . . . . . . . . . . . . . . . . . . 8
6. Account Management . . . . . . . . . . . . . . . . . . . . . 8
7. Container Operations . . . . . . . . . . . . . . . . . . . . 8
7.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Download . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Upload . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Device Connection . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Device Authenticated . . . . . . . . . . . . . . . . . . 9
8.2. PIN Authenticated . . . . . . . . . . . . . . . . . . . . 9
Hallam-Baker Expires October 6, 2019 [Page 2]
Internet-Draft Mesh Protocol Reference April 2019
8.3. EARL connection mode . . . . . . . . . . . . . . . . . . 9
9. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Confirm . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Protocol Schema . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Request Messages . . . . . . . . . . . . . . . . . . . . 9
10.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 10
10.1.2. Message: MeshRequestUser . . . . . . . . . . . . . . 10
10.2. Response Messages . . . . . . . . . . . . . . . . . . . 10
10.2.1. Message: MeshResponse . . . . . . . . . . . . . . . 10
10.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 10
10.4. Common Structures . . . . . . . . . . . . . . . . . . . 10
10.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . 11
10.4.2. Structure: ConstraintsSelect . . . . . . . . . . . . 11
10.4.3. Structure: ConstraintsData . . . . . . . . . . . . . 11
10.4.4. Structure: PolicyAccount . . . . . . . . . . . . . . 12
10.4.5. Structure: ContainerStatus . . . . . . . . . . . . . 12
10.4.6. Structure: ContainerUpdate . . . . . . . . . . . . . 12
10.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 13
10.5.1. Message: MeshHelloResponse . . . . . . . . . . . . . 13
10.6. Transaction: Status . . . . . . . . . . . . . . . . . . 13
10.6.1. Message: StatusRequest . . . . . . . . . . . . . . . 13
10.6.2. Message: StatusResponse . . . . . . . . . . . . . . 14
10.7. Transaction: Download . . . . . . . . . . . . . . . . . 14
10.7.1. Message: DownloadRequest . . . . . . . . . . . . . . 14
10.7.2. Message: DownloadResponse . . . . . . . . . . . . . 15
10.8. Transaction: Upload . . . . . . . . . . . . . . . . . . 15
10.8.1. Message: UploadRequest . . . . . . . . . . . . . . . 15
10.8.2. Message: UploadResponse . . . . . . . . . . . . . . 15
10.8.3. Structure: EntryResponse . . . . . . . . . . . . . . 16
10.9. Transaction: Post . . . . . . . . . . . . . . . . . . . 16
10.9.1. Message: PostRequest . . . . . . . . . . . . . . . . 16
10.9.2. Message: PostResponse . . . . . . . . . . . . . . . 17
10.10. Transaction: Connect . . . . . . . . . . . . . . . . . . 17
10.10.1. Message: ConnectRequest . . . . . . . . . . . . . . 17
10.10.2. Message: ConnectResponse . . . . . . . . . . . . . 17
10.11. Transaction: CreateAccount . . . . . . . . . . . . . . . 18
10.11.1. Message: CreateRequest . . . . . . . . . . . . . . 18
10.11.2. Message: CreateResponse . . . . . . . . . . . . . . 18
10.12. Transaction: DeleteAccount . . . . . . . . . . . . . . . 19
10.12.1. Message: DeleteRequest . . . . . . . . . . . . . . 19
10.12.2. Message: DeleteResponse . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 20
Hallam-Baker Expires October 6, 2019 [Page 3]
Internet-Draft Mesh Protocol Reference April 2019
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
This document describes the data structures and network protocols of
the Mathematical Mesh illustrated with illustrative examples. For an
overview of the Mesh objectives and architecture, consult the
accompanying Architecture Guide [draft-hallambaker-mesh-architecture]
This document has two main sections. The first section presents
examples of using the Mesh to address common use cases. The second
section contains the Mesh profile and service schemas. All the
material in both sections is generated from the Mesh reference
implementation [draft-hallambaker-mesh-developer] .
Although some of the services described in this document could be
used to replace existing Internet protocols including FTP and SMTP,
the principal value of any communication protocol lies in the size of
the audience it allows them to communicate with. Thus, while the
Mesh Messaging service is designed to support efficient and reliable
transfer of messages ranging in size from a few bytes to multiple
terabytes, the near term applications of these services will be to
applications that are not adequately supported by existing protocols
if at all.
2. Definitions
This section presents the related specifications and standard, the
terms that are used as terms of art within the documents and the
terms used as requirements language.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
2.2. Defined Terms
The terms of art used in this document are described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] .
2.3. Related Specifications
The architecture of the Mathematical Mesh is described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh
Hallam-Baker Expires October 6, 2019 [Page 4]
Internet-Draft Mesh Protocol Reference April 2019
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.
4. Protocol Transaction
4.1. Connection Establishment
4.2. Account Management
4.3. Device Connection
4.4. Container Synchronization
4.4.1. User Experience Considerations
Sync
o Status
o Upload outbound messages
o Download catalog and spool updates
o Upload catalog updates
Rapid access - only take last 100 messages
Limitation on message size ensures that
4.4.2. Status Transaction
Obtain updated device profile (if it exists) and the status of the
set of catalogs the device is authorized
4.4.3. Download Transaction
Read objects from a catalog or spool owned by the client making the
request.
Hallam-Baker Expires October 6, 2019 [Page 5]
Internet-Draft Mesh Protocol Reference April 2019
Optional filtering criteria MAY be specified to only return objects
matching specific criteria and/or only return certain parts of the
selected messages.
The transaction MAY be performed in one request/response round trip
or with separate round trips to confirm that the transaction is
accepted by the service before sending large volumes of data.
4.4.4. Upload Transaction
Upload objects to a catalog or spool owned by Read objects from a
catalog or spool owned by the client making the request.
Multiple objects MAY be uploaded at once. Object updates MAY be
conditional on the successful completion of other upload requests.
The transaction MAY be performed in one request/response round trip
or with separate round trips to confirm that the transaction is
accepted by the service before sending large volumes of data.
4.5. Message Exchange
Four corner model enforced.
Messages are limited to control with very small amounts of data
Long messages are exchanged as detachments using separate protocol
(HTTP).
This ensures that messages are processed quickly and reliably. A
server will not be blocked by receipt of a long message.
Aggressive controls on services may be enforced to prevent DoS
attacks.
Post transaction is used for client-service and service-service
transactions.
4.5.1. Client-Service (Post Transaction)
4.5.2. Service-Service (Post Transaction)
4.5.3. Service-Client (Synchronization)
Hallam-Baker Expires October 6, 2019 [Page 6]
Internet-Draft Mesh Protocol Reference April 2019
4.6. Mesh Service
Untrusted service, minimize trust to bare minimum
Can't read content of any message.
Can only read contact catalog entries.
4.6.1. Catalogs
4.6.1.1. Account
Contains the account entries.
4.6.2. Spools
4.6.2.1. Account
Log of all updates to accounts.
Synchronization off-host provides backup.
4.6.2.2. Incident
Reports of potential abuse
4.6.3. Partitioning
Can split out handling of accounts to separate hosts each handling a
subset of accounts.
User clients are directed to connect to a specific host in any case
by means of redirects.
4.6.4. Backup
Synchronizing Account spools protects data against loss and provides
for fast restart capability.
5. Protocol Binding
Transactions consist of single request message followed by a single
response message.
Default binding is HTTPS/DARE/JSON
Hello Transaction may be used to determine features supported by the
service and the service configuration
Hallam-Baker Expires October 6, 2019 [Page 7]
Internet-Draft Mesh Protocol Reference April 2019
```` Example ProtocolHello ````
5.1. HTTPS Presentation
5.2. DARE Message Encapsulation
5.2.1. Device Authentication
```` Example ProtocolHelloDevice ````
5.2.2. Profile Authentication
```` Example ProtocolHelloProfile ````
5.2.3. Ticket Authentication
```` Example ProtocolHelloTicket ````
5.3. JSON Encoding
5.4. JSON-B Encoding
6. Account Management
```` Example ProtocolAccountCreate ````
```` Example ProtocolAccountDelete ````
7. Container Operations
7.1. Status
```` Example ProtocolStatus ````
7.2. Download
```` Example ProtocolDownload ````
7.3. Upload
```` Example ProtocolProtocolUploadHello ````
8. Device Connection
Hallam-Baker Expires October 6, 2019 [Page 8]
Internet-Draft Mesh Protocol Reference April 2019
8.1. Device Authenticated
```` Example ProtocolConnect ````
8.2. PIN Authenticated
```` Example ProtocolConnectPIN ````
8.3. EARL connection mode
```` Example ProtocolConnectEARL ````
9. Mesh Messages
All communications between accounts is performed through mesh
messages.
Four corner model
9.1. Contact
```` Example ProtocolContact ````
9.2. Confirm
```` Example ProtocolConfirm ````
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.
Hallam-Baker Expires October 6, 2019 [Page 9]
Internet-Draft Mesh Protocol Reference April 2019
10.1.1. Message: MeshRequest
Base class for all request messages.
[No fields]
10.1.2. Message: MeshRequestUser
Base class for all request messages made by a user.
Inherits: MeshRequest
Inherits: MeshRequest
Account: String (Optional) The fully qualified account name
(including DNS address) to which the request is directed.
DeviceProfile: DareMessage (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:
Hallam-Baker Expires October 6, 2019 [Page 10]
Internet-Draft Mesh Protocol Reference April 2019
10.4.1. Structure: KeyValue
Describes a Key/Value structure used to make queries for records
matching one or more selection criteria.
Key: String (Optional) The data retrieval key.
Value: String (Optional) The data value to match.
10.4.2. Structure: ConstraintsSelect
Specifies constraints to be applied to a search result. These allow
a client to limit the number of records returned, the quantity of
data returned, the earliest and latest data returned, etc.
Container: String (Optional) The container to be searched.
IndexMin: Integer (Optional) Only return objects with an index value
that is equal to or higher than the value specified.
IndexMax: Integer (Optional) Only return objects with an index value
that is equal to or lower than the value specified.
NotBefore: DateTime (Optional) Only data published on or after the
specified time instant is requested.
Before: DateTime (Optional) Only data published before the specified
time instant is requested. This excludes data published at the
specified time instant.
PageKey: String (Optional) Specifies a page key returned in a
previous search operation in which the number of responses
exceeded the specified bounds.
When a page key is specified, all the other search parameters
except for MaxEntries and MaxBytes are ignored and the service
returns the next set of data responding to the earlier query.
10.4.3. Structure: ConstraintsData
Specifies constraints on the data to be sent.
MaxEntries: Integer (Optional) Maximum number of entries to send.
BytesOffset: Integer (Optional) Specifies an offset to be applied to
the payload data before it is sent. This allows large payloads to
be transferred incrementally.
Hallam-Baker Expires October 6, 2019 [Page 11]
Internet-Draft Mesh Protocol Reference April 2019
BytesMax: Integer (Optional) Maximum number of payload bytes to
send.
Header: Boolean (Optional) Return the entry header
Payload: Boolean (Optional) Return the entry payload
Trailer: Boolean (Optional) Return the entry trailer
10.4.4. Structure: PolicyAccount
Describes the account creation policy including constraints on
account names, whether there is an open account creation policy, etc.
Minimum: Integer (Optional) Specifies the minimum length of an
account name.
Maximum: Integer (Optional) Specifies the maximum length of an
account name.
InvalidCharacters: String (Optional) A list of characters that the
service does not accept in account names. The list of characters
MAY not be exhaustive but SHOULD include any illegal characters in
the proposed account name.
10.4.5. Structure: ContainerStatus
Container: String (Optional)
Container: String (Optional)
Index: Integer (Optional)
Index: Integer (Optional)
Digest: Binary (Optional)
10.4.6. Structure: ContainerUpdate
Container: String (Optional) The container to which the entries are
to be uploaded.
Message: DareMessage [0..Many] The entries to be uploaded. These
MAY be either complete messages or redacted messages. In either
case, the messages MUST conform to the ConstraintsUpdate specified
by the service
Hallam-Baker Expires October 6, 2019 [Page 12]
Internet-Draft Mesh Protocol Reference April 2019
10.5. Transaction: Hello
Request: HelloRequest
Request: HelloRequest
Response: MeshHelloResponse
Report service and version information.
The Hello transaction provides a means of determining which protocol
versions, message encodings and transport protocols are supported by
the service.
The PostConstraints field MAY be used to advise senders of a maximum
size of payload that MAY be sent in an initial Post request.
10.5.1. Message: MeshHelloResponse
ConstraintsUpdate: ConstraintsData (Optional) Specifies the default
data constraints for updates.
ConstraintsPost: ConstraintsData (Optional) Specifies the default
data constraints for message senders.
PolicyAccount: PolicyAccount (Optional) Specifies the account
creation policy
10.6. Transaction: Status
Request: StatusRequest
Request: StatusRequest
Response: StatusResponse
10.6.1. Message: StatusRequest
Inherits: MeshRequestUser
Inherits: MeshRequestUser
DeviceUDF: String (Optional)
DeviceUDF: String (Optional)
Catalogs: String [0..Many]
Hallam-Baker Expires October 6, 2019 [Page 13]
Internet-Draft Mesh Protocol Reference April 2019
Catalogs: String [0..Many]
Spools: String [0..Many]
10.6.2. Message: StatusResponse
Inherits: MeshResponse
Inherits: MeshResponse
ContainerStatus: ContainerStatus [0..Many]
ContainerStatus: ContainerStatus [0..Many]
CatalogEntryDevice: DareMessage (Optional) The catalog device entry
10.7. Transaction: Download
Request: DownloadRequest
Request: DownloadRequest
Response: DownloadResponse
Request objects from the specified container with the specified
search criteria.
10.7.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.
Hallam-Baker Expires October 6, 2019 [Page 14]
Internet-Draft Mesh Protocol Reference April 2019
10.7.2. Message: DownloadResponse
Inherits: MeshResponse
Return the set of objects requested.
Services SHOULD NOT return a response that is disproportionately
large relative to the speed of the network connection without a clear
indication from the client that it is relevant. A service MAY limit
the number of objects returned. A service MAY limit the scope of
each response.
Updates: ContainerUpdate [0..Many] The updated data
10.8. Transaction: Upload
Request: UploadRequest
Request: UploadRequest
Response: UploadResponse
Request objects from the specified container with the specified
search criteria.
10.8.1. Message: UploadRequest
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
Self: DareMessage [0..Many] Entries to be added to the inbound spool
on the account, e.g. completion messages.
10.8.2. Message: UploadResponse
Inherits: MeshResponse
Response to an upload request.
Entries: EntryResponse (Optional) The responses to the entries.
ConstraintsData: ConstraintsData (Optional) If the upload request
contains redacted entries, specifies constraints that apply to the
Hallam-Baker Expires October 6, 2019 [Page 15]
Internet-Draft Mesh Protocol Reference April 2019
redacted entries as a group. Thus the total payloads of all the
messages must not exceed the specified value.
10.8.3. Structure: EntryResponse
IndexRequest: Integer (Optional) The index value of the entry in the
request.
IndexContainer: Integer (Optional) The index value assigned to the
entry in the container.
Result: String (Optional) Specifies the result of attempting to add
the entry to a catalog or spool. Valid values for a message are
'Accept', 'Reject'. Valid values for an entry are 'Accept',
'Reject' and 'Conflict'.
ConstraintsData: ConstraintsData (Optional) If the entry was
redacted, specifies constraints that apply to the redacted entries
as a group. Thus the total payloads of all the messages must not
exceed the specified value.
10.9. Transaction: Post
Request: PostRequest
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.9.1. Message: PostRequest
Inherits: MeshRequest
Inherits: MeshRequest
Accounts: String [0..Many] The account(s) to which the request is
directed.
Message: DareMessage [0..Many] The entries to be uploaded. These
MAY be either complete messages or redacted messages. In either
case, the messages MUST conform to the ConstraintsUpdate specified
by the service
Hallam-Baker Expires October 6, 2019 [Page 16]
Internet-Draft Mesh Protocol Reference April 2019
Self: DareMessage (Optional) Messages to be appended to the inbound
spool of 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.
10.9.2. Message: PostResponse
Inherits: UploadResponse
[No fields]
10.10. Transaction: Connect
Request: ConnectRequest
Request: ConnectRequest
Response: ConnectResponse
Request information necessary to begin making a connection request.
10.10.1. Message: ConnectRequest
Inherits: MeshRequest
Inherits: MeshRequest
Account: String (Optional)
Account: String (Optional)
DeviceProfile: DareMessage (Optional) Device profile of the device
making the request.
ClientNonce: Binary (Optional)
ClientNonce: Binary (Optional)
PinID: String (Optional) Pin identifier used to identify a PIN
authenticated request.
10.10.2. Message: ConnectResponse
Inherits: MeshResponse
Inherits: MeshResponse
ProfileMesh: DareMessage (Optional) The account profile
Hallam-Baker Expires October 6, 2019 [Page 17]
Internet-Draft Mesh Protocol Reference April 2019
ServerNonce: Binary (Optional) Server Nonce value used to calculate
Witness
Witness: String (Optional) Witness value
10.11. Transaction: CreateAccount
Request: CreateRequest
Request: CreateRequest
Response: CreateResponse
Request creation of a new service account.
Attempt
10.11.1. Message: CreateRequest
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: MeshRequest
Inherits: MeshRequest
MeshProfile: DareMessage (Optional) The Mesh profile to be
registered.
CatalogEntryDevices: DareMessage [0..Many] The device profile(s) to
be registered in the corresponding device catalog.
CatalogEntryContacts: CatalogEntryContact [0..Many] The contact(s)
to be registered in the corresponding contact catalog. This
should usually be populated with a contact for the user
themselves.
10.11.2. Message: CreateResponse
Inherits: MeshResponse
Reports the success or failure of a Create transaction.
Reason: String (Optional) Text explaining the status of the creation
request.
Hallam-Baker Expires October 6, 2019 [Page 18]
Internet-Draft Mesh Protocol Reference April 2019
URL: String (Optional) A URL to which the user is directed to
complete the account creation request.
10.12. Transaction: DeleteAccount
Request: DeleteRequest
Request: DeleteRequest
Response: DeleteResponse
Request deletion of a new service account.
Attempt
10.12.1. Message: DeleteRequest
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.12.2. Message: DeleteResponse
Inherits: MeshResponse
Reports the success or failure of a Delete transaction.
[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
Hallam-Baker Expires October 6, 2019 [Page 19]
Internet-Draft Mesh Protocol Reference April 2019
13. Acknowledgements
14. References
14.1. Normative References
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh Part I: Architecture
Guide", draft-hallambaker-mesh-architecture-06 (work in
progress), August 2018.
[draft-hallambaker-mesh-security]
"[Reference Not Found!]".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.
14.2. Informative References
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-07 (work
in progress), April 2018.
14.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh-
protocol.html
Author's Address
Phillip Hallam-Baker
Email: phill@hallambaker.com
Hallam-Baker Expires October 6, 2019 [Page 20]