Network Working Group                                 P. M. Hallam-Baker
Internet-Draft                                      ThresholdSecrets.com
Intended status: Informational                           2 November 2020
Expires: 6 May 2021


            Mathematical Mesh 3.0 Part IV: Schema Reference
                    draft-hallambaker-mesh-schema-06

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.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Hallam-Baker               Expires 6 May 2021                   [Page 1]

Internet-Draft            Mesh Schema Reference            November 2020


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.2.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Related Specifications  . . . . . . . . . . . . . . . . .   6
     2.4.  Implementation Status . . . . . . . . . . . . . . . . . .   6
   3.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Accounts  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Activation  . . . . . . . . . . . . . . . . . . . . .  11
     3.3.  Service . . . . . . . . . . . . . . . . . . . . . . . . .  13
   4.  Catalogs  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  Access  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     4.2.  Application . . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.1.  Mesh Account  . . . . . . . . . . . . . . . . . . . .  16
       4.2.2.  SSH . . . . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.3.  Mail  . . . . . . . . . . . . . . . . . . . . . . . .  17
     4.3.  Bookmark  . . . . . . . . . . . . . . . . . . . . . . . .  17
     4.4.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .  17
     4.5.  Credential  . . . . . . . . . . . . . . . . . . . . . . .  21
     4.6.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     4.7.  Network . . . . . . . . . . . . . . . . . . . . . . . . .  21
     4.8.  Publication . . . . . . . . . . . . . . . . . . . . . . .  21
     4.9.  Task  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   5.  Spools  . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     5.1.  Outbound  . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.2.  Inbound . . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.3.  Local . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   6.  Cryptographic Operations  . . . . . . . . . . . . . . . . . .  24
     6.1.  Key Derivation from Seed  . . . . . . . . . . . . . . . .  24
     6.2.  Message Response Identifier . . . . . . . . . . . . . . .  24
     6.3.  Proof of Knowledge of PIN . . . . . . . . . . . . . . . .  25
     6.4.  EARL  . . . . . . . . . . . . . . . . . . . . . . . . . .  27
     6.5.  Key Agreement . . . . . . . . . . . . . . . . . . . . . .  27
     6.6.  Service Cryptographic Operations  . . . . . . . . . . . .  28
   7.  Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . .  28
     7.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  29
     7.2.  Mesh Profiles . . . . . . . . . . . . . . . . . . . . . .  30
     7.3.  Mesh Connections  . . . . . . . . . . . . . . . . . . . .  30
   8.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  31



Hallam-Baker               Expires 6 May 2021                   [Page 2]

Internet-Draft            Mesh Schema Reference            November 2020


     8.1.  Device Management . . . . . . . . . . . . . . . . . . . .  32
       8.1.1.  Master Profile  . . . . . . . . . . . . . . . . . . .  32
       8.1.2.  Mesh Devices  . . . . . . . . . . . . . . . . . . . .  34
     8.2.  Mesh Accounts . . . . . . . . . . . . . . . . . . . . . .  35
       8.2.1.  Creating a ProfileAccount . . . . . . . . . . . . . .  36
       8.2.2.  Connecting a Device to an Account . . . . . . . . . .  36
       8.2.3.  Binding and Account to a Service  . . . . . . . . . .  37
     8.3.  Mesh Services . . . . . . . . . . . . . . . . . . . . . .  37
       8.3.1.  Creating a ProfileService . . . . . . . . . . . . . .  37
       8.3.2.  Creating a ProfileHost  . . . . . . . . . . . . . . .  38
       8.3.3.  Creating a ConnectionHost . . . . . . . . . . . . . .  38
     8.4.  Mesh Messaging  . . . . . . . . . . . . . . . . . . . . .  38
       8.4.1.  Traffic Analysis  . . . . . . . . . . . . . . . . . .  39
   9.  Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . .  40
     9.1.  PIN . . . . . . . . . . . . . . . . . . . . . . . . . . .  40
     9.2.  Completion  . . . . . . . . . . . . . . . . . . . . . . .  40
     9.3.  Connection  . . . . . . . . . . . . . . . . . . . . . . .  41
     9.4.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .  48
     9.5.  Confirmation  . . . . . . . . . . . . . . . . . . . . . .  51
   10. Publications  . . . . . . . . . . . . . . . . . . . . . . . .  52
     10.1.  Contact Exchange . . . . . . . . . . . . . . . . . . . .  52
     10.2.  Device Preconfiguration  . . . . . . . . . . . . . . . .  52
   11. Schema  . . . . . . . . . . . . . . . . . . . . . . . . . . .  54
     11.1.  Shared Classes . . . . . . . . . . . . . . . . . . . . .  54
       11.1.1.  Classes describing keys  . . . . . . . . . . . . . .  54
       11.1.2.  Structure: KeyData . . . . . . . . . . . . . . . . .  54
       11.1.3.  Structure: CompositePrivate  . . . . . . . . . . . .  55
     11.2.  Assertion classes  . . . . . . . . . . . . . . . . . . .  55
       11.2.1.  Structure: Assertion . . . . . . . . . . . . . . . .  55
       11.2.2.  Structure: Condition . . . . . . . . . . . . . . . .  55
       11.2.3.  Base Classes . . . . . . . . . . . . . . . . . . . .  55
       11.2.4.  Structure: Connection  . . . . . . . . . . . . . . .  56
       11.2.5.  Structure: Activation  . . . . . . . . . . . . . . .  56
       11.2.6.  Structure: ActivationEntry . . . . . . . . . . . . .  56
       11.2.7.  Mesh Profile Classes . . . . . . . . . . . . . . . .  56
       11.2.8.  Structure: Profile . . . . . . . . . . . . . . . . .  56
       11.2.9.  Structure: ProfileDevice . . . . . . . . . . . . . .  56
       11.2.10. Structure: ProfileAccount  . . . . . . . . . . . . .  57
       11.2.11. Structure: ProfileUser . . . . . . . . . . . . . . .  57
       11.2.12. Structure: ProfileGroup  . . . . . . . . . . . . . .  58
       11.2.13. Structure: ProfileService  . . . . . . . . . . . . .  58
       11.2.14. Structure: ProfileHost . . . . . . . . . . . . . . .  58
       11.2.15. Connection Assertions  . . . . . . . . . . . . . . .  58
       11.2.16. Structure: ConnectionDevice  . . . . . . . . . . . .  58
       11.2.17. Structure: ConnectionApplication . . . . . . . . . .  59
       11.2.18. Structure: ConnectionGroup . . . . . . . . . . . . .  59
       11.2.19. Structure: ConnectionService . . . . . . . . . . . .  59
       11.2.20. Structure: ConnectionHost  . . . . . . . . . . . . .  59



Hallam-Baker               Expires 6 May 2021                   [Page 3]

Internet-Draft            Mesh Schema Reference            November 2020


       11.2.21. Activation Assertions  . . . . . . . . . . . . . . .  59
       11.2.22. Structure: ActivationDevice  . . . . . . . . . . . .  59
       11.2.23. Structure: ActivationAccount . . . . . . . . . . . .  60
       11.2.24. Structure: ActivationApplication . . . . . . . . . .  60
     11.3.  Data Structures  . . . . . . . . . . . . . . . . . . . .  60
       11.3.1.  Structure: Contact . . . . . . . . . . . . . . . . .  60
       11.3.2.  Structure: Anchor  . . . . . . . . . . . . . . . . .  61
       11.3.3.  Structure: TaggedSource  . . . . . . . . . . . . . .  61
       11.3.4.  Structure: ContactGroup  . . . . . . . . . . . . . .  61
       11.3.5.  Structure: ContactPerson . . . . . . . . . . . . . .  61
       11.3.6.  Structure: ContactOrganization . . . . . . . . . . .  61
       11.3.7.  Structure: OrganizationName  . . . . . . . . . . . .  62
       11.3.8.  Structure: PersonName  . . . . . . . . . . . . . . .  62
       11.3.9.  Structure: NetworkAddress  . . . . . . . . . . . . .  62
       11.3.10. Structure: NetworkProtocol . . . . . . . . . . . . .  63
       11.3.11. Structure: Role  . . . . . . . . . . . . . . . . . .  63
       11.3.12. Structure: Location  . . . . . . . . . . . . . . . .  63
       11.3.13. Structure: Bookmark  . . . . . . . . . . . . . . . .  63
       11.3.14. Structure: Reference . . . . . . . . . . . . . . . .  64
       11.3.15. Structure: Task  . . . . . . . . . . . . . . . . . .  64
     11.4.  Catalog Entries  . . . . . . . . . . . . . . . . . . . .  64
       11.4.1.  Structure: CatalogedEntry  . . . . . . . . . . . . .  64
       11.4.2.  Structure: CatalogedDevice . . . . . . . . . . . . .  65
       11.4.3.  Structure: CatalogedPublication  . . . . . . . . . .  65
       11.4.4.  Structure: CatalogedCredential . . . . . . . . . . .  66
       11.4.5.  Structure: CatalogedNetwork  . . . . . . . . . . . .  66
       11.4.6.  Structure: CatalogedContact  . . . . . . . . . . . .  66
       11.4.7.  Structure: CatalogedAccess . . . . . . . . . . . . .  66
       11.4.8.  Structure: CryptographicCapability . . . . . . . . .  66
       11.4.9.  Structure: CapabilityDecrypt . . . . . . . . . . . .  67
       11.4.10. Structure: CapabilityDecryptPartial  . . . . . . . .  67
       11.4.11. Structure: CapabilityDecryptServiced . . . . . . . .  67
       11.4.12. Structure: CapabilitySign  . . . . . . . . . . . . .  67
       11.4.13. Structure: CapabilityKeyGenerate . . . . . . . . . .  68
       11.4.14. Structure: CapabilityFairExchange  . . . . . . . . .  68
       11.4.15. Structure: CatalogedBookmark . . . . . . . . . . . .  68
       11.4.16. Structure: CatalogedTask . . . . . . . . . . . . . .  68
       11.4.17. Structure: CatalogedApplication  . . . . . . . . . .  68
       11.4.18. Structure: CatalogedMember . . . . . . . . . . . . .  69
       11.4.19. Structure: CatalogedGroup  . . . . . . . . . . . . .  69
       11.4.20. Structure: CatalogedApplicationSSH . . . . . . . . .  69
       11.4.21. Structure: CatalogedApplicationMail  . . . . . . . .  69
       11.4.22. Structure: CatalogedApplicationNetwork . . . . . . .  69
     11.5.  Publications . . . . . . . . . . . . . . . . . . . . . .  69
       11.5.1.  Structure: DevicePreconfiguration  . . . . . . . . .  69
     11.6.  Messages . . . . . . . . . . . . . . . . . . . . . . . .  70
       11.6.1.  Structure: Message . . . . . . . . . . . . . . . . .  70
       11.6.2.  Structure: MessageError  . . . . . . . . . . . . . .  70



Hallam-Baker               Expires 6 May 2021                   [Page 4]

Internet-Draft            Mesh Schema Reference            November 2020


       11.6.3.  Structure: MessageComplete . . . . . . . . . . . . .  70
       11.6.4.  Structure: MessagePinValidated . . . . . . . . . . .  70
       11.6.5.  Structure: MessagePin  . . . . . . . . . . . . . . .  70
       11.6.6.  Structure: RequestConnection . . . . . . . . . . . .  71
       11.6.7.  Structure: AcknowledgeConnection . . . . . . . . . .  71
       11.6.8.  Structure: RespondConnection . . . . . . . . . . . .  71
       11.6.9.  Structure: MessageContact  . . . . . . . . . . . . .  72
       11.6.10. Structure: GroupInvitation . . . . . . . . . . . . .  72
       11.6.11. Structure: RequestConfirmation . . . . . . . . . . .  72
       11.6.12. Structure: ResponseConfirmation  . . . . . . . . . .  72
       11.6.13. Structure: RequestTask . . . . . . . . . . . . . . .  72
       11.6.14. Structure: MessageClaim  . . . . . . . . . . . . . .  72
       11.6.15. Structure: ProcessResult . . . . . . . . . . . . . .  73
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  73
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  73
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  73
   15. Appendix A: Example Container Organization (not normative)  .  73
     15.1.  Device . . . . . . . . . . . . . . . . . . . . . . . . .  73
       15.1.1.  Creating a new Mesh  . . . . . . . . . . . . . . . .  74
       15.1.2.  Adding an Account  . . . . . . . . . . . . . . . . .  74
       15.1.3.  Adding a Device  . . . . . . . . . . . . . . . . . .  74
     15.2.  Service  . . . . . . . . . . . . . . . . . . . . . . . .  74
       15.2.1.  Creating a Service . . . . . . . . . . . . . . . . .  74
       15.2.2.  Adding an Account  . . . . . . . . . . . . . . . . .  74
   16. Appendix B: Collected Authentication and Encryption
        Requirements . . . . . . . . . . . . . . . . . . . . . . . .  74
     16.1.  Mesh Messaging . . . . . . . . . . . . . . . . . . . . .  75
   17. Normative References  . . . . . . . . . . . . . . . . . . . .  75
   18. Informative References  . . . . . . . . . . . . . . . . . . .  76

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



Hallam-Baker               Expires 6 May 2021                   [Page 5]

Internet-Draft            Mesh Schema Reference            November 2020


   the audience it allows them to communicate with.  Thus, while the
   Mesh Messaging service is designed to support efficient and reliable
   transfer of messages ranging in size from a few bytes to multiple
   terabytes, the near-term applications of these services will be to
   applications that are not adequately supported by existing protocols
   if at all.

2.  Definitions

   This section presents the related specifications and standard, the
   terms that are used as terms of art within the documents and the
   terms used as requirements language.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Defined Terms

   The terms of art used in this document are described in the _Mesh
   Architecture Guide_ [draft-hallambaker-mesh-architecture].

2.3.  Related Specifications

   The architecture of the Mathematical Mesh is described in the _Mesh
   Architecture Guide_ [draft-hallambaker-mesh-architecture].  The Mesh
   documentation set and related specifications are described in this
   document.

2.4.  Implementation Status

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

3.  Actors

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











Hallam-Baker               Expires 6 May 2021                   [Page 6]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                   [Page 7]

Internet-Draft            Mesh Schema Reference            November 2020


      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:






































Hallam-Baker               Expires 6 May 2021                   [Page 8]

Internet-Draft            Mesh Schema Reference            November 2020


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



Hallam-Baker               Expires 6 May 2021                   [Page 9]

Internet-Draft            Mesh Schema Reference            November 2020


   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:




























Hallam-Baker               Expires 6 May 2021                  [Page 10]

Internet-Draft            Mesh Schema Reference            November 2020


   {
     "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:






Hallam-Baker               Expires 6 May 2021                  [Page 11]

Internet-Draft            Mesh Schema Reference            November 2020


   {
     "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"}}}}}




Hallam-Baker               Expires 6 May 2021                  [Page 12]

Internet-Draft            Mesh Schema Reference            November 2020


   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.






Hallam-Baker               Expires 6 May 2021                  [Page 13]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 14]

Internet-Draft            Mesh Schema Reference            November 2020


   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.








Hallam-Baker               Expires 6 May 2021                  [Page 15]

Internet-Draft            Mesh Schema Reference            November 2020


   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.






Hallam-Baker               Expires 6 May 2021                  [Page 16]

Internet-Draft            Mesh Schema Reference            November 2020


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":[{



Hallam-Baker               Expires 6 May 2021                  [Page 17]

Internet-Draft            Mesh Schema Reference            November 2020


                   "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":[{



Hallam-Baker               Expires 6 May 2021                  [Page 18]

Internet-Draft            Mesh Schema Reference            November 2020


                   "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



Hallam-Baker               Expires 6 May 2021                  [Page 19]

Internet-Draft            Mesh Schema Reference            November 2020


     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.



Hallam-Baker               Expires 6 May 2021                  [Page 20]

Internet-Draft            Mesh Schema Reference            November 2020


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.








Hallam-Baker               Expires 6 May 2021                  [Page 21]

Internet-Draft            Mesh Schema Reference            November 2020


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.




Hallam-Baker               Expires 6 May 2021                  [Page 22]

Internet-Draft            Mesh Schema Reference            November 2020


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.







Hallam-Baker               Expires 6 May 2021                  [Page 23]

Internet-Draft            Mesh Schema Reference            November 2020


   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);






Hallam-Baker               Expires 6 May 2021                  [Page 24]

Internet-Draft            Mesh Schema Reference            November 2020


   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.




Hallam-Baker               Expires 6 May 2021                  [Page 25]

Internet-Draft            Mesh Schema Reference            November 2020


   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:

      +=====================+===================+===================+
      | Code                | Mesh Message      | Purpose           |
      +=====================+===================+===================+
      | "MessageContact"    | MessageContact    | Contact exchange  |
      +---------------------+-------------------+-------------------+
      | "RequestConnection" | RequestConnection | Device connection |
      +---------------------+-------------------+-------------------+

                                  Table 1

   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]







Hallam-Baker               Expires 6 May 2021                  [Page 26]

Internet-Draft            Mesh Schema Reference            November 2020


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]






Hallam-Baker               Expires 6 May 2021                  [Page 27]

Internet-Draft            Mesh Schema Reference            November 2020


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.








Hallam-Baker               Expires 6 May 2021                  [Page 28]

Internet-Draft            Mesh Schema Reference            November 2020


   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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-06.html for artwork.)

                                  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.





Hallam-Baker               Expires 6 May 2021                  [Page 29]

Internet-Draft            Mesh Schema Reference            November 2020


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.





Hallam-Baker               Expires 6 May 2021                  [Page 30]

Internet-Draft            Mesh Schema Reference            November 2020


   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




Hallam-Baker               Expires 6 May 2021                  [Page 31]

Internet-Draft            Mesh Schema Reference            November 2020


      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.



Hallam-Baker               Expires 6 May 2021                  [Page 32]

Internet-Draft            Mesh Schema Reference            November 2020


   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:

   0.  Creating a Master Signature key.

   1.  Creating an Online Signing Key

   2.  Signing the "ProfileMaster" using the Master Signature Key

   3.  Persisting the "ProfileMaster" on the administration device to
       the "CatalogHost".

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

   0.  Making the necessary changes.

   1.  Signing the ProfileMaster using the Master Signature Key

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





Hallam-Baker               Expires 6 May 2021                  [Page 33]

Internet-Draft            Mesh Schema Reference            November 2020


   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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-06.html for artwork.)

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




Hallam-Baker               Expires 6 May 2021                  [Page 34]

Internet-Draft            Mesh Schema Reference            November 2020


8.1.2.1.  Creating a ProfileDevice

   Creating a "ProfileDevice" comprises the steps of:

   0.  Creating the necessary key

   1.  Signing the "ProfileDevice" using the Master Signature Key

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

   0.  Generating the PrivateDevice keys.

   1.  Creating the ConnectionDevice data from the public components of
       the ProfileDevice and PrivateDevice keys and signing it using the
       administration key.

   2.  Creating the Activations for the device and signing them using
       the administration key.

   3.  Creating the "CatalogEntryDevice" for the device and adding it to
       the "CatalogDevice" of the Personal Mesh.

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



