Internet-Draft Mesh/Account November 2017
Hallam-Baker Expires May 13, 2018 [Page]
Independent Submission
Phillip Hallam-Baker (Comodo Group Inc.)



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. This document describes …

Mesh/Account provides a named container for mesh application profiles that are not stored in the Mesh. The name of a Mesh/Account profile is given in the standard <username>@<account> format introduced in [RFC822].

Allow profiles to be managed locally.

Support profiles containing large data items.

This document is also available online at

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

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 May 13, 2018

Table of Contents

1. 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.

1.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].

1.3. Defined Terms

No terms of art are defined.

1.4. Implementation Status

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

2. Introduction

The Mathematical Mesh is a personal PKI that permits a user to connect multiple devices to a ‘personal profile’ through which application information is shared between the connected devices. All Mesh communications are secured through a combination of end-to-end security to protect confidentiality and integrity and transport security to provide protection against traffic analysis.

A full description of the Mathematical Mesh architecture is to be found in [draft-hallambaker-mesh-architecture]

This document …

3. Mesh/Account Service

The Mesh/Account Service is used to manage accounts. All operations are regarded as privileged and will require appropriate access controls.

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

Every Mesh/Account Service transaction consists of exactly one request followed by exactly one response.

3.1. Request Messages

3.1.1. Message: AccountRequest

Base class for all request messages.

[No fields]

3.2. Response Messages

3.2.1. Message: AccountResponse

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

A service MAY return either the response message specified for that transaction or any parent of that message. Thus the RecryptResponse message MAY be returned in response to any request.

[No fields]

3.3. Imported Objects

3.4. Common classes

The following classes are referenced at multiple points in the protocol.

3.4.1. Structure: AccountData

The data associated with an account

AccountId: String (Optional)
The account identifier
Created: DateTime (Optional)
Date and time that the account identifier was created.
Status: String (Optional)
Account status
MeshUDF: String (Optional)
Fingerprint of the user's mesh profile
Portal: String [0..Many]
Mesh Portal identifier
Entries: AccountDataEntry [0..Many]
Service specific data
3.4.2. Structure: AccountDataEntry

Superclass for all account data entry objects

[No fields]

3.5. Utility Transactions

3.6. Transaction: Hello

Request: HelloRequest
Response: HelloResponse

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.

3.7. Administration Transactions

3.8. Transaction: Create

Request: CreateRequest
Response: CreateResponse

Create new account

3.8.1. Message: CreateRequest
Inherits: AccountRequest

Create a new account

Data: AccountData (Optional)
Describes the account to be created
3.8.2. Message: CreateResponse
Inherits: AccountResponse

Response to create request

UDF: String (Optional)
Unique identifier of the account

3.9. Transaction: Delete

Request: DeleteRequest
Response: DeleteResponse

Delete an account

3.9.1. Message: DeleteRequest
Inherits: AccountRequest

Delete an account

AccountId: String (Optional)
The account to delete
3.9.2. Message: DeleteResponse
Inherits: AccountResponse


[No fields]

3.10. Transaction: Update

Request: UpdateRequest
Response: UpdateResponse
3.10.1. Message: UpdateRequest
Inherits: AccountRequest

Update an account profile

Data: AccountData (Optional)
The account to update
3.10.2. Message: UpdateResponse
Inherits: AccountResponse


[No fields]

3.11. Transaction: Get

Request: GetRequest
Response: GetResponse
3.11.1. Message: GetRequest
Inherits: AccountRequest

Fetches an account profile.

AccountId: String (Optional)
The account to fetch
3.11.2. Message: GetResponse
Inherits: AccountResponse


Data: AccountData (Optional)
Describes the account (if found)


Normative References

S. Bradner "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 RFC 2119 DOI 10.17487/RFC2119
Phillip Hallam-Baker "Mathematical Mesh: Architecture" Internet-Draft draft-hallambaker-mesh-architecture-04 <>

Informative References

Phillip Hallam-Baker "Mathematical Mesh: Reference Implementation" Internet-Draft draft-hallambaker-mesh-developer-05 <>

Author's Address

Phillip Hallam-Baker
Comodo Group Inc.
Prepared: Rendered: