Internet-Draft Mesh Schema Reference April 2022
Hallam-Baker Expires 22 October 2022 [Page]
Network Working Group
Intended Status:
P. M. Hallam-Baker

Mathematical Mesh 3.0 Part IV: Schema Reference


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 (, which is archived at

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 22 October 2022.

Table of Contents

1. Introduction

This document describes the data structures of the Mathematical Mesh with illustrative examples. For an overview of the Mesh objectives and architecture, consult the accompanying Architecture Guide [draft-hallambaker-mesh-architecture]. For information on the implementation of the Mesh Service protocol, consult the accompanying Protocol Reference [draft-hallambaker-mesh-protocol]

This document has two main sections. The first section presents examples of the Mesh assertions, catalog entries and messages and their use. The second section contains the schema reference. 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.4. Implementation Status

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

3. Actors

The Mesh mediates interactions between three principal actors: Accounts, Devices, and Services.

Currently two account types are specified, user accounts which belong to an individual user and group accounts that are used to share access to confidential information between a group of users. It may prove useful to define new types of account over time or to eliminate the distinction entirely. When active a Mesh account is bound to a Mesh Service. The service to which an account is bound MAY be changed over time but an account can only be bound to a single service at a time.

A Mesh account is an abstract construct that (when active) is instantiated across one or more physical machines called a device. Each device that is connected to an account has a separate set of cryptographic keys that are used to interact with other devices connected to the account and MAY be provisioned with access to the account private keys which MAY or MAY NOT be mediated by the current Mesh Service. A user's Mesh accounts and the devices connected to them constitute that user's Personal Mesh.

A Mesh Service is an abstract construct that is provided by one or more physical machines called Hosts. A Mesh Host is a device that is attached to a service rather than an account.

3.1. Accounts

A Mesh Account is described by a Profile descended from Profile Account and contains a set of Mesh stores. Currently two account profiles are defined:


Describes a user account.


Describes a group account used to share confidential information between a group of users.

Both types of profile specify the following fields:


The public signature key used to authenticate the profile itself


The account name to which the account is currently bound. (e.g., @alice).


If the account is active, specifies the fingerprint of the service profile to which the account is currently bound.


The public signature key used to verify administrative actions on the account. In particular addition of devices to a user account or members to a group account.


The public encryption key for the account. All messages sent to the account MUST be encrypted under this key. By definition, all data encrypted under this account is encrypted under this key.

User accounts specify two additional public keys, AccountSignature and AccountAuthentication which allow signature and authentication operations under the account context.

Every account contains a set of catalogs and spools that are managed by the service as directed by the contents of the associated Access catalog.

For example, the personal account profile Alice created in

For example, Alice creates a personal account:

Alice> meshman account create

The account profile created is:


3.2. Device

Every Mesh device has a set of private keys that are unique to that device. These keys MAY be installed during manufacture, installed from an external source after manufacture or generated on the device. If the platform capabilities allow, device private keys SHOULD be bound to the device so that they cannot be extracted or exported without substantial effort.

The public keys corresponding to the device private keys are specified in a ProfileDevice. This MUST contain at least the following fields:


The public signature key used to authenticate the profile itself.


Public encryption key used as a share contribution to generation of device encryption keys to be used in the context of an account and to decrypt data during the process of connecting to an account.


Public authentication key used as a share contribution to generation of device authentication keys to be used in the context of an account and to authenticate the device to a service during the process of connecting to an account.


Public signature key used as a share contribution to generation of device signature keys to be used in the context of an account.

For example, the device profile corresponding to one of the devices belonging to Alice is:


3.2.1. Activation

The device private keys are only used to perform cryptographic operations during the process of connecting a device to an account. During that connection process, a threshold key generation scheme is used to generate a second set of device keys bound to the account by combining the base key held by the device with a second device private key provided by the administration device approving the connection of the device to the account. The resulting key is referred to as the device key. The process of combining the base keys with the contributions to form the device keys is called Activation.

For example, Alice connects the device whose profile is shown above to her account:

Alice2> meshman device complete
   Device UDF = MA75-5N5Q-BPQF-5LMP-AN6X-NM4E-U4KS
   Account =

The activation record granting the device rights to operate as a part of the account is:




The Mesh protocols are designed so that there is never a need to export or escrow private keys of any type associated with a device, neither the base key, nor the device key nor the contribution from the administration device.

This approach to device configuration ensures that the keys that are used by the device when operating within the context of the account are entirely separate from those originally provided by the device manufacturer or generated on the device, provided only that the key contributions from the administration device are sufficiently random and unguessable.

3.2.2. Connection Assertion

The administration device combines the public keys specified in the device profile with the public components of the keys specified in the activation record to calculate the public keys of the device operating in the context of the account. These public keys are then used to create at a ConnectionDevice and a ConnectionService assertion signed by the account administration signature key.

The ConnectionDevice assertion is used by the device to authenticate it to other devices connected to the account. This connection assertion specifies the Encryption, Authentication, and Signature keys the device is to use in the context of the account and the list of roles that have been authorized for the device..


The ConnectionService assertion is used to authenticate the device to the Mesh service. In order to allow the assertion to fit in a single packet, it is important that this assertion be as small as possible. Only the Authentication key is specified.

The corresponding ConnectionService assertion is:


The ConnectionDevice assertion MAY be used in the same fashion as an X.509v3/PKIX certificate to mediate interactions between devices connected to the same account without the need for interaction with the Mesh service. Thus, a coffee pot device connected to the account can receive and authenticate instructions issued by a voice recognition device connected to that account.

While the ConnectionDevice assertion MAY be used to mediate external interactions, this approach is typically undesirable as it provides the external parties with visibility to the internal configuration of the account, in particular which connected devices are being used on which occasions. Furthermore, the lack of the need to interact with the service means that the service is necessarily unable to mediate the exchange and enforce authorization policy on the interactions.

Device keys are intended to be used to secure communications between devices connected to the same account. All communication between Mesh accounts SHOULD be mediated by a Mesh service. This enables abuse mitigation by applying access control to every outbound and every inbound message.

3.3. Service

Mesh services are described by a ProfileService. This specifies the encryption, and signature authentication keys used to interact with the abstract service.


Since Mesh accounts and services are both abstract constructs, they cannot interact directly. A device connected to an account can only interact with a service by interacted with a device authorized to provide services on behalf of one or more accounts connected to the service. Such a device is called a Mesh Host.

Mesh hosts MAY be managed using the same ProfileDevice and device connection mechanism provided for management of user devices or by whatever other management protocols prove convenient. The only part of the Service/Host interaction that is visible to devices connected to a profile and to hosts connected to other services is the ConnectionHost structure that describes the set of device keys to use in interactions with that specific host.


Mesh Services MAY make use of the profile and activation mechanism used to connect devices to accounts to manage the connection of hosts to services. But this is optional. It is never necessary for a device to publish a ProfileHost assertion.

4. Catalogs

Catalogs track sets of persistent objects associated with a Mesh Service Account. The Mesh Service has no access to the entries in any Mesh catalog except for the Device and Contacts catalog which are used in device authentication and authorization of inbound messages.

Each Mesh Catalog managed by a Mesh Account has a name of the form:


Where <prefix> is the IANA assigned service name. The assigned service name for the Mathematical Mesh is mmm. Thus, all catalogs specified by the Mesh schema have names prefixed with the sequence mmm_.

The following catalogs are currently specified within the Mathematical Mesh.

Access: mmm_Access

Describes access control policy for performing operations on the account. The Access catalog is the only Mesh catalog whose contents are readable by the Mesh Service under normal circumstances.

Application: mmm_Application

Describes configuration information for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) and SSH and for the MeshAccount application itself.

Bookmark: mmm_Bookmark

Describes Web bookmarks and other citations allowing them to be shared between devices connected to the profile.

Contact: mmm_Contact

Describes logical and physical contact information for people and organizations.

Credential: mmm_Credential

Describes credentials used to access network resources.

Device: mmm_Device

Describes the set of devices connected to the account and the permissions assigned to them

Network: mmm_Network

Describes network settings such as WiFi access points, IPSEC and TLS VPN configurations, etc.

Member: mmm_Member

Describes the set of members connected to a group account.

Publication: mmm_Publication

