Network Working Group                                 P. M. Hallam-Baker
Internet-Draft                                      ThresholdSecrets.com
Intended status: Informational                           14 October 2024
Expires: 17 April 2025


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

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 17 April 2025.

Copyright Notice

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




Hallam-Baker              Expires 17 April 2025                 [Page 1]

Internet-Draft            Mesh Schema Reference             October 2024


   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  . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.2.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Related Specifications  . . . . . . . . . . . . . . . . .   7
     2.4.  Implementation Status . . . . . . . . . . . . . . . . . .   7
   3.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Accounts  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.2.1.  Activation  . . . . . . . . . . . . . . . . . . . . .  11
       3.2.2.  Connection Assertion  . . . . . . . . . . . . . . . .  16
     3.3.  Service . . . . . . . . . . . . . . . . . . . . . . . . .  17
   4.  Catalogs  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     4.1.  Access  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       4.1.1.  Access Capability . . . . . . . . . . . . . . . . . .  22
       4.1.2.  Null Capability . . . . . . . . . . . . . . . . . . .  23
       4.1.3.  Cryptographic Capabilities  . . . . . . . . . . . . .  24
       4.1.4.  Publication Capability  . . . . . . . . . . . . . . .  25
     4.2.  Application . . . . . . . . . . . . . . . . . . . . . . .  26
       4.2.1.  Mail  . . . . . . . . . . . . . . . . . . . . . . . .  26
       4.2.2.  SSH . . . . . . . . . . . . . . . . . . . . . . . . .  33
     4.3.  Bookmark  . . . . . . . . . . . . . . . . . . . . . . . .  36
     4.4.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .  36
     4.5.  Credential  . . . . . . . . . . . . . . . . . . . . . . .  40
     4.6.  Device  . . . . . . . . . . . . . . . . . . . . . . . . .  40
     4.7.  Network . . . . . . . . . . . . . . . . . . . . . . . . .  40
     4.8.  Publication . . . . . . . . . . . . . . . . . . . . . . .  41
     4.9.  Task  . . . . . . . . . . . . . . . . . . . . . . . . . .  41
   5.  Spools  . . . . . . . . . . . . . . . . . . . . . . . . . . .  42
     5.1.  Outbound  . . . . . . . . . . . . . . . . . . . . . . . .  42
     5.2.  Inbound . . . . . . . . . . . . . . . . . . . . . . . . .  43
     5.3.  Local . . . . . . . . . . . . . . . . . . . . . . . . . .  43
     5.4.  Log . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
   6.  Logs  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
   7.  Cryptographic Operations  . . . . . . . . . . . . . . . . . .  44
     7.1.  Key Derivation from Seed  . . . . . . . . . . . . . . . .  45
     7.2.  Message Envelope and Response Identifiers.  . . . . . . .  45
     7.3.  Proof of Knowledge of PIN . . . . . . . . . . . . . . . .  46
     7.4.  EARL  . . . . . . . . . . . . . . . . . . . . . . . . . .  48
   8.  Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . .  48



Hallam-Baker              Expires 17 April 2025                 [Page 2]

Internet-Draft            Mesh Schema Reference             October 2024


     8.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  48
     8.2.  Mesh Profiles . . . . . . . . . . . . . . . . . . . . . .  49
     8.3.  Mesh Connections  . . . . . . . . . . . . . . . . . . . .  50
     8.4.  Device Pre-configuration  . . . . . . . . . . . . . . . .  51
   9.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  54
     9.1.  Mesh Account  . . . . . . . . . . . . . . . . . . . . . .  55
       9.1.1.  Account Profile . . . . . . . . . . . . . . . . . . .  55
     9.2.  Device Management . . . . . . . . . . . . . . . . . . . .  56
       9.2.1.  The Device Catalog  . . . . . . . . . . . . . . . . .  56
       9.2.2.  Mesh Devices  . . . . . . . . . . . . . . . . . . . .  57
     9.3.  Mesh Services . . . . . . . . . . . . . . . . . . . . . .  58
     9.4.  Mesh Messaging  . . . . . . . . . . . . . . . . . . . . .  59
       9.4.1.  Message Status  . . . . . . . . . . . . . . . . . . .  59
       9.4.2.  Four Corner Model . . . . . . . . . . . . . . . . . .  60
       9.4.3.  Traffic Analysis  . . . . . . . . . . . . . . . . . .  61
   10. Publications  . . . . . . . . . . . . . . . . . . . . . . . .  61
     10.1.  Profile Device . . . . . . . . . . . . . . . . . . . . .  61
     10.2.  Contact Exchange . . . . . . . . . . . . . . . . . . . .  61
   11. Schema  . . . . . . . . . . . . . . . . . . . . . . . . . . .  61
     11.1.  Shared Classes . . . . . . . . . . . . . . . . . . . . .  61
       11.1.1.  Classes describing keys  . . . . . . . . . . . . . .  61
       11.1.2.  Structure: KeyData . . . . . . . . . . . . . . . . .  62
       11.1.3.  Structure: KeyShare  . . . . . . . . . . . . . . . .  62
       11.1.4.  Structure: CompositePrivate  . . . . . . . . . . . .  62
     11.2.  Assertion classes  . . . . . . . . . . . . . . . . . . .  62
       11.2.1.  Structure: Assertion . . . . . . . . . . . . . . . .  62
       11.2.2.  Structure: Condition . . . . . . . . . . . . . . . .  63
       11.2.3.  Base Classes . . . . . . . . . . . . . . . . . . . .  63
       11.2.4.  Structure: Activation  . . . . . . . . . . . . . . .  63
       11.2.5.  Structure: ActivationEntry . . . . . . . . . . . . .  63
       11.2.6.  Mesh Profile Classes . . . . . . . . . . . . . . . .  64
       11.2.7.  Structure: Profile . . . . . . . . . . . . . . . . .  64
       11.2.8.  Structure: ProfileDevice . . . . . . . . . . . . . .  64
       11.2.9.  Structure: ProfileAccount  . . . . . . . . . . . . .  64
       11.2.10. Structure: ProfileUser . . . . . . . . . . . . . . .  65
       11.2.11. Structure: ProfileGroup  . . . . . . . . . . . . . .  65
       11.2.12. Structure: ProfileService  . . . . . . . . . . . . .  65
       11.2.13. Structure: ProfileMeshService  . . . . . . . . . . .  66
       11.2.14. Structure: ProfileHost . . . . . . . . . . . . . . .  66
       11.2.15. Connection Assertions  . . . . . . . . . . . . . . .  66
       11.2.16. Structure: Connection  . . . . . . . . . . . . . . .  66
       11.2.17. Structure: CallsignBinding . . . . . . . . . . . . .  66
       11.2.18. Structure: Accreditation . . . . . . . . . . . . . .  67
       11.2.19. Structure: ConnectionStripped  . . . . . . . . . . .  67
       11.2.20. Structure: ConnectionService . . . . . . . . . . . .  68
       11.2.21. Structure: ConnectionDevice  . . . . . . . . . . . .  68
       11.2.22. Structure: ConnectionApplication . . . . . . . . . .  68
       11.2.23. Structure: ConnectionGroup . . . . . . . . . . . . .  68



Hallam-Baker              Expires 17 April 2025                 [Page 3]

Internet-Draft            Mesh Schema Reference             October 2024


       11.2.24. Structure: AccountHostAssignment . . . . . . . . . .  68
       11.2.25. Structure: ConnectionHost  . . . . . . . . . . . . .  69
       11.2.26. Activation Assertions  . . . . . . . . . . . . . . .  69
       11.2.27. Structure: ActivationAccount . . . . . . . . . . . .  69
       11.2.28. Structure: ActivationHost  . . . . . . . . . . . . .  69
       11.2.29. Structure: ActivationCommon  . . . . . . . . . . . .  69
       11.2.30. Structure: ActivationApplication . . . . . . . . . .  70
       11.2.31. Structure: ActivationApplicationSsh  . . . . . . . .  70
       11.2.32. Structure: ActivationApplicationMail . . . . . . . .  70
       11.2.33. Structure: ActivationApplicationGroup  . . . . . . .  70
     11.3.  Application Data . . . . . . . . . . . . . . . . . . . .  71
       11.3.1.  Structure: ApplicationEntry  . . . . . . . . . . . .  71
       11.3.2.  Structure: ApplicationEntrySsh . . . . . . . . . . .  71
       11.3.3.  Structure: ApplicationEntryGroup . . . . . . . . . .  71
       11.3.4.  Structure: ApplicationEntryMail  . . . . . . . . . .  71
     11.4.  Data Structures  . . . . . . . . . . . . . . . . . . . .  71
       11.4.1.  Structure: Contact . . . . . . . . . . . . . . . . .  71
       11.4.2.  Structure: Anchor  . . . . . . . . . . . . . . . . .  72
       11.4.3.  Structure: TaggedSource  . . . . . . . . . . . . . .  72
       11.4.4.  Structure: ContactGroup  . . . . . . . . . . . . . .  72
       11.4.5.  Structure: ContactPerson . . . . . . . . . . . . . .  72
       11.4.6.  Structure: ContactOrganization . . . . . . . . . . .  72
       11.4.7.  Structure: OrganizationName  . . . . . . . . . . . .  73
       11.4.8.  Structure: PersonName  . . . . . . . . . . . . . . .  73
       11.4.9.  Structure: NetworkAddress  . . . . . . . . . . . . .  73
       11.4.10. Structure: NetworkCredential . . . . . . . . . . . .  74
       11.4.11. Structure: NetworkProfile  . . . . . . . . . . . . .  74
       11.4.12. Structure: NetworkCapability . . . . . . . . . . . .  74
       11.4.13. Structure: NetworkProtocol . . . . . . . . . . . . .  74
       11.4.14. Structure: Role  . . . . . . . . . . . . . . . . . .  74
       11.4.15. Structure: Location  . . . . . . . . . . . . . . . .  74
       11.4.16. Structure: Bookmark  . . . . . . . . . . . . . . . .  75
       11.4.17. Structure: Reference . . . . . . . . . . . . . . . .  75
       11.4.18. Structure: Engagement  . . . . . . . . . . . . . . .  75
       11.4.19. Structure: WorkTask  . . . . . . . . . . . . . . . .  76
     11.5.  Catalog Entries  . . . . . . . . . . . . . . . . . . . .  76
       11.5.1.  Structure: CatalogedEntry  . . . . . . . . . . . . .  76
       11.5.2.  Structure: CatalogedDevice . . . . . . . . . . . . .  76
       11.5.3.  Structure: DeviceDescription . . . . . . . . . . . .  77
       11.5.4.  Structure: CatalogedSignature  . . . . . . . . . . .  77
       11.5.5.  Structure: CatalogedDocument . . . . . . . . . . . .  78
       11.5.6.  Structure: CatalogedPublication  . . . . . . . . . .  78
       11.5.7.  Structure: CatalogedCredential . . . . . . . . . . .  78
       11.5.8.  Structure: CatalogedNetwork  . . . . . . . . . . . .  79
       11.5.9.  Structure: CatalogedContact  . . . . . . . . . . . .  79
       11.5.10. Structure: CatalogedAccess . . . . . . . . . . . . .  79
       11.5.11. Structure: Capability  . . . . . . . . . . . . . . .  79
       11.5.12. Structure: NullCapability  . . . . . . . . . . . . .  80



Hallam-Baker              Expires 17 April 2025                 [Page 4]

Internet-Draft            Mesh Schema Reference             October 2024


       11.5.13. Structure: AccessCapability  . . . . . . . . . . . .  80
       11.5.14. Structure: PublicationCapability . . . . . . . . . .  80
       11.5.15. Structure: CryptographicCapability . . . . . . . . .  81
       11.5.16. Structure: CapabilityDecrypt . . . . . . . . . . . .  81
       11.5.17. Structure: CapabilityDecryptPartial  . . . . . . . .  81
       11.5.18. Structure: CapabilityDecryptServiced . . . . . . . .  81
       11.5.19. Structure: CapabilitySign  . . . . . . . . . . . . .  81
       11.5.20. Structure: CapabilityKeyGenerate . . . . . . . . . .  82
       11.5.21. Structure: CapabilityFairExchange  . . . . . . . . .  82
       11.5.22. Structure: NamedService  . . . . . . . . . . . . . .  82
       11.5.23. Structure: ServiceAccessToken  . . . . . . . . . . .  82
       11.5.24. Structure: CatalogedBookmark . . . . . . . . . . . .  82
       11.5.25. Structure: CatalogedTask . . . . . . . . . . . . . .  83
       11.5.26. Structure: CatalogedApplication  . . . . . . . . . .  83
       11.5.27. Structure: CatalogedMember . . . . . . . . . . . . .  83
       11.5.28. Structure: CatalogedGroup  . . . . . . . . . . . . .  83
       11.5.29. Structure: CatalogedFeed . . . . . . . . . . . . . .  84
       11.5.30. Structure: CatalogedApplicationMail  . . . . . . . .  84
       11.5.31. Structure: CatalogedApplicationPkix  . . . . . . . .  84
       11.5.32. Structure: CatalogedApplicationOpenPgp . . . . . . .  84
       11.5.33. Structure: CatalogedApplicationSsh . . . . . . . . .  84
       11.5.34. Structure: CatalogedApplicationGit . . . . . . . . .  84
       11.5.35. Structure: CatalogedApplicationDeveloper . . . . . .  85
       11.5.36. Structure: MessageInvoice  . . . . . . . . . . . . .  85
       11.5.37. Structure: CatalogedReceipt  . . . . . . . . . . . .  85
       11.5.38. Structure: CatalogedTicket . . . . . . . . . . . . .  85
     11.6.  Publications . . . . . . . . . . . . . . . . . . . . . .  85
       11.6.1.  Structure: DevicePreconfigurationPublic  . . . . . .  85
       11.6.2.  Structure: DevicePreconfigurationPrivate . . . . . .  85
     11.7.  Messages . . . . . . . . . . . . . . . . . . . . . . . .  86
       11.7.1.  Structure: Message . . . . . . . . . . . . . . . . .  86
       11.7.2.  Structure: MessageError  . . . . . . . . . . . . . .  86
       11.7.3.  Structure: MessageComplete . . . . . . . . . . . . .  86
       11.7.4.  Structure: MessageValidated  . . . . . . . . . . . .  86
       11.7.5.  Structure: MessagePin  . . . . . . . . . . . . . . .  86
       11.7.6.  Structure: RequestConnection . . . . . . . . . . . .  87
       11.7.7.  Structure: AcknowledgeConnection . . . . . . . . . .  87
       11.7.8.  Structure: RespondConnection . . . . . . . . . . . .  87
       11.7.9.  Structure: MessageContact  . . . . . . . . . . . . .  88
       11.7.10. Structure: GroupInvitation . . . . . . . . . . . . .  88
       11.7.11. Structure: MessageMail . . . . . . . . . . . . . . .  88
       11.7.12. Structure: RequestConfirmation . . . . . . . . . . .  88
       11.7.13. Structure: ResponseConfirmation  . . . . . . . . . .  88
       11.7.14. Structure: RequestTask . . . . . . . . . . . . . . .  88
       11.7.15. Structure: MessageClaim  . . . . . . . . . . . . . .  89
       11.7.16. Structure: ProcessResult . . . . . . . . . . . . . .  89
       11.7.17. Structure: ProcessResultNotSupported . . . . . . . .  89
       11.7.18. Structure: ProcessResultNotFound . . . . . . . . . .  89



Hallam-Baker              Expires 17 April 2025                 [Page 5]

Internet-Draft            Mesh Schema Reference             October 2024


   12. Security Considerations . . . . . . . . . . . . . . . . . . .  89
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  89
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  90
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  90
   16. Informative References  . . . . . . . . . . . . . . . . . . .  91
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  92

1.  Introduction

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

   This document has two main sections.  The first section presents
   examples of the Mesh assertions, catalog entries and messages and
   their use.  The second section contains the schema reference.  All
   the material in both sections is generated from the Mesh reference
   implementation [draft-hallambaker-mesh-developer].

   Although some of the services described in this document could be
   used to replace existing Internet protocols including FTP and SMTP,
   the principal value of any communication protocol lies in the size of
   the audience it allows them to communicate with.  Thus, while the
   Mesh Messaging service is designed to support efficient and reliable
   transfer of messages ranging in size from a few bytes to multiple
   terabytes, the near-term applications of these services will be to
   applications that are not adequately supported by existing protocols
   if at all.

2.  Definitions

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

2.1.  Requirements Language

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

2.2.  Defined Terms

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



Hallam-Baker              Expires 17 April 2025                 [Page 6]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

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

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

3.1.  Accounts

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

   ProfileUser  Describes a user account.

   ProfileGroup  Describes a group account used to share confidential



Hallam-Baker              Expires 17 April 2025                 [Page 7]

Internet-Draft            Mesh Schema Reference             October 2024


      information between a group of users.

   Both types of profile specify the following fields:

   ProfileSignature  The public signature key used to authenticate the
      profile itself

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

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

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

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

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

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

   For example, the personal account profile Alice created in

   For example, Alice creates a personal account:

   Alice> meshman account create alice@example.com
   Account=alice@example.com
   UDF=MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36

   The account profile created is:












Hallam-Baker              Expires 17 April 2025                 [Page 8]