Hallam-Baker               Expires 6 May 2021                  [Page 35]

Internet-Draft            Mesh Schema Reference            November 2020


   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:

   0.  [TBS]

   1.  .

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

   0.  Creating a PrivateAccount instance for the device.

   1.  Creating a ConnectionAccountDevice for the device using the
       public keys from the PrivateAccount instance and the
       ProfileDevice.

   2.  Creating an ActivationAccount for the device containing the
       PrivateAccount and ConnectionAccountDevice instances.

   3.  Adding the ActivationAccount to the "CatalogEntryDevice" of the
       device.

   4.  If the Personal Mesh has accounts that are connected to a Mesh
       Service, synchronizing the "CatalogEntryDevice" to those
       services.







Hallam-Baker               Expires 6 May 2021                  [Page 36]

Internet-Draft            Mesh Schema Reference            November 2020


8.2.3.  Binding and Account to a Service

   Binding a "ProfileAccount" to a Mesh Service the steps of:

   0.  [TBS]

   1.  .

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

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-06.html for artwork.)

                                  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:

   0.  [TBS]

   1.  .



Hallam-Baker               Expires 6 May 2021                  [Page 37]

Internet-Draft            Mesh Schema Reference            November 2020


   2.  [TBS]


   4.  Signing the ProfileMaster using the Master Signature Key


8.3.2.  Creating a ProfileHost

   Creating a "ProfileHost" comprises the steps of:

   0.  [TBS]

   1.  .

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

   0.  [TBS]

   1.  .

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

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-06.html for artwork.)



Hallam-Baker               Expires 6 May 2021                  [Page 38]

Internet-Draft            Mesh Schema Reference            November 2020


                                  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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-06.html for artwork.)

                                  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.

   (Artwork only available as svg: No external link available, see
   draft-hallambaker-mesh-schema-06.html for artwork.)

                                  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.








Hallam-Baker               Expires 6 May 2021                  [Page 39]

Internet-Draft            Mesh Schema Reference            November 2020


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








Hallam-Baker               Expires 6 May 2021                  [Page 40]

Internet-Draft            Mesh Schema Reference            November 2020


   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}







Hallam-Baker               Expires 6 May 2021                  [Page 41]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 42]

Internet-Draft            Mesh Schema Reference            November 2020


     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



Hallam-Baker               Expires 6 May 2021                  [Page 43]

Internet-Draft            Mesh Schema Reference            November 2020


     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":[{



Hallam-Baker               Expires 6 May 2021                  [Page 44]

Internet-Draft            Mesh Schema Reference            November 2020


             "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":[{



Hallam-Baker               Expires 6 May 2021                  [Page 45]

Internet-Draft            Mesh Schema Reference            November 2020


             "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



Hallam-Baker               Expires 6 May 2021                  [Page 46]

Internet-Draft            Mesh Schema Reference            November 2020


     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",



Hallam-Baker               Expires 6 May 2021                  [Page 47]

Internet-Draft            Mesh Schema Reference            November 2020


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







Hallam-Baker               Expires 6 May 2021                  [Page 48]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 49]

Internet-Draft            Mesh Schema Reference            November 2020


     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",



Hallam-Baker               Expires 6 May 2021                  [Page 50]

Internet-Draft            Mesh Schema Reference            November 2020


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




Hallam-Baker               Expires 6 May 2021                  [Page 51]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 52]

Internet-Draft            Mesh Schema Reference            November 2020


     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



Hallam-Baker               Expires 6 May 2021                  [Page 53]

Internet-Draft            Mesh Schema Reference            November 2020


     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.1.  Classes describing keys

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.



Hallam-Baker               Expires 6 May 2021                  [Page 54]

Internet-Draft            Mesh Schema Reference            November 2020


   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.






Hallam-Baker               Expires 6 May 2021                  [Page 55]

Internet-Draft            Mesh Schema Reference            November 2020


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.



Hallam-Baker               Expires 6 May 2021                  [Page 56]

Internet-Draft            Mesh Schema Reference            November 2020


   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.



Hallam-Baker               Expires 6 May 2021                  [Page 57]

Internet-Draft            Mesh Schema Reference            November 2020


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.




Hallam-Baker               Expires 6 May 2021                  [Page 58]

Internet-Draft            Mesh Schema Reference            November 2020


   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.21.  Activation Assertions

11.2.22.  Structure: ActivationDevice

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

   Inherits: Activation




Hallam-Baker               Expires 6 May 2021                  [Page 59]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 60]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 61]

Internet-Draft            Mesh Schema Reference            November 2020


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.



Hallam-Baker               Expires 6 May 2021                  [Page 62]

Internet-Draft            Mesh Schema Reference            November 2020


   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]






Hallam-Baker               Expires 6 May 2021                  [Page 63]

Internet-Draft            Mesh Schema Reference            November 2020


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





Hallam-Baker               Expires 6 May 2021                  [Page 64]

Internet-Draft            Mesh Schema Reference            November 2020


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)





Hallam-Baker               Expires 6 May 2021                  [Page 65]

Internet-Draft            Mesh Schema Reference            November 2020


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




Hallam-Baker               Expires 6 May 2021                  [Page 66]

Internet-Draft            Mesh Schema Reference            November 2020


   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]




Hallam-Baker               Expires 6 May 2021                  [Page 67]

Internet-Draft            Mesh Schema Reference            November 2020


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




Hallam-Baker               Expires 6 May 2021                  [Page 68]

Internet-Draft            Mesh Schema Reference            November 2020


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




Hallam-Baker               Expires 6 May 2021                  [Page 69]

Internet-Draft            Mesh Schema Reference            November 2020


   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



Hallam-Baker               Expires 6 May 2021                  [Page 70]

Internet-Draft            Mesh Schema Reference            November 2020


   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.





Hallam-Baker               Expires 6 May 2021                  [Page 71]

Internet-Draft            Mesh Schema Reference            November 2020


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)



Hallam-Baker               Expires 6 May 2021                  [Page 72]

Internet-Draft            Mesh Schema Reference            November 2020


   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




Hallam-Baker               Expires 6 May 2021                  [Page 73]

Internet-Draft            Mesh Schema Reference            November 2020


      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







Hallam-Baker               Expires 6 May 2021                  [Page 74]

Internet-Draft            Mesh Schema Reference            November 2020


16.1.  Mesh Messaging


          +=======================+=========+==================+
          | 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         |
          +-----------------------+---------+------------------+

                                 Table 2




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, 27 July 2020,
              <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, 27 July
              2020, <https://tools.ietf.org/html/draft-hallambaker-mesh-
              cryptography-06>.

   [draft-hallambaker-mesh-discovery]
              "[Reference Not Found!]".



Hallam-Baker               Expires 6 May 2021                  [Page 75]

Internet-Draft            Mesh Schema Reference            November 2020


   [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, 27 July 2020,
              <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, 27 July 2020,
              <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, 27 July 2020,
              <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, 3 September 2020,
              <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, 3 September 2020,
              <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, March 1997,
              <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-



Hallam-Baker               Expires 6 May 2021                  [Page 76]

Internet-Draft            Mesh Schema Reference            November 2020


              hallambaker-mesh-developer-10, 27 July 2020,
              <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, 27 July 2020,
              <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, September 1998,
              <https://www.rfc-editor.org/rfc/rfc2426>.

   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
              Core Object Specification (iCalendar)", RFC 5545,
              DOI 10.17487/RFC5545, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5545>.
































Hallam-Baker               Expires 6 May 2021                  [Page 77]