Describes data published under the account context. The data MAY be stored in the publication catalog itself or on a separate service (e.g. a Web server).

Task: mmm_CatalogTask

Describes tasks assigned to the user including calendar entries and to do lists.

The Access, and Publication catalogs are used by the service in certain Mesh Service Protocol interactions. The Device and Member catalogs are used to track the connection of devices to a user account and members to a group for administrative purposes. These interactions are further described below.

In many cases, the Mesh Catalog offers capabilities that represent a superset of the capabilities of an existing application. For example, the task catalog supports the appointment tracking functions of a traditional calendar application and the task tracking function of the traditional 'to do list' application. Combining these functions allows tasks to be triggered by other events other than the passage of time such as completion of other tasks, geographical presence, etc.

In such cases, the Mesh Catalog entries are designed to provide a superset of the data representation capabilities of the legacy formats and (where available) recent extensions. Where a catalog entry is derived from input presented in a legacy format, the original data representation MAY be attached verbatim to facilitate interoperability.

4.1. Access

The access catalog mmm_Access contains a list of access control entries providing authorization to devices authenticated by a particular credential. The access catalog provides information that is necessary for the Mesh Service to act on behalf of the user. It is therefore necessary for the service to be able to decrypt entries in the catalog.

The entries in the catalog have type CatalogedAccess and specify a capability. The following capabilities are defined:


A capability granting no access rights. May be used to establish a positive statement denying all access.


Authorizes a device authenticated by specified means to request privileged account operations. For example, requesting the status of an account catalog. Also used to provision devices with a copy of their CatalogedDevice entry encrypted under a key held by the device.


Specifies a private key encrypted under the encryption key of the service and criteria specifying the parties authorized to request use of the key.


Authorizes a device authenticated by specified means to obtain a data item.

The Access catalog plays a central role in all operations performed by the service on behalf of the user.

Every access capability is gated by a specified set of authentication criteria. The following authentication criteria are currently defined:

Profile Authentication Key

The account profile authentication key authorizes any account action without the need for an access catalog entry. This capability is normally only used during account binding. Administration devices SHOULD NOT have access to the account profile authentication key after binding is completed.

Device Authentication Key

The service will only perform the operation if the device making the request presents the specified authentication key.

This form of authentication is necessary to restrict access to account operations so that only connected devices can interact with stores, etc.

Account Profile Identifier

The service will only perform the operation if the device making the request presents an authentication key that is credentialed by a connection assertion to the specified account profile.

This form of authentication is necessary to perform administration operations on a group account since it is the account rather than the device that is authorized to perform the operation.

Proof of Knowledge

The service will only perform the operation if proof of knowledge of the identified shared secret is provided.

This form of authentication criteria is used to allow device connection and contact exchange by means of static (i.e. printed) QR codes.

Future: Currently, the set of authentication criteria is limited to direct grants of a single capability to a single specified device or account. This approach may prove to be unnecessarily verbose requiring the same information to be repeated multiple times.

4.1.1. Access Capability

The access capability permits a specified service operation on the account. Optionally, an access capability MAY specify a Data entry encrypted to a key held by the device.

The access capability specifies the set of rights granted to the requester and optionally specifies an EnvelopedCatalogedDevice entry containing the CatalogedDevice entry for the device encrypted under the base encryption key or account encryption key of the device.

The CatalogedDeviceDigest value serves as a tag for the cached data. Operation Rights

The reference code does not currently implement operation rights beyond denying all operations to devices that do not have an access capability entry.

Expansion of the rights handling is planned to permit granular expression of access rights.








Status (of specified catalogs or all catalogs)


Download (of specified catalogs or all catalogs)


Transact (of specified catalogs or all catalogs)


Post outbound message Messaging

The reference code has limited messaging capabilities at present and messaging rights are not specified. The following is a list of possible rights:


Contact messages from the specified subject.


Confirmation messages from the specified subject.


Asynchronous delivery messages (e.g. mail)


Synchronous delivery messages (e.g. chat)


Forward presence request.

The following media are defined


Text that MUST NOT contain links or external references


Text that MAY contain links or external reference


Audio data (e.g. VOIP, voicemail)


Video data


Content containing active code including macros, scripts and executables.

4.1.2. Null Capability

The null capability is used to affirmatively deny access to a function. This allows access requests from previously authorized devices whose credentials have been revoked to be handled separately from requests from devices that were never authorized.

4.1.3. Cryptographic Capabilities

A Mesh Service can perform cryptographic operations on a private key according to access criteria specified by the user. This capability is used to support use of threshold cryptography to mitigate compromise of a particular device or individual. The splitting of a cryptographic key into two or more parts allows the use of that key to be split into two or more roles.

Note that this approach limits rather than eliminates trust in the service. As with services presenting themselves as 'zero trust', a Mesh service becomes a trusted service after a sufficient number of breaches in other parts of the system have occurred. And the user trusts the service to provide availability of the service.

A Mesh Service MAY also offer to perform private key operations for other purposes. An embargo agent might offer to decrypt data under a private key but only after a specified date and time. An expiry agent might offer to decrypt data but only before a specified date and time. Such services MAY be reserved to the customers of a specified service or provided to the general public. Users of such services MAY combine key services provided by multiple service providers using threshold techniques to achieve separation of roles.

Since a service might not willingly co-operate with an account transfer request, extension of the Mesh service protocol will be required to enable threshold sharing of the keys required to effect account transfer. This would require one administration device to act as a proxy for threshold signature etc. operations being requested by another administration device. While implementation of such a scheme to support this limited function could be achieved with little difficulty, such a scheme might not support the wider range of peer-to-peer threshold capabilities that might be useful. For example, the confirmation protocol might be modified so that instead of merely providing non-repudiable evidence of the user's response to a request, the confirmation device served as a policy enforcement point through control of a necessary threshold share.

The following service cryptographic operations are specified: Threshold Key Share

A private key share s, held by the service is split into key shares x, y such that a = x + y. One key share is encrypted under a decryption key held by the service. The other is encrypted under a public key specified by the party making the request.

This operation is not currently implemented in the Reference code. When implemented, it will allow the functions of the administration device to be threshold shared between the device and the service, thus allowing the administration capability to be revoked if the device is lost, stolen or otherwise compromised.

Implementation of this capability is expected to be based on the scheme described in . [draft-komlo-frost] Key Agreement

A private key share s, held by the service is used to calculate the value (sl + c).P where l, c are integers specified by the requestor and P is a point on the curve.

This operation is used Threshold Signature

A private key share s, held by the service is used to calculate a contribution to a threshold signature scheme.

The implementation of the cryptographic operations described above is described in [draft-hallambaker-threshold].

Implementation of signatures is not currently covered pending completion of [draft-irtf-cfrg-frost]. Fair Exchange

Perform a Micali Fair Exchange trusted intermediary operation.

On receipt of a signature SIGB(Z), where Z=Ek(A, B, M), the service decrypts Z and returns the result to B.

4.1.4. Publication Capability

The publication capability is not currently implemented. Implementation would allow the Claim/PollClaim mechanism to be eliminated in favor of a mechanism capable of re-use for other purposes.

4.2. Application

The application catalog mmm_Application contains CatalogEntryApplication entries which describe the use of specific applications under the Mesh Service Account. Multiple application accounts for a single application MAY be connected to a single Mesh Service Account. Each account being specified in a separate entry.

The CatalogEntryApplication entries only contain configuration information for the application as it applies to the account as a whole. If the application requires separate configuration for individual devices, this is specified in the device activation record.

Two applications are currently defined:


An SMTP email account and associated encryption and signature keys for S/MIME and OpenPGP.


Secure Shell Client.

Accounts MAY specify multiple instances of each but each application instance is considered as describing a single application account. Thus, if Alice has email accounts and, she will have application entries for each. Accounts connected to Alice's Mesh account may be authorized to use either, both or none of the email accounts.

Note: The implementation of these features in the current specification is considered to be a 'proof of concept' rather than a proposed final form. There are many issues that need to be considered when integrating a legacy protocol with extensive deployment into a new platform.

4.2.1. Mail

Mail configuration profiles are described by one or more CatalogEntryApplicationMail entries, one for each email account connected to the Mesh profile. The corresponding activation records for the connected devices contain information used to provide the device with the necessary decryption information.