Internet-Draft            Mesh Schema Reference             October 2024


   {
     "ProfileUser":{
       "CommonSignature":{
         "Udf":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"IMyMo7fEy2vHp8syQ0VU4XivpJEhgQQSX3j8mva4HC_T0
     5UnhQYqVZyuvIQEVo2dyMCRm60Q3E0A"}}},
       "AccountAddress":"alice@example.com",
       "ServiceUdf":"MBQD-ETXU-HZRW-A26O-WDTR-K7GI-X6JD",
       "EscrowEncryption":{
         "Udf":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"1vNUAAp3rszIphG8EsfoaO5Y6sZCn0Hc8zCgdQivYpJAc
     DtmkSsCeI2gmDTCK6SrS1UgPtuYmTwA"}}},
       "AdministratorSignature":{
         "Udf":"MD2L-6M7C-Z3Z3-Q3AL-JFYI-ZIUC-BKUR",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"bHoKb0c12F7cibM_3gZcJXMzOOX4snHgPVwOfRYk6ARJO
     sGPemsd2Bm0WfmAkRYO3EQ6fj8_NzSA"}}},
       "CommonEncryption":{
         "Udf":"MAYF-D7LJ-5IMP-EUCG-HSGH-7LSR-AAPZ",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"c7oorJ808sc9d40KXDhIHgCTFz39MK3JjO0Q7K_ufDEGD
     KiwVKhd3oPQ44PEqGjwkpp7OfbcBbSA"}}},
       "CommonAuthentication":{
         "Udf":"MAFT-SINA-SFXI-PBDY-WRHE-NXYL-DXVT",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"XcgEz9y2cqsx4ZebGERTjrN-xzN83D-pcx0651x-WUCqY
     NrsnzTH40CpoMxuN-FnpT5m_b0MyuKA"}}},
       "RootUdfs":["YBJR3jR2PljdYk5qxbWdHY0rTYEaFAkHY3MmsR8zvN1Dr33Rn
     LUL3ThrG9DMWBZ3P-8ZyGzyKaQYweco2ZUtcKw"
         ]}}









Hallam-Baker              Expires 17 April 2025                 [Page 9]

Internet-Draft            Mesh Schema Reference             October 2024


3.2.  Device

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

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

   ProfileSignature  The public signature key used to authenticate the
      profile itself.

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

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

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

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



















Hallam-Baker              Expires 17 April 2025                [Page 10]

Internet-Draft            Mesh Schema Reference             October 2024


   {
     "ProfileDevice":{
       "Encryption":{
         "Udf":"MB5H-7FO4-AZRD-OJHX-OUZG-XHVG-KH2C",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"PhO96KmXS1Sui4SYmM75-4prHdG-am-TnSFcmsc9uKWhw
     Vr2RimLPVpI5se5aU1Jeo0s7-dyv_eA"}}},
       "Signature":{
         "Udf":"MCUP-MUZ6-5D5T-5KWI-HV57-7BDX-TFEI",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"NrPD354a6P1EkIUlaPHdo3PnEmNqY4P7q-UB0LANce0am
     Ail6vdx5F7VYGZthntsCBRmO6EzBD2A"}}},
       "Authentication":{
         "Udf":"MAZI-3SYG-RZ2X-TQDP-SL63-4OHD-5OTW",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"wFMa92pypOQLQPZpZfkUlx6S4OEjJfXsG5i1XBaO7QxZg
     zZoIynMpJ8eiqEWr84MHjmXk7U_UVkA"}}},
       "RootUdfs":["YOQFOuBha6ISPv3BO5hV5VcCfsP4CPiBYhzK1T2FktsOEtZ_T
     TQQIaoOnfMEzFMpnwTMLpEtHQV60gZdRAQ7gwU"
         ]}}

3.2.1.  Activation

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

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

   Alice2> meshman device complete
      Device UDF = MBQO-4TTM-QOTS-MKEG-XQTU-XNFM-WUWM
      Account = alice@example.com
      Account UDF = MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36




Hallam-Baker              Expires 17 April 2025                [Page 11]

Internet-Draft            Mesh Schema Reference             October 2024


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

   {
     "ActivationAccount":{
       "AccountUdf":"MBQO-4TTM-QOTS-MKEG-XQTU-XNFM-WUWM",
       "ActivationKey":"ZAAQ-HGFE-VOLA-P6ZX-JZE4-EZ4C-DXGM-TLP6-TEO2-F
   RZG-QWVW-N7KB-NTFB-F2PC"}}

   And:

   {
     "ActivationCommon":{
       "Encryption":{
         "Udf":"MAYF-D7LJ-5IMP-EUCG-HSGH-7LSR-AAPZ",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"c7oorJ808sc9d40KXDhIHgCTFz39MK3JjO0Q7K_ufDEGD
     KiwVKhd3oPQ44PEqGjwkpp7OfbcBbSA"}},
         "PrivateParameters":{
           "PrivateKeyECDH":{
             "Private":"raIIVpKe7NlAykMg0rPWUHzL9LnCy4ScwprV5eySGKGG
     Ab7nyjN8rbDM-opg8xVBV_dXkEKqE3I",
             "crv":"X448"}}},
       "Authentication":{
         "Udf":"MAFT-SINA-SFXI-PBDY-WRHE-NXYL-DXVT",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"XcgEz9y2cqsx4ZebGERTjrN-xzN83D-pcx0651x-WUCqY
     NrsnzTH40CpoMxuN-FnpT5m_b0MyuKA"}},
         "PrivateParameters":{
           "PrivateKeyECDH":{
             "Private":"dXpwcov9RC5WhoBy892-kQjM3MjM0ddEk9sCcjobjwxj
     0u9khiVzsHiPqc1ufphftj0Zzv9C05I",
             "crv":"X448"}}},
       "Signature":{
         "Udf":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"IMyMo7fEy2vHp8syQ0VU4XivpJEhgQQSX3j8mva4HC_T0
     5UnhQYqVZyuvIQEVo2dyMCRm60Q3E0A"}},
         "PrivateParameters":{
           "PrivateKeyECDH":{
             "Private":"19gC3rbly9Y-D-OtdKPQvar-X7WhDb9IAezvuWotnELc
     tO8Ic4BTWq2MSKcAk3lhMOKezRy_s7Y",



Hallam-Baker              Expires 17 April 2025                [Page 12]

Internet-Draft            Mesh Schema Reference             October 2024


             "crv":"Ed448"}}},
       "Entries":[{
           "Resource":"Contact",
           "Key":{
             "Udf":"MAYS-HKIQ-VCQL-6MUD-ASPW-Y3OT-BLVW",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"2-LI9YOozzShdL-nfu7WJDsedbsOyRw0nEEor3-xj
     UvAxJPS_VptsleZUg7u1jcLy3JMUQCFdGMA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"A3gNBuZ0xVggNIF6G6aftBhIeliF9IZCbn_KURJP
     M9srop-v3BfNjvkUDS29iPubM7-_OkrdlXE",
                 "crv":"X448"}}}},
         {
           "Resource":"Publication",
           "Key":{
             "Udf":"MD7I-NZQC-FAUT-EHTA-WQQA-Y4YP-L5YR",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"JwemETcr0SYLj_UWf5focJPoINqhfYxvM7l4Kn9yy
     UB6u7avc2WpEkNn6qJQFCYJEtaNR1n8OnaA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"JIVLbaj2PU9KZb6O7HPfR8z9RufcLx8bbIbCgE4h
     6aoCqGdrAz8C99i554Kdr6Nrm7K4NrYSCgk",
                 "crv":"X448"}}}},
         {
           "Resource":"Inbound",
           "Key":{
             "Udf":"MBZU-KE6J-TYNI-HXJL-ZW7W-WNLU-MQHF",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"035fQLltWxs7fJYOK4BrmcFTnLwTPhmNnyXBbpuG_
     w_jnCJJYjsTi7RExq2idvkJACnj7jz8TfsA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"dNVMbq-Q0aYujHbpGKjqeYlRZJF4dgwlUkGlRNDs
     VxQW0BKIPCcWEZVS0_waS8uO_Cv7BqG03Xg",
                 "crv":"X448"}}}},
         {
           "Resource":"Outbound",
           "Key":{
             "Udf":"MAJP-XDZ7-4WK5-CBVG-AAN4-SUVN-FWUT",
             "PublicParameters":{



Hallam-Baker              Expires 17 April 2025                [Page 13]

Internet-Draft            Mesh Schema Reference             October 2024


               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"oMblSsk2vfcnjsSTLBR_17PUMJQlVCnXvRzFzXx7r
     tIbEmUj65hHlF6oT54IQJ9IaSQrQlZfNEAA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"8M43qEAlZ1x3j8TTdWxPt4Htt-sB3oWjBd0645wA
     dlejcjNiD4UBz8nBVuusYtXln04GEmiFZ4U",
                 "crv":"X448"}}}},
         {
           "Resource":"Network",
           "Key":{
             "Udf":"MARE-FHHS-74PF-LSN2-K4HO-26SC-YDQG",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"IFi9wVeI1vSj_hGcL2Lk0Kv5BWWXITvuy4Qg999aS
     K4jPen-E8wqzJPAPaxSzbbD64zAcgKOWzuA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"TXyKjn5pSVgmTawLEQDiudySemfHxHxRboLyPNB3
     q2HNysiaDFJT4rpGVijePPApOAWuvyRWtec",
                 "crv":"X448"}}}},
         {
           "Resource":"Application",
           "Key":{
             "Udf":"MDSC-47UI-TFUH-P6V5-QNI7-UW3Y-5YZV",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"3jQ2DNaUz5JkJYCRptcJh_jV2vQm_QCbdHQIoNcxu
     42PClekweR9TtQ0oUhP4R3A5irxVIgCPPAA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"N21lQKGlBzcge-0GZudkOmivKiiyxhBlE9-Tloqg
     E2JqC-MPyQXXB3o23MjyAyb5lTbxHcqPQ5w",
                 "crv":"X448"}}}},
         {
           "Resource":"Credential",
           "Key":{
             "Udf":"MDFG-UKLG-VUPZ-XAY3-BDMH-FI35-RW3Y",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"kVrnMmX7RDcikA8LCHrX1c8e_TEKo17gvAWpVvh36
     bRRf2hIQLdWFb7JG8zbHqjODuMzhTdfLeEA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{



Hallam-Baker              Expires 17 April 2025                [Page 14]

Internet-Draft            Mesh Schema Reference             October 2024


                 "Private":"wRDSEDUGGiyjK7-uBHoNTCpn6ON6SaUUTEzK1ZUJ
     QUP3lqYjP0U816YEk7FInDyNuSD_CSesjHU",
                 "crv":"X448"}}}},
         {
           "Resource":"Task",
           "Key":{
             "Udf":"MALW-PHPA-PCXM-W3DU-WMPU-XCEW-YAM7",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"sbOJcelezmPlW-RNZYyvG0-C4fwxecksenqB8okSK
     fiihirXl01I-jtP1MRvN47QdXqzgjKqL9QA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"TOD3L2wkwDHT878UOcZERxcaVVE37UQupHbQU_bY
     BB-vcl5uKdMJNVqwwF1_LeG87zYUiOMS9S4",
                 "crv":"X448"}}}},
         {
           "Resource":"Bookmark",
           "Key":{
             "Udf":"MDZV-J4CB-QLA5-K6GU-GGP2-OAXS-3FB6",
             "PublicParameters":{
               "PublicKeyECDH":{
                 "crv":"X448",
                 "Public":"nEw2RAKhuQN2RJUi9_XmVy_aLVGpM7n6dd-rk_I2Q
     RmfFZYZRLtab_yRE-5A6HfgfsFndUbnOfQA"}},
             "PrivateParameters":{
               "PrivateKeyECDH":{
                 "Private":"QjrRmPp0wcYgC4z-vgyr_BQfbZwCOzwbl2GQZyBe
     0RDtHQQuigxURbfpoqcxV0tWJ_p4rkrcBQk",
                 "crv":"X448"}}}}
         ]}}

   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.







Hallam-Baker              Expires 17 April 2025                [Page 15]

Internet-Draft            Mesh Schema Reference             October 2024


3.2.2.  Connection Assertion

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

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

   {
     "ConnectionDevice":{
       "Roles":["message",
         "web"
         ],
       "Signature":{
         "Udf":"MBPI-BITH-EPYS-3FYE-E35S-NDB3-VTP4",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"Y46EhbDyrvyXR2rxUE3tdjUjBHow3KIVzJ6K0PxrZDFPE
     Qkrna4Q_LG9g3LBwAn9BkyFFszknh0A"}}},
       "Encryption":{
         "Udf":"MCBL-DEQY-N5WP-FY2B-SGYT-6PH3-LTZV",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"tfB8Ulcsp7A8OuymEMZtCe45ktAJGvnFeATg9n-QB81dU
     Zsxc3IGA0Gh7khkNhLBfvd3KH-a95OA"}}},
       "ProfileUdf":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
       "Authentication":{
         "Udf":"MB7K-AWT2-34F5-TVCT-BV2K-VMRH-JKVS",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"5zHjLDHVNHALaDaO0YyASwifAmiNGTtJG-LrCsA5Oyx6i
     UVJ4Xu4WUAN_smNBRg8k85_qaMkHuYA"}}}}}

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




Hallam-Baker              Expires 17 April 2025                [Page 16]

Internet-Draft            Mesh Schema Reference             October 2024


   The corresponding ConnectionService assertion is:

   {
     "ConnectionService":{
       "ProfileUdf":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
       "Authentication":{
         "Udf":"MB7K-AWT2-34F5-TVCT-BV2K-VMRH-JKVS",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"5zHjLDHVNHALaDaO0YyASwifAmiNGTtJG-LrCsA5Oyx6i
     UVJ4Xu4WUAN_smNBRg8k85_qaMkHuYA"}}}}}

   The ConnectionDeviceassertion 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 ConnectionDeviceassertion MAY be used to mediate external
   interactions, this approach is typically undesirable as it provides
   the external parties with visibility to the internal configuration of
   the account, in particular which connected devices are being used on
   which occasions.  Furthermore, the lack of the need to interact with
   the service means that the service is necessarily unable to mediate
   the exchange and enforce authorization policy on the interactions.

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

3.3.  Service

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












Hallam-Baker              Expires 17 April 2025                [Page 17]

Internet-Draft            Mesh Schema Reference             October 2024


   {
     "ProfileService":{
       "ServiceAuthentication":{
         "Udf":"MDYI-I2BH-HML3-H6YK-GNYW-JJXF-NVDH",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"gH6QMyYx5qfORaNNvsZyR83BM0anEj-VqCoL-6k_BhdFY
     Q8Qpro58p0hrTRMTLZrrBdWpjtPKiuA"}}},
       "ServiceEncryption":{
         "Udf":"MA4L-UE5A-E4VG-UGRK-TVT2-3LHG-Y7NV",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"KPrn6aPtRHGLbI2aEHzI_dtPDgaGMSSLxkD_dWsTBYVE1
     KfT3kAOqR29P82C-NrtZapnwxZfFTgA"}}},
       "ServiceSignature":{
         "Udf":"MC6L-T5P6-UZCQ-RRD7-VMJM-E2KQ-AZHE",
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"Ed448",
             "Public":"y5a7XXdof_Azi8ueTddSIZx9fFgD7ZfXBT9-N6e5qeB_p
     QtnurylRNxe2w5HrCV9sYz2jr3u4XqA"}}},
       "RootUdfs":["YBLkkXVQbdqea81QVIkppp0DOBttJFcoTI7UVewreuMBAJ3z6
     nMmf31Fb4hFy-OJjYWh95E0spNUvPjMjw3NopA"
         ]}}

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

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











Hallam-Baker              Expires 17 April 2025                [Page 18]

Internet-Draft            Mesh Schema Reference             October 2024


   {
     "ConnectionService":{
       "ProfileUdf":"MBQL-QXMC-6B6G-6RF3-BCJN-CDNU-N2K2",
       "Subject":"MC6U-BVUM-RRCG-OM6V-HB63-4BCG-TVRL",
       "Authority":"MBQD-ETXU-HZRW-A26O-WDTR-K7GI-X6JD",
       "Authentication":{
         "PublicParameters":{
           "PublicKeyECDH":{
             "crv":"X448",
             "Public":"fjAiJJe143FCODQ70z5RT-IT7MJ_SbHqs1sKk8JJ1WjUx
     cFyjOsYmG74_UbHIeM7vwZjCQJ2eQ6A"}}}}}

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

4.  Catalogs

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

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

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



Hallam-Baker              Expires 17 April 2025                [Page 19]

Internet-Draft            Mesh Schema Reference             October 2024


   Contact: mmm_Contact  Describes logical and physical contact
      information for people and organizations.

   Credential: mmm_Credential  Describes credentials used to access
      network resources.

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

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

   Member: mmm_Member  Describes the set of members connected to a group
      account.

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

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

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

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

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








Hallam-Baker              Expires 17 April 2025                [Page 20]

Internet-Draft            Mesh Schema Reference             October 2024


4.1.  Access

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

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

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

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

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

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

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

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

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

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

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



Hallam-Baker              Expires 17 April 2025                [Page 21]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

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

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

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

4.1.1.  Access Capability

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

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

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

4.1.1.1.  Operation Rights

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

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

   mmm_o_UnbindAccount  UnbindAccount

   mmm_o_Connect  Connect

   mmm_o_Complete  Complete



Hallam-Baker              Expires 17 April 2025                [Page 22]

Internet-Draft            Mesh Schema Reference             October 2024


   mmm_o_Status  Status (of specified catalogs or all catalogs)

   mmm_o_Download  Download (of specified catalogs or all catalogs)

   mmm_o_Transact  Transact (of specified catalogs or all catalogs)

   mmm_o_Post  Post outbound message

4.1.1.2.  Messaging

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

   mmm_m_Contact  Contact messages from the specified subject.

   mmm_m_Confirmation  Confirmation messages from the specified subject.

   mmm_m_Async  Asynchronous delivery messages (e.g. mail)

   mmm_m_Sync  Synchronous delivery messages (e.g. chat)

   mmm_m_Presence  Forward presence request.

   The following media are defined

   mmm_c_Text  Text that MUST NOT contain links or external references

   mmm_c_Linked  Text that MAY contain links or external reference

   mmm_c_Audio  Audio data (e.g.  VOIP, voicemail)

   mmm_c_Video  Video data

   mmm_c_Code  Content containing active code including macros, scripts
      and executables.

4.1.2.  Null Capability

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








Hallam-Baker              Expires 17 April 2025                [Page 23]

Internet-Draft            Mesh Schema Reference             October 2024


4.1.3.  Cryptographic Capabilities

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

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

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

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

   The following service cryptographic operations are specified:

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





Hallam-Baker              Expires 17 April 2025                [Page 24]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

4.1.3.2.  Key Agreement

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

   This operation is used

4.1.3.3.  Threshold Signature

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

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

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

4.1.3.4.  Fair Exchange

   Perform a Micali Fair Exchange trusted intermediary operation.

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

4.1.4.  Publication Capability

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










Hallam-Baker              Expires 17 April 2025                [Page 25]

Internet-Draft            Mesh Schema Reference             October 2024


4.2.  Application

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

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

   Two applications are currently defined:

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

   SSH  Secure Shell Client.

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

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

4.2.1.  Mail

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

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






Hallam-Baker              Expires 17 April 2025                [Page 26]

Internet-Draft            Mesh Schema Reference             October 2024


   {
     "CatalogedApplicationMail":{
       "AccountAddress":"alice@example.net",
       "InboundConnect":"imap://alice@imap.example.net",
       "OutboundConnect":"submit://alice@submit.example.net",
       "SmimeSign":{
         "Udf":"MCCJ-IANC-HEWS-7XZI-OR72-ZFC4-SCQL",
         "PublicParameters":{
           "PublicKeyRSA":{
             "n":"ujaNN0wJkcUTdJLUHPgHjzIliAMp_6-I1BwqAzaW3zIRto2aRQ
     i6oMGjqigiFq4BMt-9Jo4YAYd655FgebcfC82bu2v8kQyNJ3zUdoblMUDOFrTRffc
     zo_9h1zyBzGAnYzbGYPiEIjOubceFwlH-ZmY_3VzmWWkIuhFhgExvWQm_Ej05yyx4
     Tl8fh8TA5k1jSZM2VYTVr_3pqUXWxivDvRSFUbT6_tWH8l8WtxbDToMq70bECWW2T
     zOZ_mBTBGx4H5qXkO2upWadEtlMFOhlEfBhAOx9yBE4_TmAT-_YWJxvaCtcy-6FlN
     DWKl5J0HJ_56DP9bZJAtxPSn0-20jT9Q",
             "e":"AQAB",
             "kid":"MCCJ-IANC-HEWS-7XZI-OR72-ZFC4-SCQL"}}},
       "SmimeEncrypt":{
         "Udf":"MDO5-36TO-HN5V-6SZ5-MD5B-63BZ-737K",
         "PublicParameters":{
           "PublicKeyRSA":{
             "n":"rDdENxO4dTXs-G2Esue3P0lym8e-WF3sKyv2eOP5Dn_IBRlJiS
     wbPWzfj9gMPE8z0Yx80RUwQ0AmyiACD6nPRHOtVPIzF3OFuwFZjMvDdY4Tkgg60dd
     BOV6X_U3fCzA_aThwFU8sQXw69imT6GnLpYf0Wt2AEojFY8rEStVC2yZRqPxcbXo2
     1aTHwgoyly9LmhmHmxSJ3XqJNq0OJNWG19UXy3qHyRG_SvsKsN2I-AlxDBBno3m1M
     vvzmYwM-XCYkXDbeCtyiPOqD4UPj-XPryBx00-aOFozP6T2WncC7xi48MPq3AK0bp
     K9HnqRccSCpFCEW1L1sqFNoB5HinhOyQ",
             "e":"AQAB",
             "kid":"MDO5-36TO-HN5V-6SZ5-MD5B-63BZ-737K"}}},
       "OpenpgpSign":{
         "Udf":"MAII-NUGV-FX7P-IAQ2-UXZ3-CP3J-6MKN",
         "PublicParameters":{
           "PublicKeyRSA":{
             "n":"wgbGU8SvN9kyykGSaAcsOpA9x6m3axF1vnGk1O_sedVRTrK5jB
     I-EbVL-nFthAMh1TqO25sh5kJYZTX43pfpEUOeyoNo_U5uQf6n1bskQjkdpjMG3xR
     TNzCOajO_NnyuETebUuNkBNoPQZEw9BcwbJIGiqH63vZyM-TiZ6r8vPNoeTCmlOtz
     u9heJ0ULAs4K7yiGNmfto5YdAOBgMrd27_a-kLIRusmPBrPq2kFIYSlP_z9VKKKra
     PWv4vskwHPb3UGF4fc_aL2hfSIDxn4jif9Uq_GUSHNO5xLlKCqFgq5tHCxD_5oK0k
     H-CJF9xnyqFolyZDaAVBWEeDEUEUZPcQ",
             "e":"AQAB",
             "kid":"MAII-NUGV-FX7P-IAQ2-UXZ3-CP3J-6MKN"}}},
       "OpenpgpEncrypt":{
         "Udf":"MB74-LYO7-NBVD-EZ3E-7ADE-AR4N-2AY7",
         "PublicParameters":{
           "PublicKeyRSA":{
             "n":"8Ygw69BbA8aPA2m24HqBfV6o9pJtbx8PoJLIszlROyRQZy_CxY
     v0gCsh5oKEVxAdTV5m_u7rgZOuSuwsMe-8HjTfbgBpL1pfuu76Ih-5KBsoJvWH5Ag
     dYJV2HrLxuHi4BvVZbD3DckOEtMPU03paGmHF7V6SISGfGLvlmpsIwhw-44EjMVPZ



Hallam-Baker              Expires 17 April 2025                [Page 27]

Internet-Draft            Mesh Schema Reference             October 2024


     GD_Y-4eF6FmN2wVb0SjAmc9pUKUG5pNj6-HmM-d0pGFFjwrGW2L2-NVhPy29z9spZ
     4DZq17Xi-HqCq5acAdbd3AN-B0UCJkYhoperKT8x3CUyluLE0Y-Edn3NXTXBCxTlQ
     86aAhwuHQx9nahW7KaHR8VYwfGyr7L_Q",
             "e":"AQAB",
             "kid":"MB74-LYO7-NBVD-EZ3E-7ADE-AR4N-2AY7"}}},
       "Key":"mailto:alice@example.net",
       "Grant":["web"
         ],
       "EnvelopedEscrow":[[{
             "enc":"A256CBC",
             "kid":"EBQI-M6QR-LVYR-SCFV-XSFJ-EJLN-HS7F",
             "Salt":"4XORHvoh7KKpsffW8AqIlg",
             "recipients":[{
                 "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
                 "epk":{
                   "PublicKeyECDH":{
                     "crv":"X448",
                     "Public":"olkRv5dHpel7vSLrt0X4_prek7ZL3bXATFnvp
     nUw8EtlYvXDko5QBCkPuZeicmBZuFzqo81869-A"}},
                 "wmk":"f1ztYcg-UkEnjLFN4uHFPxi_pO425ANr3hsI_A-4dp0w
     ZHhDfAO1bw"}
               ]},
           "vxZ7o219ECnin-AdOfCgnR4OknBud7h9kAZk1tjWYMfFSrDSQorTDDwg
     6o1IqpG77rB-n5Qmv-33edsRoxSmUcNaLSjeSv5TaocuYw6KbFLV-nQZGTzzcMp4N
     aU4YwEAhalBwrBfkyOOSmegVjxm4edPRkAnDsZ8rxgodl1btYVwJJMWoSuclMmRE-
     DKaT0yyTh9X0RLXLv8GVe0yUlVKafcm3hoQ5M5U5rzW2MenoDBzY6oFOR_OJXvcJ_
     -_xreztE8oj-modyUY3fpxYmbEVM_mrw1nsYWDik_qZ5CJlPFvPaVEEtEfWtqbowK
     xgGLTCLm8E00z3iZPKWFOrjh0nIgGAZJfKBikIzLIb0romccHCT8OI8feAfM2ytz-
     ymk_aat6I21n5SM9ltm8P5OGsAT9v1gS-v8x-OJCSKLnfS7No86Re1WCr1z790N1f
     gDM89OzchpQHS-EzM73PGb2VdqNGSp_4VjLk2EAJ5JkeNBktOO1kZQWoA4dfhxR41
     6hE7uiGxg4o4uP81eUGPfzHvFxwwvo8GoMSQ91OECfHzvNzcg2zDLUgpzIc6QtqSH
     NYkqH3BI3GhAjDMKtMz9qX2DZ0r7mOwzmD6ith6AhA1X_Jtuo2Gqi6JLb_FbPLdlf
     Js9HN5HDl2Ns3i4S7KjG6eTEG9sZQb1EnZo1JSDg0Yt9iAwjJ4O0qs15Y2QLpkn8X
     hiimlOLCWaAW2NoxkoViSpLjn8Pn9DVWOcw8-1_jDdlO8n0B5S5i3N_jDY0iY8T4c
     qi4LuC6IivrmIr4kHwWOB9lYjQlJO_oHjBoO7wOqeub_YG8EhSNM-CBaYDEP7DU31
     Nph2lVqLeZWQh3NbdfXS5oE8PAFrdc1TsS8Hvqi6-9xfc0hLoH_zCluX09DP1a7gN
     miq9-kkAEcSRPLJ0-IN57olUKCajmGOviQySO7Nf5qBm5J7GKDqsxIWhBBpe6JHXM
     p2Dc6YgfTrNBFhQAa7clb5UT553XFTskfF6KwzQObEzuAFeAIfeKZndt4veSgDJHL
     -F_02NGKO8deQJ6S2T7CGJLLjec9jskQy07T6jJDoH9lebDTO8OtX2n6k5USBZsYy
     4C1XnPk27MVA_lTIpr8d2uUM__m4q3cTpe92ygicGIopViiqGccwgPblHMksUoLHc
     kZ2uCd1CO181cZ9JF0abEtFegEe0WoH81tq7wTBFIMHxL6JYQnTrXkmo3o06LSaNx
     5QkwF1HndTBMdCgy-OZR7KNyBWr9v3SnV4e1MvTU4mJG7YlyxUInXubhjevv5vo4D
     aMz7BfegeeGLKYYOQOJTgHkcFuWaoHxSs9PLVmnjUl8B1EhuDRYXEpiagZ0e6lMhL
     nhatKd_LjGse91ax5BEnquoQN_XU4yM2g8m_FqO5yy5v1E-UPuGuI70u5burwoLEd
     ZFgoh08e9n0INJja4WgzZkjTe5gTmgtP85cCwtiyws9d3kkbxI9S7NFUP5Ws7xSBz
     _Ox3hsODPaBvBrkl-4-6REESus47pCoB9z8YIC6YD0hCYTi67E6oHvzEogOYaLpT7
     JzBtpRhE6orPK44OOKtWbpgxgwQ7TROK2ReWdKhCr8EtpyqogxZ9_OX07al-lppfC
     OeBUHB_P1RQ9AiE5hHjmXxTFu3iJcRFE7UxTePv2P5NCofBeqYHA0u-xziSyoHswa



Hallam-Baker              Expires 17 April 2025                [Page 28]

Internet-Draft            Mesh Schema Reference             October 2024


     R7Z6q3FNzA9M_kujDZh3ukF5um3PEltaHBjmSMWE9RFvgVqq0UVF1Y1zeVuxcFaqN
     T_OGbxTReiymDpWYsD0gUgQ3J-zzFk1QZPBQbCJsUwbiE6VPBVEKb_NBRxOdhFH1Y
     _UxaAnvL1YHjVBeDwy3hNXGYQJdxQc6vH2onZtZpthvfMKh9r0UIbLQ3gyoDItGJj
     N2WId3CssskJh29T0Unv5Epa-pRgVqEUWyKvEWm-P-glwdTeO_Q56WrE63UJukURn
     M9pKBqxR9AgiH95jJpTGiEKXtpoox1LllWWYTHg2V-SvV7Lyjkt3eOEYb-GErAopy
     ehB5sxLuGqCXxEfd2l_GXPhkt7EKQxC_6nxkkOatJgh5zUSj5grJckxmet04OONUr
     apS6tuG78Tmlinfki0xedSo9kKl_gBLaaI6MCEYrrDC7y1U39pGFusa0qr9-3ocYp
     v3MbdBe58IKV1yWBH3fzDxxjiHZjrBKjlTvjv5xgagxFn3dowEh1OOqoAl3FBXD6A
     iPHZB1buWkuBZFWygawj_ORMvNQSCYJ9vQ4iqpqTxNDu23Kh2_IwdgMw9T5XlQXJ0
     Tcd0z7HYLEskjnWl7ierMFjzawbgxaE1nDiK2nm7D519EHpDdKevchnDOjx28Cojo
     hAPWT7hykOSubdfmxpXFKG2nHI0zxIZJQKQqJQ2cE7Row5r_vxXnmbrcOPbsU0XH1
     VmvYUrxsLbbny5qpnxFK1wBvRxRx5QqZedVeso1AN3vrhfAkNVtm7Nds1kySjShFX
     MCJsXQq8umUyMEAOLFn0AqJedR-jXGR_p5ALu3SsDfpBjk-l7eCE6F-G6F4ffdEYQ
     jr-qLvO1c4D94yY5wd_1wQXaXjTyAXKlcxOX0MgGaR294OQQuHge2gFXueHGVS7n7
     kc9QJL66MQ1WtwLe9vquNVA3827vN7rz79BVINhL7J2TNbI8vV_tvP7OVlOlG6bT2
     P0FuFBoT0546_xwCKC-nPkcpjRk9-qHJXr6eQV7tiWEHJL6g813VoOjdXBB0oEIVB
     cE7_oIhPfz3VJyIETGroZSJYgzCCRDuHU4KsUsFXm9vzrkvqGmbgv52zCcVP3BAVG
     G_RZIe-9BbSP-G_QdQ30vKJqKa2Lzblk4jwMDTjcH-VH-tJrt3h2zVIirshEYiwZR
     0cXj8DOxoE7idqDYH3ncDIJRYvbFNeXtAuNxNQauaeRZKqcNI7VvhySoxo2jYUqap
     gfKVeAYQQHwtljCyGfum9umwhRvXBvMlOQY59JLaJW6GSECIVmDMmEk_d-FHJgpg8
     tRGsIC0Cq56onKEPMZsYXob2dnRAaB3eQYxuP1N47tKQ6cgvaGfR5OWw8A32rnxs-
     oWtlNjYXQ7KUdDekY81CNdkVAZbZ8iOYjs1fmoWOHw5siuiG6rrXQFJP1y1PZiiYK
     DIrDMpjN_7q2e1Bq6S4CNQEXOVrdAZCRuF2qFG50ASoapx6KZwcorX-WCAsuB6tkg
     OE1caLzi8sE3c7qKIBukrvffsx4BmxMLf2rpxIsGn_Q0OQ"
           ],
         [{
             "enc":"A256CBC",
             "kid":"EBQD-XY75-2IST-C6DH-KTEU-363I-CWBR",
             "Salt":"2AwJI4VHneTLk2UMSbaLAw",
             "recipients":[{
                 "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
                 "epk":{
                   "PublicKeyECDH":{
                     "crv":"X448",
                     "Public":"7wk9t2JK-Gx9ESxA7jAPJXjZ4rRhH2RHUidz8
     n5FsDxMQPXtO78_F3d3__RefNRiPoCfTm8D0DmA"}},
                 "wmk":"N6SgC4MEtbxrHyFLpsETbTsZDgqxnfnxnm7EhGQNpuFX
     o73GCEMCXQ"}
               ]},
           "kCV8prvbW_p60KlyLR1zhjmhHhgewBXXgL_e_cDouqjSJY6c50Wz6-OQ
     9kRXOIlLOnFt_Vepyl8IT_6zF97Kw09EluhJBrcQVYCpxNVWcOMMKeUk2FnZ6vCFZ
     LhXLWvW4sQ9tThkNzJ9XdxAl4KUASEjvm6J3Khi5n_-HeUPiK-tfYQsHfEqskZ1t5
     AoYnGf7ubTxElHI13SHdD-UqPd1wR1TUJVHpgCrdXtHrnFvxRR-ZmyTlX4AAiUYXd
     fPSZPTewmu7anrKOS8FzJUu4YtZlWNl8ImSG748cHmW5QkfVviX6AE27rdGqgEuI7
     1o2ehr06HG7s9NoR_ybGLnufxyPN6IbP4EHQ397mh1xiPujLADJc8saEolXbfvlu9
     F8kDJIir2vnvIwWT-dw4bMDeyLp3QykbgPAonpNVZfUpwHxHRLmxD06CMFvlWfGga
     O-mUI18qhrRArJE4UIQysYimOE0GDk5jTXWaXcNiMkpFvdNOVaH7sXjAU9t_uvUbl
     ztPqxV-LOgpelu0ibJxPmN3YS_N5hOskUsB0R1pBmYJHYpD2Y5VuiSwlX7xaEpmAA



Hallam-Baker              Expires 17 April 2025                [Page 29]

Internet-Draft            Mesh Schema Reference             October 2024


     8wQCmQXutzV8qkzmBDZ6dpw1buyV7cCSx1ybx2jZuhfKwEUbEB9QcmykytEsGK-32
     Aq7mjMh4ojSjL7XPOkLnD5pILneufxFJlpXfjI_KNijXVzKtA6JrZYWxbffIWXSSu
     6u0JXiPZvsmGv_aMHn0nGnV0jaJgpRG-177s0JHGIRClhgi0y68_dmrovRH6Uk9Tj
     uthhTeKdW6FxouFy1p6uZxqwoiTraBpBbfOBUUkbEsUvffE-92_gD1-bet9tHjY7z
     7jum2bhuN_Uc-fESQ62IYZm7ZXy5r9tDOvToR8XcADPCF6lGLOkjQESgsCgJ_megl
     2zB4FEbfEVU5k9doplzWHSItIa8ZMhY9Q4Ma1FAe6NGuUlPCyRyW5Kat2fPVcyiKA
     qh99VU9f51cozay6zlOiyWCGCNWf-6AMHF-OBhbubXMiwlvrxcKLMFT5CfYDVEDkG
     hLizxIqHW_B8cEljiA0GJ7Ouo9WLSJetqhpWkGFl1hpTrvOXTe0qzLwHW_m38F5je
     Gwp-zqY7CfYRHTrPzshbQ9-E7-cClZPUtC3q0LH8ZjKZMeiuoarQQIbDt4cIpmCrr
     szMo_oQksjYQwAsjdRBl8SpJgyMJvE-JEv7Iimg-Ua7DKL0m3XTXDoUmlyRB9-LQR
     zvlXSDaVvTKzMNUOrOwHMcBvlzwW6XgCdFwBVpSeGHGJrTvvGLCgudAhibzfkBy6h
     waaCwTmNNbZ3d0Kz5Cu416upM0N6rTGDY2fo0TC8E7cmFQ9Nkib-raTNF_GHBjzvK
     KzBJlKBCueP48Mn2wwqlL1CTr65GW4jPNoHAnE6Ki_f8jDtPjzNBgfO_FzF1Z8Uv6
     Xej135jBEiDQGVYd24t5R2yUh2v1q4X4Gz4RB_bYskqjPKlEdxTD8FIk1A0M41OjD
     BG49WcYLIEggLMfwBMOez6XPkLBQOOnVcufxX1hpRQ1keLVLaOM9IRm01fsbrd1_i
     DDZ_MdIpV11y0gxqKQlQar75w5U-z0RtzV9W3rtYd3-rsb6X-AQzlEQC3p-hYBiRL
     WITvY5KYv1gYK33oeDuoFR5eXRWPiAc-SJiQf-qq6mxCTrmzm6nZ_b3sKHGt8bRNf
     r41wRKq5tF4tt-F-5fQlt5BHPWH0nTWvUMi31xVP3tKLPAr1ho9PkQsJtuFh7JSJ0
     c6327d7K0MMph5XNp-HsclCBOO1vJNQ_v75g99P6Pg9keZcqM04wZtzsUQgTuAVBC
     Mi319yfJQzGLOn3Q0MEatN67h1Eu49lPC0aSYWXxos6-D35acpGKC8s7xutiK5xt0
     wSxXDw2H1-u7MWeevmAzkRQTPWN1z_Hq6rLTFegLjhb24QnK_ARgWOj6mHNpEPFbL
     rxIG5JbtVVVXAJs0JGfaJ8uWP619qhgmUwwgsxhYoAsW3jCyfu7twLCzhQM8TI87z
     1veaO0XJevLK5mVWHVojB-d6WiU3-Hjsqvefaubt9yXutKI_POazUuxS-yvc59jyp
     iQ0V4fq-W41FoYG1Im0yi8RlcNKhcY4PKq4EpyYy2gVhGKgpXfEX1RMUFD1SixnvW
     HQog_ECPi9qveuKlXk8uFEMkKlIFn8vLUlfKRXoqxUUTJtxCEjbcx7TampvDxMhOC
     vzrknfLbJiAWl_Fu9Xh4MXtcF6MxNdneu-yBKg68VZHNXkjaDUedM_NiQIme8O1a4
     uya2CdoZJqHAsbm-87hjpuiIzulpUynFjsQKxU_Ytni5I6p1YWp21HRiIrYyF5UQv
     XH_7D8sLzHfdy2U2JItW0RdmI5cAawDUayKuX2Rz6sZVWjftbrlApwXUbqRR2tuyn
     V9wBu9XcLYwjftIIFBiHZXSTk4WP4oIklOpvgLb6LRPD93FzVRA3XAS65flR_a3IC
     Fu4DS7jqu1t7AKN57Z4x2me_5m2ICBunKksVMO1_MO5525X8L5OXhvmH21DafczOU
     0EiDNA3FYFeBX-f6NPGJ0mxLO2ftEHUXT6z1Z0O1z7HnvYH0-K3zKvWyFHMnJZM3g
     9SLELkc8gv-ZH4M2ArOX_tZWLO7Wj8OmgzWv3Pz7IsNNYyWvdGJfnKyyUIJ5b2WJU
     3mdzM-DtgXo4YOEFvJ01K9cr5xjvPrN54MaMhv12ZG_0aKpP3rTLCkVe4KCyY6S1G
     UMwmCcCK6T6AzZHJSQbC4cudTRjh71LrRTKfVdLHrsGHsHurVOdLR_DtttkFQwmmg
     HM0LPgiMU2RVZ-ghyQms5LsegIYp4WnF6WkDAC7WO9frpBkPA2a1KHHs5_0LMpxc5
     3ianEojz7Nuqw6_SvbuVZQic9eYA4DqFYmTS3jeKxcwZ_tza9pb2YHWqiia9kW_0Q
     jbPWzue_TcIHP-FBFtTkX1MiN66LyGsapKOLkyiedgKl_KIKXIt857GLuujpe4IR7
     WcFJhyjxNTNUsdpUWvNdFA7K8de7XM0Pn7o2sZH9iCKx0FfJImxBehcUUNqGef5Q2
     dRpecGs9GXbbFzQ5aLQ5O2dUDZ6A8dZ1u3eDJfdQ4lE6ccn4bxO37nQSULfgEqmlQ
     l6cqettCB6K3q9JGmP3PpMW9Pn610ufF-5T0LwEiQGF-aebS7Y5_oYHyASA14eUk2
     MQOhFGDZYL0JveIlsD7byYer5FQTD35ocK5L05-O6LR9Hw"
           ],
         [{
             "enc":"A256CBC",
             "kid":"EBQF-IX7C-VHUN-ISB4-RYQT-HJ7O-INMS",
             "Salt":"6dSZ908dT3Syo4-z_eEiRw",
             "recipients":[{
                 "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",



Hallam-Baker              Expires 17 April 2025                [Page 30]

Internet-Draft            Mesh Schema Reference             October 2024


                 "epk":{
                   "PublicKeyECDH":{
                     "crv":"X448",
                     "Public":"jYcxhXOF8j1YycxnOuz8yRuSUEZwKwZ9FZCXg
     0PvFYuHMfPUr_86-sSWj5hBPrlVrSKg3rZn9jCA"}},
                 "wmk":"3kUOWUxLusSNPJcEmSU2y7hLEqhp2MDcxyOESqIJMXJn
     oY15hx_b1g"}
               ]},
           "YzYa8qjVovYBXq-PaIU_fijaNfSi-lt-1SLv-BgTvE30cvyXlS7orQzy
     82bFZ9gxRceRfFYvenzQmPTimvPwW-vLz7KR5NP0gZDsQF5jGlzE321tUMvl35psc
     d1a_vwQGBF0xSNQ0Gzp_O7qNFjb0OCQ1Bhx6NKdrhrHWe8sGQmAnMa5zB6iKGDX08
     id6L2RJC0gwzNM96VhTjinHCm8yrn3i8gXyGoAoc__NCu70Dx3xMl_LAzXf1FgiD2
     ET3sUHROzT2q0uMP-bEAXKuNVldw8UA1h2moS2X5gOzcDV73YilYoxgM1anM4MJ_y
     3t-HzwrWBcGGNaecCNSxB2y55PbMaeDY_D0elguxNaBPSiX31UYAYoRNeivdR8LcS
     em9lOleXqWwES-9PSmhFMxOTJc8l5J3hcInJBHqfNy73JBdkOCdjnYh89i-p3rJVP
     oGGMOlgX4WZuDe0O3m8ko2a-ErcHLTSGUZ2LB3dRZIwHrIJsGHjfThCuQCjmP_Qb6
     qTnbWnUtulhojghMNYJQfGsheMpk7qS_nKSmqtR4VV55l_xooDhsFcKZ5gytwuN8B
     dUxQ0HnMAwzNEcUQsFteAopQ9NksIkXv1wFNzoID2poZ4A9FAOGw_GtHVQGFmUhaJ
     c81iCbGupF45AvzYuTJzjJY3IxVfomaHCS1-bynKhwz1MAwl4Lxzppp_qh8cewACm
     zUr9OpnRVTVgC7BEJUKmqxKncCplFA0TyYwliu69BvIX-P41F0cAVcbGZJb06ZGDV
     -lqmbirmFoZLoIpulvDMPuLmxHOIIhNhETsrP8WUdjuadiGKk7gQenDFlltVn62Op
     yiPX_NoQxyjbI3ztHAdCgLK3urhPN6H6bro-PLSbs_n7rt68EY2Br5HnDflyIrx9-
     BK9O17AFNO0V__UYimzFrk35b_Zt5iaj8cXeraq9ghWjXaRJEPkX6qyx1S-uH4gXB
     oBZbfVOAcVX_Zd-JrFW7VRz5ik0LDGb0RX65bHKTffY3bNFClVPPhDrjhiyKdITQl
     FCrbhEeDmY5D7XxoVvtdReY6QrRg8Q9M2kikh9fcXmwXpvTH7x9eaT8nhtgjg-zCA
     qd7CTYfBgoWmVMUiUKXsv6HI7aHlgYsgWzu8bHs2AJMAvLlMX7vVYMvfmC63AFLcE
     PNLWYDKk8q9fXM8c4f-v4O-w_H4JO33Xgj7MEqkCOmFIzxoXOnlSp2jHwMvImxcdM
     g5ttz8pxjoCBARrobbqL2RdkmdMUq1IA3GGaR3fuPmHVABBDKyICi90el5jTnT6qP
     WtTZ39bm0omPC_OCjKt10EFdmQS-_nsI66hqDMIuTSUEVKzT8eqb4fMDgpG8Rzq6d
     KDL8qyuySIZAxx59lWEcLOyDxe9dqD5_9HH0GogCgFUfn7dkZZSuC-pvEfLEsVKse
     Yjqmr7JDqgisgxgc8zZHLdL9WMw3uQoV4il_ZFrCag3-oLncO52Dl_vX0gazI7xMI
     8Fj1xIOgBNg-x8UdbK76_r9eWDImj-7s7Nwh-4XEXuMJsWErLiALTB3-9Nino2BJj
     DtYqbjqjoYOVohtkNemqw5kD5g5V0rRygsnbYOM9F7bP6usopeLnxZFlifdFc5mlT
     cVR9JfgzK3xBC9qgbHQcOBlx4rSTa3YwFgz1MqyfeSFrNLOtdbCYiob9xwQaB-MkV
     OiXB991CKenhh3Ju_sQp6iTMsoI7BOgvbwV7X9mAMlqzJY5trvhtLh2aUgn-_VqkF
     wohja2W-RY5tQVLB3uWBApKNr5Y6diPxcBrHAK-8JWKl81jeq9sVrCT1HDdmas6O1
     PCuyvfQQgw8DZs_5jnQTBPwhb60o85X4kq4_tLLDnkIF-Rn4X1ErZJr9dkWfwTWSG
     LropqyN1MfFLSNjP3PQ4EHjmEW_YrF-cYxnI1gWVYv3Q3jQMqun1n_wGzC4pPdJFs
     8bJWwvi_Df7vBii5IiQYGuAAdk8cPcYVu1EjqbIZLnWD3pSzTQR487kauzkm6ahuY
     Y_qxD0kfMQxtJxTKv3_q4yCCzk0DJpGFWltPywFhfcErWK398sM9YSWVvAtCntWXB
     h6hqqkJwV5EBh9QhjnL1n-V4TxxQ2HHJHFb2zmtLs6kxOclLs-XG7HZfcWga_CYiX
     6rj3loM2GIjRZBLMnVkizuLQY2Dw_rJASYKBLSq2KoqNpTfPmiTNCVII7DGBhlMtR
     jnPcREaCNmg3NyA6xc_t4SvmXLQ39w5YeEXWXtoSNGVBfxaJTqRtI8sh2c0tTCBQy
     NhTZ62rhnkEC1QePE1uu_K-HKokMExACQyAy2mlWaNkBWQoOvsantfgzQ1ea_csM_
     r01QaYHMWHqPVNUagH33XiuFutCTV9LURRLmKG-OIoUKGVumsr4pBrf6iJDRbvLyo
     rOwuzub-jiqHr3frjCsOBs8i0Kd9-sxZtl-WW-yfOWvS2ZsUlI02eHwpeZBS3WQwX
     8Alyg5AiqHUn5frCNsEvOxZSzMkoH8mTgqgyHbqappdUJcYZNV54KDayHHChW2C21
     ySG09kZgu9iLkdQM_KOqrwmSt0Zf8sJXLQOIhCpdJuR3sC2Z4XZ3KGQRwpponVoh_



Hallam-Baker              Expires 17 April 2025                [Page 31]

Internet-Draft            Mesh Schema Reference             October 2024


     1IKv7ZzV5JJLy6UT5WXc_b8-eqVOK-itOa0x1pDF3EiD1ncsS7463mTJfMWRZY5IT
     l271t-rWFtccLFTdupiLbfbU-vxGG4fJXPLEvRJg13-XLbBcVQe4HEWHb_Rg7e1I8
     veVmJm0oVZEOoESNxVWtHXjfqTAUaSKQW8b6ZdbjwLntSzIkdSld8ZThdEOPaELDi
     OHsOx4UnUyE6rkGK1CA_-ZQPeECpV4VKE2dmwQtzbqimZD9dXeIzS8ZjXk77ScTVY
     Yzo69loheL0BIULRlXCvteBVxvbKayuLtYX4QkyirxHeDv9b8cQJZ-RY5S6wyFt4G
     n8AtFcqJJyxUg_8o5QeRjpEebcmrKA34PG1ZnPNxvH0r-Lo8ywkMzfJryMwD-OFAM
     AglGeQy0h3_6ETedIrDsdqN82KR080qcwBb6-3t-dkR4bcOvTZ51lGcXieHLLycEZ
     sF-yHIfL2GRjzU0HsORsKGtDobIDCbtRvB0_q-LI6X_jm5VfQ3Zs6s2HNKXVBeu9O
     i4Hhl5pWow5JJq8inSfh0nJ2hPTO5Xzu0coLP-nY6CEJcEp5q2VFRmatdyrR9xKgP
     jlyeG23nMiXPftXx1ArGktMMa6cXCWoGsie_eEYtdvBtkg"
           ],
         [{
             "enc":"A256CBC",
             "kid":"EBQK-IU54-MJW2-YRQM-SYJU-743K-YTXR",
             "Salt":"5RPrUS8eme48PmJoq26bKg",
             "recipients":[{
                 "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
                 "epk":{
                   "PublicKeyECDH":{
                     "crv":"X448",
                     "Public":"1amXlZFcG0dN2W6d2J_sogC_13U0fI_yWEoVa
     6w5SJkypaYe2B1Gu2rnWlC2QZdRfCUOl2nvKpeA"}},
                 "wmk":"ZMwe3K0dUh4iVBckg5dm-ganKo9sj84Br949or4ncCGN
     KbDj8q9V-g"}
               ]},
           "grWcZT_x2PRQEoyKnocey2ABDHyjREDaxna5csQ0KbUaBik7bZ9VxDDi
     oIQ-0ZTw35IR_mFOmBHPfowqP8KKef7ZsJM8m6JkmJT148--u0QxgrrCkRC_z5alM
     yJS6XGbt-Jr8mlI5UXKYW_upxn7_9wamJLg3_ZbS83Y0X4cqG7TxSiDn6EJNQAgO2
     e8z7k59d7Sz87P1zXRVSI2JX1MIXhgqVLoQ_3B4F-vnIrdnc9Xs7L2W48sT2lJD3b
     N9Ydq8bQ19GSIvJxCa86hDdtGtS4fAi2uqEgVt5TA2Ta3xvavn602WSIOhNPjzT2a
     QvL-CcKp2-tBT01u7TL2cXK0MmQTBvt_Zwv4gP2pN9cibb9gBnPqGIzeeb8djwXfo
     -D6la1dNAGijjWwPNZhFGoInGIvI37zLlBMHAxBXhXXssxveCQOje_SvYvjKQnx6L
     nM9v_grPpoP3rmlAI-6qy0-Wuq05itgMEZE-1LDJhhVx9c8sqTL6huXrWdiriuzMO
     qAg1J6Bt_mdgR6smB-HNu5b_2SCJ1WjbmCS4FI7C5s4NMeNLmz6jHjIax8Dguj5b4
     7a--SWXtWu2Nt2tEMNtUKNkBnI5y0bBfEJupV8pUXo-lTTrSmFm7HG0kgGM4bqWiw
     knl65pdDnfMbgRrcC3c0zF_uTHqPGDkEQabVPcUYouAezsLAVeVCnqkqsu7uUh_nI
     36i_TwptzGrolIGzc8WbBMgwfZRUbCRSx-fLslVN1fxirWx9-AqHFw3vXp5eJME7W
     Wwx0WKVO4paXaFcVa_hxrNnrr8fAcXRxRNWaW-eZiq7Vm-X4jgCthiVyvM62Gq6WR
     4qUjZm3XOss1of11dJbY-zCCbPIhfyzIcUzfckexfpZ1N_KeDUuKwiZPPjN8Zjqti
     3lGOhZQPpIIn2Nv8CGUl6mMWlMY3kIfmaY3019x069HVkx7Uvi2RazcnHvVydwyq0
     yr4clO8A27qjcHarFJ7XNTnZkx-0oJl_t56DxyZpgal0NJHDU-jT1LlF1fnmqZB2d
     lW6FPilrVFjXFHhQVADznJvC3HrM61jCclhV2aV-ZXYbrvcxFw_Bo8teH_OEH55qQ
     8TbB_PcliJ9B_QnnCqGiTSHm7uT8RV04QCHYhcsWgTj93AEQIXc2k3ZYmP-h-Qi9-
     1fypICMRh2bI6fPWP8SXkmI7MczDRYsSFqfvxwMZsYGbTEBX4esn2zkRAJdcRjbT4
     bGt-VjEOzjT4ttMmKOHheVvm6cfP4zqAEcCiy8rETFUq-Ij928UHaA5aJi2NytUhb
     kQE8TStrxzCq7qihZrjIUuWsjv0d8xRHO66B6uvozI0hkRyeSqwUxNg2PXpT7euOz
     Je4Y8WP9406Xt-IrXk6uRYSj6hBpK8WF16pBj1Htrg80TWoDvOH8wM-0VSfD3ZsXm
     p46-BAl1kOKkHIU6eFOtRaPXgfrYvIyHurR5J0XWFAEHINx2PHbwUa0gFug8unHek



Hallam-Baker              Expires 17 April 2025                [Page 32]

Internet-Draft            Mesh Schema Reference             October 2024


     Bch_kgcovrCxymBKAaS5v9aDJKtRHkgRHsXBqAiVyzvLavQOE5ZjFNFoQ9d1JsE6k
     buT2KPhp-dKzF9aYd1pYX7Ts6vdA-HquZ1yugCantVoNqsSWg0QLlcxt-FEbkVq0N
     2fbTP2bWxFYI0rC3hTFFUs5tjgea8eQgHa9bIXqWlmBbO1D5qnWDNgKfZySx6eyEv
     MbsRJgOc2YGDcRhgU1Xd0-ivdY3Zw3vnJUU_qcbSque34uCtPVz52kxet81P-J4b-
     2KvNOiZKOAFQUoXjUmX3Sodnc_OMCbMG0iLVCgDrkGiy9R6Kg40gY5ivuRJD6CesD
     nViZCdlIKPjH79hWxGIPVjPthApieQ8wGlDie_4aWi9GFVvCgFWCiQI3XLADfbP7r
     gWJComS-FFk4y_fXkmpqDNpHN9CeW_7t_6kM1PZ4H9TepYsrNltCytmvXcvGoK4Lo
     Uj_D5xxNEaxpkxxfqxm8e0BR9uojPaXGlAe1Fwbsl3jTRI5xHOf5ToXm6AGydfVR9
     0LfX7mmMvjdXqRsG5c428aRWa3ShMSOdcYRIgQJ7VSMjOe8AVV0huCOKMWzK8DpPC
     7EsXC268q5CK3LnTg2fK0PK3lHfpTFmtpEj6c5fTJc_5v5LDr8rjDMgcFDM-kd9Gj
     TYIbzJgbAjzG7lNMhNmFur7WCXOIwmJS3dbBonR1wW3JdI8s6nyL8uFGqIBOaMVwg
     yuBJ1_9fK0cITWqk0R_G_bE5NJO8Gxql5I0DEv7BZtqOXSfeoL0kaEoscC8VuIp5p
     873rjl4u5mRvyU3Q8i2Tcp39VFmixQIkSNuQpYjY5gAmGRFZmK5eTcGAbOxTocQVr
     1ASmRdUMTOSWTEw_fBtssp3FoXi9-agRb702SmlKdXv5wVn6yQGN2rKSzIphR-YMT
     tUimNVoGEd5qSnvIztrCMuDYJnwq0H9tqQ3B0TBNas58faIg5rQ82LO8lYyEuQTBW
     KwH_xcC3JRE2uI5ruIPIGXEGWcip0vbQIvKnaB2MmBkBudnY7_TzhTw3r0X27QzZO
     6xEfFgbhyfSzMlrXVTW2No20UND-dsEXrQwMv91ERP4OcEP5bWaPtcH54aWtL0i3o
     T5Jv116lOQp1AqoB0SlSKIl1DCvaiasUMNo3NNJtrHduO9PH6jdDn2IerEnS1Kdk0
     ASDuc2IToEybod4lC4MlL5M9y1o1WAox_4GGmj4HG_gVAIDCq3k2a61uu4PLWajQB
     05ZCqsXVwPLUkipy1J63Me00ngnU2_yU7jRJoSRwYlzbORpwVtykfMjZQH9qhz1bn
     h9jYc4C5yu8FfeItkNbgdsfH0Ul_3miGWOQEXxiaPw_sOWQbgQZROKjMwQVuZYyEX
     N05vuLBXkHHj7sOvz1cGxJg-IZ1JAhUA0eBtzYScfDRJHUnd7p1gyTh4Yf14PMC3Q
     H2kYh0Z9lcMA7bXQAoHPwbf4UgqjHu542gqUMWqg0Qd-naQ0rfs66A2Jz7sXFECnQ
     v0fDCpkoEc2l6jwDZvnfhQ4CRQ2USLfQvoB_RRvlQ6CPJbajg7FfQnlydfDojosnK
     eab9lVykZXBaouGGv8f40X5JisN_P8dPBDtxcVerCxk_SmWnDKOvGlyB6a88m76RL
     4YVpx-yWLoB9oBA2oSMDtdLGKG3Y3SZqqj1WEeEqA5qS-XVwA9CSBN53qJCC-R4vg
     c2C0bemj9LC_YqhQaGaOzGi9lT4E4XPBVqOMqPgb6MrT2A"
           ]
         ]}}

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

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

4.2.2.  SSH

   SSH configuration profiles are described by entries in multiple
   catalogs

   CatalogedApplicationSsh entries in the Applications catalog.  Specify
      an SSH client credential or certificate signing credential

   CatalogedCredential entries in the Credential catalog.  Specify SSH
      host keys (i.e. contents of the known hosts file)



Hallam-Baker              Expires 17 April 2025                [Page 33]

Internet-Draft            Mesh Schema Reference             October 2024


   CatalogedContact entries in the Contacts catalog.  Specify SSH client
      keys (i.e. material from which an authorized_key file entry might
      be constructed).

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

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

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

   {
     "CatalogedApplicationSsh":{
       "ClientKey":{
         "Udf":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77",
         "PublicParameters":{
           "PublicKeyRSA":{
             "n":"6WSR_7MjW1hqpyLC45ZTZRWNKF0MFXN_GNuZw7wHhmZgTQwiAc
     Wa48OTj6hsj30-4Vkt-ze42q0kqlpeghveJiZA89QEWE2rO3nPuE7Og0yPp8kJEpK
     XPuwjOWD6hTNcG4jiWc7oX-pvNZCqD1ej2qh9CZVnXa7idGK1GXOWICXZhUnTN15o
     5Ou5tZDK73vvmAaIVldARiAW-ywLL4OAYQGN47RIKDUNkO8Tvhi3WZ7VR1GCduEZ2
     7k3SxyskGlgTuRTj4rRM60IWF3Pk9-j_-B3oGsMjNdvrUbnngJ_VpfDU9GLRtR4SG
     ufIrYqiw6Pbm8RIHRVco_koVSfG26N0Q",
             "e":"AQAB",
             "kid":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77"}}},
       "Key":"MBR3-LM6K-JRW2-JWYF-JK3C-SIA4-HG77",
       "Grant":["web",
         "threshold"
         ],
       "EnvelopedEscrow":[[{
             "enc":"A256CBC",
             "kid":"EBQO-W5DT-FEGY-CLWB-KZX6-TTGF-JB4S",
             "Salt":"n8FIgDGkJ6x9w3zu3ZTKLg",
             "recipients":[{
                 "kid":"MCKD-3MR6-P2TE-M6U4-4LIO-ZTRG-DZVS",
                 "epk":{
                   "PublicKeyECDH":{
                     "crv":"X448",
                     "Public":"VYUaDmhYI6cy3ltzeLXy5iAiYxDRjzXYlEbIw
     PIMcjaZJD998DURwMcqig6cEPAYjQGDfeJ90FWA"}},



Hallam-Baker              Expires 17 April 2025                [Page 34]

Internet-Draft            Mesh Schema Reference             October 2024


                 "wmk":"xROBIN5zTCSppVnv0eASxxMZ-bOtAx9qy0O7rxL4C9J-
     bUX-D_9J1w"}
               ]},
           "-16c2DKJU7Ib5lE4p8mtpMgBPuM114w6Vj16PdvrtrMLsRt_WRSeu7i4
     uTcrW4rh2S6133gol_An1ZPT9kWCmUu1rsZMF0RgAm-d4B_X3CZ8P_HfN1zZTRaMt
     IobZuk_cZoTamrgldNdmlcy_U_JsrHsFGbv0sAXoIRHXK_bUuCCe0Xb1A5ILWukyG
     2H8-4Pcccld9r8bdoYZbBWiwXfK103BQm9gc89BO2GNXi4ncbyRO0w4SWF75-Ir_u
     ynihwi1acQcesV8XRhG3dn7x9ol0UESLY1WbkwFD2_5JRmRqiXPryKnyyuEABxji9
     nz57s90MMTXS9pHcN9axvPGEccK8svM0N5ba8_CjAV_zar8kk2t26yLi55Sead1QG
     6jjXzoQMb1-BrN6wwYrMR7zdESYJD_fShIr8o9ual909PUOnCKi-LWMtth7LQVXzv
     LUsHyMvGtFrN-qmnSfrubWiY2lx9CI1rM7cn_lu2Hrf6jnR7x6ty8czXQfw1zuBry
     XpEWaL6gdLa2PqIfJ100QPecFcJCK7DqzUWQGaH6jpVWgw_Ub3fnCJlzbA4K06Z1X
     TwfEOcHiCfKVisgCVth3br70HG6GGCJhO6EYAu2KZxeV2c6p4cWBntTkA1fTJvDeI
     0tJwgb8a69AL9FWHs3AGZaC-bwbg1cMC3yw2gCAEtVNvlAuDxgzV9hoXuI6N9wOt4
     p-H0BmgB0hdOqTaaWjlkrDcHPbPqDkosxr7Xgo2BKXVtg_nDcQ9EEyrfNaNGtvLlT
     kfpcE6ra5qbeDLZHR7iw-HrD_X1rzfnXa5syXiTNmdU6yQpDPojAAzynPJM1dZXCX
     fHD4aXc3Ow3oCUgGFYektdQHc0avKBLP_JjZMlaeOdAt6SW4hqIaFyjwYJABE3juf
     0s8IrBZEqa8rT-2OUDc0WJlsN4OPBZBfPrj4UeXtZe58eS2j-oxdf5SlWpBZzHwt3
     uqvU2h8PIa3dTL2ZXLr1SpL-bsWvtxD3ZUYfECs4JvIdayWJJpSJv99dBd3aYyWob
     vGdo9lg7v9KG0_8c7X-sXKcQuhPu8lRQTLU1KzORTcZf5AyuLb_VdmDLSXcPoEkyP
     mCkMgebpyA_l17DVKLesSzxHiKsAI0qlpdjhYECDvQ6nGZ0slrfRBQ_nWGzFUZeiE
     k-Ogu2ti2QJMvsLaXO7SHfZbk-eB4pyuy9tx8XBjCzpuanWn1LquYR7bXmdiBXGnz
     6M711qCEXtAEpaq75SZpq_T7aIojwTTlrumCxfOnn3ZCX1yw6KuM1l9DM_h2n269J
     tFEdAzRYLQtfNzxpkppN04rs3ZHSZnqRcEqieSLroSlM55iSi8Yso7HXyxpOGIJxj
     NiOj-9KYj9cvlkUzsIF2LHP5O6vxoA7gKy1tbE4H2U9gIPzMF-bwX-dsEFwcYTQ8l
     -eI_EHF9SAfnwJekjY2NcMqwNVzr7QCpgJenxkSNBl_jNoIMzdZqAuHJ5GAFcQfVF
     eRMpVARZrIq6aPxB-RzNeXSeQ_w1FwOPqJnm2y9RZCvKsj4em1WMQiZjCvzssnWv9
     tZlldDpGL4TjTfTU2G0JgJoMr8qW8fFMHWj2twfvGF18L4GptZZL3JE7dR-qDnljY
     tns_8xm_PIgvTGMGCMmPaJwEGIhwugd6lL-kxQMEDUY-QECGJPZBOeVhI0NAsfsBY
     T7AVip4cmBxBOXEK3lVTw9LcP1mL8Z48TPebNljIqlvlIryFnF6p4kadDH3UZzHTs
     V0Aq5Ic8FkRz-TIXBE6gZPN8RCZiR1Pnn6Ti2yCkKbpUUvbADVCOJhoJIu75ANvy1
     nNaGw-a4qL2aW81xV_2BjoFBUyH77TDT7ndzXifJr5T2q1LtUoDOwREhuuOCAIt1f
     nx-BAWHg_7VipCPNy7U2umRgL0ND-IGk2BMKYSPXqdZ7bSulzcMKI_rCb7rGt4hTh
     NXLfGJ_CH4H5gyaWNBAzADNvpAHX-ZfLBA5AW9KPOU_WE5goxwymKZuyBiFneNbNN
     7-AZ6goaNcrPV3m0LpnavYBGbpJafu-zu8ygY6RryIUgVEAaPR6xC6ARe45BVcv_D
     RQw4CQkNV_u7arIGFshLuZlp5FVmSy9D-p7wOTQ4MmTCK9kiHkYNezjBTL_x2DPjR
     ru9gExOzBmRS6hKX8g4fRGA0gG3F-aylo3smC8OELJCm4eLiw9o27Rj0LLlggwEw4
     W4RSiefol0jQvSv4p0SqE8Nx1X5JmGLIdQHTbyLOWyHzwJ3AiuigWv7MbpM88-vBw
     OKlVrrjzcNSH214OFxQThYXBDdQkj5494eE-QXXsvJ0AI5PcKrQzf0QdJmahhhtFV
     LjqoSplAfDC0q2UWoN9Ij6nl6_Ir7tuaWrB9Q4zoEAuVgjpZ0Y4fOImzPeCZSYnad
     eMe3YsZchJBbFOIML6xGT03EPg1kphU2a0oU9DFfAE1WNyh2p4Nqs9wRJnsRdJqVF
     Esc-7pgnDWCMqFCYm4Wu3q99ORalZRZIFmQfZNGGf__kf08YS4nEsXfNumTvLv-mD
     pr9KtkGGiwMUuDzu78dMoo-sFXxAAJB2lI8Z1XEzblgqDffNsYX2J4IlEIytUqCmP
     E0vreMDPOSI23f-Il5uWCsinsQOIyd7nKcnhHX9UznPmGb39huu5SHs7K-HlGWpTq
     RnE70x7ynQMNkrbquXHSzyx3EUJNpay1O4z33idUf24oaleer7RAZ8aalsfDaYNoP
     aSJzGG1m1q2kPwBVh-xSUGJFr4Eve1NcqutQxbDW-GyHOeczYEsuDaeI_klx9baOK
     H-DLAd9xv0l3xTn5Qu-GS4MxgBMBLCD03Peh6H9lRg3iOZmmSEuh-D-AV3dDQiHx2
     7Kqub00u7YAHxLDECczJiyO5L2C4cpHDkc2U3Ts6MGaCc7RMe1bVqo1Mgl0Cwu273



Hallam-Baker              Expires 17 April 2025                [Page 35]

Internet-Draft            Mesh Schema Reference             October 2024


     _AIxnhLEWfOFSSFVpdbSaTfIzzeSkjPDU9Tr8OAFbQiATsdbtZVQNM8nV8GAMAWfI
     aHg5NUPuQTnglgVI6el50fEHv4YrqzLILWnBYFaXh6ZG8ZIuw7_X06qKlIw7J9mC5
     g23qWmbXHzHoqH4yw3GHAJ6u45rcSkbZwC9DamyYSX6GN7LBi_1OsovLMMiGHte8d
     nifVZoPZjNcyVzGSeRsAOAALVfA8yFTcTz66dMO_zVHt5gcW11o9SEsgLXlVfBjFe
     FPboAGNDEbGYxAFDbcXxX7dhHJtt9KAFtctPq6FaRvQW4Q"
           ]
         ],
       "LocalName":"ssh"}}

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.example.com",
       "Title":"site1",
       "Uid":"NAXG-NNHG-MK3R-SZ73-3TQS-LS6M-M2W3",
       "LocalName":"Sites-1"}}

4.4.  Contact

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

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

   {
     "CatalogedContact":{
       "Key":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
       "Self":true,
       "Contact":{
         "ContactPerson":{
           "CommonNames":[{}
             ],
           "Id":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
           "Anchors":[{
               "Udf":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
               "Validation":"Self"}
             ],



Hallam-Baker              Expires 17 April 2025                [Page 36]

Internet-Draft            Mesh Schema Reference             October 2024


           "NetworkAddresses":[{
               "NetworkProfile":{
                 "EnvelopedProfileAccount":[{
                     "EnvelopeId":"MBQC-7OHA-RNBA-FRDL-R4GI-YQHA-DL36",
                     "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFD
     LTdPSEEtUk5CQS1GUkRMLVI0R0ktWVFIQS1ETDM2IiwKICAiTWVzc2FnZVR5cGUiO
     iAiUHJvZmlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdC
     IsCiAgIkNyZWF0ZWQiOiAiMjAyNC0xMC0xNFQxMzoxMDo0NVoifQ",
                     "dig":"S512"},
                   "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJDb21tb25TaWdu
     YXR1cmUiOiB7CiAgICAgICJVZGYiOiAiTUROVC1XVDNHLTM0NkctNEk1VC1ZVjdGL
     UxUUVgtUFNOVCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgIC
     JQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICA
     gICAgICAiUHVibGljIjogIklNeU1vN2ZFeTJ2SHA4c3lRMFZVNFhpdnBKRWhnUVFT
     WDNqOG12YTRIQ19UMDVVbmhRWXEKICBWWnl1dklRRVZvMmR5TUNSbTYwUTNFMEEif
     X19LAogICAgIkFjY291bnRBZGRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIiwKIC
     AgICJTZXJ2aWNlVWRmIjogIk1CUUQtRVRYVS1IWlJXLUEyNk8tV0RUUi1LN0dJLVg
     2SkQiLAogICAgIkVzY3Jvd0VuY3J5cHRpb24iOiB7CiAgICAgICJVZGYiOiAiTUNL
     RC0zTVI2LVAyVEUtTTZVNC00TElPLVpUUkctRFpWUyIsCiAgICAgICJQdWJsaWNQY
     XJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgIC
     AgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAiMXZOVUFBcDNyc3p
     JcGhHOEVzZm9hTzVZNnNaQ24wSGM4ekNnZFFpdllwSkFjRHRta1NzQwogIGVJMmdt
     RFRDSzZTclMxVWdQdHVZbVR3QSJ9fX0sCiAgICAiQWRtaW5pc3RyYXRvclNpZ25hd
     HVyZSI6IHsKICAgICAgIlVkZiI6ICJNRDJMLTZNN0MtWjNaMy1RM0FMLUpGWUktWk
     lVQy1CS1VSIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB
     1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAg
     ICAgICJQdWJsaWMiOiAiYkhvS2IwYzEyRjdjaWJNXzNnWmNKWE16T09YNHNuSGdQV
     ndPZlJZazZBUkpPc0dQZW1zZAogIDJCbTBXZm1Ba1JZTzNFUTZmajhfTnpTQSJ9fX
     0sCiAgICAiQ29tbW9uRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVlGLUQ
     3TEotNUlNUC1FVUNHLUhTR0gtN0xTUi1BQVBaIiwKICAgICAgIlB1YmxpY1BhcmFt
     ZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY
     3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJjN29vcko4MDhzYzlkND
     BLWERoSUhnQ1RGejM5TUszSmpPMFE3S191ZkRFR0RLaXdWS2hkCiAgM29QUTQ0UEV
     xR2p3a3BwN09mYmNCYlNBIn19fSwKICAgICJDb21tb25BdXRoZW50aWNhdGlvbiI6
     IHsKICAgICAgIlVkZiI6ICJNQUZULVNJTkEtU0ZYSS1QQkRZLVdSSEUtTlhZTC1EW
     FZUIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0
     tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB
     1YmxpYyI6ICJYY2dFejl5MmNxc3g0WmViR0VSVGpyTi14ek44M0QtcGN4MDY1MXgt
     V1VDcVlOcnNuelRICiAgNDBDcG9NeHVOLUZucFQ1bV9iME15dUtBIn19fSwKICAgI
     CJSb290VWRmcyI6IFsiWUJKUjNqUjJQbGpkWWs1cXhiV2RIWTByVFlFYUZBa0hZM0
     1tc1I4enZOMURyMzNSbkwKICBVTDNUaHJHOURNV0JaM1AtOFp5R3p5S2FRWXdlY28
     yWlV0Y0t3Il19fQ",
                   {
                     "signatures":[{
                         "alg":"ED448",
                         "kid":"MAJF-DXRU-OY7F-RXLC-JZVM-LNM5-DWGS",
                         "SignatureKey":{
                           "PublicKeyECDH":{



Hallam-Baker              Expires 17 April 2025                [Page 37]

Internet-Draft            Mesh Schema Reference             October 2024


                             "crv":"Ed448",
                             "Public":"9sZGEfYSIoTvVSL0Q5c_Oip_Hi2iO
     Tsl4L3iLwhfOv9bA-5nd7PyRooKEsQx-lA7PMAYBewSOmIA"}},
                         "signature":"6x3k8AC2jkUQv0jzlUVWJDqP7zcNkK
     AqvPcAs7Ci2jXULjbIFAFCct8GC8Nb8KiD5ljoLAsVHr-AnYcjklyXSHN6Gn_BIZi
     LiW3Yu5_ChXHspywX-ZGMD6soXJIilOzreauR-_aiUE7Gx0eh3Fje2wEA"}
                       ],
                     "PayloadDigest":"tXPfbmg_SRmARF_7HLPq-bM6NMO1h1
     Oa30f_Ag_TIRzGKMrmTKtV7XH-h3NIBFGxOQYuD0BproKNEg6uhtG0Mw"}
                   ],
                 "Address":"alice@example.com"}}
             ],
           "Sources":[{
               "Validation":"Self",
               "EnvelopedSource":[{
                   "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb2
     50YWN0UGVyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAo
     gICJDcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NDVaIn0",
                   "dig":"S512"},
                 "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkNvbW1vbk5hbW
     VzIjogW251bGxdLAogICAgIkFuY2hvcnMiOiBbewogICAgICAgICJVZGYiOiAiTUJ
     RQy03T0hBLVJOQkEtRlJETC1SNEdJLVlRSEEtREwzNiIsCiAgICAgICAgIlZhbGlk
     YXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3JrQWRkcmVzc2VzIjogW3sKICAgI
     CAgICAiTmV0d29ya1Byb2ZpbGUiOiB7CiAgICAgICAgICAiRW52ZWxvcGVkUHJvZm
     lsZUFjY291bnQiOiBbewogICAgICAgICAgICAgICJFbnZlbG9wZUlkIjogIk1CUUM
     tN09IQS1STkJBLUZSREwtUjRHSS1ZUUhBLURMMzYiLAogICAgICAgICAgICAgICJD
     b250ZW50TWV0YURhdGEiOiAiZXdvZ0lDSlZibWx4ZFdWSlpDSTZJQ0pOUWxGRExUZ
     FBTRUV0VWs1Q1FTMQogIEdVa1JNTFZJMFIwa3RXVkZJUVMxRVRETTJJaXdLSUNBaV
     RXVnpjMkZuWlZSNWNHVWlPaUFpVUhKdlptbHNaCiAgVlZ6WlhJaUxBb2dJQ0pqZEh
     raU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQWdJa04KICB5
     WldGMFpXUWlPaUFpTWpBeU5DMHhNQzB4TkZReE16b3hNRG8wTlZvaWZRIiwKICAgI
     CAgICAgICAgICAiZGlnIjogIlM1MTIifSwKICAgICAgICAgICAgImV3b2dJQ0pRY2
     05bWFXeGxWWE5sY2lJNklIc0tJQ0FnSUNKRGIyMXRiMjVUYVdkdVlYUjFjbVUKICB
     pT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUFpVFVST1ZDMVhWRE5ITFRNME5rY3RORWsx
     VkMxWlZqZEdMVXhVVQogIFZndFVGTk9WQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZW
     EpoYldWMFpYSnpJam9nZXdvZ0lDQWdJQ0FnSUNKCiAgUWRXSnNhV05MWlhsRlEwUk
     lJam9nZXdvZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2SUNKRlpEUTBPQ0lzQ2lBZ0kKICB
     DQWdJQ0FnSUNBaVVIVmliR2xqSWpvZ0lrbE5lVTF2TjJaRmVUSjJTSEE0YzNsUk1G
     WlZORmhwZG5CS1JXaAogIG5VVkZUV0ROcU9HMTJZVFJJUTE5VU1EVlZibWhSV1hFS
     0lDQldXbmwxZGtsUlJWWnZNbVI1VFVOU2JUWXdVCiAgVE5GTUVFaWZYMTlMQW9nSU
     NBZ0lrRmpZMjkxYm5SQlpHUnlaWE56SWpvZ0ltRnNhV05sUUdWNFlXMXdiR1UKICB
     1WTI5dElpd0tJQ0FnSUNKVFpYSjJhV05sVldSbUlqb2dJazFDVVVRdFJWUllWUzFJ
     V2xKWExVRXlOazh0VgogIDBSVVVpMUxOMGRKTFZnMlNrUWlMQW9nSUNBZ0lrVnpZM
     0p2ZDBWdVkzSjVjSFJwYjI0aU9pQjdDaUFnSUNBCiAgZ0lDSlZaR1lpT2lBaVRVTk
     xSQzB6VFZJMkxWQXlWRVV0VFRaVk5DMDBURWxQTFZwVVVrY3RSRnBXVXlJc0MKICB
     pQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2V3b2dJQ0FnSUNBZ0lD
     SlFkV0pzYVdOTFpYbAogIEZRMFJJSWpvZ2V3b2dJQ0FnSUNBZ0lDQWdJbU55ZGlJN
     klDSllORFE0SWl3S0lDQWdJQ0FnSUNBZ0lDSlFkCiAgV0pzYVdNaU9pQWlNWFpPVl



Hallam-Baker              Expires 17 April 2025                [Page 38]

Internet-Draft            Mesh Schema Reference             October 2024


     VGQmNETnljM3BKY0doSE9FVnpabTloVHpWWk5uTmFRMjR3U0dNNGVrTm5aRkYKICB
     wZGxsd1NrRmpSSFJ0YTFOelF3b2dJR1ZKTW1kdFJGUkRTelpUY2xNeFZXZFFkSFZa
     YlZSM1FTSjlmWDBzQwogIGlBZ0lDQWlRV1J0YVc1cGMzUnlZWFJ2Y2xOcFoyNWhkS
     FZ5WlNJNklIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKCiAgTlJESk1MVFpOTjBNdFdqTm
     FNeTFSTTBGTUxVcEdXVWt0V2tsVlF5MUNTMVZTSWl3S0lDQWdJQ0FnSWxCMVkKICB
     teHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0lsQjFZbXhwWTB0bGVV
     VkRSRWdpT2lCN0NpQQogIGdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lrVmtORFE0SWl3S
     0lDQWdJQ0FnSUNBZ0lDSlFkV0pzYVdNaU9pQWlZCiAga2h2UzJJd1l6RXlSamRqYV
     dKTlh6Tm5XbU5LV0UxNlQwOVlOSE51U0dkUVZuZFBabEpaYXpaQlVrcFBjMGQKICB
     RWlcxelpBb2dJREpDYlRCWFptMUJhMUpaVHpORlVUWm1hamhmVG5wVFFTSjlmWDBz
     Q2lBZ0lDQWlRMjl0YgogIFc5dVJXNWpjbmx3ZEdsdmJpSTZJSHNLSUNBZ0lDQWdJb
     FZrWmlJNklDSk5RVmxHTFVRM1RFb3ROVWxOVUMxCiAgRlZVTkhMVWhUUjBndE4weF
     RVaTFCUVZCYUlpd0tJQ0FnSUNBZ0lsQjFZbXhwWTFCaGNtRnRaWFJsY25NaU8KICB
     pQjdDaUFnSUNBZ0lDQWdJbEIxWW14cFkwdGxlVVZEUkVnaU9pQjdDaUFnSUNBZ0lD
     QWdJQ0FpWTNKMklqbwogIGdJbGcwTkRnaUxBb2dJQ0FnSUNBZ0lDQWdJbEIxWW14c
     Fl5STZJQ0pqTjI5dmNrbzRNRGh6WXpsa05EQkxXCiAgRVJvU1VoblExUkdlak01VF
     VzelNtcFBNRkUzUzE5MVprUkZSMFJMYVhkV1MyaGtDaUFnTTI5UVVUUTBVRVYKICB
     4UjJwM2EzQndOMDltWW1OQ1lsTkJJbjE5ZlN3S0lDQWdJQ0pEYjIxdGIyNUJkWFJv
     Wlc1MGFXTmhkR2x2YgogIGlJNklIc0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFVWlVMV
     k5KVGtFdFUwWllTUzFRUWtSWkxWZFNTRVV0VGxoCiAgWlRDMUVXRlpVSWl3S0lDQW
     dJQ0FnSWxCMVlteHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ0kKICB
     sQjFZbXhwWTB0bGVVVkRSRWdpT2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0ls
     ZzBORGdpTEFvZ0lDQQogIGdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSllZMmRGZWpsN
     U1tTnhjM2cwV21WaVIwVlNWR3B5VGkxNGVrNDRNCiAgMFF0Y0dONE1EWTFNWGd0Vj
     FWRGNWbE9jbk51ZWxSSUNpQWdOREJEY0c5TmVIVk9MVVp1Y0ZRMWJWOWlNRTEKICA
     1ZFV0QkluMTlmU3dLSUNBZ0lDSlNiMjkwVldSbWN5STZJRnNpV1VKS1VqTnFVakpR
     Ykdwa1dXczFjWGhpVgogIDJSSVdUQnlWRmxGWVVaQmEwaFpNMDF0YzFJNGVuWk9NV
     VJ5TXpOU2Jrd0tJQ0JWVEROVWFISkhPVVJOVjBKCiAgYU0xQXRPRnA1UjNwNVMyRl
     JXWGRsWTI4eVdsVjBZMHQzSWwxOWZRIiwKICAgICAgICAgICAgewogICAgICAgICA
     gICAgICJzaWduYXR1cmVzIjogW3sKICAgICAgICAgICAgICAgICAgImFsZyI6ICJF
     RDQ0OCIsCiAgICAgICAgICAgICAgICAgICJraWQiOiAiTUFKRi1EWFJVLU9ZN0YtU
     lhMQy1KWlZNLUxOTTUtRFdHUyIsCiAgICAgICAgICAgICAgICAgICJTaWduYXR1cm
     VLZXkiOiB7CiAgICAgICAgICAgICAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiA
     gICAgICAgICAgICAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICAg
     ICAgICAgICAgICJQdWJsaWMiOiAiOXNaR0VmWVNJb1R2VlNMMFE1Y19PaXBfSGkya
     U9Uc2w0TDNpTHdoZk92OWJBLTVuZDdQeQogIFJvb0tFc1F4LWxBN1BNQVlCZXdTT2
     1JQSJ9fSwKICAgICAgICAgICAgICAgICAgInNpZ25hdHVyZSI6ICI2eDNrOEFDMmp
     rVVF2MGp6bFVWV0pEcVA3emNOa0tBcXZQY0FzN0NpMmpYVUxqYklGCiAgQUZDY3Q4
     R0M4TmI4S2lENWxqb0xBc1ZIci1BblljamtseVhTSE42R25fQklaaUxpVzNZdTVfQ
     2hYSHNweXcKICBYLVpHTUQ2c29YSklpbE96cmVhdVItX2FpVUU3R3gwZWgzRmplMn
     dFQSJ9XSwKICAgICAgICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICJ0WFBmYm1nX1N
     SbUFSRl83SExQcS1iTTZOTU8xaDFPYTMwZl9BZ19USVJ6R0sKICBNcm1US3RWN1hI
     LWgzTklCRkd4T1FZdUQwQnByb0tORWc2dWh0RzBNdyJ9XSwKICAgICAgICAgICJBZ
     GRyZXNzIjogImFsaWNlQGV4YW1wbGUuY29tIn19XX19",
                 {
                   "signatures":[{
                       "alg":"ED448",
                       "kid":"MDNT-WT3G-346G-4I5T-YV7F-LTQX-PSNT",



Hallam-Baker              Expires 17 April 2025                [Page 39]

Internet-Draft            Mesh Schema Reference             October 2024


                       "signature":"XNiZFxlGpuRctoAwDE2M8-E9H1T2YEYj
     vvtA3-7IauLyRUyXUmdd84apRaYEtCmjgVZWlurG1ywAAOj9MfFdDkucJ-QGefgtg
     mhN5YUI4K6s7p9LjjAheFt3YYRY9TNrcBFgStXVT01OL9NdO4VPyhwA"}
                     ],
                   "PayloadDigest":"O_emyhwHRf9e38XKr7utUgB-gKMyo6qi
     v-Hd03Xui8KhZUCyw3LsdqG4OP5vgzJ7RM4uxJei5hOwd6-fn9MISQ"}
                 ]}
             ]}}}}

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

4.5.  Credential

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

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

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

4.6.  Device

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

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

4.7.  Network

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





Hallam-Baker              Expires 17 April 2025                [Page 40]

Internet-Draft            Mesh Schema Reference             October 2024


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

4.8.  Publication

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

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

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

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

   Contact  Used in the Static QR Code Contact Exchange interaction.

   Profile Device  Used in the Preconfigured Device Connection
      interaction.

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

   >>>> Unfinished SchemaEntryPublication

   Missing example 13

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",
       "Uid":"NDQD-6QT7-56MN-ONAG-2NUJ-DADI-BPOA"}}



Hallam-Baker              Expires 17 April 2025                [Page 41]

Internet-Draft            Mesh Schema Reference             October 2024


5.  Spools

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

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

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

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

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

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

5.1.  Outbound

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

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

   Initial  The initial state of a message posted to the spool.

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

   Received  The Mesh Service of the sender has delivered the message to




Hallam-Baker              Expires 17 April 2025                [Page 42]

Internet-Draft            Mesh Schema Reference             October 2024


      the Mesh Service of the recipient and the recipient has
      acknowledged receipt.

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

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

5.2.  Inbound

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

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

   Initial  The initial state of a message posted to the spool.

   Read  The message has been read.

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

5.3.  Local

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

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

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

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

   Initial  The initial state of a message posted to the spool.

   Closed  The action associated with the message has been completed.




Hallam-Baker              Expires 17 April 2025                [Page 43]

Internet-Draft            Mesh Schema Reference             October 2024


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

5.4.  Log

   The log spo

6.  Logs

   The logging functions are not currently implemented.

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

   The following logs are specified:

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

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

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

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

7.  Cryptographic Operations

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









Hallam-Baker              Expires 17 April 2025                [Page 44]

Internet-Draft            Mesh Schema Reference             October 2024


7.1.  Key Derivation from Seed

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

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

7.2.  Message Envelope and Response Identifiers.

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

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

   Where the values of content are given as follows:

   application/mmm/envelopeid  The proposed IANA content identifier for
      the Mesh message type.

   application/mmm/responseid  The proposed IANA content identifier for
      the Mesh message type.

   For example:










Hallam-Baker              Expires 17 April 2025                [Page 45]

Internet-Draft            Mesh Schema Reference             October 2024


   MessageID
       = NBAM-IBG7-4IM2-UNK6-NQOQ-HFSR-4LBD

   EnvelopeID
       = MBRN-LSG3-IBIK-2RUK-U4TO-HOZK-7ZJP

   ResponseID
       = MBB3-YB75-4P67-6YFY-2WWY-AKUA-UHPV

7.3.  Proof of Knowledge of PIN

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

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

   The inputs to the PIN proof of knowledge functions are:

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

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

   Account: string  The account for which the PIN code is issued.

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

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

   The following values of Action are currently defined:

   Device  Action info for device PIN

   Contact  Action info for contact PIN




Hallam-Baker              Expires 17 April 2025                [Page 46]

Internet-Draft            Mesh Schema Reference             October 2024


   These inputs are used to derive values as follows:

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

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

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

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

   For example, to generate saltedPIN for the pin ADE7-U5DR-2YNJ-XKVX-
   4RUE-SVL5-5I used to authenticate a an action of type Device:

   pin = ADE7-U5DR-2YNJ-XKVX-4RUE-SVL5-5I
   action = message.

   alg = UdfAlg (PIN)
       = Authenticator_HMAC_SHA_2_512

   hashalg = default (alg, HMAC_SHA_2_512)

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

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

   saltedPIN = UDFPresent (hashalg + saltedPINData)
       = ABYY-PTS3-HOUO-E3VH-TOCJ-GFJI-XPHS

   The PinId binding the pin to the account alice@example.com is

   Account =  alice@example.com

   PinId = UDFPresent (MAC (Account, saltedPINData))
       = ACMS-5CGG-NMBJ-JOPG-MALJ-ZPSP-GDLS





Hallam-Baker              Expires 17 April 2025                [Page 47]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

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

7.4.  EARL

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

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

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

8.  Mesh Assertions

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

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

   (Artwork only available as svg: see https://www.ietf.org/archive/id/
   draft-hallambaker-mesh-schema-13.html)

                     Figure 1: Profiles And Connections

8.1.  Encoding

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



Hallam-Baker              Expires 17 April 2025                [Page 48]

Internet-Draft            Mesh Schema Reference             October 2024


   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-callsign] at a future date.

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

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

8.2.  Mesh Profiles

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

   *  Profiles describe credentials, they do not make identity
      statements

   *  Profiles do not expire, there is therefore no need to support
      renewal processing.

   *  Profiles may be modified over time, the current and past status of
      a profile being recorded in an append only log.







Hallam-Baker              Expires 17 April 2025                [Page 49]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

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

   A Profile is valid if and only if:

   *  There is a SignatureKey field.

   *  The profile is signed under the key specified in the SignatureKey
      field.

   A profile has the status current if and only if:

   *  The Profile is valid

   *  Every Conditions clause in the profile is understood by the
      relying party and evaluates to true.

8.3.  Mesh Connections

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

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

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

   *  The profile _P_ is valid

   *  The AuthorityUdf field of the connection is consistent with the
      UDF of _P_





Hallam-Baker              Expires 17 April 2025                [Page 50]

Internet-Draft            Mesh Schema Reference             October 2024


   *  The profile is signed under the key specified in the
      AdministrationKey field of _P_.

   *  Any conditions specified in the profile are met

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

   *  The connection is valid with respect to the account with profile
      _P_.

   *  The profile P is current.

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

   *  The connection is valid with respect to the account with profile
      _P_.

   *  The device has presented an appropriate proof of knowledge of the
      DeviceAuthentication key specified in the connection.

8.4.  Device Pre-configuration

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

   *  The Enveloped ProfileDevice.

   *  A ConnectionDevice assertion credentialing the device to the
      configuration provider Mesh Service.

   *  A ConnectionService assertion credentialing the device to the
      configuration provider Mesh Service.

   *  The secret seed used to create the ProfileDevice data.

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

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





Hallam-Baker              Expires 17 April 2025                [Page 51]

Internet-Draft            Mesh Schema Reference             October 2024


   {
     "DevicePreconfigurationPrivate":{
       "EnvelopedConnectionDevice":[{
           "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
     9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ
     DcmVhdGVkIjogIjIwMjQtMTAtMTRUMTM6MTA6NThaIn0",
           "dig":"S512"},
         "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIlNpZ25hdHVyZSI6IH
     sKICAgICAgIlVkZiI6ICJNRFY1LUVJQ0ktSk5GVi0zNUs3LUlQREctNkNWNy1OU1Y
     1IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tl
     eUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQd
     WJsaWMiOiAiQVVPMUIyR1RLNGZjSk9rUFlNN0RJa3VDT2s0SWNJbHFzTGZuQVlnQS
     1BQ0dhZmNvUFZCdQogIEJDSGYzR2JDMEx2bHBiS2cwNmliREh5QSJ9fX0sCiAgICA
     iRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQkZGLUVTUDMtVk5YWS1EWUhM
     LTVNSkktVjRLNy1WN1dOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgI
     CAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLA
     ogICAgICAgICAgIlB1YmxpYyI6ICJMd2oxNlE3QmNraWU3ZU9jMG85NXJYbGZ6enh
     rSDFFTGVCMGxlLURJdklxemVpeHlocjZhCiAgTjRTSV94Vzh6eGwxSGVSclRKN1lh
     Uy1BIn19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ
     kZGLUVTUDMtVk5YWS1EWUhMLTVNSkktVjRLNy1WN1dOIiwKICAgICAgIlB1YmxpY1
     BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICA
     gICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJMd2oxNlE3QmNr
     aWU3ZU9jMG85NXJYbGZ6enhrSDFFTGVCMGxlLURJdklxemVpeHlocjZhCiAgTjRTS
     V94Vzh6eGwxSGVSclRKN1lhUy1BIn19fX19",
         {
           "signatures":[{
               "alg":"ED448",
               "kid":"MD66-B7Q7-HWEB-UAF6-PWNM-YVBH-HXE7",
               "signature":"T5q8Ygyj3aM5tDzUmjoFMAVdGasi0PF1SZlgFYCl
     3kCT5_NZrd5iuGcJetwaq0bINEJHDjUppQuAdbpe8eZPlJBtTo8EBksurd04sqf1U
     NIokTq5HA-eXh45bjPkOGjwZmBBO46LlyQDG_kq-6roUw0A"}
             ],
           "PayloadDigest":"CQupHrY2ASmhF8QOcXCnjid4nC6wlVlUk9cxmIUc
     MGC1_YLhJwc7wpE-EfoDCcmkTtRCPmwq1tmdX88VClLkSw"}
         ],
       "EnvelopedConnectionService":[{
           "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW
     9uU2VydmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICA
     iQ3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU4WiJ9",
           "dig":"S512"},
         "ewogICJDb25uZWN0aW9uU2VydmljZSI6IHsKICAgICJBdXRoZW50aWNhdG
     lvbiI6IHsKICAgICAgIlVkZiI6ICJNQkZGLUVTUDMtVk5YWS1EWUhMLTVNSkktVjR
     LNy1WN1dOIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1
     YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgI
     CAgIlB1YmxpYyI6ICJMd2oxNlE3QmNraWU3ZU9jMG85NXJYbGZ6enhrSDFFTGVCMG
     xlLURJdklxemVpeHlocjZhCiAgTjRTSV94Vzh6eGwxSGVSclRKN1lhUy1BIn19fX1
     9",
         {



Hallam-Baker              Expires 17 April 2025                [Page 52]

Internet-Draft            Mesh Schema Reference             October 2024


           "signatures":[{
               "alg":"ED448",
               "kid":"MD66-B7Q7-HWEB-UAF6-PWNM-YVBH-HXE7",
               "signature":"4FkfmdMX6sWMQ5zskF7V_1UsoBTBKVVQtYigF41m
     MGOx1_yTQtpDs1lnqxmBt6yAtjfUvv1NsG2AdYx425rJ5-lryqyud6m-MNoTCUeWW
     wuO0jGMpaw2PyjFUFh62_k5fGDzZVgqx-larLbwVf6vFQsA"}
             ],
           "PayloadDigest":"z4aP8rSa_WxiufLZcZmhBbJd-3OCz70GX4gIkH0y
     U4LCO8QdoX-4iAbwfwylksQDTtNbKmVfxQam4MCT-2oKZw"}
         ],
       "PrivateKey":{
         "PrivateKeyUDF":{
           "PrivateValue":"ZAAQ-AUKH-YPXV-5NTI-ZVIK-4Q2D-EFAP-UR7Y-5XX
   N-EDXE-HX3O-LYFS-BJOU-CMQE",
           "KeyType":"MeshProfileDevice",
           "RootSignAlgorithms":["ED448"
             ]}},
       "ConnectUri":"mcd://maker@example.com/EBH3-DT6M-G2WA-EF7E-DA42-
   DN55-7E",
       "EnvelopedProfileDevice":[{
           "EnvelopeId":"MBQK-36BF-K7RS-UDWD-PVC3-CVMR-BJCP",
           "ContentMetaData":"ewogICJVbmlxdWVJZCI6ICJNQlFLLTM2QkYtSz
     dSUy1VRFdELVBWQzMtQ1ZNUi1CSkNQIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml
     sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi
     Q3JlYXRlZCI6ICIyMDI0LTEwLTE0VDEzOjEwOjU4WiJ9",
           "dig":"S512"},
         "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIkVuY3J5cHRpb24iOiB7Ci
     AgICAgICJVZGYiOiAiTUJGRi1FU1AzLVZOWFktRFlITC01TUpJLVY0SzctVjdXTiI
     sCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlF
     Q0RIIjogewogICAgICAgICAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsa
     WMiOiAiTHdqMTZRN0Jja2llN2VPYzBvOTVyWGxmenp4a0gxRUxlQjBsZS1ESXZJcX
     plaXh5aHI2YQogIE40U0lfeFc4enhsMUhlUnJUSjdZYVMtQSJ9fX0sCiAgICAiU2l
     nbmF0dXJlIjogewogICAgICAiVWRmIjogIk1EVjUtRUlDSS1KTkZWLTM1SzctSVBE
     Ry02Q1Y3LU5TVjUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgI
     CAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogIC
     AgICAgICAgIlB1YmxpYyI6ICJBVU8xQjJHVEs0ZmNKT2tQWU03RElrdUNPazRJY0l
     scXNMZm5BWWdBLUFDR2FmY29QVkJ1CiAgQkNIZjNHYkMwTHZscGJLZzA2aWJESHlB
     In19fSwKICAgICJBdXRoZW50aWNhdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQVZHL
     VlXWVYtMlVXNy1MU1QzLUFQQkctUkw3SC1ONTMzIiwKICAgICAgIlB1YmxpY1Bhcm
     FtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICA
     iY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJyRlZGUi1jTDZjdWNU
     U3JmRm4xNDZYVE9kMWgzSkdBM0hrQ0VlYkNzaUEzT3dWQXBkN2ZsCiAgZ0Z4Zlh0d
     lkzVXRpNmlRd1RTdmVFWmtBIn19fSwKICAgICJSb290VWRmcyI6IFsiWU5lVGVBYk
     l4NVdSdEN4Q3llbnBqYWJKVlJuOERUbGF1SFBUZFFUYnRJOEFHblY1bk8KICBWM1l
     PWENlRFlRZTk5VnFIcWZwYi10MFZxSjI5blZKRW1yUEpNIl19fQ",
         {
           "signatures":[{
               "alg":"ED448",



Hallam-Baker              Expires 17 April 2025                [Page 53]

Internet-Draft            Mesh Schema Reference             October 2024


               "kid":"MDLZ-G6AG-ZDDZ-LENU-FRBM-T2PJ-RWTM",
               "SignatureKey":{
                 "PublicKeyECDH":{
                   "crv":"Ed448",
                   "Public":"WPX0CBEOzgJWHVJqiyTAr4MrieFJQYzdutZML5-
     MnHsfF7KfRmGxsUR9eppBIKTFhzLaRhd06XmA"}},
               "signature":"s1AVL-omThJqK3LTFXtg58xvRBZoeansc39u4rqT
     iKRHKrCQx-11PG9b0Vq-VC_MRWxbCwZenawAo4fBnNnpNvtbNGUaALlFVvLK5nPZV
     O6nY6gA_i3ID9ZrUTxYJz0lbj-ZTIt6NZOGxTJX4yxJiC8A"}
             ],
           "PayloadDigest":"OrZNsRzLz7olETFljSpKbdG1bNjj5MBr-ireuPK6
     Sn9-ARWs4E3Xk2_HvrHA7cySavkX6anRBSGzQ5uYty0_Ow"}
         ]}}

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

9.  Architecture

   The Mesh architecture has four principal components:

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

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

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

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

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

   A Mesh Account May be active or inactive.  By definition, an active
   Mesh account is serviced by exactly one Mesh Service, an inactive
   Mesh account is not serviced by a Mesh Service.  A Mesh Service
   Provider MAY offer a backup service for accounts hosted by other
   providers.  In this case the backup provider is connected to the



Hallam-Baker              Expires 17 April 2025                [Page 54]

Internet-Draft            Mesh Schema Reference             October 2024


   account as a Mesh device, thus allowing the backup provider to
   maintain a copy of the stores contained in the account and
   facilitating a rapid transfer of responsibility for servicing the
   account should that be desired.  The use of backup providers is
   described further in [draft-hallambaker-mesh-discovery].

9.1.  Mesh Account

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

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

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

9.1.1.  Account Profile

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

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

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







Hallam-Baker              Expires 17 April 2025                [Page 55]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

9.2.  Device Management

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

   *  The Access catalog is used to instruct the Mesh Service how to
      respond to requests from the device.

   *  The Device catalog records information for use by administration
      devices managing the device.

9.2.1.  The Device Catalog

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






Hallam-Baker              Expires 17 April 2025                [Page 56]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

9.2.2.  Mesh Devices

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

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

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

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

   (Artwork only available as svg: see https://www.ietf.org/archive/id/
   draft-hallambaker-mesh-schema-13.html)

      Figure 2: Mapping of Device Profile and Device Private to Device
                              Connection Keys.

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







Hallam-Baker              Expires 17 April 2025                [Page 57]

Internet-Draft            Mesh Schema Reference             October 2024


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

9.2.2.2.  Connection to a Meh Account

   Devices are only connected to a personal Mesh by an 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 account.

   4.  Creating an AccessCapability granting the necessary access rights
       for the device and adding that to the CatalogAccess of the
       account.

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

9.3.  Mesh Services

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

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





Hallam-Baker              Expires 17 April 2025                [Page 58]

Internet-Draft            Mesh Schema Reference             October 2024


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

   (Artwork only available as svg: see https://www.ietf.org/archive/id/
   draft-hallambaker-mesh-schema-13.html)

          Figure 3: Service Profile and Delegated Host Assertion.

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

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

9.4.  Mesh Messaging

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

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

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

9.4.1.  Message Status

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

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




Hallam-Baker              Expires 17 April 2025                [Page 59]

Internet-Draft            Mesh Schema Reference             October 2024


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

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

9.4.2.  Four Corner Model

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

   (Artwork only available as svg: see https://www.ietf.org/archive/id/
   draft-hallambaker-mesh-schema-13.html)

                   Figure 4: Four Corner Messaging Model

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

   (Artwork only available as svg: see https://www.ietf.org/archive/id/
   draft-hallambaker-mesh-schema-13.html)

          Figure 5: Performing Access Control on Outbound Messages

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

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

   (Artwork only available as svg: see https://www.ietf.org/archive/id/
   draft-hallambaker-mesh-schema-13.html)

          Figure 6: Performing Access Control on Inbound Messages



Hallam-Baker              Expires 17 April 2025                [Page 60]

Internet-Draft            Mesh Schema Reference             October 2024


9.4.3.  Traffic Analysis

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

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

10.  Publications

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

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

10.1.  Profile Device

10.2.  Contact Exchange

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

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

11.  Schema

11.1.  Shared Classes

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

11.1.1.  Classes describing keys






Hallam-Baker              Expires 17 April 2025                [Page 61]

Internet-Draft            Mesh Schema Reference             October 2024


11.1.2.  Structure: KeyData

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

   Udf: String (Optional)  UDF fingerprint of the public key parameters

   X509Certificate: Binary (Optional)  List of X.509 Certificates

   X509Chain: Binary [0..Many]  X.509 Certificate chain.

   X509CSR: Binary (Optional)  X.509 Certificate Signing Request.

   NotBefore: DateTime (Optional)  If present specifies a time instant
      that use of the private key is not valid before.

   NotOnOrAfter: DateTime (Optional)  If present specifies a time
      instant that use of the private key is not valid on or after.

11.1.3.  Structure: KeyShare

   Inherits: Key

   ServiceId: String (Optional)  The identifier used to claim the
      capability from the service.[Only present for a partial key.]

   ServiceAddress: String (Optional)  The service account that supports
      a serviced capability.  [Only present for a partial key.]

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



Hallam-Baker              Expires 17 April 2025                [Page 62]

Internet-Draft            Mesh Schema Reference             October 2024


   Updated: DateTime (Optional)  The time instant the profile was last
      modified.

   NotaryToken: String (Optional)  A Uniform Notary Token providing
      evidence that a signature was performed after the notary token was
      created.

11.2.2.  Structure: Condition

   Parent class from which all condition classes are derived.

   [No fields]

11.2.3.  Base Classes

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

11.2.4.  Structure: 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 account
      resource activations.  These are separate from Application
      activations which are

11.2.5.  Structure: ActivationEntry

   Resource: String (Optional)  Name of the activated resource

   Key: KeyData (Optional)  The activation key or key share

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







Hallam-Baker              Expires 17 April 2025                [Page 63]

Internet-Draft            Mesh Schema Reference             October 2024


11.2.6.  Mesh Profile Classes

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

11.2.7.  Structure: Profile

   Inherits: Assertion

   Parent class from which all profile classes are derived

   Description: String (Optional)  Description of the profile

   RootUdfs: Binary [0..Many]  A list of binary UDF fingerprints of
      accepted root signature keys for the profile.  The profile
      finderprint is calculated over the concatenation of the
      fingerprint URIs.

11.2.8.  Structure: ProfileDevice

   Inherits: Profile

   Describes a mesh device.

   Encryption: KeyData (Optional)  Base key contribution for encryption
      keys.  Also used to decrypt activation data sent to the device
      during connection to an account.

   Signature: KeyData (Optional)  Base key contribution for signature
      keys.

   Authentication: KeyData (Optional)  Base key contribution for
      authentication keys.  Also used to authenticate the device during
      connection to an account.

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



Hallam-Baker              Expires 17 April 2025                [Page 64]

Internet-Draft            Mesh Schema Reference             October 2024


   EscrowEncryption: KeyData (Optional)  Escrow key associated with the
      account.

   AdministratorSignature: KeyData (Optional)  Key used to sign
      connection assertions to the account.

   CommonEncryption: KeyData (Optional)  Key currently used to encrypt
      data under this profile

   CommonAuthentication: KeyData (Optional)  Key used to authenticate
      requests made under this user account.  This key SHOULD NOT be
      provisioned to any device except for the purpose of enabling
      account recovery.

11.2.10.  Structure: ProfileUser

   Inherits: ProfileAccount

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

   CommonSignature: KeyData (Optional)  Key used to sign data under the
      account.

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

   Cover: Binary (Optional)  HTML document containing cover text to be
      presented if a document encrypted under the group key cannot be
      decrypted.

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




Hallam-Baker              Expires 17 April 2025                [Page 65]

Internet-Draft            Mesh Schema Reference             October 2024


   ServiceSignature: KeyData (Optional)  Key used to sign data under the
      account.

11.2.13.  Structure: ProfileMeshService

   Inherits: ProfileService

   Profile of a Mesh Service

   [No fields]

11.2.14.  Structure: ProfileHost

   Inherits: ProfileDevice

   Profile of a Mesh Host providing one or more Mesh Services.

   [No fields]

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

   Inherits: Assertion

   Subject: String (Optional)  UDF of the connection target.

   Authority: String (Optional)  UDF of the connection source.

   Authentication: KeyData (Optional)  The authentication key for use of
      the device under the profile

11.2.17.  Structure: CallsignBinding

   Inherits: Assertion

   Canonical: String (Optional)  The canonical form of the callsign.

   Display: String (Optional)  The display form of the callsign.  This
      MAY include characters such as whitespace, trademark signifiers,
      etc. that are omitted of trranslated in the canonical form.

   CharacterPage: String (Optional)  Specifies the page to which the
      Description"CharacterPageLatin"



Hallam-Baker              Expires 17 April 2025                [Page 66]

Internet-Draft            Mesh Schema Reference             October 2024


   ProfileUdf: String (Optional)  The profile to which the name is
      bound.

   TransferUdf: String (Optional)  The profile to which the name has
      been transfered.

   Services: NamedService [0..Many]  List of named services.  If
      multiple service providers are specified for a given service,
      these are listed in order of priority, most preferred first.

   ServiceAddress: String (Optional)  The Mesh service address.

   CommonEncryption: KeyData (Optional)  Key currently used to encrypt
      data under this profile

11.2.18.  Structure: Accreditation

   Registration of a trusted third party accreditation of a callsign/
   profile binding.

   Callsign: String (Optional)  The callsign to which the accreditation
      applies

   ProfileUdf: String (Optional)  The profile to which the accreditation
      applies.

   SubjectNames: String [0..Many]  The validated names of the subject

   SubjectLogos: String [0..Many]  Mesh strong URIs from which a
      validated logo belonging to the subject MAY be retreived and
      validated.

   Issued: DateTime (Optional)  The time the assertion was issued.

   Expires: DateTime (Optional)  The time the assertion is due to expire

   Policy: String (Optional)  The issuing policy under which the
      validation was performed.

   Practice: String (Optional)  The issuing practices under which the
      validation was performed.

11.2.19.  Structure: ConnectionStripped

   Asserts that a profile is connected to an account address.

   Inherits: Connection




Hallam-Baker              Expires 17 April 2025                [Page 67]

Internet-Draft            Mesh Schema Reference             October 2024


   Stripped down connection assertion

   Account: String (Optional)  To be removed

11.2.20.  Structure: ConnectionService

   Inherits: Connection

   Asserts that a device is connected to an account profile

   ProfileUdf: String (Optional)  The account address

11.2.21.  Structure: ConnectionDevice

   Inherits: ConnectionService

   Asserts that a device is connected to an account profile

   Roles: String [0..Many]

   Signature: KeyData (Optional)  The signature key for use of the
      device under the profile

   Encryption: KeyData (Optional)  The encryption key for use of the
      device under the profile

11.2.22.  Structure: ConnectionApplication

   Inherits: Connection

   Connection assertion stating that a particular device is

   [No fields]

11.2.23.  Structure: ConnectionGroup

   Describes the connection of a member to a group.

   Inherits: Connection

   [No fields]

11.2.24.  Structure: AccountHostAssignment

   Inherits: Assertion

   AccountAddess: String (Optional)  The account being bound




Hallam-Baker              Expires 17 April 2025                [Page 68]

Internet-Draft            Mesh Schema Reference             October 2024


   HostAddresses: String [0..Many]  Host address in Callsign, DNS or IP
      format in order of preference.

   AccessEncrypt: KeyData (Optional)  Encryption key to be used to
      encrypt data for the service to use.

   CallsignServiceProfile: ProfileAccount (Optional)  Profile of the
      callsign registry used by the service.

   EnvelopedProfileService: Enveloped (Optional)  Profile of the
      service.

11.2.25.  Structure: ConnectionHost

   Inherits: Connection

   [No fields]

11.2.26.  Activation Assertions

11.2.27.  Structure: ActivationAccount

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

   Inherits: Activation

   AccountUdf: String (Optional)  The UDF of the account

11.2.28.  Structure: ActivationHost

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

   Inherits: ActivationAccount

   [No fields]

11.2.29.  Structure: ActivationCommon

   Inherits: Activation

   ProfileSignatures: KeyData [0..Many]  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.




Hallam-Baker              Expires 17 April 2025                [Page 69]

Internet-Draft            Mesh Schema Reference             October 2024


   Encryption: KeyData (Optional)  Grant access to ProfileUser account
      encryption key

   Authentication: KeyData (Optional)  Grant access to ProfileUser
      account authentication key

   Signature: KeyData (Optional)  Grant access to ProfileUser account
      signature key

11.2.30.  Structure: ActivationApplication

   Inherits: Activation

   [No fields]

11.2.31.  Structure: ActivationApplicationSsh

   Inherits: ActivationApplication

   ClientKey: KeyData (Optional)  The SSH client key.

11.2.32.  Structure: ActivationApplicationMail

   Inherits: ActivationApplication

   SmimeSign: KeyData (Optional)  The S/Mime signature key

   SmimeEncrypt: KeyData (Optional)  The S/Mime encryption key

   OpenpgpSign: KeyData (Optional)  The OpenPGP signature key

   OpenpgpEncrypt: KeyData (Optional)  The OpenPGP encryption key

11.2.33.  Structure: ActivationApplicationGroup

   Inherits: ActivationApplication

   AccountEncryption: KeyData (Optional)  Key or capability allowing
      account encryption keys to be created for new members.

   AdministratorSignature: KeyData (Optional)  Key or capability
      allowing account updates, connection assertions etc to be signed.

   AccountAuthentication: KeyData (Optional)  Key or capability allowing
      administration of the group.

   EnvelopedConnectionService: Enveloped (Optional)  Signed connection
      service delegation allowing the device to access the account.



Hallam-Baker              Expires 17 April 2025                [Page 70]

Internet-Draft            Mesh Schema Reference             October 2024


11.3.  Application Data

11.3.1.  Structure: ApplicationEntry

   Identifier: String (Optional)

11.3.2.  Structure: ApplicationEntrySsh

   Inherits: ApplicationEntry

   EnvelopedActivation: Enveloped (Optional)

11.3.3.  Structure: ApplicationEntryGroup

   Inherits: ApplicationEntry

   EnvelopedActivation: Enveloped (Optional)

11.3.4.  Structure: ApplicationEntryMail

   Inherits: ApplicationEntry

   EnvelopedActivation: Enveloped (Optional)

11.4.  Data Structures

   Classes describing data used in cataloged data.

11.4.1.  Structure: Contact

   Inherits: Assertion

   Base class for contact entries.

   Id: String (Optional)  The globally unique contact identifier.

   Local: String (Optional)  The local name.

   Anchors: Anchor [0..Many]  Mesh fingerprints associated with the
      contact.

   Locations: Location [0..Many]  The physical locations the contact is
      associated with.

   Roles: Role [0..Many]  The roles of the contact

   Bookmark: Bookmark [0..Many]  The Web sites and other online
      presences of the contact



Hallam-Baker              Expires 17 April 2025                [Page 71]

Internet-Draft            Mesh Schema Reference             October 2024


   Sources: TaggedSource [0..Many]  Source(s) from which this contact
      was constructed.

11.4.2.  Structure: Anchor

   Trust anchor

   Udf: String (Optional)  The trust anchor.

   Validation: String (Optional)  The means of validation.

11.4.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.4.4.  Structure: ContactGroup

   Inherits: Contact

   Contact for a group, including encryption groups.

   [No fields]

11.4.5.  Structure: ContactPerson

   Inherits: Contact

   CommonNames: PersonName [0..Many]  List of person names in order of
      preference

11.4.6.  Structure: ContactOrganization

   Inherits: Contact

   CommonNames: OrganizationName [0..Many]  List of person names in
      order of preference






Hallam-Baker              Expires 17 April 2025                [Page 72]

Internet-Draft            Mesh Schema Reference             October 2024


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

   Protocol: String (Optional)  The IANA protocol|identifier of the




Hallam-Baker              Expires 17 April 2025                [Page 73]

Internet-Draft            Mesh Schema Reference             October 2024


      network protocols by which the contact may be reached using the
      specified Address.

11.4.10.  Structure: NetworkCredential

   Inherits: NetworkAddress

   Type: String (Optional)  The IANA credential type

   Credential: Binary (Optional)  The credential

11.4.11.  Structure: NetworkProfile

   Inherits: NetworkAddress

   EnvelopedProfileAccount: Enveloped (Optional)  The account profile

11.4.12.  Structure: NetworkCapability

   Inherits: NetworkProfile

   [No fields]

11.4.13.  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.4.14.  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.4.15.  Structure: Location

   Appartment: String (Optional)

   Street: String (Optional)

   District: String (Optional)




Hallam-Baker              Expires 17 April 2025                [Page 74]

Internet-Draft            Mesh Schema Reference             October 2024


   Locality: String (Optional)

   County: String (Optional)

   Postcode: String (Optional)

   Country: String (Optional)

11.4.16.  Structure: Bookmark

   Uri: String (Optional)

   Title: String (Optional)

   Role: String [0..Many]

11.4.17.  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.4.18.  Structure: Engagement

   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]



Hallam-Baker              Expires 17 April 2025                [Page 75]

Internet-Draft            Mesh Schema Reference             October 2024


   Conference: String [0..Many]

   Repeat: String (Optional)

   Busy: Boolean (Optional)

11.4.19.  Structure: WorkTask

   Inherits: Engagement

   Dependency: String [0..Many]

11.5.  Catalog Entries

11.5.1.  Structure: CatalogedEntry

   Base class for cataloged Mesh data.

   Uid: String (Optional)  Globaly unique identifier

   LocalName: String (Optional)  User specified identifier.

   Path: String (Optional)  The set of labels describing the entry

   Description: String (Optional)  Description

11.5.2.  Structure: CatalogedDevice

   Inherits: CatalogedEntry

   Public device entry, indexed under the device ID Hello

   Updated: DateTime (Optional)  Timestamp, allows

   Udf: String (Optional)  UDF of the signature key of the device in the
      Mesh

   Platform: String (Optional)  Device Platform

   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.  Why is
      this still here?  This is not specific to the device.




Hallam-Baker              Expires 17 April 2025                [Page 76]

Internet-Draft            Mesh Schema Reference             October 2024


   EnvelopedProfileDevice: Enveloped (Optional)  The device profile

   DeviceDescription: DeviceDescription (Optional)  Description of the
      device

   EnvelopedConnectionService: Enveloped (Optional)  Slim version of
      ConnectionDevice used by the presentation layer

   EnvelopedConnectionDevice: Enveloped (Optional)  The public assertion
      demonstrating connection of the Device to the Mesh

   EnvelopedActivationAccount: Enveloped (Optional)  The activation of
      the device within the Mesh account

   EnvelopedActivationCommon: Enveloped (Optional)  The activation of
      the device within the Mesh account

11.5.3.  Structure: DeviceDescription

   Idiom: String (Optional)  The device form factor, valid values are
      Desktop, Phone, Tablet, TV, Watch

   Manufacturer: String (Optional)  Manufacturer name

   Model: String (Optional)  Manufacturer defined model

   Name: String (Optional)  Name of the device as specified by the user

   Platform: String (Optional)  The device platform or operating system:
      Android / iOS / macOS / Tizen / watchOS / Windows

   Version: String (Optional)  Platform version in format
      Major.Minor.Build.Revision

   ImageLocator: String (Optional)  EARL specifying an image of the
      device.

11.5.4.  Structure: CatalogedSignature

   Inherits: CatalogedEntry

   Cataloged Signature

   [No fields]







Hallam-Baker              Expires 17 April 2025                [Page 77]

Internet-Draft            Mesh Schema Reference             October 2024


11.5.5.  Structure: CatalogedDocument

   A document stored on a service somewhere.

   Inherits: CatalogedEntry

   Udf: String (Optional)  Document fingerprint.

   Filename: String (Optional)

   Title: String (Optional)

   Version: String (Optional)

   URI: String (Optional)  Locator to be used to retrieve the data.

   ContentType: String (Optional)  IANA content type of the encoded
      content.

   Encoding: String (Optional)  Content encoding, typically DARE
      envelope.

   Created: DateTime (Optional)

   Updated: DateTime (Optional)

   Length: Integer (Optional)  Encoded document length in bytes.

11.5.6.  Structure: CatalogedPublication

   Inherits: CatalogedEntry

   A publication.

   Id: String (Optional)  Unique identifier code

   Authenticator: String (Optional)  The witness key value to use to
      request access to the record.

   EnvelopedData: DareEnvelope (Optional)  Dare Envelope containing the
      entry data.  The data type is specified by the envelope metadata.

   NotOnOrAfter: DateTime (Optional)  Epiration time (inclusive)

11.5.7.  Structure: CatalogedCredential

   Inherits: CatalogedEntry




Hallam-Baker              Expires 17 April 2025                [Page 78]

Internet-Draft            Mesh Schema Reference             October 2024


   Protocol: String (Optional)

   Service: String (Optional)

   Username: String (Optional)

   Password: String (Optional)

   ClientAuthentication: KeyData [0..Many]  Specifies the client
      identification key

   HostAuthentication: KeyData [0..Many]  Means of authenticating the
      host key

11.5.8.  Structure: CatalogedNetwork

   Inherits: CatalogedEntry

   Protocol: String (Optional)

   Service: String (Optional)

   Username: String (Optional)

   Password: String (Optional)

11.5.9.  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.5.10.  Structure: CatalogedAccess

   Inherits: CatalogedEntry

   [No fields]

11.5.11.  Structure: Capability

   Id: String (Optional)  The identifier of the capability.  If this is
      a cryptographic capability, this is the KeyIdentifier of the
      primary key that was shared.  If this is an access capability,
      this is the KeyIdentifier of the authentication key being
      authorized for access.



Hallam-Baker              Expires 17 April 2025                [Page 79]

Internet-Draft            Mesh Schema Reference             October 2024


   Active: Boolean (Optional)

   Issued: Integer (Optional)

   Mode: String (Optional)  The authentication mode: Device, Account,
      PIN

   Udf: String (Optional)  Identifies the authentication credential.
      For a device, this is the authentication key identifier, for an
      account, the profile identifier, for a PIN, the locator value of
      the PIN.

   Witness: String (Optional)  The verification value used to perform
      proof of knowledge of the secret.

11.5.12.  Structure: NullCapability

   Inherits: Capability

   [No fields]

11.5.13.  Structure: AccessCapability

   Inherits: Capability

   Rights: String [0..Many]  Access rights associated with the key

   EnvelopedCatalogedDevice: Enveloped (Optional)

   CatalogedDeviceDigest: String (Optional)  Digest value used to signal
      updates to envelope

11.5.14.  Structure: PublicationCapability

   Inherits: Capability

   Identifier: String (Optional)  Selector allowing a specific document
      to be requested.

   Digest: String (Optional)  Document digest, this allows a status/
      claim request to request an update to be returned only if the
      document has changed.

   Data: Binary (Optional)  The published document.







Hallam-Baker              Expires 17 April 2025                [Page 80]

Internet-Draft            Mesh Schema Reference             October 2024


11.5.15.  Structure: CryptographicCapability

   Inherits: Capability

   KeyData: KeyData (Optional)  The key that enables the capability

   GranteeAccount: String (Optional)

   GranteeUdf: String (Optional)

   EnvelopedKeyShare: Enveloped (Optional)  One or more enveloped key
      shares.

11.5.16.  Structure: CapabilityDecrypt

   Inherits: CryptographicCapability

   The corresponding key is a decryption key

   [No fields]

11.5.17.  Structure: CapabilityDecryptPartial

   Inherits: CapabilityDecrypt

   The corresponding key is an encryption key

   [No fields]

11.5.18.  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.5.19.  Structure: CapabilitySign

   Inherits: CryptographicCapability

   The corresponding key is an administration key

   [No fields]





Hallam-Baker              Expires 17 April 2025                [Page 81]

Internet-Draft            Mesh Schema Reference             October 2024


11.5.20.  Structure: CapabilityKeyGenerate

   Inherits: CryptographicCapability

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

   [No fields]

11.5.21.  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.5.22.  Structure: NamedService

   Prefix: String (Optional)  The IANA service name (e.g. dns)

   Mapping: String (Optional)  Optional name mapping, (e.g.
      alice@example.com -> alice.mesh)

   Endpoints: String [0..Many]  The service endpoints.  This MAY be
      specified as a callsign (@alice), a DNS address (example.com), an
      IP address (10.0.0.1) or a fully qualified URI.

11.5.23.  Structure: ServiceAccessToken

   Inherits: NamedService

   Token: Binary (Optional)  Session initiation token

   SharedSecret: Binary (Optional)  Session shared secret

11.5.24.  Structure: CatalogedBookmark

   Inherits: CatalogedEntry

   Uri: String (Optional)

   Title: String (Optional)

   Comments: String [0..Many]  User comments on bookmark entry




Hallam-Baker              Expires 17 April 2025                [Page 82]

Internet-Draft            Mesh Schema Reference             October 2024


11.5.25.  Structure: CatalogedTask

   Inherits: CatalogedEntry

   Title: String (Optional)

   EnvelopedTask: Enveloped (Optional)

11.5.26.  Structure: CatalogedApplication

   Inherits: CatalogedEntry

   Default: Integer (Optional)

   Key: String (Optional)

   Grant: String [0..Many]

   Deny: String [0..Many]

   EnvelopedCapabilities: DareEnvelope [0..Many]  Enveloped keys for use
      with Application

   EnvelopedEscrow: Enveloped [0..Many]  Escrow entries for the
      application.

11.5.27.  Structure: CatalogedMember

   ContactAddress: String (Optional)

   MemberCapabilityId: String (Optional)

   ServiceCapabilityId: String (Optional)

   Inherits: CatalogedEntry

11.5.28.  Structure: CatalogedGroup

   Inherits: CatalogedApplication

   EnvelopedConnectionAddress: Enveloped (Optional)  The connection
      allowing control of the group.

   EnvelopedProfileGroup: Enveloped (Optional)  The Mesh profile

   EnvelopedActivationCommon: Enveloped (Optional)  The activation of
      the device within the Mesh account




Hallam-Baker              Expires 17 April 2025                [Page 83]

Internet-Draft            Mesh Schema Reference             October 2024


11.5.29.  Structure: CatalogedFeed

   Inherits: CatalogedBookmark

   Protocol: String (Optional)

11.5.30.  Structure: CatalogedApplicationMail

   Inherits: CatalogedApplication

   AccountAddress: String (Optional)

   InboundConnect: String (Optional)

   OutboundConnect: String (Optional)

   SmimeSign: KeyData (Optional)  The S/Mime signature key

   SmimeEncrypt: KeyData (Optional)  The S/Mime encryption key

   OpenpgpSign: KeyData (Optional)  The OpenPGP signature key

   OpenpgpEncrypt: KeyData (Optional)  The OpenPGP encryption key

11.5.31.  Structure: CatalogedApplicationPkix

   Inherits: CatalogedApplication

   [No fields]

11.5.32.  Structure: CatalogedApplicationOpenPgp

   Inherits: CatalogedApplication

   [No fields]

11.5.33.  Structure: CatalogedApplicationSsh

   Inherits: CatalogedApplication

   ClientKey: KeyData (Optional)  The S/Mime encryption key

11.5.34.  Structure: CatalogedApplicationGit

   Inherits: CatalogedApplication

   [No fields]




Hallam-Baker              Expires 17 April 2025                [Page 84]

Internet-Draft            Mesh Schema Reference             October 2024


11.5.35.  Structure: CatalogedApplicationDeveloper

   Inherits: CatalogedApplication

   [No fields]

11.5.36.  Structure: MessageInvoice

   Inherits: Message

   [No fields]

11.5.37.  Structure: CatalogedReceipt

   Inherits: CatalogedEntry

   [No fields]

11.5.38.  Structure: CatalogedTicket

   Inherits: CatalogedEntry

   [No fields]

11.6.  Publications

11.6.1.  Structure: DevicePreconfigurationPublic

   EnvelopedProfileDevice: Enveloped (Optional)  The device profile

   Hailing: String [0..Many]  A list of URIs specifying hailing
      transports that may be used to initiate a connection to the
      device.  This allows a device to specify that it can be reached by
      WiFi transport to a particular private SSID, or by Bluetooth, IR
      etc. etc.

11.6.2.  Structure: DevicePreconfigurationPrivate

   Inherits: DevicePreconfigurationPublic

   A data structure that is passed

   EnvelopedConnectionDevice: Enveloped (Optional)  The device
      connection

   EnvelopedConnectionService: Enveloped (Optional)  The device
      connection




Hallam-Baker              Expires 17 April 2025                [Page 85]

Internet-Draft            Mesh Schema Reference             October 2024


   ConnectUri: String (Optional)  The connection URI.  This would
      normally be printed on the device as a QR code.

11.7.  Messages

11.7.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.7.2.  Structure: MessageError

   Inherits: Message

   ErrorCode: String (Optional)

11.7.3.  Structure: MessageComplete

   Inherits: Message

   References: Reference [0..Many]

11.7.4.  Structure: MessageValidated

   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.7.5.  Structure: MessagePin

   Account: String (Optional)

   Inherits: Message



Hallam-Baker              Expires 17 April 2025                [Page 86]

Internet-Draft            Mesh Schema Reference             October 2024


   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.

   Roles: String [0..Many]  The set of rights bound to the PIN grant.

11.7.6.  Structure: RequestConnection

   Connection request message.  This message contains the information

   Inherits: MessageValidated

   AccountAddress: String (Optional)

11.7.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.7.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 17 April 2025                [Page 87]

Internet-Draft            Mesh Schema Reference             October 2024


11.7.9.  Structure: MessageContact

   Inherits: MessageValidated

   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.7.10.  Structure: GroupInvitation

   Inherits: Message

   Text: String (Optional)

11.7.11.  Structure: MessageMail

   Inherits: Message

   Text: String (Optional)

11.7.12.  Structure: RequestConfirmation

   Inherits: Message

   Text: String (Optional)

11.7.13.  Structure: ResponseConfirmation

   Inherits: Message

   Request: Enveloped (Optional)

   Accept: Boolean (Optional)

11.7.14.  Structure: RequestTask

   Inherits: Message

   [No fields]







Hallam-Baker              Expires 17 April 2025                [Page 88]

Internet-Draft            Mesh Schema Reference             October 2024


11.7.15.  Structure: MessageClaim

   Inherits: Message

   PublicationId: String (Optional)

   ServiceAuthenticate: String (Optional)

   DeviceAuthenticate: String (Optional)

   Expires: DateTime (Optional)

11.7.16.  Structure: ProcessResult

   Report result of message processing.

   Inherits: Message

   Success: Boolean (Optional)

   ErrorReport: String (Optional)  The error report code.

11.7.17.  Structure: ProcessResultNotSupported

   The message type is not supported.

   Inherits: ProcessResult

   [No fields]

11.7.18.  Structure: ProcessResultNotFound

   Inherits: ProcessResult

   [No fields]

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





Hallam-Baker              Expires 17 April 2025                [Page 89]

Internet-Draft            Mesh Schema Reference             October 2024


14.  Acknowledgements

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

15.  Normative References

   [draft-hallambaker-mesh-architecture]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
              Architecture Guide", Work in Progress, Internet-Draft,
              draft-hallambaker-mesh-architecture-22, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-architecture-22>.

   [draft-hallambaker-mesh-callsign]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: Mesh
              Callsign Service", Work in Progress, Internet-Draft,
              draft-hallambaker-mesh-callsign-03, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-callsign-03>.

   [draft-hallambaker-mesh-dare]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data
              At Rest Encryption (DARE)", Work in Progress, Internet-
              Draft, draft-hallambaker-mesh-dare-17, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-dare-17>.

   [draft-hallambaker-mesh-discovery]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: Mesh
              Discovery Service", Work in Progress, Internet-Draft,
              draft-hallambaker-mesh-discovery-01, 13 January 2021,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-discovery-01>.

   [draft-hallambaker-mesh-protocol]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol
              Reference", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-protocol-15, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-protocol-15>.

   [draft-hallambaker-mesh-security]
              Hallam-Baker, P., "Mathematical Mesh 3.0 Part IX Security
              Considerations", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-security-09, 20 April 2022,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-security-09>.



Hallam-Baker              Expires 17 April 2025                [Page 90]

Internet-Draft            Mesh Schema Reference             October 2024


   [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-18, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-udf-18>.

   [draft-hallambaker-threshold]
              Hallam-Baker, P., "Threshold Modes in Elliptic Curves",
              Work in Progress, Internet-Draft, draft-hallambaker-
              threshold-09, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              threshold-09>.

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

16.  Informative References

   [draft-hallambaker-mesh-developer]
              Hallam-Baker, P., "Mathematical Mesh: Reference
              Implementation", Work in Progress, Internet-Draft, draft-
              hallambaker-mesh-developer-11, 28 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-hallambaker-
              mesh-developer-11>.

   [draft-irtf-cfrg-frost]
              Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood,
              "Two-Round Threshold Schnorr Signatures with FROST", Work
              in Progress, Internet-Draft, draft-irtf-cfrg-frost-15, 18
              September 2023, <https://datatracker.ietf.org/doc/html/
              draft-irtf-cfrg-frost-15>.

   [draft-komlo-frost]
              Komlo, C. and I. Goldberg, "FROST: Flexible Round-
              Optimized Schnorr Threshold Signatures", Work in Progress,
              Internet-Draft, draft-komlo-frost-00, 7 August 2020,
              <https://datatracker.ietf.org/doc/html/draft-komlo-frost-
              00>.

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






Hallam-Baker              Expires 17 April 2025                [Page 91]

Internet-Draft            Mesh Schema Reference             October 2024


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

Author's Address

   Phillip Hallam-Baker
   ThresholdSecrets.com
   Email: phill@hallambaker.com









































Hallam-Baker              Expires 17 April 2025                [Page 92]