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]