Entries specify the email account address(es), the inbound and outbound server configuration and the cryptographic keys to be used for S/MIME and OpenPGP encryption.


Note that the inbound and outbound server configuration does not specify the access credentials to be used to access the service. These are specified in the Credential catalog.

Future: The mail application should support automated means of credentialling the public key including obtaining an X.509v3 certificate or uploading the key to a key service.

4.2.2. SSH

SSH configuration profiles are described by entries in multiple catalogs

CatalogedApplicationSsh entries in the Applications catalog.

Specify an SSH client credential or certificate signing credential

CatalogedCredential entries in the Credential catalog.

Specify SSH host keys (i.e. contents of the known hosts file)

CatalogedContact entries in the Contacts catalog.

Specify SSH client keys (i.e. material from which an authorized_key file entry might be constructed).

Future: Client and Host certificates are not currently supported. This is clearly desirable but requires additional implementation considerations.

Future: Provisioning of SSH host private keys is currently out of scope. This is best considered as part of the device provisioning and authorization flow and will lead to entries being created/updated in the device catalog.

A user may have separate SSH configurations for separate purposes within a single Mesh Account. This allows a system administrator servicing multiple clients to maintain separate SSH profiles for each of her customers allowing credentials to be easily (and verifiably) revoked at contract termination.


4.3. Bookmark

The bookmark catalog mmm_bookmark contains CatalogEntryBookmark entries which describe Web bookmarks and other citations allowing them to be shared between devices connected to the profile.

The fields currently supported by the Bookmarks catalog are currently limited to the fields required for tracking Web bookmarks. Specification of additional fields to track full academic citations is a work in progress.


4.4. Contact

The contact catalog mmm_contact contains CatalogEntryContact entries which describe the person, organization or location described.

The fields of the contact catalog provide a superset of the capabilities of vCard [RFC2426].


The Contact catalog is typically used by the MeshService as a source of authorization information to perform access control on inbound and outbound message requests. For this reason, Mesh Service SHOULD be granted read access to the contacts catalog by providing a decryption entry for the service.

4.5. Credential

The credential catalog mmm_credential contains CatalogEntryCredential entries which describe credentials used to access network resources.


Only username/password credentials are stored in the credential catalog. If public key credentials are to be used, these SHOULD be managed as an application profile allowing separate credentials to be created for each device.

4.6. Device

The device catalog mmm_Device contains CatalogEntryDevice entries which describe the devices connected to the account and the permissions assigned to them.

Each device connected to a Mesh Account has an associated CatalogEntryDevice entry that includes the activation and connection records for the account. These records are described in further detail in section ???.

4.7. Network

The network catalog contains CatalogEntryNetwork entries which describe network settings, IPSEC and TLS VPN configurations, etc.


4.8. Publication

[Note, this catalog is obsolete, the functions provided by this catalog are being merged with the Access catalog]

The publication catalog mmm_Publication contains CatalogEntryPublication entries which describe content published through the account.

If the data being published is small, it MAY be specified in the CatalogEntryPublication entry itself as enveloped data. Otherwise a link to the external content is required.

The Publication catalog is currently used to publish two types of data:


Used in the Static QR Code Contact Exchange interaction.

Profile Device

Used in the Preconfigured Device Connection interaction.

The interactions using this published data are described in [draft-hallambaker-mesh-protocol].

>>>> Unfinished SchemaEntryPublication

Missing example 11

4.9. Task

The Task catalog mmm_Task contains CatalogEntryTask entries which describe tasks assigned to the user including calendar entries and to do lists.

The fields of the task catalog currently reflect those offered by the iCalendar specification [RFC5545]. Specification of additional fields to allow task triggering on geographic location and/or completion of other tasks is a work in progress.


5. Spools

Spools are DARE Sequences containing an append only list of messages sent or received by an account. Three spools are currently defined:


Messages sent to the account. These are encrypted under the account encryption keys of the sender and receiver that were current at the time the message was sent.


Messages sent from the account. These are encrypted under the account encryption keys of the sender and receiver that were current at the time the message was sent.


Messages sent from the account for internal use. These are encrypted under the encryption key of the intended recipient alone. This is either the account administration encryption key or a device encryption key.

Every Mesh Message has a unique message identifier. Messages created at the beginning of a new messaging protocol interaction are assigned a random message identifier. Responses to previous messages are assigned message identifiers formed from the message identifier to which they respond by means of a message digest function.

Every Mesh Message stored in a spool is encapsulated in an envelope which bears a unique identifier that is formed by applying a message digest function to the message identifier. Each stored message has an associated state which is initially set to the state Initial and MAY be subsequently altered by one or more MessageComplete messages subsequently appended to the spool. The allowable message states depending upon the spool in question.

5.1. Outbound

The outbound spool stores messages that are to be or have been sent and MessageComplete messages reporting changes to the status of the messages stored on the spool.

Messages posted to the outbound spool have the state Initial, Sent, Received or Refused:


The initial state of a message posted to the spool.


The Mesh Service of the sender has delivered the message to the Mesh Service of the recipient which accepted it.


The Mesh Service of the sender has delivered the message to the Mesh Service of the recipient and the recipient has acknowledged receipt.


The Mesh Service of the sender has delivered the message to the Mesh Service of the recipient which refused to accept it.

MessageComplete messages are only valid when posted to the spool by the service.

5.2. Inbound

The inbound spool stores messages that have been received by the Mesh service servicing the account and MessageComplete messages reporting changes to the status of the messages stored on the spool.

Messages posted to the outbound spool have the state Initial, Read:


The initial state of a message posted to the spool.


The message has been read.

A message previously marked as read MAY be returned to the unread state by marking it as being in the Initial state.

5.3. Local

The local spool stores messages that are used for administrative functions. In normal circumstances, only administrator devices and the Mesh Service require access to the local spool.

The local spool is used to store MessagePin messages used to notify administration devices that a PIN code has been registered for some purpose and RespondConnection messages used to inform a device of the result of a connection request.

The local spool is used in a device connection operation to provide a device with the activation and connection records required to access the service as an authorized client. Servicing these requests requires that the service be able to access messages stored in the spool by envelope id.

Messages posted to the outbound spool have the states Initial, Closed:


The initial state of a message posted to the spool.


The action associated with the message has been completed.

Future: Redefining the role of the Local spool would allow the Claim/PollClaim operations used in device connection to be eliminated and greater consistency achieved between the device connection interactions.

5.4. Log

The log spo

6. Logs

The logging functions are not currently implemented.

Logs are records of events. Mesh logs SHOULD be encrypted and notarized.

The following logs are specified:


A log written by the Mesh Service containing a list of all actions performed on the account


A log written by the Mesh Service containing a list of all exception events such as requests for access that were refused.


A log written by administration devices connected to the account containing a sequence of status entries and cross notarization receipts.

The notary log will perform a particularly important role in future Mesh versions as it provides the ultimate root of trust for the account itself through cross notarization with the account holder's MSP which in turn achieves mutual cross notarization with every other MSP by cross notarizing with the Callsign registry. Thus every Mesh user is cross notarized with every other Mesh user making use of the Callsign registry through a graph with a diameter of 4.

7. Cryptographic Operations

The Mesh makes use of various cryptographic operations including threshold operations. For convenience, these are gathered here and specified as functions that are referenced by other parts of the specification.

7.1. Key Derivation from Seed

Mesh Keys that derived from a seed value use the mechanism described in [draft-hallambaker-mesh-udf]. Use of the keyname parameter allows multiple keys for different uses to be derived from a single key. Thus escrow of a single seed value permits recovery of all the private keys associated with the profile.

The keyname parameter is a string formed by concatenating identifiers specifying the key type, the actor that will use the key and the key operation:

7.2. Message Envelope and Response Identifiers.

Every Mesh message has a unique Message Identifier MessageId. The MakeID() function is used to calculate the value of Envelope Identifier and Response identifier from the message identifier as follows:

static string MakeID(string udf, string content) {
    var (code, bds) = UDF.Parse(udf);
    return code switch
            UdfTypeIdentifier.Digest_SHA_3_512 =>
                bds, content, cryptoAlgorithmId:
            _ => UDF.ContentDigestOfDataString(
            bds, content, cryptoAlgorithmId:

Where the values of content are given as follows:


The proposed IANA content identifier for the Mesh message type.


The proposed IANA content identifier for the Mesh message type.

For example:




7.3. Proof of Knowledge of PIN

Mesh Message classes that are subclasses of MessagePinValidated MAY be authenticated by means of a PIN. Currently two such messages are defined: MessageContact used in contact exchange and RequestConnection message used in device connection.

The PIN codes used to authenticate MessagePinValidated messages are UDF Authenticator strings. The type code of the identifier specifies the algorithm to be used to authenticate the PIN code and the Binary Data Sequence value specifies the key.

The inputs to the PIN proof of knowledge functions are:

PIN: string

A UDF Authenticator. The type code of the identifier specifies the algorithm to be used to authenticate the PIN code and the Binary Data Sequence value specifies the key.

Action: string

A code determining the specific action that the PIN code MAY be used to authenticate. By convention this is the name of the Mesh message type used to perform the action.

Account: string

The account for which the PIN code is issued.

ClientNonce: binary

Nonce value generated by the client using the PIN code to authenticate its message.

PayloadDigest: binary

The PayloadDigest of a DARE Envelope that contains the message to be authenticated. Note that if the envelope is encrypted, this value is calculated over the ciphertext and does not provide proof of knowledge of the plaintext.

The following values of Action are currently defined:


Action info for device PIN


Action info for contact PIN

These inputs are used to derive values as follows:

alg =           UdfAlg (PIN)
pinData =       UdfBDS (PIN)
saltedPINData = MAC (Action, pinData)
saltedPIN =     UDFPresent (HMAC_SHA_2_512 + saltedPINData)
PinId =         UDFPresent (MAC (Account, saltedPINData))

The issuer of the PIN code stores the value saltedPIN for retrieval using the key PinId.

The witness value for a Dare Envelope with payload digest PayloadDigest authenticated by a PIN code whose salted value is saltedPINData, issued by account Account is given by PinWitness() as follows:

witnessData =   Account.ToUTF8() + ClientNonce + PayloadDigest
witnessValue =  MAC (witnessData , saltedPINData)

For example, to generate saltedPIN for the pin ADFR-TEQU-3HJD-IRND-P4TS-CRBD-NI used to authenticate a an action of type Device:

action = message.

alg = UdfAlg (PIN)
    = Authenticator_HMAC_SHA_2_512

hashalg = default (alg, HMAC_SHA_2_512)

pinData = UdfBDS (PIN)
    = System.Byte[]

    = hashalg(pinData, hashalg);
    = System.Byte[]

saltedPIN = UDFPresent (hashalg + saltedPINData)

The PinId binding the pin to the account is

Account =

PinId = UDFPresent (MAC (Account, saltedPINData))

Where MAC(data, key) is the message authentication code algorithm specified by the value of alg.

When an administrative device issues a PIN code, a Message PIN is appended to the local spool. This has the MessageId PinId and specifies the value saltedPIN in the field of that name.

When PIN code authentication is used, a message of type MessagePinValidated specifies the values ClientNonce, PinWitness and PinId in the fields of those names. These values are used to authenticate the inner message data specified by the AuthenticatedData field.

7.4. EARL

The UDF Encrypted Authenticated Resource Locator mechanism is used to publish data and provide means of authentication and access through a static identifier such as a QR code.

This mechanism is used to allow contact exchange by means of a QR code printed on a business card and to connect a device to an account using a static identifier printed on the device in the form of a QR code.

In both cases, the information is passed using the EARL format described in [draft-hallambaker-mesh-udf].

8. Mesh Assertions

Mesh Assertions are signed DARE Envelopes that contain one of more claims. Mesh Assertions provide the basis for trust in the Mathematical Mesh.

Mesh Assertions are divided into two classes. Mesh Profiles are self-signed assertions. Assertions that are not self-signed are called declarations. The only type of declaration currently defined is a Connection Declaration describing the connection of a device to an account.

t r n n s c t t r t V g e v u o e u n i r r B e a y l t r c S A a e n t n e u o S d y r V E o n l e s P s t t m o i v t i e e n u o i f v r e E n n A i A g n c S u e s S n r e v e A c C r S d r n c u a n A t D c t i e p e e r h i a e u i t A e o e u l u n t t e d e c i i o i e l i c u t r P c p u g d t r i a s . a A c a i g o i c i g s u e e D e o t S i D i i i a t n f r g e o c e f P r n e n i V a e f U r d e c e S c v f P s S u l n i n o n c a o l S a D A c n e B t r e c o a i g s o a a i e v a t i h i i B n D a g t d e u r l u
Figure 1: Profiles And Connections

8.1. Encoding

The payload of a Mesh Assertion is a JSON encoded object that is a subclass of the Assertion class which defines the following fields:


An identifier for the assertion.


The date and time at which the assertion was issued or last updated


An assertion may optionally contain one or more notary tokens issued by a Mesh Notary service. These establish a proof that the assertion was signed after the date the notary token was created.


A list of conditions that MAY be used to verify the status of the assertion if the relying party requires.

The implementation of the NotaryToken and Conditions mechanisms is to be specified in [draft-hallambaker-mesh-callsign] at a future date.

Note that the implementation of Conditions differs significantly from that of SAML. Relying parties are required to process condition clauses in a SAML assertion to determine validity. Mesh Relying parties MAY verify the conditions clauses or rely on the trustworthiness of the provider.

The reason for weakening the processing of conditions clauses in the Mesh is that it is only ever possible to validate a conditions clause of any type relative to a ground truth. In SAML applications, the relying party almost invariably has access to an independent source of ground truth. A Mesh device connected to a Mesh Service does not. Thus the types of verification that can be achieved in practice are limited to verifying the consistency of current and previous statements from the Mesh Service.

8.2. Mesh Profiles

Mesh Profiles perform a similar role to X.509v3 certificates but with important differences:

  • Profiles describe credentials, they do not make identity statements
  • Profiles do not expire, there is therefore no need to support renewal processing.
  • Profiles may be modified over time, the current and past status of a profile being recorded in an append only log.

Profiles provide the axioms of trust for the Mesh PKI. Unlike in the PKIX model in which all trust flows from axioms of trust held by a small number of Certificate Authorities, every part in the Mesh contributes their own axiom of trust.

It should be noted however that the role of Certificate Authorities is redefined rather than eliminated. Rather than making assertions whose subject is represented by identities which are inherently mutable and subjective, Certificate Authorities can now make assertions about immutable cryptographic keys.

Every Profile MUST contain a SignatureKey field and MUST be signed by the key specified in that field.

A Profile is valid if and only if:

  • There is a SignatureKey field.
  • The profile is signed under the key specified in the SignatureKey field.

A profile has the status current if and only if:

  • The Profile is valid
  • Every Conditions clause in the profile is understood by the relying party and evaluates to true.

8.3. Mesh Connections

A Mesh connection is an assertion describing the connection of a device or a member to an account.

Mesh connections provide similar functionality to 'end-entity' certificates in PKIX but with the important proviso that they are only used to provide trust between a device connected to an account and the service to which that account is bound and between the devices connected to an account.

A connection is valid with respect to an account with profile P if and only if:

  • The profile P is valid
  • The AuthorityUdf field of the connection is consistent with the UDF of P
  • The profile is signed under the key specified in the AdministrationKey field of P.
  • Any conditions specified in the profile are met

A connection has the status current with respect to an account with profile if and only if:

  • The connection is valid with respect to the account with profile P.
  • The profile P is current.

A device is authenticated with respect to an account with profile P if and only if:

  • The connection is valid with respect to the account with profile P.
  • The device has presented an appropriate proof of knowledge of the DeviceAuthentication key specified in the connection.

8.4. Device Pre-configuration

The DevicePreconfiguration record provides a means of bundling all the information used to preconfigure a device for use in the Mesh. This comprises:

  • The Enveloped ProfileDevice.
  • A ConnectionDevice assertion credentialing the device to the configuration provider Mesh Service.
  • A ConnectionService assertion credentialing the device to the configuration provider Mesh Service.
  • The secret seed used to create the ProfileDevice data.

The DevicePreconfiguration record MAY be used as the means of preconfiguring devices to allow connection to a user's account profile using the Preconfigured/Static QR Code device connection interaction.

For example, Alice's coffee pot was preconfigured for connection to a Mesh account at the factory and the following DevicePreconfiguration record created:


The use of the publication mechanism in device connection is discussed further in [draft-hallambaker-mesh-protocol].

9. Architecture

The Mesh architecture has four principal components:

Mesh Account

A collection of information (contacts, calendar entries, inbound and outbound messages, etc.) belonging to a user who uses the Mesh to management.

Mesh Device Management

The various functions that manage binding of devices to a Mesh to grant access to information and services bound to that account.

Mesh Service

Provides network services through which devices and other Mesh users may interact with a Mesh Account.

Mesh Messaging

An end-to-end secure messaging service that allows short messages (less than 32KB) to be exchanged between Mesh Accounts and between the Mesh devices connected to a particular account.

The separation of accounts and services as separate components is a key distinction between the Mesh and earlier Internet applications. A Mesh account belongs to the owner of the Mesh and not the Mesh Service Provider which the user may change at any time of their choosing.

A Mesh Account May be active or inactive. By definition, an active Mesh account is serviced by exactly one Mesh Service, an inactive Mesh account is not serviced by a Mesh Service. A Mesh Service Provider MAY offer a backup service for accounts hosted by other providers. In this case the backup provider is connected to the account as a Mesh device, thus allowing the backup provider to maintain a copy of the stores contained in the account and facilitating a rapid transfer of responsibility for servicing the account should that be desired. The use of backup providers is described further in [draft-hallambaker-mesh-discovery].

9.1. Mesh Account

Mesh Accounts contains all the stateful information (contacts, calendar entries, inbound and outbound messages, etc.) related to a particular persona used by the owner.

By definition a Mesh Account is active if it is serviced by a Mesh Service and inactive otherwise. A Mesh user MAY change their service provider at any time. An active Mesh Account is serviced by exactly one Mesh Service at once but a user MAY register a 'backup' service provider to their account in the same manner as adding an advice. This ensures that the backup service is pre-populated with all the information required to allow the user to switch to the new provider without interruption of service.

Each Mesh account is described by an Account Profile. Currently separate profile Account Profile are defined for user accounts and group accounts. It is not clear if this distinction is a useful one.

9.1.1. Account Profile

A Mesh account profile provides the axiom of trust for a mesh user. It contains a Master Signature Key and one or more Administration Signature Keys. The unique identifier of the master profile is the UDF of the Master Signature Key.

An Account Profile MUST specify an EscrowEncryption key. This key MAY be used to escrow private keys used for encryption of stored data. They SHOULD NOT be used to escrow authentication keys and MUST NOT be used to escrow signature keys.

A user should not need to replace their account profile unless they intend to establish a separate identity. To minimize the risk of disclosure, the Profile Signature Key is only ever used to sign updates to the account profile itself. This allows the user to secure their Profile Signature Key by either keeping it on hardware token or device dedicated to that purpose or by using the escrow mechanism and paper recovery keys as described in this document. Creating a ProfileMaster

Creating a ProfileMaster comprises the steps of:

  1. Creating a Master Signature key.
  2. Creating an Online Signing Key
  3. Signing the ProfileMaster using the Master Signature Key
  4. Persisting the ProfileMaster on the administration device to the CatalogHost.
  5. (Optional) Connecting at least one Administration Device and granting it the ActivationAdministration activation. Updating a ProfileMaster

Updating a ProfileMaster comprises the steps of:

  1. Making the necessary changes.
  2. Signing the ProfileMaster using the Master Signature Key
  3. Persisting the ProfileMaster on the administration device to the CatalogHost.

9.2. Device Management

Device management allows a collection of devices belonging to a user to function as a single personal Mesh. Two catalogs are used to manage this process:

  • The Access catalog is used to instruct the Mesh Service how to respond to requests from the device.
  • The Device catalog records information for use by administration devices managing the device.

9.2.1. The Device Catalog

Each Mesh Account has a Device Catalog CatalogDevice associated with it. The Device Catalog is used to manage the connection of devices to the Personal Mesh and has a CatalogEntryDevice for each device currently connected to the catalog.

Each Administration Device MUST have access to an up-to-date copy of the Device Catalog in order to manage the devices connected to the Mesh. The Mesh Service protocol MAY be used to synchronize the Device Catalog between administration devices in the case that there is more than one administration device.

The CatalogEntryDevice contains fields for the device profile, device private and device connection.

9.2.2. Mesh Devices

The principle of radical distrust requires us to consider the possibility that a device might be compromised during manufacture. Once consequence of this possibility is that when an administration device connects a new device to a user's personal Mesh, we cannot put our full trust in either the device being connected or the administration device connecting it.

This concern is resolved by (at minimum) combining keying material generated from both sources to create the keys to be used in the context of the user's personal Mesh with the process being fully verified by both parties.

Additional keying material sources could be added if protection against the possibility of compromise at both devices was required but this is not supported by the current specifications.

A device profile provides the axiom of trust and the key contributions of the device. When bound to an account, the base keys specified in the Device Profile are combined with the key data provided in the Activation device to construct the keys the device will use in the context of the account.

e i h n i D f g u t t u B n s n e h e v s o n n n t r c i i c c r a e e a B t e o i i v o c o o y r i S e v e e i S g r i P c i i n D e A l a c p i t i y o n c n u c t D v v t e s e v t t p c e n A i n e o u e e D A r i B E a n i a D e n i c e e c t t o t c e a t i v D C e a E n a
Figure 2: Mapping of Device Profile and Device Private to Device Connection Keys.

Unless exceptional circumstances require, a device should not require more than one Device profile even if the device supports use by multiple users under different accounts. But a device MAY have multiple profiles if this approach is more convenient for implementation. Creating a ProfileDevice

Creating a ProfileDevice comprises the steps of:

  1. Creating the necessary key
  2. Signing the ProfileDevice using the Master Signature Key
  3. Once created, a ProfileDevice is never changed. In the unlikely event that any modification is required, a completely new ProfileDevice MUST be created. Connection to a Meh Account

Devices are only connected to a personal Mesh by an administration device. This comprises the steps of:

  1. Generating the PrivateDevice keys.
  2. Creating the ConnectionDevice data from the public components of the ProfileDevice and PrivateDevice keys and signing it using the administration key.
  3. Creating the Activations for the device and signing them using the administration key.
  4. Creating the CatalogEntryDevice for the device and adding it to the CatalogDevice of the account.
  5. Creating an AccessCapability granting the necessary access rights for the device and adding that to the CatalogAccess of the account.

These steps are usually performed through use of the Mesh Protocol Connection mechanism. However, Mesh clients MAY support additional mechanisms as circumstances require provided that the appropriate authentication and private key protection controls are provided.

9.3. Mesh Services

A Mesh Service provides one or more Mesh Hosts that support Mesh Accounts through the Mesh Web Service Protocol.

Mesh Services and Hosts are described by Service Profiles and Host Profiles. The means by which services manage the hosts through which they provide service is outside the scope of this document.

As with a Device connected to a Mesh Account, a the binding of a Host to the service it supports is described by a connection record:

t r A y s t g r r i n D B A c o s e S v e e v i V s i r i y i t f r e i u a i n l d s c P i . l s p n i t t l B c t e a r e a n l t t u c g g c e e n r g u E i o e i i r t l o i e e n a e e A n c i H n i c i e e e i t V t t D i a a S n S S a i e c S a t C c n r p h r u o t i t d r r a o E V i t h S t d a e r a r e e n e t n S l i t m i e g r u g o c i t H l r o e f r a n e o B v n u e c r P r u o d a n s e d s n e S v y A o e v n i e e f g e s n e n e a n e S i e P P S s i u r t a D c p f i S a o S E i n u v u u o s o g e o r v r c u A
Figure 3: Service Profile and Delegated Host Assertion.

The credentials provided by the ProfileService and ProfileHost are distinct from those provided by the WebPKI that typically services TLS requests. WebPKI credentials provide service introduction and authentication while a Mesh ProfileHost only provides authentication.

Unless exceptional circumstances require, a service should not need to revise its Service Profile unless it is intended to change its identity. Service Profiles MAY be countersigned by Trusted Third Parties to establish accountability.

9.4. Mesh Messaging

Mesh Messaging is an end-to-end secure messaging system used to exchange short (32KB) messages between Mesh devices and services. In cases where exchange of longer messages is required, Mesh Messaging MAY be used to provide a control plane to advise the intended message recipient(s) of the type of data being offered and the means of retrieval (e.g an EARL).

All communications between Mesh accounts takes the form of a Mesh Message carried in a Dare Envelope. Mesh Messages are stored in two spools associated with the account, the SpoolOutbound and the SpoolInbound containing the messages sent and received respectively.

This document only describes the representation of the messages within the message spool. The Mesh Service protocol by which the messages are exchanged between devices and services and between services is described in [draft-hallambaker-mesh-protocol].

9.4.1. Message Status

As previously described in section ###, every message stored in a spool has a specified state. The range of allowable states is defined by the message type. New message states MAY be defined for new message types as they are defined.

By default, messages are appended to a spool in the Initial state, but a spool entry MAY specify any state that is valid for that message type.

The state of a message is changed by appending a completion message to the spool as described in [draft-hallambaker-mesh-protocol].

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.

9.4.2. Four Corner Model

A four-corner messaging model is enforced. Mesh Services only accept outbound messages from devices connected to accounts that it services. Inbound messages are only accepted from other Mesh Services. This model enables access control at both the outbound and inbound services

B M P M P A e l i c e ' s b ' l B o c o A s S S i b
Figure 4: Four Corner Messaging Model

The outbound Mesh Service checks to see that the request to send a message does not violate its acceptable use policy. Accounts that make a large number of message requests that result in complaints SHOULD be subject to consequences ranging from restriction of the number and type of messages sent to suspending or terminating messaging privileges. Services that fail to implement appropriate controls are likely to be subject to sanctions from either their users or from other services.

S i p s A e y d a t l A s e c c P i M M i A p e e s g e l e i ' S r o v p l c o
Figure 5: Performing Access Control on Outbound Messages

The inbound Mesh Service also checks to see that messages received are consistent with the service Acceptable Use Policy and the user's personal access control settings.

Mesh Services that fail to police abuse by their account holders SHOULD be subject to consequences in the same fashion as account holders.

e t y ' A d M e a e c M S p c b i e c a g B b s B e s y l P c P i o M o b i o e g S t e o o s s B l s P
Figure 6: Performing Access Control on Inbound Messages

9.4.3. Traffic Analysis

The Mesh Messaging protocol as currently specified provides only limited protection against traffic analysis attacks. The use of TLS to encrypt communication between Mesh Services limits the effectiveness of na?ve traffic analysis mechanisms but does not prevent timing attacks unless dummy traffic is introduced to obfuscate traffic flows.

The limitation of the message size is in part intended to facilitate use of mechanisms capable of providing high levels of traffic analysis such as mixmaster and onion routing but the current Mesh Service Protocol does not provide support for such approaches and there are no immediate plans to do so.

10. Publications

Static QR codes MAY be used to allow contact exchange or device connection. In either case, the QR code contains an EARL providing the means of locating, decrypting and authenticating the published data.

The use of EARLs as a means of publishing encrypted data and the use of EARLs for location, decryption and authentication is discussed in [draft-hallambaker-mesh-dare] .

10.2. Contact Exchange

When used for contact exchange, the envelope payload is a CatalogedContact record.

Besides allowing for exchange of contact information on a business card, a user might have their contact information printed on personal property to facilitate return of lost property.

11. Schema

11.1. Shared Classes

The following classes are used as common elements in Mesh profile specifications.

11.1.2. Structure: KeyData

The KeyData class is used to describe public key pairs and trust assertions associated with a public key.

Udf: String (Optional)

UDF fingerprint of the public key parameters

X509Certificate: Binary (Optional)

List of X.509 Certificates

X509Chain: Binary [0..Many]

X.509 Certificate chain.

X509CSR: Binary (Optional)

X.509 Certificate Signing Request.

NotBefore: DateTime (Optional)

If present specifies a time instant that use of the private key is not valid before.

NotOnOrAfter: DateTime (Optional)

If present specifies a time instant that use of the private key is not valid on or after.

11.1.3. Structure: CompositePrivate

Inherits: Key
DeviceKeyUdf: String (Optional)

UDF fingerprint of the bound device key (if used).

11.2. Assertion classes

Classes that are derived from an assertion.

11.2.1. Structure: Assertion

Parent class from which all assertion classes are derived

Names: String [0..Many]

Fingerprints of index terms for profile retrieval. The use of the fingerprint of the name rather than the name itself is a precaution against enumeration attacks and other forms of abuse.

Updated: DateTime (Optional)

The time instant the profile was last modified.

NotaryToken: String (Optional)

A Uniform Notary Token providing evidence that a signature was performed after the notary token was created.

11.2.2. Structure: Condition

Parent class from which all condition classes are derived.

[No fields]

11.2.3. Base Classes

Abstract classes from which the Profile, Activation and Connection classes are derrived.

11.2.4. Structure: Connection

Inherits: Assertion
SubjectUdf: String (Optional)

UDF of the connection target.

AuthorityUdf: String (Optional)

UDF of the connection source.

11.2.5. Structure: Activation

Inherits: Assertion

Contains the private activation information for a Mesh application running on a specific device

ActivationKey: String (Optional)

Secret seed used to derive keys that are not explicitly specified.

Entries: ActivationEntry [0..Many]

Activation of named resources.

11.2.6. Structure: ActivationEntry

Resource: String (Optional)

Name of the activated resource

Key: KeyData (Optional)

The activation key or key share

11.2.7. Mesh Profile Classes

Classes describing Mesh Profiles. All Profiles are Assertions derrived from Assertion.

11.2.8. Structure: Profile

Inherits: Assertion

Parent class from which all profile classes are derived

ProfileSignature: KeyData (Optional)

The permanent signature key used to sign the profile itself. The UDF of the key is used as the permanent object identifier of the profile. Thus, by definition, the KeySignature value of a Profile does not change under any circumstance.

11.2.9. Structure: ProfileDevice

Inherits: Profile

Describes a mesh device.

Description: String (Optional)

Description of the device

BaseEncryption: KeyData (Optional)

Base key contribution for encryption keys. Also used to decrypt activation data sent to the device during connection to an account.

BaseAuthentication: KeyData (Optional)

Base key contribution for authentication keys. Also used to authenticate the device during connection to an account.

BaseSignature: KeyData (Optional)

Base key contribution for signature keys.

11.2.10. Structure: ProfileAccount

Base class for the account profiles ProfileUser and ProfileGroup. These subclasses may be merged at some future date.

Inherits: Profile
AccountAddress: String (Optional)

The account address. This is either a DNS service address (e.g. or a Mesh Name (@alice).

ServiceUdf: String (Optional)

The fingerprint of the service profile to which the account is currently bound.

EscrowEncryption: KeyData (Optional)

Escrow key associated with the account.

AccountEncryption: KeyData (Optional)

Key currently used to encrypt data under this profile

AdministratorSignature: KeyData (Optional)

Key used to sign connection assertions to the account.

11.2.11. Structure: ProfileUser

Inherits: ProfileAccount

Account assertion. This is signed by the service hosting the account.

AccountAuthentication: KeyData (Optional)

Key used to authenticate requests made under this user account.

AccountSignature: KeyData (Optional)

Key used to sign data under the account.

11.2.12. Structure: ProfileGroup

Inherits: ProfileAccount

Describes a group. Note that while a group is created by one person who becomes its first administrator, control of the group may pass to other administrators over time.

[No fields]

11.2.13. Structure: ProfileService

Inherits: Profile

Profile of a Mesh Service

ServiceAuthentication: KeyData (Optional)

Key used to authenticate service connections.

ServiceEncryption: KeyData (Optional)

Key used to encrypt data under this profile

ServiceSignature: KeyData (Optional)

Key used to sign data under the account.

11.2.14. Structure: ProfileHost

Inherits: Profile
KeyAuthentication: KeyData (Optional)

Key used to authenticate service connections.

KeyEncryption: KeyData (Optional)

Key used to pass encrypted data to the device such as a

11.2.15. Connection Assertions

Connection assertions are used to authenticate and authorize interactions between devices and the service currently servicing the account. They SHOULD NOT be visible to external parties.

11.2.16. Structure: ConnectionDevice

Inherits: Connection

Connection assertion used to authenticate service requests made by a device.

AccountAddress: String (Optional)

The account address

DeviceSignature: KeyData (Optional)

The signature key for use of the device under the profile

DeviceEncryption: KeyData (Optional)

The encryption key for use of the device under the profile

DeviceAuthentication: KeyData (Optional)

The authentication key for use of the device under the profile

11.2.17. Structure: ConnectionApplication

Inherits: Connection

Connection assertion stating that a particular device is

[No fields]

11.2.18. Structure: ConnectionGroup

Describes the connection of a member to a group.

Inherits: Connection

[No fields]

11.2.19. Structure: ConnectionService

Inherits: Connection

[No fields]

11.2.20. Structure: ConnectionHost

Inherits: Connection

[No fields]

11.2.22. Structure: ActivationDevice

Contains activation data for device specific keys used in the context of a Mesh account.

Inherits: Activation
AccountUdf: String (Optional)

The UDF of the account

11.2.23. Structure: ActivationAccount

Inherits: Activation
ProfileSignature: KeyData (Optional)

Grant access to profile online signing key used to sign updates to the profile.

AdministratorSignature: KeyData (Optional)

Grant access to Profile administration key used to make changes to administrator catalogs.

AccountEncryption: KeyData (Optional)

Grant access to ProfileUser account encryption key

AccountAuthentication: KeyData (Optional)

Grant access to ProfileUser account authentication key

AccountSignature: KeyData (Optional)

Grant access to ProfileUser account signature key

11.2.24. Structure: ActivationApplication

Inherits: Activation

[No fields]

11.3. Data Structures

Classes describing data used in cataloged data.

11.3.1. Structure: Contact

Inherits: Assertion

Base class for contact entries.

Id: String (Optional)

The globally unique contact identifier.

Anchors: Anchor [0..Many]

Mesh fingerprints associated with the contact.

NetworkAddresses: NetworkAddress [0..Many]

Network address entries

Locations: Location [0..Many]

The physical locations the contact is associated with.

Roles: Role [0..Many]

The roles of the contact

Bookmark: Bookmark [0..Many]

The Web sites and other online presences of the contact

Sources: TaggedSource [0..Many]

Source(s) from which this contact was constructed.

11.3.2. Structure: Anchor

Trust anchor

Udf: String (Optional)

The trust anchor.

Validation: String (Optional)

The means of validation.

11.3.3. Structure: TaggedSource

Source from which contact information was obtained.

LocalName: String (Optional)

Short name for the contact information.

Validation: String (Optional)

The means of validation.

BinarySource: Binary (Optional)

The contact data in binary form.

EnvelopedSource: Enveloped (Optional)

The contact data in enveloped form. If present, the BinarySource property is ignored.

11.3.4. Structure: ContactGroup

Inherits: Contact

Contact for a group, including encryption groups.

[No fields]

11.3.5. Structure: ContactPerson

Inherits: Contact
CommonNames: PersonName [0..Many]

List of person names in order of preference

11.3.6. Structure: ContactOrganization

Inherits: Contact
CommonNames: OrganizationName [0..Many]

List of person names in order of preference

11.3.7. Structure: OrganizationName

The name of an organization

Inactive: Boolean (Optional)

If true, the name is not in current use.

RegisteredName: String (Optional)

The registered name.

DBA: String (Optional)

Names that the organization uses including trading names and doing business as names.

11.3.8. Structure: PersonName

The name of a natural person

Inactive: Boolean (Optional)

If true, the name is not in current use.

FullName: String (Optional)

The preferred presentation of the full name.

Prefix: String (Optional)

Honorific or title, E.g. Sir, Lord, Dr., Mr.

First: String (Optional)

First name.

Middle: String [0..Many]

Middle names or initials.

Last: String (Optional)

Last name.

Suffix: String (Optional)

Nominal suffix, e.g. Jr., III, etc.

PostNominal: String (Optional)

Post nominal letters (if used).

11.3.9. Structure: NetworkAddress

Provides all means of contacting the individual according to a particular network address

Inactive: Boolean (Optional)

If true, the name is not in current use.

Address: String (Optional)

The network address, e.g.

NetworkCapability: String [0..Many]

The capabilities bound to this address.

EnvelopedProfileAccount: Enveloped (Optional)

The account profile

Protocols: NetworkProtocol [0..Many]

Public keys associated with the network address

11.3.10. Structure: NetworkProtocol

Protocol: String (Optional)

The IANA protocol|identifier of the network protocols by which the contact may be reached using the specified Address.

11.3.11. Structure: Role

OrganizationName: String (Optional)

The organization at which the role is held

Titles: String [0..Many]

The titles held with respect to that organization.

Locations: Location [0..Many]

Postal or physical addresses associated with the role.

11.3.12. Structure: Location

Appartment: String (Optional)
Street: String (Optional)
District: String (Optional)
Locality: String (Optional)
County: String (Optional)
Postcode: String (Optional)
Country: String (Optional)

11.3.13. Structure: Bookmark

Uri: String (Optional)
Title: String (Optional)
Role: String [0..Many]

11.3.14. Structure: Reference

MessageId: String (Optional)

The received message to which this is a response

ResponseId: String (Optional)

Message that was generated in response to the original (optional).

Relationship: String (Optional)

The relationship type. This can be Read, Unread, Accept, Reject.

11.3.15. Structure: Task

Key: String (Optional)

Unique key.

Start: DateTime (Optional)
Finish: DateTime (Optional)
StartTravel: String (Optional)
FinishTravel: String (Optional)
TimeZone: String (Optional)
Title: String (Optional)
Description: String (Optional)
Location: String (Optional)
Trigger: String [0..Many]
Conference: String [0..Many]
Repeat: String (Optional)
Busy: Boolean (Optional)

11.4. Catalog Entries

11.4.1. Structure: CatalogedEntry

Base class for cataloged Mesh data.

Labels: String [0..Many]

The set of labels describing the entry

11.4.2. Structure: CatalogedDevice

Inherits: CatalogedEntry

Public device entry, indexed under the device ID Hello

Udf: String (Optional)

UDF of the signature key of the device in the Mesh

DeviceUdf: String (Optional)

UDF of the offline signature key of the device

SignatureUdf: String (Optional)

UDF of the account online signature key

EnvelopedProfileUser: Enveloped (Optional)

The Mesh profile

EnvelopedProfileDevice: Enveloped (Optional)

The device profile

EnvelopedConnectionUser: Enveloped (Optional)

The public assertion demonstrating connection of the Device to the Mesh

EnvelopedActivationDevice: Enveloped (Optional)

The activation of the device within the Mesh account

EnvelopedActivationAccount: Enveloped (Optional)

The activation of the device within the Mesh account

EnvelopedActivationApplication: Enveloped [0..Many]

Application activations granted to the device.

11.4.3. Structure: CatalogedPublication

Inherits: CatalogedEntry

A publication.

Id: String (Optional)

Unique identifier code

Authenticator: String (Optional)

The witness key value to use to request access to the record.

EnvelopedData: DareEnvelope (Optional)

Dare Envelope containing the entry data. The data type is specified by the envelope metadata.

NotOnOrAfter: DateTime (Optional)

Epiration time (inclusive)

11.4.4. Structure: CatalogedCredential

Inherits: CatalogedEntry
Protocol: String (Optional)
Service: String (Optional)
Username: String (Optional)
Password: String (Optional)

11.4.5. Structure: CatalogedNetwork

Inherits: CatalogedEntry
Protocol: String (Optional)
Service: String (Optional)
Username: String (Optional)
Password: String (Optional)

11.4.6. Structure: CatalogedContact

Inherits: CatalogedEntry
Key: String (Optional)

Unique key.

Self: Boolean (Optional)

If true, this catalog entry is for the user who created the catalog.

11.4.7. Structure: CatalogedAccess

Inherits: CatalogedEntry

[No fields]

11.4.8. Structure: CryptographicCapability

Id: String (Optional)

The identifier of the capability. If this is a user capability, MUST match the KeyData identifier. If this is a serviced capability, MUST match the value of ServiceId on the corresponding service capability.

KeyData: KeyData (Optional)

The key that enables the capability

EnvelopedKeyShares: Enveloped [0..Many]

One or more enveloped key shares.

SubjectId: String (Optional)

The identifier of the resource that is controlled using the key.

SubjectAddress: String (Optional)

The address of the resource that is controlled using the key.

11.4.9. Structure: CapabilityDecrypt

Inherits: CryptographicCapability

The corresponding key is a decryption key

[No fields]

11.4.10. Structure: CapabilityDecryptPartial

Inherits: CapabilityDecrypt

The corresponding key is an encryption key

ServiceId: String (Optional)

The identifier used to claim the capability from the service.[Only present for a partial capability.]

ServiceAddress: String (Optional)

The service account that supports a serviced capability. [Only present for a partial capability.]

11.4.11. Structure: CapabilityDecryptServiced

Inherits: CapabilityDecrypt

The corresponding key is an encryption key

AuthenticationId: String (Optional)

UDF of trust root under which request to use a serviced capability must be authorized. [Only present for a serviced capability]

11.4.12. Structure: CapabilitySign

Inherits: CryptographicCapability

The corresponding key is an administration key

[No fields]

11.4.13. Structure: CapabilityKeyGenerate

Inherits: CryptographicCapability

The corresponding key is a key that may be used to generate key shares.

[No fields]

11.4.14. Structure: CapabilityFairExchange

Inherits: CryptographicCapability

The corresponding key is a decryption key to be used in accordance with the Micali Fair Electronic Exchange with Invisible Trusted Parties protocol.

[No fields]

11.4.15. Structure: CatalogedBookmark

Inherits: CatalogedEntry
Uri: String (Optional)
Title: String (Optional)
Path: String (Optional)

11.4.16. Structure: CatalogedTask

Inherits: CatalogedEntry
EnvelopedTask: Enveloped (Optional)
Title: String (Optional)
Key: String (Optional)

Unique key.

11.4.17. Structure: CatalogedApplication

Inherits: CatalogedEntry
Key: String (Optional)
EnvelopedCapabilities: DareEnvelope [0..Many]

Enveloped keys for use with Application

11.4.18. Structure: CatalogedMember

ContactAddress: String (Optional)
MemberCapabilityId: String (Optional)
ServiceCapabilityId: String (Optional)
Inherits: CatalogedEntry

11.4.19. Structure: CatalogedGroup

Inherits: CatalogedApplication
EnvelopedProfileGroup: Enveloped (Optional)

The Mesh profile

EnvelopedActivationAccount: Enveloped (Optional)

The activation of the device within the Mesh account

11.4.20. Structure: CatalogedApplicationSSH

Inherits: CatalogedApplication

[No fields]

11.4.21. Structure: CatalogedApplicationMail

Inherits: CatalogedApplication

[No fields]

11.4.22. Structure: CatalogedApplicationNetwork

Inherits: CatalogedApplication

[No fields]

11.5. Publications

11.5.1. Structure: DevicePreconfiguration

A data structure that is passed

EnvelopedProfileDevice: Enveloped (Optional)

The device profile

EnvelopedConnectionDevice: Enveloped (Optional)

The device connection

ConnectUri: String (Optional)

The connection URI. This would normally be printed on the device as a QR code.

11.6. Messages

11.6.1. Structure: Message

MessageId: String (Optional)

Unique per-message ID. When encapsulating a Mesh Message in a DARE envelope, the envelope EnvelopeID field MUST be a UDF fingerprint of the MessageId value.

Sender: String (Optional)
Recipient: String (Optional)

11.6.2. Structure: MessageError

Inherits: Message
ErrorCode: String (Optional)

11.6.3. Structure: MessageComplete

Inherits: Message
References: Reference [0..Many]

11.6.4. Structure: MessagePinValidated

Inherits: Message
AuthenticatedData: DareEnvelope (Optional)

Enveloped data that is authenticated by means of the PIN

ClientNonce: Binary (Optional)

Nonce provided by the client to validate the PIN

PinId: String (Optional)

Pin identifier value calculated from the PIN code, action and account address.

PinWitness: Binary (Optional)

Witness value calculated as KDF (Device.Udf + AccountAddress, ClientNonce)

11.6.5. Structure: MessagePin

Account: String (Optional)
Inherits: Message
Expires: DateTime (Optional)
Automatic: Boolean (Optional)

If true, authentication against the PIN code is sufficient to complete the associated action without further authorization.

SaltedPin: String (Optional)

PIN code bound to the specified action.

Action: String (Optional)

The action to which this PIN code is bound.

11.6.6. Structure: RequestConnection

Connection request message. This message contains the information

Inherits: MessagePinValidated
AccountAddress: String (Optional)

11.6.7. Structure: AcknowledgeConnection

Connection request message generated by a service on receipt of a valid MessageConnectionRequestClient

Inherits: Message
EnvelopedRequestConnection: Enveloped (Optional)

The client connection request.

ServerNonce: Binary (Optional)
Witness: String (Optional)

11.6.8. Structure: RespondConnection

Respond to RequestConnection message to grant or refuse the connection request.

Inherits: Message
Result: String (Optional)

The response to the request. One of "Accept", "Reject" or "Pending".

CatalogedDevice: CatalogedDevice (Optional)

The device information. MUST be present if the value of Result is "Accept". MUST be absent or null otherwise.

11.6.9. Structure: MessageContact

Inherits: MessagePinValidated
Reply: Boolean (Optional)

If true, requests that the recipient return their own contact information in reply.

Subject: String (Optional)

Optional explanation of the reason for the request.

PIN: String (Optional)

One time authentication code supplied to a recipient to allow authentication of the response.

11.6.10. Structure: GroupInvitation

Inherits: Message
Text: String (Optional)

11.6.11. Structure: RequestConfirmation

Inherits: Message
Text: String (Optional)

11.6.12. Structure: ResponseConfirmation

Inherits: Message
Request: Enveloped (Optional)
Accept: Boolean (Optional)

11.6.13. Structure: RequestTask

Inherits: Message

[No fields]

11.6.14. Structure: MessageClaim

Inherits: Message
PublicationId: String (Optional)
ServiceAuthenticate: String (Optional)
DeviceAuthenticate: String (Optional)
Expires: DateTime (Optional)

11.6.15. Structure: ProcessResult

For future use, allows logging of operations and results

Inherits: Message
Success: Boolean (Optional)
ErrorReport: String (Optional)

The error report code.

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

13. IANA Considerations

All the IANA considerations for the Mesh documents are specified in this document

14. Acknowledgements

A list of people who have contributed to the design of the Mesh is presented in [draft-hallambaker-mesh-architecture].

15. Normative References

Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: Architecture Guide", Work in Progress, Internet-Draft, draft-hallambaker-mesh-architecture-19, , <>.
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Mesh Callsign Service", Work in Progress, Internet-Draft, draft-hallambaker-mesh-callsign-01, , <>.
Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)", Work in Progress, Internet-Draft, draft-hallambaker-mesh-dare-14, , <>.
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: Mesh Discovery Service", Work in Progress, Internet-Draft, draft-hallambaker-mesh-discovery-01, , <>.
Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol Reference", Work in Progress, Internet-Draft, draft-hallambaker-mesh-protocol-12, , <>.
Hallam-Baker, P., "Mathematical Mesh 3.0 Part IX Security Considerations", Work in Progress, Internet-Draft, draft-hallambaker-mesh-security-08, , <>.
Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, Internet-Draft, draft-hallambaker-mesh-udf-15, , <>.
Hallam-Baker, P., "Threshold Modes in Elliptic Curves", Work in Progress, Internet-Draft, draft-hallambaker-threshold-06, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

16. Informative References

Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft-hallambaker-mesh-developer-10, , <>.
Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood, "Two-Round Threshold Schnorr Signatures with FROST", Work in Progress, Internet-Draft, draft-irtf-cfrg-frost-04, , <>.
Komlo, C. and I. Goldberg, "FROST: Flexible Round-Optimized Schnorr Threshold Signatures", Work in Progress, Internet-Draft, draft-komlo-frost-00, , <>.
Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, DOI 10.17487/RFC2426, , <>.
Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, , <>.