Internet-Draft Mesh Schema Reference November 2020
Hallam-Baker Expires 6 May 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-hallambaker-mesh-schema
Published:
Intended Status:
Informational
Expires:
Author:
P. M. Hallam-Baker
ThresholdSecrets.com

Mathematical Mesh 3.0 Part IV: Schema Reference

Abstract

The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.

[Note to Readers]

Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.

This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 May 2021.

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 entry and messages in 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 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:

ProfileUser

Describes a user account.

ProfileGroup

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

Both types of profile specify the following fields:

ProfileSignature

The public signature key used to authenticate the profile itself

AccountAddress

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

ServiceUdf

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

AdministratorSignature

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.

AccountEncryption

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 is:

{
  "ProfileUser":{
    "ProfileSignature":{
      "Udf":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"LP6f4A0WTGxBGwVQxHEdm0nZEWk3_OlsDscWs9QjGMT82ka
  7_TDJEqQ_pGto8260PD7AXEdsxUUA"}}},
    "AccountAddress":"alice@example.com",
    "ServiceUdf":"MBSL-H45P-PM3W-NTYI-NMKG-L46T-5HWM",
    "AccountEncryption":{
      "Udf":"MC2D-WX25-JK5S-6R7R-NPK5-XNQ7-O334",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"aBbYhik-VDUPmZ3Xh7N5Lppkn_f504MN6-YWmMnQAyiIJnK
  aWvPTTA889IgD3dx3GfBHmLj1iXMA"}}},
    "AdministratorSignature":{
      "Udf":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"LP6f4A0WTGxBGwVQxHEdm0nZEWk3_OlsDscWs9QjGMT82ka
  7_TDJEqQ_pGto8260PD7AXEdsxUUA"}}},
    "AccountAuthentication":{
      "Udf":"MAGU-WLGH-QX7L-RQKS-KHP4-C5LR-5RG2",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"yoIi0dvQBNI4UtiUCA5LvYBirDHjlEQXHOgzV4ktsqQKPwh
  -lN4cEjCIinyi8J5GU_R94CF5he0A"}}},
    "AccountSignature":{
      "Udf":"MBVN-UC2H-EKC2-GLZA-CLSC-6XQ2-QZIA",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"EvPYHGRCJsZ0kmbBMu_sxcGuUIOHFXc4iz0oCyY19fpYUG5
  qJyn467Wq85zuVWviBl8zd3-9X_wA"}}}}}

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:

ProfileSignature

The public signature key used to authenticate the profile itself.

BaseEncryption

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.

BaseAuthentication

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.

BaseSignature

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

For example, the device profile corresponding to Alice's coffee pot device is:

{
  "ProfileDevice":{
    "ProfileSignature":{
      "Udf":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"dyQgDeZX0Y7u5FElerLbzFhbGUTj3jrkO5biutnd9CuhtUP
  npNM7UDTk5otmloreiJ9OBln70L0A"}}},
    "BaseEncryption":{
      "Udf":"MAFF-4P54-ORYF-SBAN-6XQ7-CO6S-OXWQ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"7rEjlTclEPAoytZLGJbf5-eO8mBWLlNaevJ3YAt_aRhJAhe
  -ROYL_ASfBuKEL9d0O8pCDlWzwA2A"}}},
    "BaseAuthentication":{
      "Udf":"MANB-DYXE-7CNC-W6LW-3R6I-BLAB-2TKC",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"BoY_wxLtxK1MsFOhOEs8LkY6HY6N6x46i0L_MJLMAMkqwsA
  yiymRk6pV4vvtCc6DzBO8LF_MWYgA"}}},
    "BaseSignature":{
      "Udf":"MAW7-YIO3-5A7M-55YU-OZ7W-BJFT-QTHW",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"Psf8tojE6O4Q7JYBXe4r-bdLQdy4E8tzMTE3ADCs4OwXKyn
  WrvlqO7cyGcX1Wn6bd2V5hLF48R8A"}}}}}

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.

The activation record for Alice's coffee pot device is:

{
  "ActivationDevice":{
    "ActivationKey":"ZAAQ-GBHF-AKLZ-WMGO-NWLQ-CYAB-ZLLY-6MLD-6QYJ-6
MR3-A4OV-YHMH-JLL7-URSL",
    "AccountUdf":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV"}}

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.

The public keys corresponding to the composite keys generated during the connection process are described in a ConnectionUser assertion signed by the administration key of the corresponding account.

The connection record for Alice's coffee pot device is:

{
  "ConnectionDevice":{
    "DeviceSignature":{
      "Udf":"MBTO-NNFK-P6K2-4FW4-WTKW-OLGU-GAZS",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"Ed448",
          "Public":"NXxkDFuagDESh6-FD7LSkkOSVgIW-S4E3TDHR9c5qbW4AUV
  kJMEh1nZlnVO2xwcGI8SNfov6RR8A"}}},
    "DeviceEncryption":{
      "Udf":"MAUU-Q2JT-BHOM-ZEPX-HOFG-XYU7-FGCJ",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"eSh00dco-Ee4X1sb96S9lkcdso7Qu8Uz6NnuDZSu7ww59JJ
  xF7lEZtWkkELe10cGfpeQZ-qxdkYA"}}},
    "DeviceAuthentication":{
      "Udf":"MCAY-A6DR-FSY6-2T4K-UD2B-OJHA-MT3H",
      "PublicParameters":{
        "PublicKeyECDH":{
          "crv":"X448",
          "Public":"XyBegJt8kgVMzFTcQWyathYay6aT5C3ubb_ktZc0Gevcz4x
  u0y9aJlEPNV-siXJxqwdr6bBgySIA"}}}}}

The ConnectionUser 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 ConnectionUser 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.

Since Alice's coffee pot does not require the external communication right, the activation record for the coffee pot does not provide access to the account keys required to perform external communications. Alice's watch device does require access to the account keys so it can receive messages and task updates. But since it is a device that Alice has to carry on her person to use, it is a device that might easily be lost or stolen. Accordingly, the activation record for Alice's watch provides access to the account decryption and signature keys but in the form of threshold key shares mediated by the Mesh service. Thus, Alice's watch can sign and read message sent to the account but only under the control of the Mesh service.

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.

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:

<prefix>_<name>

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, Publication, Device and Member catalogs are involved in Mesh Service Protocol interactions. These interactions are further described in the Protocol Reference [draft-hallambaker-mesh-protocol].

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 granting a party authenticated using a particular cryptographic credential a specific privilege such as:

  • Accept Mesh Messages of particular types
  • Perform an operation on a private key known to the service.

As with the publication catalog, the access catalog provides information that is necessary for the Mesh Service to act on behalf of the user. It is therefore necessary to grant a decryption capability for this catalog during the process of binding the account to a service.

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 separate activation records specified in the corresponding ConnectionDevice.

4.2.1. Mesh Account

Mesh Accounts are described by CatalogEntryAccount entries. The corresponding activation records for the connected devices contain the contributions used to derive the private keys for use of the account.

The CatalogEntryAccount entry is described in the section describing Mesh accounts above.

4.2.2. SSH

SSH configuration profiles are described by CatalogEntryApplicationSSH entries. The corresponding activation records for the connected devices contain the contributions used to derive the private keys.

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.

The SSH profile contains the information that is stored in the known_hosts and authorized_keys files of SSH clients and servers.

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

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.

{
  "CatalogedBookmark":{
    "Uri":"http://www.site1.com",
    "Title":"site1",
    "Path":"Sites.1"}}

4.4. Contact

The contact catalog mmm_contact contains CatalogEntryContact entries which describe

{
  "CatalogedContact":{
    "Key":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
    "Self":true,
    "Contact":{
      "ContactPerson":{
        "Id":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
        "Anchors":[{
            "Udf":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
            "Validation":"Self"}
          ],
        "NetworkAddresses":[{
            "Address":"alice@example.com",
            "EnvelopedProfileAccount":[{
                "EnvelopeID":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
                "dig":"S512",
                "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNQUlILVFG
  Mk0tUFZEMy1OUUpPLUNXR1gtRzY3Uy1KWUVRIiwKICAiTWVzc2FnZVR5cGUiOiAiU
  HJvZmlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCi
  AgIkNyZWF0ZWQiOiAiMjAyMC0xMS0wMlQxNzoyNTo1MVoifQ"},
              "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0
  dXJlIjogewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HN
  jdTLUpZRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUH
  VibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICA
  gICAgIlB1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0Rz
  Y1dzOVFqR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19f
  SwKICAgICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgIC
  AiU2VydmljZVVkZiI6ICJNQlNMLUg0NVAtUE0zVy1OVFlJLU5NS0ctTDQ2VC01SFd
  NIiwKICAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQzJE
  LVdYMjUtSks1Uy02UjdSLU5QSzUtWE5RNy1PMzM0IiwKICAgICAgIlB1YmxpY1Bhc
  mFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgIC
  AiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJhQmJZaGlrLVZEVVB
  tWjNYaDdONUxwcGtuX2Y1MDRNTjYtWVdtTW5RQXlpSUpuS2FXdlBUCiAgVEE4ODlJ
  Z0QzZHgzR2ZCSG1MajFpWE1BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0d
  XJlIjogewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HNj
  dTLUpZRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHV
  ibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAg
  ICAgIlB1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0RzY
  1dzOVFqR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19fS
  wKICAgICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUF
  HVS1XTEdILVFYN0wtUlFLUy1LSFA0LUM1TFItNVJHMiIsCiAgICAgICJQdWJsaWNQ
  YXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgI
  CAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAieW9JaTBkdlFCTk
  k0VXRpVUNBNUx2WUJpckRIamxFUVhIT2d6VjRrdHNxUUtQd2gtbE40YwogIEVqQ0l
  pbnlpOEo1R1VfUjk0Q0Y1aGUwQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6
  IHsKICAgICAgIlVkZiI6ICJNQlZOLVVDMkgtRUtDMi1HTFpBLUNMU0MtNlhRMi1RW
  klBIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
  tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ
  QdWJsaWMiOiAiRXZQWUhHUkNKc1owa21iQk11X3N4Y0d1VUlPSEZYYzRpejBvQ3lZ
  MTlmcFlVRzVxSnluNAogIDY3V3E4NXp1Vld2aUJsOHpkMy05WF93QSJ9fX19fQ",
              {
                "signatures":[{
                    "alg":"S512",
                    "kid":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
                    "signature":"PuG3M10QcqNXxUtJzk83C2LkExhO1jYqfB
  x_pcgl-_MH9lBPdT5JMiNSyVLsHRM9ZMUO-GVcDMiAITPUt5jG6t-GP3-6bdyEd6h
  DKavFUJYr4tWjKvro-3Uh7KP5BvFCz1VNoccCaiNhsrCf6uie4wkA"}
                  ],
                "PayloadDigest":"OmGeYT1GZa5-mNx5fYmK0Jk2AzqPxuEJ-d
  RnTuoPLSgOSjHMzLnu8y1q6NTYxZomMK0ZfkuPtfD9Uyemy-npHQ"}
              ],
            "Protocols":[{
                "Protocol":"mmm"}
              ]}
          ],
        "Sources":[{
            "Validation":"Self",
            "EnvelopedSource":[{
                "dig":"S512",
                "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250
  YWN0UGVyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogI
  CJDcmVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NTFaIn0"},
              "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBb
  ewogICAgICAgICJVZGYiOiAiTUFJSC1RRjJNLVBWRDMtTlFKTy1DV0dYLUc2N1MtS
  llFUSIsCiAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3
  JrQWRkcmVzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJhbGljZUBleGFtcGx
  lLmNvbSIsCiAgICAgICAgIkVudmVsb3BlZFByb2ZpbGVBY2NvdW50IjogW3sKICAg
  ICAgICAgICAgIkVudmVsb3BlSUQiOiAiTUFJSC1RRjJNLVBWRDMtTlFKTy1DV0dYL
  Uc2N1MtSllFUSIsCiAgICAgICAgICAgICJkaWciOiAiUzUxMiIsCiAgICAgICAgIC
  AgICJDb250ZW50TWV0YURhdGEiOiAiZXdvZ0lDSlZibWx4ZFdWSlJDSTZJQ0pOUVV
  sSUxWRkdNazB0VUZaRU15MQogIE9VVXBQTFVOWFIxZ3RSelkzVXkxS1dVVlJJaXdL
  SUNBaVRXVnpjMkZuWlZSNWNHVWlPaUFpVUhKdlptbHNaCiAgVlZ6WlhJaUxBb2dJQ
  0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQWdJa0
  4KICB5WldGMFpXUWlPaUFpTWpBeU1DMHhNUzB3TWxReE56b3lOVG8xTVZvaWZRIn0
  sCiAgICAgICAgICAiZXdvZ0lDSlFjbTltYVd4bFZYTmxjaUk2SUhzS0lDQWdJQ0pR
  Y205bWFXeAogIGxVMmxuYm1GMGRYSmxJam9nZXdvZ0lDQWdJQ0FpVldSbUlqb2dJa
  zFCU1VndFVVWXlUUzFRVmtRekxVNVJTCiAgazh0UTFkSFdDMUhOamRUTFVwWlJWRW
  lMQW9nSUNBZ0lDQWlVSFZpYkdsalVHRnlZVzFsZEdWeWN5STZJSHMKICBLSUNBZ0l
  DQWdJQ0FpVUhWaWJHbGpTMlY1UlVORVNDSTZJSHNLSUNBZ0lDQWdJQ0FnSUNKamNu
  WWlPaUFpUgogIFdRME5EZ2lMQW9nSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk2SUNKT
  VVEWm1ORUV3VjFSSGVFSkhkMVpSZUVoCiAgRlpHMHdibHBGVjJzelgwOXNjMFJ6WT
  Fkek9WRnFSMDFVT0RKcllUZGZWRVJLQ2lBZ1JYRlJYM0JIZEc4NE0KICBqWXdVRVE
  zUVZoRlpITjRWVlZCSW4xOWZTd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2NtVnpjeUk2
  SUNKaGJHbAogIGpaVUJsZUdGdGNHeGxMbU52YlNJc0NpQWdJQ0FpVTJWeWRtbGpaV
  lZrWmlJNklDSk5RbE5NTFVnME5WQXRVCiAgRTB6VnkxT1ZGbEpMVTVOUzBjdFREUT
  JWQzAxU0ZkTklpd0tJQ0FnSUNKQlkyTnZkVzUwUlc1amNubHdkR2wKICB2YmlJNkl
  Ic0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlF6SkVMVmRZTWpVdFNrczFVeTAyVWpkU0xV
  NVFTelV0VwogIEU1Uk55MVBNek0wSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21Gd
  FpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBCiAgZ0lsQjFZbXhwWTB0bGVVVkRSRWdpT2
  lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0kKICBDQWdJQ0F
  nSUNBZ0lsQjFZbXhwWXlJNklDSmhRbUpaYUdsckxWWkVWVkJ0V2pOWWFEZE9OVXh3
  Y0d0dVgyWQogIDFNRFJOVGpZdFdWZHRUVzVSUVhscFNVcHVTMkZYZGxCVUNpQWdWR
  UU0T0RsSlowUXpaSGd6UjJaQ1NHMU1hCiAgakZwV0UxQkluMTlmU3dLSUNBZ0lDSk
  JaRzFwYm1semRISmhkRzl5VTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0EKICBnSUNBaVZ
  XUm1Jam9nSWsxQlNVZ3RVVVl5VFMxUVZrUXpMVTVSU2s4dFExZEhXQzFITmpkVExV
  cFpSVkVpTAogIEFvZ0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS
  0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJWCiAgNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSU
  NBZ0lDSmpjbllpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0kKICBsQjFZbXh
  wWXlJNklDSk1VRFptTkVFd1YxUkhlRUpIZDFaUmVFaEZaRzB3YmxwRlYyc3pYMDlz
  YzBSelkxZAogIHpPVkZxUjAxVU9ESnJZVGRmVkVSS0NpQWdSWEZSWDNCSGRHODRNa
  ll3VUVRM1FWaEZaSE40VlZWQkluMTlmCiAgU3dLSUNBZ0lDSkJZMk52ZFc1MFFYVj
  BhR1Z1ZEdsallYUnBiMjRpT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUEKICBpVFVGSFZ
  TMVhURWRJTFZGWU4wd3RVbEZMVXkxTFNGQTBMVU0xVEZJdE5WSkhNaUlzQ2lBZ0lD
  QWdJQ0pRZAogIFdKc2FXTlFZWEpoYldWMFpYSnpJam9nZXdvZ0lDQWdJQ0FnSUNKU
  WRXSnNhV05MWlhsRlEwUklJam9nZXdvCiAgZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2SU
  NKWU5EUTRJaXdLSUNBZ0lDQWdJQ0FnSUNKUWRXSnNhV01pT2lBaWUKICBXOUphVEJ
  rZGxGQ1RrazBWWFJwVlVOQk5VeDJXVUpwY2tSSWFteEZVVmhJVDJkNlZqUnJkSE54
  VVV0UWQyZwogIHRiRTQwWXdvZ0lFVnFRMGxwYm5scE9FbzFSMVZmVWprMFEwWTFhR
  1V3UVNKOWZYMHNDaUFnSUNBaVFXTmpiCiAgM1Z1ZEZOcFoyNWhkSFZ5WlNJNklIc0
  tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFsWk9MVlZETWtndFJVdERNaTEKICBIVEZwQkx
  VTk1VME10TmxoUk1pMVJXa2xCSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21GdFpY
  Umxjbk1pTwogIGlCN0NpQWdJQ0FnSUNBZ0lsQjFZbXhwWTB0bGVVVkRSRWdpT2lCN
  0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvCiAgZ0lrVmtORFE0SWl3S0lDQWdJQ0FnSU
  NBZ0lDSlFkV0pzYVdNaU9pQWlSWFpRV1VoSFVrTktjMW93YTIxaVEKICBrMTFYM04
  0WTBkMVZVbFBTRVpZWXpScGVqQnZRM2xaTVRsbWNGbFZSelZ4U25sdU5Bb2dJRFkz
  VjNFNE5YcAogIDFWbGQyYVVKc09IcGtNeTA1V0Y5M1FTSjlmWDE5ZlEiLAogICAgI
  CAgICAgewogICAgICAgICAgICAic2lnbmF0dXJlcyI6IFt7CiAgICAgICAgICAgIC
  AgICAiYWxnIjogIlM1MTIiLAogICAgICAgICAgICAgICAgImtpZCI6ICJNQUlILVF
  GMk0tUFZEMy1OUUpPLUNXR1gtRzY3Uy1KWUVRIiwKICAgICAgICAgICAgICAgICJz
  aWduYXR1cmUiOiAiUHVHM00xMFFjcU5YeFV0SnprODNDMkxrRXhoTzFqWXFmQnhfc
  GNnbC1fTUg5bEJQZAogIFQ1Sk1pTlN5VkxzSFJNOVpNVU8tR1ZjRE1pQUlUUFV0NW
  pHNnQtR1AzLTZiZHlFZDZoREthdkZVSllyNHRXCiAgakt2cm8tM1VoN0tQNUJ2RkN
  6MVZOb2NjQ2FpTmhzckNmNnVpZTR3a0EifV0sCiAgICAgICAgICAgICJQYXlsb2Fk
  RGlnZXN0IjogIk9tR2VZVDFHWmE1LW1OeDVmWW1LMEprMkF6cVB4dUVKLWRSblR1b
  1BMU2dPUwogIGpITXpMbnU4eTFxNk5UWXhab21NSzBaZmt1UHRmRDlVeWVteS1ucE
  hRIn1dLAogICAgICAgICJQcm90b2NvbHMiOiBbewogICAgICAgICAgICAiUHJvdG9
  jb2wiOiAibW1tIn1dfV19fQ",
              {
                "signatures":[{
                    "alg":"S512",
                    "kid":"MBVN-UC2H-EKC2-GLZA-CLSC-6XQ2-QZIA",
                    "signature":"ueOrjyE-0-zJ_DRQW-zJIH0ZLcxvsjhzKV
  tNOnUYV116UBm740XP4gfHwkqR1WvL2Lpb25SWi66Aj7lTZtaSOFreEm9i0TgIBco
  g4_O49DFf7s4HK6wo53KUe8J5pbjvYCnY8bsRWA6ZNAtTbyT_YDEA"}
                  ],
                "PayloadDigest":"h4lFjVf0eiHdZT1eg0iBK8eXYAXvB1dLo7
  7beFR8LbEuFULlYds0eGH85HWrcZXyIZtzAZtv866fIqRWI2ARqQ"}
              ]}
          ]}}}}

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.

{
  "CatalogedCredential":{
    "Service":"ftp.example.com",
    "Username":"alice1",
    "Password":"password"}}

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 REF _Ref54628559 \r \h 0.

4.7. Network

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

{
  "CatalogedNetwork":{
    "Service":"myWiFi",
    "Password":"securePassword"}}

4.8. Publication

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

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.

{
  "CatalogedTask":{
    "Title":"SomeItem",
    "Key":"NCYK-YRNO-OHE5-3KZQ-IPS5-T3W4-WFHB"}}

5. Spools

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

Inbound

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.

Outbound

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.

Local

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:

Initial

The initial state of a message posted to the spool.

Sent

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

Received

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

Refused

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:

Initial

The initial state of a message posted to the spool.

Read

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:

Initial

The initial state of a message posted to the spool.

Closed

The action associated with the message has been completed.

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

6.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:

6.2. Message Response Identifier

Every Mesh message has a unique MessageId. When encapsulated in a DARE Envelope, the EnvelopeId field of the envelope header is the UDF Content Digest of the enclosed MessageId as a string:

public static string GetEnvelopeId(string messageID) =>
            UDF.ContentDigestOfUDF(messageID);

When processing a Mesh message results in the creation of a response to the sender, the MessageId of the response is UDF Content Digest of the Binary Data Sequence of the original MessageId:

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

For example:

[To be specified]

6.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:

Table 1
Code Mesh Message Purpose
"MessageContact" MessageContact Contact exchange
"RequestConnection" RequestConnection Device connection

These inputs are used to derive values as follows:

alg = UdfAlg (PIN)
pinData = UdfBDS (PIN)
saltedPINData = MAC (Action, pinData)
saltedPIN = UDFPresent (Authenticator_HMAC_SHA_2_512 + saltedPINData)
PinId = UDFPresent (MAC (Account, saltedPINData))
witnessData = Account.ToUTF8() + ClientNonce + PayloadDigest
witnessValue =  MAC (witnessData , saltedPINData)

Eg.

[To be specified]

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.

[To be specified]

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

6.5. Key Agreement

All Mesh Protocol requests except for the HelloRequest and every response MUST be authenticated under the device key of the host or device making the request.

Initial authentication is achieved by performing a Key agreement under the DeviceAuthentication key of each of the hosts and combining the result with nonce values provided by the requestor and respondent using a KDF function as follows:

Two bindings are currently planned.

DARE Envelope over HTTPS

The request or response is encapsulated in a DARE Envelope that is exchanged by means of a HTTP POST method over a TLS transport. The shared secret is used as the key on Message Authentication Code that authenticates the request payload.

UDP Transport

Presents the same information as for the DARE Envelope over HTTPS case but in a compact encoding using the shared secret and an authenticated encryption scheme to pass the required information.

Once authentication has been performed, the same pair of devices MAY re-authenticate using the previously agreed key. To facilitate stateless implementation, a host specifies an opaque identifier to be used to identify the shared secret on subsequent uses which MAY be used to recover the shared secret from the opaque identifier.

[To be specified]

6.6. Service Cryptographic Operations

A Mesh Service acts as the counterparty for threshold operations allowing mitigation of the risk of compromise of an individual device connected to a user account or an insider threat from an individual member of a group account.

When acting in this role, the Mesh service controls the use of the cryptographic function but does not have the ability to perform the action either by itself or by collaborating with other services to which the account has been bound in the past.

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.

Three service cryptographic operations are currently 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.

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

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] and [draft-hallambaker-threshold-sigs].

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

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

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

Identifier

An identifier for the assertion.

Updated

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

NotaryToken

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.

Conditions

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

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

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

$$$$$$$$$$$ This has plenty or areas that need to be upgraded to the single master/account approach.

The Mesh architecture has four principal components:

Mesh Device Management

Binds a collection of devices that the owner of the Mesh uses together to function as a single personal Mesh.

Mesh Account

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

Mesh Service

Provides a service identifier (e.g. alice@example.com) through which devices and other Mesh users may interact with a Mesh Account.

Mesh Messaging

Allows short messages (less than 32KB) to be exchanged between Mesh devices connected to an account and between Mesh Accounts.

Device management and Accounts components are defined by a data schema alone. The Service and Messaging components are defined by a data schema and a service protocol.

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

8.1. Device Management

Device Management provides the foundation for all Mesh functions allowing a collection of devices belonging to a user to function as a single personal Mesh.

The device management layer of a personal Mesh consists of exactly one Master Profile and a catalog containing the entries describing the connected devices.

8.1.1. Master Profile

A Mesh master 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.

A Master 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.

8.1.1.1. 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.
8.1.1.2. 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.
8.1.1.3. The Device Catalog

Each personal Mesh 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.

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

o S i u v y a n f n t D t v S v p u c t r n t h a o e c t e e t A c t E c D C n t a e g e c r t i i o e g e a i i A i u c n B v n a c v v e i n o i r s a h e o e e D i l c t B a s i t u e i e i D v n i B e c t D c n i s c D i o y E n e P n r i n p t e A a i r e e n o c e o i e n e
Figure 2

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.

The derivation of the Connection encryption and signature keys from the Profile and Private contributions in this example is shown in [draft-hallambaker-mesh-cryptography].

8.1.2.1. 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.
8.1.2.2. Connection to a Personal Mesh

Devices are only connected to a personal Mesh by 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 Personal Mesh.
  5. If the Personal Mesh has accounts that are connected to a Mesh Service, synchronizing the CatalogEntryDevice to those services.

8.2. Mesh Accounts

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

A Mesh Profile MAY be connected to multiple accounts at the same time allowing the user to maintain separate personas for separate purposes.

Unlike traditional Internet application accounts, Mesh accounts are created by and belong to the user, not the Mesh Service provider. A user MAY change their Mesh Service provider at any time and disconnect the profile from all Mesh Services (e.g. to archive the account).

Alice's personal account is connected to two Mesh services:

The account profile specifies the online and offline signature keys used to maintain the profile and the encryption key to be used by the account.

Each device connected to the account requires an activation record. This specifies the key contribtions added to the manufacturer device profile keys:

The resulting key set is specified in the device connection:

All the above plus the ProfileDevice are combined to form the CatalogedDevice entry:

8.2.1. Creating a ProfileAccount

Creating a ProfileAccount comprises the steps of:

  1. [TBS]
  2. .
  3. Signing the ProfileMaster using the Master Signature Key

8.2.2. Connecting a Device to an Account

Adding a device to an account comprises the steps of:

  1. Creating a PrivateAccount instance for the device.
  2. Creating a ConnectionAccountDevice for the device using the public keys from the PrivateAccount instance and the ProfileDevice.
  3. Creating an ActivationAccount for the device containing the PrivateAccount and ConnectionAccountDevice instances.
  4. Adding the ActivationAccount to the CatalogEntryDevice of the device.
  5. If the Personal Mesh has accounts that are connected to a Mesh Service, synchronizing the CatalogEntryDevice to those services.

8.2.3. Binding and Account to a Service

Binding a ProfileAccount to a Mesh Service the steps of:

  1. [TBS]
  2. .
  3. Signing the ProfileMaster using the Master Signature Key

8.3. Mesh Services

A service profile provides the axiom of trust and cryptographic keys for a Mesh Service. A Mesh Service Host SHOULD return a copy of its ProfileHost and the parent ProfileService in response to a Hello transaction request.

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

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.

The service profile

The host also has a profile

And there should be a connection of the host to the service but this isn't implemented yet:

8.3.1. Creating a ProfileService

[TBS]

Creating a ProfileService comprises the steps of:

  1. [TBS]
  2. .
  3. [TBS]
  4. Signing the ProfileMaster using the Master Signature Key

8.3.2. Creating a ProfileHost

Creating a ProfileHost comprises the steps of:

  1. [TBS]
  2. .
  3. [TBS]
  4. Signing the ConnectionHost using the Master Signature Key of the ProfileService.

8.3.3. Creating a ConnectionHost

Creating a ConnectionHost comprises the steps of:

  1. [TBS]
  2. .
  3. Signing the ConnectionHost using the Master Signature Key of the ProfileService.

8.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).

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 s P S i o e B b o ' M P l c S M l c e A ' A B i s
Figure 4

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.

c e i e p l l e r M y l p s e i e g P t c A i i d S s e o o ' A c M S A p v s a
Figure 5

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.

c e e s a c ' c e e t i P y s a b s i o y o e s l t B o S g e o e p d b S l c M s A b o B P M P B i g M
Figure 6

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

9. Mesh Messages

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

One-time use 'PIN' codes are used to provide a means of out of band authentication in many Mesh Message applications. In particular the device connection and contact exchange message flows.

For example, when Alice reads the connection request from the device in the architecture examples, a completion message is added to Alice's inbound spool so that the device is not activated a second time by mistake:

{
  "MessagePin":{
    "MessageId":"ADWE-3XBF-GGLA-AMCX-XVDM-KMXB-BQRN",
    "Account":"alice@example.com",
    "Expires":"2020-11-03T17:25:57Z",
    "Automatic":true,
    "SaltedPin":"ADPA-GPKO-V6TG-BPWJ-42YS-V5K7-NCZD",
    "Action":"Device"}}

The details of the presentation and verification of the PIN code are further described in the section below.

9.2. Completion

Completion messages are dummy messages that are added to a Mesh Spool to change the status of messages previously posted. Any message that is in the inbound spool and has not been erased or redacted MAY be marked as read, unread or deleted. Any message in the outbound spool MAY be marked as sent, received or deleted.

Services MAY erase or redact messages in accordance with local site policy. Since messages are not removed from the spool on being marked deleted, they may be undeleted by marking them as read or unread. Marking a message deleted MAY make it more likely that the Service will purge the message however.

Having processed a message, a completion message is added to the spool so that other devices can see that it has been read.

For example, when Alice's administration device uses the PIN registered above to authenticate a device connection request, a completion message is added to Alice's inbound spool so that the PIN cannot be reused to authenticate a second device:

Missing example 25

9.3. Connection

Connection requests are sent by a device requesting connection to a Mesh Service Account.

The MessageConnectionRequest is originally sent by the device requesting connection to the Mesh Service associated with the account.

If the connection request is accepted by the Mesh Service, it creates a MessageConnectionResponse containing the ServerNonce and Witness values used in the authentication of the response together with a verbatim copy of the original request. The MessageConnectionResponse is then returned to the device that made the original request and placed on the SpoolInbound of the account to which the request was directed.

Further details of this mechanism are described in [draft-hallambaker-mesh-protocol].

Alice connects a watch to her account. Since the watch has a camera (to allow for video calls) she can use the dynamic QR code connection mechanism.

The watch reads the QR code generated on Alice's watch. This contains the device connection URI.

QR = {Connect.ConnectQRURI}

The URI tells the device the Mesh account to connect to and the PIN Code to be used to authenticate the request. The device requesting the connection adds its Profile device to create a RequestConnection message that will be presented to the service as a Connect transaction request.

{
  "RequestConnection":{
    "MessageId":"NB2K-E33D-IXPK-LR7X-DL5R-7GJW-FLEP",
    "AuthenticatedData":[{
        "EnvelopeID":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNREpELTdFSkItTEJN
  Wi1NQU81LUNHSUUtRERFQi1MUVZIIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZmlsZ
  URldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAiQ3
  JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI1OjU3WiJ9"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cmUi
  OiB7CiAgICAgICJVZGYiOiAiTURKRC03RUpCLUxCTVotTUFPNS1DR0lFLURERUItT
  FFWSCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW
  NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA
  iUHVibGljIjogImlZajZfbEU2enUta2xxZ0doMGtnMlZBT2o1cENYcEtWMDk0OFJT
  ZWJqUkpfdmphS0dKRXoKICBDQll0ZkZzb2tMUUg5aUduWnRfTEd3d0EifX19LAogI
  CAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1DUFgtWkhQNC01Nl
  NPLVpMT0ktN1FITS1IMkE0LUdYUE0iLAogICAgICAiUHVibGljUGFyYW1ldGVycyI
  6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAi
  WDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInBnei1ZS3hjdzFrUHJJRzd4ejNlb
  0tZZGlsQzZUa3NUTE0tcjhINUNuNFdUY3gtbGtDZUgKICBONmtzcTVPelc1N3laX1
  9LZkZlelBhNEEifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgICA
  gIlVkZiI6ICJNQ1RVLUVCR1QtQjVDRS1EUlpBLUhOSFEtQ05UVS1ITVBFIiwKICAg
  ICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiO
  iB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6IC
  JaY05LdGhmdUk4QTNibUt1c284dWJzSDkwcG1VUXdBV1FNTGpwcFh1dHh0anVsR2l
  pYjZkCiAgU0p3R18tYmh6ZlBUQ0RpY05oSFVXa2NBIn19fSwKICAgICJCYXNlU2ln
  bmF0dXJlIjogewogICAgICAiVWRmIjogIk1DNzYtR1VGNy1MRUhYLTNWR0ctS1ZHU
  C03TjJLLUNFUVUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC
  AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA
  gICAgICAgIlB1YmxpYyI6ICJqZG1ibnZKNkM5ajhzbF9pRUlmcDkxMlItQ3lKX1E1
  MXdsc1d4X1ZxYWIwd0cwc0JNd21mCiAgbkx2ZFMydWFTTVpBN1RuYTNvWUItdENBI
  n19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH",
            "signature":"ZXggJgXzooa2Ui5zxNXrY6UCNXFFUBgGgpPl5Qe_OC
  1o_oJKHJkwEIDBEj45OHQZPGhn1TEl5UwAJxemsop7Rnr5U3DdNc2ERYL4hYHGVVx
  5W2PzeQk4U1mviwYdfqp_5V80vRL4RcZiTozviK6sWwwA"}
          ],
        "PayloadDigest":"JRadknNMvezXjCMPoluxtnw8sUX4QXZ1oSG6HANsJn
  IAZwXEzvTjbZwrngywjG82UJ8p6DXBMfcYTR0AhJIBBg"}
      ],
    "ClientNonce":"-suxzsj-OEQhgNZeuQFfiQ",
    "PinId":"ADWE-3XBF-GGLA-AMCX-XVDM-KMXB-BQRN",
    "PinWitness":"cRP1Zv5O5NH-GRJi1qv0rZNPJEsix0RyXMxgPLz5XzXsMQOzd
  OOgSVDeFrZWoyY2DitMfZdjIharXUL_cWovJA",
    "AccountAddress":"alice@example.com"}}

The service generates an AcknowledgeConnection message which is returned to the device requesting the connection (via the Connect transaction response) and adds it to the inbound spool of the account for Alice's approval (or not).

{
  "AcknowledgeConnection":{
    "MessageId":"T365-C62P-LUPX-76V5-CUND-IB5M-OE7P",
    "EnvelopedRequestConnection":[{
        "EnvelopeID":"MCPK-XGW3-624O-UVCF-G33S-I6VX-U2P7",
        "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJOQjJLLUUzM0QtSVhQ
  Sy1MUjdYLURMNVItN0dKVy1GTEVQIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWVzd
  ENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCi
  AgIkNyZWF0ZWQiOiAiMjAyMC0xMS0wMlQxNzoyNTo1N1oifQ"},
      "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOiAi
  TkIySy1FMzNELUlYUEstTFI3WC1ETDVSLTdHSlctRkxFUCIsCiAgICAiQXV0aGVud
  GljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlEIjogIk1ESkQtN0VKQi
  1MQk1aLU1BTzUtQ0dJRS1EREVCLUxRVkgiLAogICAgICAgICJkaWciOiAiUzUxMiI
  sCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKUkNJ
  NklDSk5SRXBFTFRkRlNrSXRURUpOV2kxCiAgTlFVODFMVU5IU1VVdFJFUkZRaTFNV
  VZaSUlpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxkbW
  xqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV04
  wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJd0xURXhMVEF5VkRFM09qSTFP
  alUzV2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V3b
  2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNKVl
  pHWWlPaUFpVFVSS1JDMDNSVXBDTFV4Q1RWb3RUCiAgVUZQTlMxRFIwbEZMVVJFUlV
  JdFRGRldTQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KICBn
  ZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0FnS
  UNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmliR2
  xqSWpvZ0ltbFphalpmYkVVMmVuVXRhMnh4WjBkCiAgb01HdG5NbFpCVDJvMWNFTll
  jRXRXTURrME9GSlRaV0pxVWtwZmRtcGhTMGRLUlhvS0lDQkRRbGwwWmtaemIKICAy
  dE1VVWc1YVVkdVduUmZURWQzZDBFaWZYMTlMQW9nSUNBZ0lrSmhjMlZGYm1OeWVYQ
  jBhVzl1SWpvZ2V3bwogIGdJQ0FnSUNBaVZXUm1Jam9nSWsxRFVGZ3RXa2hRTkMwMU
  5sTlBMVnBNVDBrdE4xRklUUzFJTWtFMExVZFlVCiAgRTBpTEFvZ0lDQWdJQ0FpVUh
  WaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS0lDQWdJQ0FnSUNBaVVIVmliR2wKICBq
  UzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjbllpT2lBaVdEUTBPQ0lzQ
  2lBZ0lDQWdJQ0FnSQogIENBaVVIVmliR2xqSWpvZ0luQm5laTFaUzNoamR6RnJVSE
  pKUnpkNGVqTmxiMHRaWkdsc1F6WlVhM05VVEUwCiAgdGNqaElOVU51TkZkVVkzZ3R
  iR3REWlVnS0lDQk9ObXR6Y1RWUGVsYzFOM2xhWDE5TFprWmxlbEJoTkVFaWYKICBY
  MTlMQW9nSUNBZ0lrSmhjMlZCZFhSb1pXNTBhV05oZEdsdmJpSTZJSHNLSUNBZ0lDQ
  WdJbFZrWmlJNklDSgogIE5RMVJWTFVWQ1IxUXRRalZEUlMxRVVscEJMVWhPU0ZFdF
  EwNVVWUzFJVFZCRklpd0tJQ0FnSUNBZ0lsQjFZCiAgbXhwWTFCaGNtRnRaWFJsY25
  NaU9pQjdDaUFnSUNBZ0lDQWdJbEIxWW14cFkwdGxlVVZEUkVnaU9pQjdDaUEKICBn
  SUNBZ0lDQWdJQ0FpWTNKMklqb2dJbGcwTkRnaUxBb2dJQ0FnSUNBZ0lDQWdJbEIxW
  W14cFl5STZJQ0phWQogIDA1TGRHaG1kVWs0UVROaWJVdDFjMjg0ZFdKelNEa3djRz
  FWVVhkQlYxRk5UR3B3Y0ZoMWRIaDBhblZzUjJsCiAgcFlqWmtDaUFnVTBwM1IxOHR
  ZbWg2WmxCVVEwUnBZMDVvU0ZWWGEyTkJJbjE5ZlN3S0lDQWdJQ0pDWVhObFUKICAy
  bG5ibUYwZFhKbElqb2dld29nSUNBZ0lDQWlWV1JtSWpvZ0lrMUROell0UjFWR055M
  U1SVWhZTFROV1IwYwogIHRTMVpIVUMwM1RqSkxMVU5GVVZVaUxBb2dJQ0FnSUNBaV
  VIVmliR2xqVUdGeVlXMWxkR1Z5Y3lJNklIc0tJCiAgQ0FnSUNBZ0lDQWlVSFZpYkd
  salMyVjVSVU5FU0NJNklIc0tJQ0FnSUNBZ0lDQWdJQ0pqY25ZaU9pQWlSV1EKICAw
  TkRnaUxBb2dJQ0FnSUNBZ0lDQWdJbEIxWW14cFl5STZJQ0pxWkcxaWJuWktOa001Y
  WpoemJGOXBSVWxtYwogIERreE1sSXRRM2xLWDFFMU1YZHNjMWQ0WDFaeFlXSXdkMG
  N3YzBKTmQyMW1DaUFnYmt4MlpGTXlkV0ZUVFZwCiAgQk4xUnVZVE52V1VJdGRFTkJ
  JbjE5ZlgxOSIsCiAgICAgIHsKICAgICAgICAic2lnbmF0dXJlcyI6IFt7CiAgICAg
  ICAgICAgICJhbGciOiAiUzUxMiIsCiAgICAgICAgICAgICJraWQiOiAiTURKRC03R
  UpCLUxCTVotTUFPNS1DR0lFLURERUItTFFWSCIsCiAgICAgICAgICAgICJzaWduYX
  R1cmUiOiAiWlhnZ0pnWHpvb2EyVWk1enhOWHJZNlVDTlhGRlVCZ0dncFBsNVFlX09
  DMW9fb0pLSAogIEprd0VJREJFajQ1T0hRWlBHaG4xVEVsNVV3QUp4ZW1zb3A3Um5y
  NVUzRGROYzJFUllMNGhZSEdWVng1VzJQCiAgemVRazRVMW12aXdZZGZxcF81Vjgwd
  lJMNFJjWmlUb3p2aUs2c1d3d0EifV0sCiAgICAgICAgIlBheWxvYWREaWdlc3QiOi
  AiSlJhZGtuTk12ZXpYakNNUG9sdXh0bnc4c1VYNFFYWjFvU0c2SEFOc0puSUFaCiA
  gd1hFenZUamJad3JuZ3l3akc4MlVKOHA2RFhCTWZjWVRSMEFoSklCQmcifV0sCiAg
  ICAiQ2xpZW50Tm9uY2UiOiAiLXN1eHpzai1PRVFoZ05aZXVRRmZpUSIsCiAgICAiU
  GluSWQiOiAiQURXRS0zWEJGLUdHTEEtQU1DWC1YVkRNLUtNWEItQlFSTiIsCiAgIC
  AiUGluV2l0bmVzcyI6ICJjUlAxWnY1TzVOSC1HUkppMXF2MHJaTlBKRXNpeDBSeVh
  NeGdQTHo1WHpYc01RT3oKICBkT09nU1ZEZUZyWldveVkyRGl0TWZaZGpJaGFyWFVM
  X2NXb3ZKQSIsCiAgICAiQWNjb3VudEFkZHJlc3MiOiAiYWxpY2VAZXhhbXBsZS5jb
  20ifX0"
      ],
    "ServerNonce":"1yJIRnfjOC0JFCCQZAFznw",
    "Witness":"T365-C62P-LUPX-76V5-CUND-IB5M-OE7P"}}

Alice's administration device synchronizes to the service and receives the connection request acknowledgement from the service. Since the request is authenticated by a PIN code that has been marked for automatic execution, the service can generate the assertions the device to participate in the account and appends the corresponding RespondConnection message to the local delivery spool.

{
  "RespondConnection":{
    "MessageId":"MAE6-HCD5-CTU3-T4LW-HW7N-C3SQ-F2OI",
    "Result":"Accept",
    "CatalogedDevice":{
      "Udf":"MCCR-2BLZ-ME27-SWM4-I73R-A7IA-MTYN",
      "DeviceUdf":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH",
      "EnvelopedProfileUser":[{
          "EnvelopeID":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
          "dig":"S512",
          "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNQUlILVFGMk0tUF
  ZEMy1OUUpPLUNXR1gtRzY3Uy1KWUVRIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy
  ZWF0ZWQiOiAiMjAyMC0xMS0wMlQxNzoyNTo1MVoifQ"},
        "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj
  ogewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HNjdTLUp
  ZRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj
  S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI
  lB1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0RzY1dzOV
  FqR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19fSwKICA
  gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy
  dmljZVVkZiI6ICJNQlNMLUg0NVAtUE0zVy1OVFlJLU5NS0ctTDQ2VC01SFdNIiwKI
  CAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQzJELVdYMj
  UtSks1Uy02UjdSLU5QSzUtWE5RNy1PMzM0IiwKICAgICAgIlB1YmxpY1BhcmFtZXR
  lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2
  IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJhQmJZaGlrLVZEVVBtWjNYa
  DdONUxwcGtuX2Y1MDRNTjYtWVdtTW5RQXlpSUpuS2FXdlBUCiAgVEE4ODlJZ0QzZH
  gzR2ZCSG1MajFpWE1BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIjo
  gewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HNjdTLUpZ
  RVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS
  2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIl
  B1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0RzY1dzOVF
  qR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19fSwKICAg
  ICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUFHVS1XT
  EdILVFYN0wtUlFLUy1LSFA0LUM1TFItNVJHMiIsCiAgICAgICJQdWJsaWNQYXJhbW
  V0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImN
  ydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAieW9JaTBkdlFCTkk0VXRp
  VUNBNUx2WUJpckRIamxFUVhIT2d6VjRrdHNxUUtQd2gtbE40YwogIEVqQ0lpbnlpO
  Eo1R1VfUjk0Q0Y1aGUwQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6IHsKIC
  AgICAgIlVkZiI6ICJNQlZOLVVDMkgtRUtDMi1HTFpBLUNMU0MtNlhRMi1RWklBIiw
  KICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVD
  REgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsa
  WMiOiAiRXZQWUhHUkNKc1owa21iQk11X3N4Y0d1VUlPSEZYYzRpejBvQ3lZMTlmcF
  lVRzVxSnluNAogIDY3V3E4NXp1Vld2aUJsOHpkMy05WF93QSJ9fX19fQ",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ",
              "signature":"PuG3M10QcqNXxUtJzk83C2LkExhO1jYqfBx_pcgl
  -_MH9lBPdT5JMiNSyVLsHRM9ZMUO-GVcDMiAITPUt5jG6t-GP3-6bdyEd6hDKavFU
  JYr4tWjKvro-3Uh7KP5BvFCz1VNoccCaiNhsrCf6uie4wkA"}
            ],
          "PayloadDigest":"OmGeYT1GZa5-mNx5fYmK0Jk2AzqPxuEJ-dRnTuoP
  LSgOSjHMzLnu8y1q6NTYxZomMK0ZfkuPtfD9Uyemy-npHQ"}
        ],
      "EnvelopedProfileDevice":[{
          "EnvelopeID":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH",
          "dig":"S512",
          "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNREpELTdFSkItTE
  JNWi1NQU81LUNHSUUtRERFQi1MUVZIIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
  sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
  Q3JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI1OjU3WiJ9"},
        "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm
  UiOiB7CiAgICAgICJVZGYiOiAiTURKRC03RUpCLUxCTVotTUFPNS1DR0lFLURERUI
  tTFFWSCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs
  aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI
  CAiUHVibGljIjogImlZajZfbEU2enUta2xxZ0doMGtnMlZBT2o1cENYcEtWMDk0OF
  JTZWJqUkpfdmphS0dKRXoKICBDQll0ZkZzb2tMUUg5aUduWnRfTEd3d0EifX19LAo
  gICAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1DUFgtWkhQNC01
  NlNPLVpMT0ktN1FITS1IMkE0LUdYUE0iLAogICAgICAiUHVibGljUGFyYW1ldGVyc
  yI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOi
  AiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInBnei1ZS3hjdzFrUHJJRzd4ejN
  lb0tZZGlsQzZUa3NUTE0tcjhINUNuNFdUY3gtbGtDZUgKICBONmtzcTVPelc1N3la
  X19LZkZlelBhNEEifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgI
  CAgIlVkZiI6ICJNQ1RVLUVCR1QtQjVDRS1EUlpBLUhOSFEtQ05UVS1ITVBFIiwKIC
  AgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREg
  iOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6
  ICJaY05LdGhmdUk4QTNibUt1c284dWJzSDkwcG1VUXdBV1FNTGpwcFh1dHh0anVsR
  2lpYjZkCiAgU0p3R18tYmh6ZlBUQ0RpY05oSFVXa2NBIn19fSwKICAgICJCYXNlU2
  lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1DNzYtR1VGNy1MRUhYLTNWR0ctS1Z
  HUC03TjJLLUNFUVUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAg
  ICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogI
  CAgICAgICAgIlB1YmxpYyI6ICJqZG1ibnZKNkM5ajhzbF9pRUlmcDkxMlItQ3lKX1
  E1MXdsc1d4X1ZxYWIwd0cwc0JNd21mCiAgbkx2ZFMydWFTTVpBN1RuYTNvWUItdEN
  BIn19fX19",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH",
              "signature":"ZXggJgXzooa2Ui5zxNXrY6UCNXFFUBgGgpPl5Qe_
  OC1o_oJKHJkwEIDBEj45OHQZPGhn1TEl5UwAJxemsop7Rnr5U3DdNc2ERYL4hYHGV
  Vx5W2PzeQk4U1mviwYdfqp_5V80vRL4RcZiTozviK6sWwwA"}
            ],
          "PayloadDigest":"JRadknNMvezXjCMPoluxtnw8sUX4QXZ1oSG6HANs
  JnIAZwXEzvTjbZwrngywjG82UJ8p6DXBMfcYTR0AhJIBBg"}
        ],
      "EnvelopedConnectionUser":[{
          "dig":"S512",
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
  9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
  DcmVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NThaIn0"},
        "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkRldmljZVNpZ25hdH
  VyZSI6IHsKICAgICAgIlVkZiI6ICJNQlFFLU1CTzUtVlNBRy02UVVXLUdBSlUtNEV
  HTi1FN1ZYIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1
  YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgI
  CAgICJQdWJsaWMiOiAieWVVaUgyZ3EydTc4YUQzbER4WXRQUmhZQTM1ZW5vTjBIME
  81Z3FLMlhySVhSVzdOVGsxUAogIFpZbFp0a3h4WjZFUlQxcEpQVXdKVlFzQSJ9fX0
  sCiAgICAiRGV2aWNlRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ080LTRN
  NDUtT1dPRS1VVVBNLVdJUEstQVNCRS00SjJOIiwKICAgICAgIlB1YmxpY1BhcmFtZ
  XRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3
  J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJCVzBBWGZpWE1iVnZrUlp
  uTnp5anJucTdSU2FiVjJBSnBsQzJTSzBPUnB6UEpxbmhaeEVxCiAgVHRFZjJ0TzVJ
  TlRwcUJPd21MU0ZvLS1BIn19fSwKICAgICJEZXZpY2VBdXRoZW50aWNhdGlvbiI6I
  HsKICAgICAgIlVkZiI6ICJNQjZKLTRWWFYtRFhRUS1HVVFWLVkzSlQtWVRUQS1KRU
  41IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0t
  leUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1
  YmxpYyI6ICJhYjVUSGQybmVFOHFjM0hEeW5YRzZMWThiVmp3Z0dpYnUwRGhOS0I5M
  XhQOWF4bFpybHA4CiAgYUw2WHA3TVJ3QU9TQU02TjJZY1dKdXFBIn19fX19",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBXO-5JKI-OWJH-UH5T-C4SU-YKEE-D3FP",
              "signature":"kLHglBYqL6rZPz6Fo7Jz2-pGZMlt6DG1zQVWu-nJ
  F0eEmkb2QnGc5GEhiwfiVIBw171_sunZBvqAzQh_hdwrHebrP8Q46kp8emfCksm9b
  -BrsjG3YsjuBg7_N98uJOyWoIdQ6j0upKZX6XV2re7JpzwA"}
            ],
          "PayloadDigest":"5gZs1tch-I8eCUcLBhNLGwv_YFl11hKt-I6rstjF
  Xe90lfi4z2KsLmKKcAGY7KpTejpYmGXUVHC1H7ns4YGDkw"}
        ],
      "EnvelopedActivationDevice":[{
          "enc":"A256CBC",
          "dig":"S512",
          "kid":"EBQO-I6OP-D6SH-Q2MD-QBBQ-PUKG-BBCE",
          "Salt":"Vc0qvABdCE6vS8G3orAiNA",
          "recipients":[{
              "kid":"MCPX-ZHP4-56SO-ZLOI-7QHM-H2A4-GXPM",
              "epk":{
                "PublicKeyECDH":{
                  "crv":"X448",
                  "Public":"rdeKkVGxewmd5848kt6ysRkl8Fbnjez7Va-TcRb
  -acX83owoCknyb9joo38vs_vzBkgEW5yPxXwA"}},
              "wmk":"DnzzAha8AY_-kkv6Qq3M6rvM3LXTH9yQLSujqOkDEyBXnr
  ajY4BoUA"}
            ],
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0aW
  9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
  DcmVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NThaIn0"},
        "9YI2S_zl1lfnuTYHlFvbZpNonWv-cx75v2P5YXQLl5mKbRQtc6mf6Ub3f3
  WFokrzaz1AoOCNk9amIe-OH1Nv1upgxEd9s3X1Q_UUHOzb84HslsjjtCxqYSuaKFj
  QoP2oBzXWGCaoh8t4jIPAaMzdW4gZOQ0NNxb0t47pLHEiUe1Jy1ez5m-PK9faJtH2
  wXhtogeWlppdJ2IvxkK4ofCpgY-clsl8yT8qdNFLG4GdEr-SFCn8cmDhYKAT9n5i-
  THP",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBXO-5JKI-OWJH-UH5T-C4SU-YKEE-D3FP",
              "signature":"BZMkm5R4Emy2M5Xljebbvwlu94FWRIvV23zi5Yzt
  8dobj_JIfrYP9YHfovGVGtNBeuuA3C0VsJ0AWYECXEng9-ysYke93Er_gfNPx-scx
  31nhcNozE4uDSL63UrNZ-J0RzFfo1x8ZoNUTNizr79I5j4A",
              "witness":"H8uCeAQI1Nffql1X4qGqK_i9-sgQaDshpTebNsBQr_
  w"}
            ],
          "PayloadDigest":"u8hmjJAqV014X0KwhOvZpcSxbRevKMuBWJgBA1qy
  Q7VyF78Iux68V447pfrUa8iLjD2T32LHJv0u9zCzaJQkhQ"}
        ],
      "EnvelopedActivationAccount":[{
          "dig":"S512",
          "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0aW
  9uQWNjb3VudCIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICA
  iQ3JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI1OjU4WiJ9"},
        "ewogICJBY3RpdmF0aW9uQWNjb3VudCI6IHt9fQ",
        {
          "signatures":[{
              "alg":"S512",
              "kid":"MBXO-5JKI-OWJH-UH5T-C4SU-YKEE-D3FP",
              "signature":"b5skN0iKRohn0JGfQO9YzVWvPiB9uW4Df-co8k_m
  J8HxFGZUnPEJUKhcLcj0YRQIv1mS9VGFptQAR8UCxqNlxDsKPyzgYZSZ8Wfyoa5ZV
  voW15G2zBUAx3VjE9neXXVc0HvqD-TWchto0uTFcdK2njYA"}
            ],
          "PayloadDigest":"xgR5j7NiUbDvKWjP7IjI4HuMAPLD8-ru3cMITmgI
  iPuX9gh1llky1cgZPc1zU0wwYGKucV6mGegsV5wg7ZGYoA"}
        ]}}}

9.4. Contact

A contact request presents a proposed contact entry and requests that it be added to the Contacts catalog of the specified Mesh Service Account. A contact request is usually sent by the party requesting that their contact be added but this is not necessarily the case.

The MessageContact contains a DARE Envelope containing the Contact information of the requester. If the request is accepted, this information will be added to the contact catalog of the relevant account. If the Reply field has the value 'true', this indicates that the sender is asking for the recipient to return their own credentials in reply.

Since the sender requires the user's contact information before the request can be made, the MessageContact message MAY be encrypted under either the user's account encryption key (if known) or the Mesh Service encryption key (which may be obtained from the service on request.

Bob asks Alice to send her contact details and sends his.

{
  "MessageContact":{
    "MessageId":"ND5Y-QMOY-42ZW-TE2Z-HJL2-7G3L-EQQB",
    "Sender":"bob@example.com",
    "Recipient":"alice@example.com",
    "AuthenticatedData":[{
        "dig":"S512",
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250YWN0UGVy
  c29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmVhd
  GVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NTRaIn0"},
      "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBbewogICAg
  ICAgICJVZGYiOiAiTURNWi01UFdXLVUyN1MtSlNNNC1aTU9CLUJQWDMtSFZJTiIsC
  iAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3JrQWRkcm
  Vzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJib2JAZXhhbXBsZS5jb20iLAo
  gICAgICAgICJFbnZlbG9wZWRQcm9maWxlQWNjb3VudCI6IFt7CiAgICAgICAgICAg
  ICJFbnZlbG9wZUlEIjogIk1ETVotNVBXVy1VMjdTLUpTTTQtWk1PQi1CUFgzLUhWS
  U4iLAogICAgICAgICAgICAiZGlnIjogIlM1MTIiLAogICAgICAgICAgICAiQ29udG
  VudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpSQ0k2SUNKTlJFMWFMVFZRVjF
  jdFZUSTNVeTEKICBLVTAwMExWcE5UMEl0UWxCWU15MUlWa2xPSWl3S0lDQWlUV1Z6
  YzJGblpWUjVjR1VpT2lBaVVISnZabWxzWgogIFZWelpYSWlMQW9nSUNKamRIa2lPa
  UFpWVhCd2JHbGpZWFJwYjI0dmJXMXRMMjlpYW1WamRDSXNDaUFnSWtOCiAgeVpXRj
  BaV1FpT2lBaU1qQXlNQzB4TVMwd01sUXhOem95TlRvMU5Gb2lmUSJ9LAogICAgICA
  gICAgImV3b2dJQ0pRY205bWFXeGxWWE5sY2lJNklIc0tJQ0FnSUNKUWNtOW1hV3gK
  ICBsVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxRVRWb3ROV
  kJYVnkxVk1qZFRMVXBUVAogIFRRdFdrMVBRaTFDVUZnekxVaFdTVTRpTEFvZ0lDQW
  dJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzCiAgS0lDQWdJQ0FnSUNBaVV
  IVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjbllpT2lBaVIK
  ICBXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSnZjbUZ2UlVGV
  VYwdFFNMnRyTFVOMlF6QgogIElkRkI2YjFSeWFXMXVVbFpYYUVaT1ZGVldjR1JpUk
  dORVdqSjRPVWxaYVVScENpQWdhR3BYWjBoQk1UWnZTCiAgVGRIWWxOSlpVZHVSV0V
  3WDBGQkluMTlmU3dLSUNBZ0lDSkJZMk52ZFc1MFFXUmtjbVZ6Y3lJNklDSmliMkoK
  ICBBWlhoaGJYQnNaUzVqYjIwaUxBb2dJQ0FnSWxObGNuWnBZMlZWWkdZaU9pQWlUV
  UpUVEMxSU5EVlFMVkJOTQogIDFjdFRsUlpTUzFPVFV0SExVdzBObFF0TlVoWFRTSX
  NDaUFnSUNBaVFXTmpiM1Z1ZEVWdVkzSjVjSFJwYjI0CiAgaU9pQjdDaUFnSUNBZ0l
  DSlZaR1lpT2lBaVRVTkNWQzFGU1VKU0xWRk9TVU10VGtSRlFTMVpORU5NTFUwMVYK
  ICBsWXRUMVpWV0NJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ
  2V3b2dJQ0FnSUNBZ0lDSgogIFFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSU
  NBZ0lDQWdJbU55ZGlJNklDSllORFE0SWl3S0lDQWdJCiAgQ0FnSUNBZ0lDSlFkV0p
  zYVdNaU9pQWlZV28zY1hvMU9IZFVTVGhEYzB3M1pHcDNRbWhRUmkwMVJXOVZhbVIK
  ICBHVnpScldreHBZbVZOVW5WdFZqVkhlbkJoV2xGd01Bb2dJRlZVVFVsT04zUjJXR
  XBJV1ZGSlQzSTNZVk5wTgogIEVNMlFTSjlmWDBzQ2lBZ0lDQWlRV1J0YVc1cGMzUn
  lZWFJ2Y2xOcFoyNWhkSFZ5WlNJNklIc0tJQ0FnSUNBCiAgZ0lsVmtaaUk2SUNKTlJ
  FMWFMVFZRVjFjdFZUSTNVeTFLVTAwMExWcE5UMEl0UWxCWU15MUlWa2xPSWl3S0kK
  ICBDQWdJQ0FnSWxCMVlteHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ
  0lsQjFZbXhwWTB0bGVVVgogIERSRWdpT2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySW
  pvZ0lrVmtORFE0SWl3S0lDQWdJQ0FnSUNBZ0lDSlFkCiAgV0pzYVdNaU9pQWliM0p
  oYjBWQlZGZExVRE5yYXkxRGRrTXdTSFJRZW05VWNtbHRibEpXVjJoR1RsUlZWbkIK
  ICBrWWtSalJGb3llRGxKV1dsRWFRb2dJR2hxVjJkSVFURTJiMGszUjJKVFNXVkhia
  1ZoTUY5QlFTSjlmWDBzQwogIGlBZ0lDQWlRV05qYjNWdWRFRjFkR2hsYm5ScFkyRj
  BhVzl1SWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxCiAgQlRra3RSakpCVUMxTFZ
  sbE5MVnBYVDFBdFRFYzNVUzFZVUZKTkxVeFNSMU1pTEFvZ0lDQWdJQ0FpVUhWaWIK
  ICBHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJWN
  VJVTkVTQ0k2SUhzS0lDQQogIGdJQ0FnSUNBZ0lDSmpjbllpT2lBaVdEUTBPQ0lzQ2
  lBZ0lDQWdJQ0FnSUNBaVVIVmliR2xqSWpvZ0luVnVWCiAgbmhmU1haeWVWbGZlamh
  EYzJkV2MzaHBSWGR4YlU1VUxWVkdNakEwVEdSbGVVNUZSMlJPUWxGa1drWk1kM3AK
  ICBSV1RRS0lDQm1Oa0p4YWtGclltVlhURlF0WkhGV2FXcHJSMFJyVFVFaWZYMTlMQ
  W9nSUNBZ0lrRmpZMjkxYgogIG5SVGFXZHVZWFIxY21VaU9pQjdDaUFnSUNBZ0lDSl
  ZaR1lpT2lBaVRVSlhXaTFITWpKQ0xVSkdRVlF0UmxkCiAgQlJ5MU9NMFZYTFZwVFV
  WY3RNelpQU0NJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2UK
  ICB3b2dJQ0FnSUNBZ0lDSlFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSUNBZ
  0lDQWdJbU55ZGlJNklDSgogIEZaRFEwT0NJc0NpQWdJQ0FnSUNBZ0lDQWlVSFZpYk
  dsaklqb2dJbXRhVldSSVMzVm5XbkZ1T0ZWb2VHcG1UCiAgMlZuZFhNeFRDMDNUelZ
  wZDJWelIzazNORTlLZW5sd1RFNDBORlJTVVU5SmVHUUtJQ0J3TTJObU4ybFdiMkYK
  ICBHVkRkRGFUZE9SRlJ2UWtsNlZVRWlmWDE5ZlgwIiwKICAgICAgICAgIHsKICAgI
  CAgICAgICAgInNpZ25hdHVyZXMiOiBbewogICAgICAgICAgICAgICAgImFsZyI6IC
  JTNTEyIiwKICAgICAgICAgICAgICAgICJraWQiOiAiTURNWi01UFdXLVUyN1MtSlN
  NNC1aTU9CLUJQWDMtSFZJTiIsCiAgICAgICAgICAgICAgICAic2lnbmF0dXJlIjog
  IlQtQUJzanZicGxXMlN3LUFLX0d6eFJ4OXBJb3BjNnZ0UF9FMDVlVmhaZWlpOEtkZ
  k4KICBmcGYxMGZTNWFtUkNYLUlCaGJIeXA4aHpONEFyc25aUFNZa25kQnBsTnJ0am
  U3NklhYjNpVFp5QUJoeFBVTAogIHpMMThnN1kxSGgyRVB2Rm9GeHFHazM5dWN6WkF
  UQlNMc3RUeXhIUjhBIn1dLAogICAgICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICI4
  WHZWaUxjZExra0NfaW5uSlZRelM3Uk5XSGxCVVZmSDREd0Rqc1kweHNlQVkKICB6U
  nd4WDJRN2VyR01JLTFOT0NNV3MxSldWN2tabFlPNDBXYnJNMmJ5USJ9XSwKICAgIC
  AgICAiUHJvdG9jb2xzIjogW3sKICAgICAgICAgICAgIlByb3RvY29sIjogIm1tbSJ
  9XX1dfX0",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MBWZ-G22B-BFAT-FWAG-N3EW-ZSQW-36OH",
            "signature":"wN4bBu-tL_qZ1v74Teo2ZRQnwlxciiQOMRCf_Dgewq
  kuqGoWW22CLeDc7HJoYg22pTxKC7gCWFsAJm_kgR64jxSwZCb3JBAoDzuLQ-Qnb9B
  c4r4r4ZEDIQgvH45TFdhb5yRP7yqurQds2UMgVOemMS0A"}
          ],
        "PayloadDigest":"ofJhr9i1k27VRu81sCKWy7qEahxpuw0rtvwrQaYkag
  PBvVLkoNY2F6jLGCQ5Y42_9jMYVglcMVXhkB_AvYG52Q"}
      ],
    "Reply":true,
    "Subject":"alice@example.com",
    "PIN":"AA3V-CH7O-FGHI-W2DP-VCCY-IRXB-IO2A"}}

Alice responds with her own contact information. Since she already has Bob's contact information, there is no need to request a response or provide a PIN code.

The current protocol assumes that all contact management will be performed end-to-end through the Mesh Services themselves. If the number of Mesh users were to become exceptionally large, additional infrastructure to facilitate contact management will be required. These topics are discussed at a high level in [draft-hallambaker-mesh-trust].

In situations where a user is well known and has a very large number of contacts, they are likely to make use of a tiered approach to contact management in which they keep separate accounts for their 'public' and 'restricted' personas and delegate management of their public account to a subordinate or to their Mesh Service provider.

9.5. Confirmation

Confirmation messages are used to provide an improved form of second factor authentication capability.

Two confirmation messages are specified, a request and response.

A confirmation request is initiated by sending a MessageConfirmationRequest to the Mesh Service hosting the recipient Mesh Service Account. The request specifies the question that is to be put to the user.

To respond to a confirmation request, a user generates a MessageConfirmationResponse. This MUST be signed by a device authorized to respond to confirmation requests by a Device Connection Assertion with the Confirmation privilege.

The console generates a confirmation request message:

{
  "RequestConfirmation":{
    "MessageId":"NC2K-XDLE-KNN2-GSLN-AEUX-WJXF-RA5B",
    "Sender":"console@example.com",
    "Recipient":"alice@example.com",
    "Text":"start"}}

Alice accepts the request and returns a ResponseConfirmation confirmation containing both the request and the response:

Missing example 26

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.

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

10.2. Device Preconfiguration

The static QR code device connection interaction allows a device with no keyboard, display or other user affordances to be connected to a Mesh account.

The information necessary to establish communication with the device and to complete a device connection workflow is provided by means of a DevicePreconfiguration record accessed by means of an EARL.

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

{
  "DevicePreconfiguration":{
    "EnvelopedProfileDevice":[{
        "EnvelopeID":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV",
        "dig":"S512",
        "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNQ1E3LUZGTjQtM1dD
  WS1ORFlVLUNQRlEtWEZINC1FSE5WIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZmlsZ
  URldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAiQ3
  JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI2OjAwWiJ9"},
      "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cmUi
  OiB7CiAgICAgICJVZGYiOiAiTUNRNy1GRk40LTNXQ1ktTkRZVS1DUEZRLVhGSDQtR
  UhOViIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW
  NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA
  iUHVibGljIjogImR5UWdEZVpYMFk3dTVGRWxlckxiekZoYkdVVGozanJrTzViaXV0
  bmQ5Q3VodFVQbnBOTTcKICBVRFRrNW90bWxvcmVpSjlPQmxuNzBMMEEifX19LAogI
  CAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1BRkYtNFA1NC1PUl
  lGLVNCQU4tNlhRNy1DTzZTLU9YV1EiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI
  6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAi
  WDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIjdyRWpsVGNsRVBBb3l0WkxHSmJmN
  S1lTzhtQldMbE5hZXZKM1lBdF9hUmhKQWhlLVJPWUwKICBfQVNmQnVLRUw5ZDBPOH
  BDRGxXendBMkEifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgICA
  gIlVkZiI6ICJNQU5CLURZWEUtN0NOQy1XNkxXLTNSNkktQkxBQi0yVEtDIiwKICAg
  ICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiO
  iB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6IC
  JCb1lfd3hMdHhLMU1zRk9oT0VzOExrWTZIWTZONng0NmkwTF9NSkxNQU1rcXdzQXl
  peW1SCiAgazZwVjR2dnRDYzZEekJPOExGX01XWWdBIn19fSwKICAgICJCYXNlU2ln
  bmF0dXJlIjogewogICAgICAiVWRmIjogIk1BVzctWUlPMy01QTdNLTU1WVUtT1o3V
  y1CSkZULVFUSFciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC
  AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA
  gICAgICAgIlB1YmxpYyI6ICJQc2Y4dG9qRTZPNFE3SllCWGU0ci1iZExRZHk0RTh0
  ek1URTNBRENzNE93WEt5bldydmxxCiAgTzdjeUdjWDFXbjZiZDJWNWhMRjQ4UjhBI
  n19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV",
            "signature":"lVcSWqEEVvr-AsnhUeUQ4OwnIa-enZ3ZXre4sc3M3b
  JY_tre8U0e_AfM-VFERgN7OQ67OBatfj8AqZLU6SxhaJHira3uZbw1Ha8yQXMXSed
  pPm9hefDHb0-zwT80Pr0530SByJmW2uU5sQUh1rxmhiAA"}
          ],
        "PayloadDigest":"KflhE7fsBB_6jk4XP2sFRVtoqIj5zZ2j3QISDfuLTw
  se9bZBKTY8IPcGTlXtnaBTEH4P9smbO6AB6EDy8Nnegw"}
      ],
    "EnvelopedConnectionDevice":[{
        "dig":"S512",
        "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW9u
  RGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDc
  mVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjY6MDBaIn0"},
      "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkRldmljZVNpZ25hdHVy
  ZSI6IHsKICAgICAgIlVkZiI6ICJNQVc3LVlJTzMtNUE3TS01NVlVLU9aN1ctQkpGV
  C1RVEhXIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1Ym
  xpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICA
  gICJQdWJsaWMiOiAiUHNmOHRvakU2TzRRN0pZQlhlNHItYmRMUWR5NEU4dHpNVEUz
  QURDczRPd1hLeW5XcnZscQogIE83Y3lHY1gxV242YmQyVjVoTEY0OFI4QSJ9fX0sC
  iAgICAiRGV2aWNlRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQUZGLTRQNT
  QtT1JZRi1TQkFOLTZYUTctQ082Uy1PWFdRIiwKICAgICAgIlB1YmxpY1BhcmFtZXR
  lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2
  IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICI3ckVqbFRjbEVQQW95dFpMR
  0piZjUtZU84bUJXTGxOYWV2SjNZQXRfYVJoSkFoZS1ST1lMCiAgX0FTZkJ1S0VMOW
  QwTzhwQ0RsV3p3QTJBIn19fSwKICAgICJEZXZpY2VBdXRoZW50aWNhdGlvbiI6IHs
  KICAgICAgIlVkZiI6ICJNQUZGLTRQNTQtT1JZRi1TQkFOLTZYUTctQ082Uy1PWFdR
  IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tle
  UVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1Ym
  xpYyI6ICI3ckVqbFRjbEVQQW95dFpMR0piZjUtZU84bUJXTGxOYWV2SjNZQXRfYVJ
  oSkFoZS1ST1lMCiAgX0FTZkJ1S0VMOWQwTzhwQ0RsV3p3QTJBIn19fX19",
      {
        "signatures":[{
            "alg":"S512",
            "kid":"MDJN-Y22I-NBWS-TF2I-7HJV-N4JS-T5GU",
            "signature":"3dKPeRJ1OFB-h3Mt99GDJf4slU8XjkmkrmucvEbdlm
  dbxl7pf_7Wi8PxjtH2xwCDD8IqamVPGaiAmK6slj2-dHfQfpOAl7hMkyKFE3W5sR2
  t9DGrYCqZU9J-rUd1eLc8wUh3kSZ08MDVGEcCcLEZuD4A"}
          ],
        "PayloadDigest":"rIuHcY2LV8tgbaFHN88oYDGytN5Giv1KTyQGDifkwX
  -HBK1IsApCD_pJ4h5jpG9fx9TSIqEiuMIb7iHqheByWg"}
      ],
    "PrivateKey":{
      "PrivateKeyUDF":{
        "PrivateValue":"ZAAQ-AAQT-ZDDI-IU7M-ORQA-YRRR-MMEH-D4PN-3YP
W-HGJH-FXSR-BZXH-PYMG-KZBC",
        "KeyType":"MeshProfileDevice"}},
    "ConnectUri":"mcu://maker@example.com/ECO6-IN3T-HZYJ-S7W4-T4XZ-
JX6R-Y5SO-ATKN-TU2E-MDAF-VJEA-JV6Z-BOXE-G"}}

To connect to the coffee pot, Alice first scans the QR code with her administrative device which uses the PIN code and service to retrieve, decrypt and authenticate the DevicePreconfiguration record. Future versions of the specification will allow this record to specify means by which the administration device can establish direct peer-to-peer communication to complete the connection process by any communication modality supported by both devices (e.g. IR, Bluetooth, WiFi-Direct, etc.)

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. alice@example.com) 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. alice@example.com

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. Appendix A: Example Container Organization (not normative)

The means by which profiles are stored on devices is outside the scope of the specification. Only catalogs that are required to be shared between machines by means of accounts need to be standardized.

15.1. Device

Host Catalog: Host.dare

Catalog of all the Mesh Profiles that the user has registered with the device and the latest version of the device profile for this device.

MeshCatalog: [UDF-Mesh].dcat

Catalog containing the Account Entries for the Mesh [UDF-Mesh].

Account Catalogs: [UDF-Account]/mmm_Device.dcat

The device catalog associated with the specified account

Account Catalogs: [UDF-Account]/[Catalog name].dcat

The set of account catalogs that are shared verbatim between the devices connected to the account.

15.1.1. Creating a new Mesh

Create new Mesh Profile, Device Profile, Add to Host Catalog

Create MeshCatalog

15.1.2. Adding an Account

Create new Account Profile, Add to MeshCatalog

Create new Account Device Catalog

For each device to be added to the account: Create Account Connection Assertion, add to Account Device Catalog.

15.1.3. Adding a Device

Create a Device Connection Assertion.

For each account the device is to be added to: Create Account Connection Assertion, add to Account Device Catalog.

15.2. Service

Master Catalog

Catalog of all services on machine

Service Catalog

Catalog of accounts in the service.

15.2.1. Creating a Service

Create a Service Description, add to Master Catalog

15.2.2. Adding an Account

Create the account entry, add to Service Catalog

Create the Account Directory

16. Appendix B: Collected Authentication and Encryption Requirements

16.1. Mesh Messaging

Table 2
Message Signer Recipients
RequestConnection Device Service
AcknowledgeConnection Service Device, Receiver
OfferGroup Sender Receiver
RequestContact Sender Receiver
ReplyContact Sender Receiver
RequestConfirmation Sender Receiver
ResponseConfirmation Sender Receiver
RequestTask Sender Receiver
ResponseTask Sender Receiver

17. Normative References

[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: Architecture Guide", Work in Progress, Internet-Draft, draft-hallambaker-mesh-architecture-14, , <https://tools.ietf.org/html/draft-hallambaker-mesh-architecture-14>.
[draft-hallambaker-mesh-cryptography]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Work in Progress, Internet-Draft, draft-hallambaker-mesh-cryptography-06, , <https://tools.ietf.org/html/draft-hallambaker-mesh-cryptography-06>.
[draft-hallambaker-mesh-discovery]
"[Reference Not Found!]".
[draft-hallambaker-mesh-notary]
"[Reference Not Found!]".
[draft-hallambaker-mesh-protocol]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol Reference", Work in Progress, Internet-Draft, draft-hallambaker-mesh-protocol-06, , <https://tools.ietf.org/html/draft-hallambaker-mesh-protocol-06>.
[draft-hallambaker-mesh-security]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Security Considerations", Work in Progress, Internet-Draft, draft-hallambaker-mesh-security-05, , <https://tools.ietf.org/html/draft-hallambaker-mesh-security-05>.
[draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Work in Progress, Internet-Draft, draft-hallambaker-mesh-udf-10, , <https://tools.ietf.org/html/draft-hallambaker-mesh-udf-10>.
[draft-hallambaker-threshold]
Hallam-Baker, P., "Threshold Modes in Elliptic Curves", Work in Progress, Internet-Draft, draft-hallambaker-threshold-03, , <https://tools.ietf.org/html/draft-hallambaker-threshold-03>.
[draft-hallambaker-threshold-sigs]
Hallam-Baker, P., "Threshold Signatures in Elliptic Curves", Work in Progress, Internet-Draft, draft-hallambaker-threshold-sigs-04, , <https://tools.ietf.org/html/draft-hallambaker-threshold-sigs-04>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.

18. Informative References

[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft-hallambaker-mesh-developer-10, , <https://tools.ietf.org/html/draft-hallambaker-mesh-developer-10>.
[draft-hallambaker-mesh-trust]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The Trust Mesh", Work in Progress, Internet-Draft, draft-hallambaker-mesh-trust-06, , <https://tools.ietf.org/html/draft-hallambaker-mesh-trust-06>.
[RFC2426]
Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, DOI 10.17487/RFC2426, , <https://www.rfc-editor.org/rfc/rfc2426>.
[RFC5545]
Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, , <https://www.rfc-editor.org/rfc/rfc5545>.