idnits 2.17.1 draft-hallambaker-mesh-schema-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document date (2 November 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBS' is mentioned on line 1704, but not defined == Missing Reference: 'UDF-Mesh' is mentioned on line 3383, but not defined -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 2 November 2020 5 Expires: 6 May 2021 7 Mathematical Mesh 3.0 Part IV: Schema Reference 8 draft-hallambaker-mesh-schema-06 10 Abstract 12 The Mathematical Mesh 'The Mesh' is an end-to-end secure 13 infrastructure that facilitates the exchange of configuration and 14 credential data between multiple user devices. The core protocols of 15 the Mesh are described with examples of common use cases and 16 reference data. 18 [Note to Readers] 20 Discussion of this draft takes place on the MATHMESH mailing list 21 (mathmesh@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 24 This document is also available online at 25 http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 6 May 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 60 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Related Specifications . . . . . . . . . . . . . . . . . 6 62 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 6 63 3. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.2.1. Activation . . . . . . . . . . . . . . . . . . . . . 11 67 3.3. Service . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.1. Access . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.2. Application . . . . . . . . . . . . . . . . . . . . . . . 16 71 4.2.1. Mesh Account . . . . . . . . . . . . . . . . . . . . 16 72 4.2.2. SSH . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 4.2.3. Mail . . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.3. Bookmark . . . . . . . . . . . . . . . . . . . . . . . . 17 75 4.4. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 4.5. Credential . . . . . . . . . . . . . . . . . . . . . . . 21 77 4.6. Device . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 4.7. Network . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 4.8. Publication . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.9. Task . . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 5. Spools . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 5.1. Outbound . . . . . . . . . . . . . . . . . . . . . . . . 23 83 5.2. Inbound . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 5.3. Local . . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 6. Cryptographic Operations . . . . . . . . . . . . . . . . . . 24 86 6.1. Key Derivation from Seed . . . . . . . . . . . . . . . . 24 87 6.2. Message Response Identifier . . . . . . . . . . . . . . . 24 88 6.3. Proof of Knowledge of PIN . . . . . . . . . . . . . . . . 25 89 6.4. EARL . . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 6.5. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 27 91 6.6. Service Cryptographic Operations . . . . . . . . . . . . 28 92 7. Mesh Assertions . . . . . . . . . . . . . . . . . . . . . . . 28 93 7.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 29 94 7.2. Mesh Profiles . . . . . . . . . . . . . . . . . . . . . . 30 95 7.3. Mesh Connections . . . . . . . . . . . . . . . . . . . . 30 96 8. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 31 97 8.1. Device Management . . . . . . . . . . . . . . . . . . . . 32 98 8.1.1. Master Profile . . . . . . . . . . . . . . . . . . . 32 99 8.1.2. Mesh Devices . . . . . . . . . . . . . . . . . . . . 34 100 8.2. Mesh Accounts . . . . . . . . . . . . . . . . . . . . . . 35 101 8.2.1. Creating a ProfileAccount . . . . . . . . . . . . . . 36 102 8.2.2. Connecting a Device to an Account . . . . . . . . . . 36 103 8.2.3. Binding and Account to a Service . . . . . . . . . . 37 104 8.3. Mesh Services . . . . . . . . . . . . . . . . . . . . . . 37 105 8.3.1. Creating a ProfileService . . . . . . . . . . . . . . 37 106 8.3.2. Creating a ProfileHost . . . . . . . . . . . . . . . 38 107 8.3.3. Creating a ConnectionHost . . . . . . . . . . . . . . 38 108 8.4. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 38 109 8.4.1. Traffic Analysis . . . . . . . . . . . . . . . . . . 39 110 9. Mesh Messages . . . . . . . . . . . . . . . . . . . . . . . . 40 111 9.1. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 112 9.2. Completion . . . . . . . . . . . . . . . . . . . . . . . 40 113 9.3. Connection . . . . . . . . . . . . . . . . . . . . . . . 41 114 9.4. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 48 115 9.5. Confirmation . . . . . . . . . . . . . . . . . . . . . . 51 116 10. Publications . . . . . . . . . . . . . . . . . . . . . . . . 52 117 10.1. Contact Exchange . . . . . . . . . . . . . . . . . . . . 52 118 10.2. Device Preconfiguration . . . . . . . . . . . . . . . . 52 119 11. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 120 11.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 54 121 11.1.1. Classes describing keys . . . . . . . . . . . . . . 54 122 11.1.2. Structure: KeyData . . . . . . . . . . . . . . . . . 54 123 11.1.3. Structure: CompositePrivate . . . . . . . . . . . . 55 124 11.2. Assertion classes . . . . . . . . . . . . . . . . . . . 55 125 11.2.1. Structure: Assertion . . . . . . . . . . . . . . . . 55 126 11.2.2. Structure: Condition . . . . . . . . . . . . . . . . 55 127 11.2.3. Base Classes . . . . . . . . . . . . . . . . . . . . 55 128 11.2.4. Structure: Connection . . . . . . . . . . . . . . . 56 129 11.2.5. Structure: Activation . . . . . . . . . . . . . . . 56 130 11.2.6. Structure: ActivationEntry . . . . . . . . . . . . . 56 131 11.2.7. Mesh Profile Classes . . . . . . . . . . . . . . . . 56 132 11.2.8. Structure: Profile . . . . . . . . . . . . . . . . . 56 133 11.2.9. Structure: ProfileDevice . . . . . . . . . . . . . . 56 134 11.2.10. Structure: ProfileAccount . . . . . . . . . . . . . 57 135 11.2.11. Structure: ProfileUser . . . . . . . . . . . . . . . 57 136 11.2.12. Structure: ProfileGroup . . . . . . . . . . . . . . 58 137 11.2.13. Structure: ProfileService . . . . . . . . . . . . . 58 138 11.2.14. Structure: ProfileHost . . . . . . . . . . . . . . . 58 139 11.2.15. Connection Assertions . . . . . . . . . . . . . . . 58 140 11.2.16. Structure: ConnectionDevice . . . . . . . . . . . . 58 141 11.2.17. Structure: ConnectionApplication . . . . . . . . . . 59 142 11.2.18. Structure: ConnectionGroup . . . . . . . . . . . . . 59 143 11.2.19. Structure: ConnectionService . . . . . . . . . . . . 59 144 11.2.20. Structure: ConnectionHost . . . . . . . . . . . . . 59 145 11.2.21. Activation Assertions . . . . . . . . . . . . . . . 59 146 11.2.22. Structure: ActivationDevice . . . . . . . . . . . . 59 147 11.2.23. Structure: ActivationAccount . . . . . . . . . . . . 60 148 11.2.24. Structure: ActivationApplication . . . . . . . . . . 60 149 11.3. Data Structures . . . . . . . . . . . . . . . . . . . . 60 150 11.3.1. Structure: Contact . . . . . . . . . . . . . . . . . 60 151 11.3.2. Structure: Anchor . . . . . . . . . . . . . . . . . 61 152 11.3.3. Structure: TaggedSource . . . . . . . . . . . . . . 61 153 11.3.4. Structure: ContactGroup . . . . . . . . . . . . . . 61 154 11.3.5. Structure: ContactPerson . . . . . . . . . . . . . . 61 155 11.3.6. Structure: ContactOrganization . . . . . . . . . . . 61 156 11.3.7. Structure: OrganizationName . . . . . . . . . . . . 62 157 11.3.8. Structure: PersonName . . . . . . . . . . . . . . . 62 158 11.3.9. Structure: NetworkAddress . . . . . . . . . . . . . 62 159 11.3.10. Structure: NetworkProtocol . . . . . . . . . . . . . 63 160 11.3.11. Structure: Role . . . . . . . . . . . . . . . . . . 63 161 11.3.12. Structure: Location . . . . . . . . . . . . . . . . 63 162 11.3.13. Structure: Bookmark . . . . . . . . . . . . . . . . 63 163 11.3.14. Structure: Reference . . . . . . . . . . . . . . . . 64 164 11.3.15. Structure: Task . . . . . . . . . . . . . . . . . . 64 165 11.4. Catalog Entries . . . . . . . . . . . . . . . . . . . . 64 166 11.4.1. Structure: CatalogedEntry . . . . . . . . . . . . . 64 167 11.4.2. Structure: CatalogedDevice . . . . . . . . . . . . . 65 168 11.4.3. Structure: CatalogedPublication . . . . . . . . . . 65 169 11.4.4. Structure: CatalogedCredential . . . . . . . . . . . 66 170 11.4.5. Structure: CatalogedNetwork . . . . . . . . . . . . 66 171 11.4.6. Structure: CatalogedContact . . . . . . . . . . . . 66 172 11.4.7. Structure: CatalogedAccess . . . . . . . . . . . . . 66 173 11.4.8. Structure: CryptographicCapability . . . . . . . . . 66 174 11.4.9. Structure: CapabilityDecrypt . . . . . . . . . . . . 67 175 11.4.10. Structure: CapabilityDecryptPartial . . . . . . . . 67 176 11.4.11. Structure: CapabilityDecryptServiced . . . . . . . . 67 177 11.4.12. Structure: CapabilitySign . . . . . . . . . . . . . 67 178 11.4.13. Structure: CapabilityKeyGenerate . . . . . . . . . . 68 179 11.4.14. Structure: CapabilityFairExchange . . . . . . . . . 68 180 11.4.15. Structure: CatalogedBookmark . . . . . . . . . . . . 68 181 11.4.16. Structure: CatalogedTask . . . . . . . . . . . . . . 68 182 11.4.17. Structure: CatalogedApplication . . . . . . . . . . 68 183 11.4.18. Structure: CatalogedMember . . . . . . . . . . . . . 69 184 11.4.19. Structure: CatalogedGroup . . . . . . . . . . . . . 69 185 11.4.20. Structure: CatalogedApplicationSSH . . . . . . . . . 69 186 11.4.21. Structure: CatalogedApplicationMail . . . . . . . . 69 187 11.4.22. Structure: CatalogedApplicationNetwork . . . . . . . 69 188 11.5. Publications . . . . . . . . . . . . . . . . . . . . . . 69 189 11.5.1. Structure: DevicePreconfiguration . . . . . . . . . 69 190 11.6. Messages . . . . . . . . . . . . . . . . . . . . . . . . 70 191 11.6.1. Structure: Message . . . . . . . . . . . . . . . . . 70 192 11.6.2. Structure: MessageError . . . . . . . . . . . . . . 70 193 11.6.3. Structure: MessageComplete . . . . . . . . . . . . . 70 194 11.6.4. Structure: MessagePinValidated . . . . . . . . . . . 70 195 11.6.5. Structure: MessagePin . . . . . . . . . . . . . . . 70 196 11.6.6. Structure: RequestConnection . . . . . . . . . . . . 71 197 11.6.7. Structure: AcknowledgeConnection . . . . . . . . . . 71 198 11.6.8. Structure: RespondConnection . . . . . . . . . . . . 71 199 11.6.9. Structure: MessageContact . . . . . . . . . . . . . 72 200 11.6.10. Structure: GroupInvitation . . . . . . . . . . . . . 72 201 11.6.11. Structure: RequestConfirmation . . . . . . . . . . . 72 202 11.6.12. Structure: ResponseConfirmation . . . . . . . . . . 72 203 11.6.13. Structure: RequestTask . . . . . . . . . . . . . . . 72 204 11.6.14. Structure: MessageClaim . . . . . . . . . . . . . . 72 205 11.6.15. Structure: ProcessResult . . . . . . . . . . . . . . 73 206 12. Security Considerations . . . . . . . . . . . . . . . . . . . 73 207 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 208 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 209 15. Appendix A: Example Container Organization (not normative) . 73 210 15.1. Device . . . . . . . . . . . . . . . . . . . . . . . . . 73 211 15.1.1. Creating a new Mesh . . . . . . . . . . . . . . . . 74 212 15.1.2. Adding an Account . . . . . . . . . . . . . . . . . 74 213 15.1.3. Adding a Device . . . . . . . . . . . . . . . . . . 74 214 15.2. Service . . . . . . . . . . . . . . . . . . . . . . . . 74 215 15.2.1. Creating a Service . . . . . . . . . . . . . . . . . 74 216 15.2.2. Adding an Account . . . . . . . . . . . . . . . . . 74 217 16. Appendix B: Collected Authentication and Encryption 218 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 74 219 16.1. Mesh Messaging . . . . . . . . . . . . . . . . . . . . . 75 220 17. Normative References . . . . . . . . . . . . . . . . . . . . 75 221 18. Informative References . . . . . . . . . . . . . . . . . . . 76 223 1. Introduction 225 This document describes the data structures of the Mathematical Mesh 226 with illustrative examples. For an overview of the Mesh objectives 227 and architecture, consult the accompanying _Architecture Guide_ 228 [draft-hallambaker-mesh-architecture]. For information on the 229 implementation of the Mesh Service protocol, consult the accompanying 230 _Protocol Reference_ [draft-hallambaker-mesh-protocol] 232 This document has two main sections. The first section presents 233 examples of the Mesh assertions, catalog entry and messages in use. 234 The second section contains the schema reference. All the material 235 in both sections is generated from the Mesh reference implementation 236 [draft-hallambaker-mesh-developer]. 238 Although some of the services described in this document could be 239 used to replace existing Internet protocols including FTP and SMTP, 240 the principal value of any communication protocol lies in the size of 241 the audience it allows them to communicate with. Thus, while the 242 Mesh Messaging service is designed to support efficient and reliable 243 transfer of messages ranging in size from a few bytes to multiple 244 terabytes, the near-term applications of these services will be to 245 applications that are not adequately supported by existing protocols 246 if at all. 248 2. Definitions 250 This section presents the related specifications and standard, the 251 terms that are used as terms of art within the documents and the 252 terms used as requirements language. 254 2.1. Requirements Language 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 2.2. Defined Terms 262 The terms of art used in this document are described in the _Mesh 263 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 265 2.3. Related Specifications 267 The architecture of the Mathematical Mesh is described in the _Mesh 268 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 269 documentation set and related specifications are described in this 270 document. 272 2.4. Implementation Status 274 The implementation status of the reference code base is described in 275 the companion document [draft-hallambaker-mesh-developer]. 277 3. Actors 279 The Mesh mediates interactions between three principal actors: 280 *Accounts*, *Devices*, and *Services*. 282 Currently two account types are specified, *user accounts* which 283 belong to an individual user and *group accounts* that are used to 284 share access to confidential information between a group of users. 285 It may prove useful to define new types of account over time or to 286 eliminate the distinction entirely. When active a Mesh account is 287 bound to a Mesh Service. The service to which an account is bound 288 MAY be changed over time but an account can only be bound to a single 289 service at a time. 291 A Mesh account is an abstract construct that (when active) is 292 instantiated across one or more physical machines called a device. 293 Each device that is connected to an account has a separate set of 294 cryptographic keys that are used to interact with other devices 295 connected to the account and MAY be provisioned with access to the 296 account private keys which MAY or MAY NOT be mediated by the current 297 Mesh Service. 299 A Mesh Service is an abstract construct that is provided by one or 300 more physical machines called Hosts. A Mesh Host is a device that is 301 attached to a service rather than an account. 303 3.1. Accounts 305 A Mesh Account is described by a Profile descended from Profile 306 Account and contains a set of Mesh stores. Currently two account 307 profiles are defined: 309 ProfileUser Describes a user account. 311 ProfileGroup Describes a group account used to share confidential 312 information between a group of users. 314 Both types of profile specify the following fields: 316 ProfileSignature The public signature key used to authenticate the 317 profile itself 319 AccountAddress The account name to which the account is currently 320 bound. (e.g. "alice@example.com", "@alice"). 322 ServiceUdf If the account is active, specifies the fingerprint of 323 the service profile to which the account is currently bound. 325 AdministratorSignature The public signature key used to verify 326 administrative actions on the account. In particular addition of 327 devices to a user account or members to a group account. 329 AccountEncryption The public encryption key for the account. All 330 messages sent to the account MUST be encrypted under this key. By 331 definition, all data encrypted under this account is encrypted 332 under this key. 334 User accounts specify two additional public keys, "AccountSignature" 335 and "AccountAuthentication" which allow signature and authentication 336 operations under the account context. 338 Every account contains a set of catalogs and spools that are managed 339 by the service as directed by the contents of the associated "Access" 340 catalog. 342 For example, the personal account profile Alice created is: 344 { 345 "ProfileUser":{ 346 "ProfileSignature":{ 347 "Udf":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 348 "PublicParameters":{ 349 "PublicKeyECDH":{ 350 "crv":"Ed448", 351 "Public":"LP6f4A0WTGxBGwVQxHEdm0nZEWk3_OlsDscWs9QjGMT82ka 352 7_TDJEqQ_pGto8260PD7AXEdsxUUA"}}}, 353 "AccountAddress":"alice@example.com", 354 "ServiceUdf":"MBSL-H45P-PM3W-NTYI-NMKG-L46T-5HWM", 355 "AccountEncryption":{ 356 "Udf":"MC2D-WX25-JK5S-6R7R-NPK5-XNQ7-O334", 357 "PublicParameters":{ 358 "PublicKeyECDH":{ 359 "crv":"X448", 360 "Public":"aBbYhik-VDUPmZ3Xh7N5Lppkn_f504MN6-YWmMnQAyiIJnK 361 aWvPTTA889IgD3dx3GfBHmLj1iXMA"}}}, 362 "AdministratorSignature":{ 363 "Udf":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 364 "PublicParameters":{ 365 "PublicKeyECDH":{ 366 "crv":"Ed448", 367 "Public":"LP6f4A0WTGxBGwVQxHEdm0nZEWk3_OlsDscWs9QjGMT82ka 368 7_TDJEqQ_pGto8260PD7AXEdsxUUA"}}}, 369 "AccountAuthentication":{ 370 "Udf":"MAGU-WLGH-QX7L-RQKS-KHP4-C5LR-5RG2", 371 "PublicParameters":{ 372 "PublicKeyECDH":{ 373 "crv":"X448", 374 "Public":"yoIi0dvQBNI4UtiUCA5LvYBirDHjlEQXHOgzV4ktsqQKPwh 375 -lN4cEjCIinyi8J5GU_R94CF5he0A"}}}, 376 "AccountSignature":{ 377 "Udf":"MBVN-UC2H-EKC2-GLZA-CLSC-6XQ2-QZIA", 378 "PublicParameters":{ 379 "PublicKeyECDH":{ 380 "crv":"Ed448", 381 "Public":"EvPYHGRCJsZ0kmbBMu_sxcGuUIOHFXc4iz0oCyY19fpYUG5 382 qJyn467Wq85zuVWviBl8zd3-9X_wA"}}}}} 384 3.2. Device 386 Every Mesh device has a set of private keys that are unique to that 387 device. These keys MAY be installed during manufacture, installed 388 from an external source after manufacture or generated on the device. 389 If the platform capabilities allow, device private keys SHOULD be 390 bound to the device so that they cannot be extracted or exported 391 without substantial effort. 393 The public keys corresponding to the device private keys are 394 specified in a ProfileDevice. This MUST contain at least the 395 following fields: 397 ProfileSignature The public signature key used to authenticate the 398 profile itself. 400 BaseEncryption Public encryption key used as a share contribution to 401 generation of device encryption keys to be used in the context of 402 an account and to decrypt data during the process of connecting to 403 an account. 405 BaseAuthentication Public authentication key used as a share 406 contribution to generation of device authentication keys to be 407 used in the context of an account and to authenticate the device 408 to a service during the process of connecting to an account. 410 BaseSignature Public signature key used as a share contribution to 411 generation of device authentication keys to be used in the context 412 of an account. 414 For example, the device profile corresponding to Alice's coffee pot 415 device is: 417 { 418 "ProfileDevice":{ 419 "ProfileSignature":{ 420 "Udf":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV", 421 "PublicParameters":{ 422 "PublicKeyECDH":{ 423 "crv":"Ed448", 424 "Public":"dyQgDeZX0Y7u5FElerLbzFhbGUTj3jrkO5biutnd9CuhtUP 425 npNM7UDTk5otmloreiJ9OBln70L0A"}}}, 426 "BaseEncryption":{ 427 "Udf":"MAFF-4P54-ORYF-SBAN-6XQ7-CO6S-OXWQ", 428 "PublicParameters":{ 429 "PublicKeyECDH":{ 430 "crv":"X448", 431 "Public":"7rEjlTclEPAoytZLGJbf5-eO8mBWLlNaevJ3YAt_aRhJAhe 432 -ROYL_ASfBuKEL9d0O8pCDlWzwA2A"}}}, 433 "BaseAuthentication":{ 434 "Udf":"MANB-DYXE-7CNC-W6LW-3R6I-BLAB-2TKC", 435 "PublicParameters":{ 436 "PublicKeyECDH":{ 437 "crv":"X448", 438 "Public":"BoY_wxLtxK1MsFOhOEs8LkY6HY6N6x46i0L_MJLMAMkqwsA 439 yiymRk6pV4vvtCc6DzBO8LF_MWYgA"}}}, 440 "BaseSignature":{ 441 "Udf":"MAW7-YIO3-5A7M-55YU-OZ7W-BJFT-QTHW", 442 "PublicParameters":{ 443 "PublicKeyECDH":{ 444 "crv":"Ed448", 445 "Public":"Psf8tojE6O4Q7JYBXe4r-bdLQdy4E8tzMTE3ADCs4OwXKyn 446 WrvlqO7cyGcX1Wn6bd2V5hLF48R8A"}}}}} 448 3.2.1. Activation 450 The device private keys are only used to perform cryptographic 451 operations during the process of connecting a device to an account. 452 During that connection process, a threshold key generation scheme is 453 used to generate a second set of device keys bound to the account by 454 combining the base key held by the device with a second device 455 private key provided by the administration device approving the 456 connection of the device to the account. The resulting key is 457 referred to as the device key. The process of combining the base 458 keys with the contributions to form the device keys is called 459 Activation. 461 The activation record for Alice's coffee pot device is: 463 { 464 "ActivationDevice":{ 465 "ActivationKey":"ZAAQ-GBHF-AKLZ-WMGO-NWLQ-CYAB-ZLLY-6MLD-6QYJ-6 466 MR3-A4OV-YHMH-JLL7-URSL", 467 "AccountUdf":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV"}} 469 The Mesh protocols are designed so that there is never a need to 470 export or escrow private keys of any type associated with a device, 471 neither the base key, nor the device key nor the contribution from 472 the administration device. 474 This approach to device configuration ensures that the keys that are 475 used by the device when operating within the context of the account 476 are entirely separate from those originally provided by the device 477 manufacturer or generated on the device, provided only that the key 478 contributions from the administration device are sufficiently random 479 and unguessable. 481 The public keys corresponding to the composite keys generated during 482 the connection process are described in a "ConnectionUser" assertion 483 signed by the administration key of the corresponding account. 485 The connection record for Alice's coffee pot device is: 487 { 488 "ConnectionDevice":{ 489 "DeviceSignature":{ 490 "Udf":"MBTO-NNFK-P6K2-4FW4-WTKW-OLGU-GAZS", 491 "PublicParameters":{ 492 "PublicKeyECDH":{ 493 "crv":"Ed448", 494 "Public":"NXxkDFuagDESh6-FD7LSkkOSVgIW-S4E3TDHR9c5qbW4AUV 495 kJMEh1nZlnVO2xwcGI8SNfov6RR8A"}}}, 496 "DeviceEncryption":{ 497 "Udf":"MAUU-Q2JT-BHOM-ZEPX-HOFG-XYU7-FGCJ", 498 "PublicParameters":{ 499 "PublicKeyECDH":{ 500 "crv":"X448", 501 "Public":"eSh00dco-Ee4X1sb96S9lkcdso7Qu8Uz6NnuDZSu7ww59JJ 502 xF7lEZtWkkELe10cGfpeQZ-qxdkYA"}}}, 503 "DeviceAuthentication":{ 504 "Udf":"MCAY-A6DR-FSY6-2T4K-UD2B-OJHA-MT3H", 505 "PublicParameters":{ 506 "PublicKeyECDH":{ 507 "crv":"X448", 508 "Public":"XyBegJt8kgVMzFTcQWyathYay6aT5C3ubb_ktZc0Gevcz4x 509 u0y9aJlEPNV-siXJxqwdr6bBgySIA"}}}}} 511 The "ConnectionUser" assertion MAY be used in the same fashion as an 512 X.509v3/PKIX certificate to mediate interactions between devices 513 connected to the same account without the need for interaction with 514 the Mesh service. Thus, a coffee pot device connected to the account 515 can receive and authenticate instructions issued by a voice 516 recognition device connected to that account. 518 While the "ConnectionUser" assertion MAY be used to mediate external 519 interactions, this approach is typically undesirable as it provides 520 the external parties with visibility to the internal configuration of 521 the account, in particular which connected devices are being used on 522 which occasions. Furthermore, the lack of the need to interact with 523 the service means that the service is necessarily unable to mediate 524 the exchange and enforce authorization policy on the interactions. 526 Device keys are intended to be used to secure communications between 527 devices connected to the same account. All communication between 528 Mesh accounts SHOULD be mediated by a Mesh service. This enables 529 abuse mitigation by applying access control to every outbound and 530 every inbound message. 532 Since Alice's coffee pot does not require the external communication 533 right, the activation record for the coffee pot does not provide 534 access to the account keys required to perform external 535 communications. Alice's watch device does require access to the 536 account keys so it can receive messages and task updates. But since 537 it is a device that Alice has to carry on her person to use, it is a 538 device that might easily be lost or stolen. Accordingly, the 539 activation record for Alice's watch provides access to the account 540 decryption and signature keys but in the form of threshold key shares 541 mediated by the Mesh service. Thus, Alice's watch can sign and read 542 message sent to the account but only under the control of the Mesh 543 service. 545 3.3. Service 547 Mesh services are described by a "ProfileService". This specifies 548 the encryption, and signature authentication keys used to interact 549 with the abstract service. 551 Since Mesh accounts and services are both abstract constructs, they 552 cannot interact directly. A device connected to an account can only 553 interact with a service by interacted with a device authorized to 554 provide services on behalf of one or more accounts connected to the 555 service. Such a device is called a Mesh Host. 557 Mesh hosts MAY be managed using the same ProfileDevice and device 558 connection mechanism provided for management of user devices or by 559 whatever other management protocols prove convenient. The only part 560 of the Service/Host interaction that is visible to devices connected 561 to a profile and to hosts connected to other services is the 562 ConnectionHost structure that describes the set of device keys to use 563 in interactions with that specific host. 565 4. Catalogs 567 Catalogs track sets of persistent objects associated with a Mesh 568 Service Account. The Mesh Service has no access to the entries in 569 any Mesh catalog except for the Device and Contacts catalog which are 570 used in device authentication and authorization of inbound messages. 572 Each Mesh Catalog managed by a Mesh Account has a name of the form: 574 "_" 576 Where "" is the IANA assigned service name. The assigned 577 service name for the Mathematical Mesh is mmm. Thus, all catalogs 578 specified by the Mesh schema have names prefixed with the sequence 579 "mmm_". 581 The following catalogs are currently specified within the 582 Mathematical Mesh. 584 Access: mmm_Access Describes access control policy for performing 585 operations on the account. The Access catalog is the only Mesh 586 catalog whose contents are readable by the Mesh Service under 587 normal circumstances. 589 Application: "mmm_Application" Describes configuration information 590 for applications including mail (SMTP, IMAP, OpenPGP, S/MIME, etc) 591 and SSH and for the MeshAccount application itself. 593 Bookmark: "mmm_Bookmark" Describes Web bookmarks and other citations 594 allowing them to be shared between devices connected to the 595 profile. 597 Contact: "mmm_Contact" Describes logical and physical contact 598 information for people and organizations. 600 Credential: "mmm_Credential" Describes credentials used to access 601 network resources. 603 Device: "mmm_Device" Describes the set of devices connected to the 604 account and the permissions assigned to them 606 Network: "mmm_Network" Describes network settings such as WiFi 607 access points, IPSEC and TLS VPN configurations, etc. 609 Member: mmm_Member Describes the set of members connected to a group 610 account. 612 Publication: mmm_Publication Describes data published under the 613 account context. The data MAY be stored in the publication 614 catalog itself or on a separate service (e.g. a Web server). 616 Task: "mmm_CatalogTask" Describes tasks assigned to the user 617 including calendar entries and to do lists. 619 The Access, Publication, Device and Member catalogs are involved in 620 Mesh Service Protocol interactions. These interactions are further 621 described in the Protocol Reference 622 [draft-hallambaker-mesh-protocol]. 624 In many cases, the Mesh Catalog offers capabilities that represent a 625 superset of the capabilities of an existing application. For 626 example, the task catalog supports the appointment tracking functions 627 of a traditional calendar application and the task tracking function 628 of the traditional 'to do list' application. Combining these 629 functions allows tasks to be triggered by other events other than the 630 passage of time such as completion of other tasks, geographical 631 presence, etc. 633 In such cases, the Mesh Catalog entries are designed to provide a 634 superset of the data representation capabilities of the legacy 635 formats and (where available) recent extensions. Where a catalog 636 entry is derived from input presented in a legacy format, the 637 original data representation MAY be attached verbatim to facilitate 638 interoperability. 640 4.1. Access 642 The access catalog "mmm_Access" contains a list of access control 643 entries granting a party authenticated using a particular 644 cryptographic credential a specific privilege such as: 646 * Accept Mesh Messages of particular types 648 * Perform an operation on a private key known to the service. 650 As with the publication catalog, the access catalog provides 651 information that is necessary for the Mesh Service to act on behalf 652 of the user. It is therefore necessary to grant a decryption 653 capability for this catalog during the process of binding the account 654 to a service. 656 4.2. Application 658 The application catalog "mmm"_"Application" contains 659 "CatalogEntryApplication" entries which describe the use of specific 660 applications under the Mesh Service Account. Multiple application 661 accounts for a single application MAY be connected to a single Mesh 662 Service Account. Each account being specified in a separate entry. 664 The "CatalogEntryApplication" entries only contain configuration 665 information for the application as it applies to the account as a 666 whole. If the application requires separate configuration for 667 individual devices, this is specified in separate activation records 668 specified in the corresponding "ConnectionDevice". 670 4.2.1. Mesh Account 672 Mesh Accounts are described by "CatalogEntryAccount" entries. The 673 corresponding activation records for the connected devices contain 674 the contributions used to derive the private keys for use of the 675 account. 677 The "CatalogEntryAccount" entry is described in the section 678 describing Mesh accounts above. 680 4.2.2. SSH 682 SSH configuration profiles are described by 683 "CatalogEntryApplicationSSH" entries. The corresponding activation 684 records for the connected devices contain the contributions used to 685 derive the private keys. 687 A user may have separate SSH configurations for separate purposes 688 within a single Mesh Account. This allows a system administrator 689 servicing multiple clients to maintain separate SSH profiles for each 690 of her customers allowing credentials to be easily (and verifiably) 691 revoked at contract termination. 693 The SSH profile contains the information that is stored in the 694 "known_hosts" and "authorized_keys" files of SSH clients and servers. 696 4.2.3. Mail 698 Mail configuration profiles are described by one or more 699 "CatalogEntryApplicationMail" entries, one for each email account 700 connected to the Mesh profile. The corresponding activation records 701 for the connected devices contain information used to provide the 702 device with the necessary decryption information. 704 Entries specify the email account address(es), the inbound and 705 outbound server configuration and the cryptographic keys to be used 706 for S/MIME and OpenPGP encryption. 708 4.3. Bookmark 710 The bookmark catalog "mmm_bookmark" contains "CatalogEntryBookmark" 711 entries which describe Web bookmarks and other citations allowing 712 them to be shared between devices connected to the profile. 714 The fields currently supported by the Bookmarks catalog are currently 715 limited to the fields required for tracking Web bookmarks. 716 Specification of additional fields to track full academic citations 717 is a work in progress. 719 { 720 "CatalogedBookmark":{ 721 "Uri":"http://www.site1.com", 722 "Title":"site1", 723 "Path":"Sites.1"}} 725 4.4. Contact 727 The contact catalog "mmm_contact" contains "CatalogEntryContact" 728 entries which describe 730 { 731 "CatalogedContact":{ 732 "Key":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 733 "Self":true, 734 "Contact":{ 735 "ContactPerson":{ 736 "Id":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 737 "Anchors":[{ 738 "Udf":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 739 "Validation":"Self"} 740 ], 741 "NetworkAddresses":[{ 742 "Address":"alice@example.com", 743 "EnvelopedProfileAccount":[{ 744 "EnvelopeID":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 745 "dig":"S512", 746 "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNQUlILVFG 747 Mk0tUFZEMy1OUUpPLUNXR1gtRzY3Uy1KWUVRIiwKICAiTWVzc2FnZVR5cGUiOiAiU 748 HJvZmlsZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCi 749 AgIkNyZWF0ZWQiOiAiMjAyMC0xMS0wMlQxNzoyNTo1MVoifQ"}, 750 "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0 751 dXJlIjogewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HN 752 jdTLUpZRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUH 753 VibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICA 754 gICAgIlB1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0Rz 755 Y1dzOVFqR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19f 756 SwKICAgICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgIC 757 AiU2VydmljZVVkZiI6ICJNQlNMLUg0NVAtUE0zVy1OVFlJLU5NS0ctTDQ2VC01SFd 758 NIiwKICAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQzJE 759 LVdYMjUtSks1Uy02UjdSLU5QSzUtWE5RNy1PMzM0IiwKICAgICAgIlB1YmxpY1Bhc 760 mFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgIC 761 AiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJhQmJZaGlrLVZEVVB 762 tWjNYaDdONUxwcGtuX2Y1MDRNTjYtWVdtTW5RQXlpSUpuS2FXdlBUCiAgVEE4ODlJ 763 Z0QzZHgzR2ZCSG1MajFpWE1BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0d 764 XJlIjogewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HNj 765 dTLUpZRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHV 766 ibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAg 767 ICAgIlB1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0RzY 768 1dzOVFqR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19fS 769 wKICAgICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUF 770 HVS1XTEdILVFYN0wtUlFLUy1LSFA0LUM1TFItNVJHMiIsCiAgICAgICJQdWJsaWNQ 771 YXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgI 772 CAgImNydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAieW9JaTBkdlFCTk 773 k0VXRpVUNBNUx2WUJpckRIamxFUVhIT2d6VjRrdHNxUUtQd2gtbE40YwogIEVqQ0l 774 pbnlpOEo1R1VfUjk0Q0Y1aGUwQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6 775 IHsKICAgICAgIlVkZiI6ICJNQlZOLVVDMkgtRUtDMi1HTFpBLUNMU0MtNlhRMi1RW 776 klBIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0 777 tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJ 778 QdWJsaWMiOiAiRXZQWUhHUkNKc1owa21iQk11X3N4Y0d1VUlPSEZYYzRpejBvQ3lZ 779 MTlmcFlVRzVxSnluNAogIDY3V3E4NXp1Vld2aUJsOHpkMy05WF93QSJ9fX19fQ", 780 { 781 "signatures":[{ 782 "alg":"S512", 783 "kid":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 784 "signature":"PuG3M10QcqNXxUtJzk83C2LkExhO1jYqfB 785 x_pcgl-_MH9lBPdT5JMiNSyVLsHRM9ZMUO-GVcDMiAITPUt5jG6t-GP3-6bdyEd6h 786 DKavFUJYr4tWjKvro-3Uh7KP5BvFCz1VNoccCaiNhsrCf6uie4wkA"} 787 ], 788 "PayloadDigest":"OmGeYT1GZa5-mNx5fYmK0Jk2AzqPxuEJ-d 789 RnTuoPLSgOSjHMzLnu8y1q6NTYxZomMK0ZfkuPtfD9Uyemy-npHQ"} 790 ], 791 "Protocols":[{ 792 "Protocol":"mmm"} 793 ]} 794 ], 795 "Sources":[{ 796 "Validation":"Self", 797 "EnvelopedSource":[{ 798 "dig":"S512", 799 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250 800 YWN0UGVyc29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogI 801 CJDcmVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NTFaIn0"}, 802 "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBb 803 ewogICAgICAgICJVZGYiOiAiTUFJSC1RRjJNLVBWRDMtTlFKTy1DV0dYLUc2N1MtS 804 llFUSIsCiAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3 805 JrQWRkcmVzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJhbGljZUBleGFtcGx 806 lLmNvbSIsCiAgICAgICAgIkVudmVsb3BlZFByb2ZpbGVBY2NvdW50IjogW3sKICAg 807 ICAgICAgICAgIkVudmVsb3BlSUQiOiAiTUFJSC1RRjJNLVBWRDMtTlFKTy1DV0dYL 808 Uc2N1MtSllFUSIsCiAgICAgICAgICAgICJkaWciOiAiUzUxMiIsCiAgICAgICAgIC 809 AgICJDb250ZW50TWV0YURhdGEiOiAiZXdvZ0lDSlZibWx4ZFdWSlJDSTZJQ0pOUVV 810 sSUxWRkdNazB0VUZaRU15MQogIE9VVXBQTFVOWFIxZ3RSelkzVXkxS1dVVlJJaXdL 811 SUNBaVRXVnpjMkZuWlZSNWNHVWlPaUFpVUhKdlptbHNaCiAgVlZ6WlhJaUxBb2dJQ 812 0pqZEhraU9pQWlZWEJ3YkdsallYUnBiMjR2YlcxdEwyOWlhbVZqZENJc0NpQWdJa0 813 4KICB5WldGMFpXUWlPaUFpTWpBeU1DMHhNUzB3TWxReE56b3lOVG8xTVZvaWZRIn0 814 sCiAgICAgICAgICAiZXdvZ0lDSlFjbTltYVd4bFZYTmxjaUk2SUhzS0lDQWdJQ0pR 815 Y205bWFXeAogIGxVMmxuYm1GMGRYSmxJam9nZXdvZ0lDQWdJQ0FpVldSbUlqb2dJa 816 zFCU1VndFVVWXlUUzFRVmtRekxVNVJTCiAgazh0UTFkSFdDMUhOamRUTFVwWlJWRW 817 lMQW9nSUNBZ0lDQWlVSFZpYkdsalVHRnlZVzFsZEdWeWN5STZJSHMKICBLSUNBZ0l 818 DQWdJQ0FpVUhWaWJHbGpTMlY1UlVORVNDSTZJSHNLSUNBZ0lDQWdJQ0FnSUNKamNu 819 WWlPaUFpUgogIFdRME5EZ2lMQW9nSUNBZ0lDQWdJQ0FnSWxCMVlteHBZeUk2SUNKT 820 VVEWm1ORUV3VjFSSGVFSkhkMVpSZUVoCiAgRlpHMHdibHBGVjJzelgwOXNjMFJ6WT 821 Fkek9WRnFSMDFVT0RKcllUZGZWRVJLQ2lBZ1JYRlJYM0JIZEc4NE0KICBqWXdVRVE 822 zUVZoRlpITjRWVlZCSW4xOWZTd0tJQ0FnSUNKQlkyTnZkVzUwUVdSa2NtVnpjeUk2 823 SUNKaGJHbAogIGpaVUJsZUdGdGNHeGxMbU52YlNJc0NpQWdJQ0FpVTJWeWRtbGpaV 824 lZrWmlJNklDSk5RbE5NTFVnME5WQXRVCiAgRTB6VnkxT1ZGbEpMVTVOUzBjdFREUT 825 JWQzAxU0ZkTklpd0tJQ0FnSUNKQlkyTnZkVzUwUlc1amNubHdkR2wKICB2YmlJNkl 826 Ic0tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlF6SkVMVmRZTWpVdFNrczFVeTAyVWpkU0xV 827 NVFTelV0VwogIEU1Uk55MVBNek0wSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21Gd 828 FpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBCiAgZ0lsQjFZbXhwWTB0bGVVVkRSRWdpT2 829 lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvZ0lsZzBORGdpTEFvZ0kKICBDQWdJQ0F 830 nSUNBZ0lsQjFZbXhwWXlJNklDSmhRbUpaYUdsckxWWkVWVkJ0V2pOWWFEZE9OVXh3 831 Y0d0dVgyWQogIDFNRFJOVGpZdFdWZHRUVzVSUVhscFNVcHVTMkZYZGxCVUNpQWdWR 832 UU0T0RsSlowUXpaSGd6UjJaQ1NHMU1hCiAgakZwV0UxQkluMTlmU3dLSUNBZ0lDSk 833 JaRzFwYm1semRISmhkRzl5VTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0EKICBnSUNBaVZ 834 XUm1Jam9nSWsxQlNVZ3RVVVl5VFMxUVZrUXpMVTVSU2s4dFExZEhXQzFITmpkVExV 835 cFpSVkVpTAogIEFvZ0lDQWdJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS 836 0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJWCiAgNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSU 837 NBZ0lDSmpjbllpT2lBaVJXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0kKICBsQjFZbXh 838 wWXlJNklDSk1VRFptTkVFd1YxUkhlRUpIZDFaUmVFaEZaRzB3YmxwRlYyc3pYMDlz 839 YzBSelkxZAogIHpPVkZxUjAxVU9ESnJZVGRmVkVSS0NpQWdSWEZSWDNCSGRHODRNa 840 ll3VUVRM1FWaEZaSE40VlZWQkluMTlmCiAgU3dLSUNBZ0lDSkJZMk52ZFc1MFFYVj 841 BhR1Z1ZEdsallYUnBiMjRpT2lCN0NpQWdJQ0FnSUNKVlpHWWlPaUEKICBpVFVGSFZ 842 TMVhURWRJTFZGWU4wd3RVbEZMVXkxTFNGQTBMVU0xVEZJdE5WSkhNaUlzQ2lBZ0lD 843 QWdJQ0pRZAogIFdKc2FXTlFZWEpoYldWMFpYSnpJam9nZXdvZ0lDQWdJQ0FnSUNKU 844 WRXSnNhV05MWlhsRlEwUklJam9nZXdvCiAgZ0lDQWdJQ0FnSUNBZ0ltTnlkaUk2SU 845 NKWU5EUTRJaXdLSUNBZ0lDQWdJQ0FnSUNKUWRXSnNhV01pT2lBaWUKICBXOUphVEJ 846 rZGxGQ1RrazBWWFJwVlVOQk5VeDJXVUpwY2tSSWFteEZVVmhJVDJkNlZqUnJkSE54 847 VVV0UWQyZwogIHRiRTQwWXdvZ0lFVnFRMGxwYm5scE9FbzFSMVZmVWprMFEwWTFhR 848 1V3UVNKOWZYMHNDaUFnSUNBaVFXTmpiCiAgM1Z1ZEZOcFoyNWhkSFZ5WlNJNklIc0 849 tJQ0FnSUNBZ0lsVmtaaUk2SUNKTlFsWk9MVlZETWtndFJVdERNaTEKICBIVEZwQkx 850 VTk1VME10TmxoUk1pMVJXa2xCSWl3S0lDQWdJQ0FnSWxCMVlteHBZMUJoY21GdFpY 851 Umxjbk1pTwogIGlCN0NpQWdJQ0FnSUNBZ0lsQjFZbXhwWTB0bGVVVkRSRWdpT2lCN 852 0NpQWdJQ0FnSUNBZ0lDQWlZM0oySWpvCiAgZ0lrVmtORFE0SWl3S0lDQWdJQ0FnSU 853 NBZ0lDSlFkV0pzYVdNaU9pQWlSWFpRV1VoSFVrTktjMW93YTIxaVEKICBrMTFYM04 854 0WTBkMVZVbFBTRVpZWXpScGVqQnZRM2xaTVRsbWNGbFZSelZ4U25sdU5Bb2dJRFkz 855 VjNFNE5YcAogIDFWbGQyYVVKc09IcGtNeTA1V0Y5M1FTSjlmWDE5ZlEiLAogICAgI 856 CAgICAgewogICAgICAgICAgICAic2lnbmF0dXJlcyI6IFt7CiAgICAgICAgICAgIC 857 AgICAiYWxnIjogIlM1MTIiLAogICAgICAgICAgICAgICAgImtpZCI6ICJNQUlILVF 858 GMk0tUFZEMy1OUUpPLUNXR1gtRzY3Uy1KWUVRIiwKICAgICAgICAgICAgICAgICJz 859 aWduYXR1cmUiOiAiUHVHM00xMFFjcU5YeFV0SnprODNDMkxrRXhoTzFqWXFmQnhfc 860 GNnbC1fTUg5bEJQZAogIFQ1Sk1pTlN5VkxzSFJNOVpNVU8tR1ZjRE1pQUlUUFV0NW 861 pHNnQtR1AzLTZiZHlFZDZoREthdkZVSllyNHRXCiAgakt2cm8tM1VoN0tQNUJ2RkN 862 6MVZOb2NjQ2FpTmhzckNmNnVpZTR3a0EifV0sCiAgICAgICAgICAgICJQYXlsb2Fk 863 RGlnZXN0IjogIk9tR2VZVDFHWmE1LW1OeDVmWW1LMEprMkF6cVB4dUVKLWRSblR1b 864 1BMU2dPUwogIGpITXpMbnU4eTFxNk5UWXhab21NSzBaZmt1UHRmRDlVeWVteS1ucE 865 hRIn1dLAogICAgICAgICJQcm90b2NvbHMiOiBbewogICAgICAgICAgICAiUHJvdG9 866 jb2wiOiAibW1tIn1dfV19fQ", 867 { 868 "signatures":[{ 869 "alg":"S512", 870 "kid":"MBVN-UC2H-EKC2-GLZA-CLSC-6XQ2-QZIA", 871 "signature":"ueOrjyE-0-zJ_DRQW-zJIH0ZLcxvsjhzKV 872 tNOnUYV116UBm740XP4gfHwkqR1WvL2Lpb25SWi66Aj7lTZtaSOFreEm9i0TgIBco 873 g4_O49DFf7s4HK6wo53KUe8J5pbjvYCnY8bsRWA6ZNAtTbyT_YDEA"} 874 ], 875 "PayloadDigest":"h4lFjVf0eiHdZT1eg0iBK8eXYAXvB1dLo7 876 7beFR8LbEuFULlYds0eGH85HWrcZXyIZtzAZtv866fIqRWI2ARqQ"} 877 ]} 878 ]}}}} 880 The fields of the contact catalog provide a superset of the 881 capabilities of vCard [RFC2426]. 883 The Contact catalog is typically used by the MeshService as a source 884 of authorization information to perform access control on inbound and 885 outbound message requests. For this reason, Mesh Service SHOULD be 886 granted read access to the contacts catalog by providing a decryption 887 entry for the service. 889 4.5. Credential 891 The credential catalog "mmm_credential" contains 892 "CatalogEntryCredential" entries which describe credentials used to 893 access network resources. 895 { 896 "CatalogedCredential":{ 897 "Service":"ftp.example.com", 898 "Username":"alice1", 899 "Password":"password"}} 901 Only username/password credentials are stored in the credential 902 catalog. If public key credentials are to be used, these SHOULD be 903 managed as an application profile allowing separate credentials to be 904 created for each device. 906 4.6. Device 908 The device catalog "mmm_Device" contains "CatalogEntryDevice" entries 909 which describe the devices connected to the account and the 910 permissions assigned to them. 912 Each device connected to a Mesh Account has an associated 913 CatalogEntryDevice entry that includes the activation and connection 914 records for the account. These records are described in further 915 detail in section REF _Ref54628559 \r \h 0. 917 4.7. Network 919 The network catalog contains "CatalogEntryNetwork" entries which 920 describe network settings, IPSEC and TLS VPN configurations, etc. 922 { 923 "CatalogedNetwork":{ 924 "Service":"myWiFi", 925 "Password":"securePassword"}} 927 4.8. Publication 929 The publication catalog "mmm_Publication" contains 930 "CatalogEntryPublication" entries which describe content published 931 through the account. 933 4.9. Task 935 The Task catalog "mmm_Task" contains "CatalogEntryTask" entries which 936 describe tasks assigned to the user including calendar entries and to 937 do lists. 939 The fields of the task catalog currently reflect those offered by the 940 iCalendar specification [RFC5545]. Specification of additional 941 fields to allow task triggering on geographic location and/or 942 completion of other tasks is a work in progress. 944 { 945 "CatalogedTask":{ 946 "Title":"SomeItem", 947 "Key":"NCYK-YRNO-OHE5-3KZQ-IPS5-T3W4-WFHB"}} 949 5. Spools 951 Spools are DARE Containers containing an append only list of messages 952 sent or received by an account. Three spools are currently defined: 954 Inbound Messages sent to the account. These are encrypted under the 955 account encryption keys of the sender and receiver that were 956 current at the time the message was sent. 958 Outbound Messages sent from the account. These are encrypted under 959 the account encryption keys of the sender and receiver that were 960 current at the time the message was sent. 962 Local Messages sent from the account for internal use. These are 963 encrypted under the encryption key of the intended recipient 964 alone. This is either the account administration encryption key 965 or a device encryption key. 967 Every Mesh Message has a unique message identifier. Messages created 968 at the beginning of a new messaging protocol interaction are assigned 969 a random message identifier. Responses to previous messages are 970 assigned message identifiers formed from the message identifier to 971 which they respond by means of a message digest function. 973 Every Mesh Message stored in a spool is encapsulated in an envelope 974 which bears a unique identifier that is formed by applying a message 975 digest function to the message identifier. Each stored message has 976 an associated state which is initially set to the state "Initial" and 977 MAY be subsequently altered by one or more "MessageComplete" messages 978 subsequently appended to the spool. The allowable message states 979 depending upon the spool in question. 981 5.1. Outbound 983 The outbound spool stores messages that are to be or have been sent 984 and "MessageComplete" messages reporting changes to the status of the 985 messages stored on the spool. 987 Messages posted to the outbound spool have the state Initial, Sent, 988 Received or Refused: 990 Initial The initial state of a message posted to the spool. 992 Sent The Mesh Service of the sender has delivered the message to the 993 Mesh Service of the recipient which accepted it. 995 Received The Mesh Service of the sender has delivered the message to 996 the Mesh Service of the recipient and the recipient has 997 acknowledged receipt. 999 Refused The Mesh Service of the sender has delivered the message to 1000 the Mesh Service of the recipient which refused to accept it. 1002 "MessageComplete" messages are only valid when posted to the spool by 1003 the service. 1005 5.2. Inbound 1007 The inbound spool stores messages that have been received by the Mesh 1008 service servicing the account and MessageComplete messages reporting 1009 changes to the status of the messages stored on the spool. 1011 Messages posted to the outbound spool have the state Initial, Read: 1013 Initial The initial state of a message posted to the spool. 1015 Read The message has been read. 1017 A message previously marked as read MAY be returned to the unread 1018 state by marking it as being in the Initial state. 1020 5.3. Local 1022 The local spool stores messages that are used for administrative 1023 functions. In normal circumstances, only administrator devices and 1024 the Mesh Service require access to the local spool. 1026 The local spool is used to store MessagePin messages used to notify 1027 administration devices that a PIN code has been registered for some 1028 purpose and RespondConnection messages used to inform a device of the 1029 result of a connection request. 1031 The local spool is used in a device connection operation to provide a 1032 device with the activation and connection records required to access 1033 the service as an authorized client. Servicing these requests 1034 requires that the service be able to access messages stored in the 1035 spool by envelope id. 1037 Messages posted to the outbound spool have the states Initial, 1038 Closed: 1040 Initial The initial state of a message posted to the spool. 1042 Closed The action associated with the message has been completed. 1044 6. Cryptographic Operations 1046 The Mesh makes use of various cryptographic operations including 1047 threshold operations. For convenience, these are gathered here and 1048 specified as functions that are referenced by other parts of the 1049 specification. 1051 6.1. Key Derivation from Seed 1053 Mesh Keys that derived from a seed value use the mechanism described 1054 in [draft-hallambaker-mesh-udf]. Use of the "keyname" parameter 1055 allows multiple keys for different uses to be derived from a single 1056 key. Thus escrow of a single seed value permits recovery of all the 1057 private keys associated with the profile. 1059 The keyname parameter is a string formed by concatenating identifiers 1060 specifying the key type, the actor that will use the key and the key 1061 operation: 1063 6.2. Message Response Identifier 1065 Every Mesh message has a unique "MessageId". When encapsulated in a 1066 DARE Envelope, the EnvelopeId field of the envelope header is the UDF 1067 Content Digest of the enclosed MessageId as a string: 1069 public static string GetEnvelopeId(string messageID) => 1070 UDF.ContentDigestOfUDF(messageID); 1072 When processing a Mesh message results in the creation of a response 1073 to the sender, the MessageId of the response is UDF Content Digest of 1074 the Binary Data Sequence of the original MessageId: 1076 static string MakeID(string udf, string content) { 1077 var (code, bds) = UDF.Parse(udf); 1078 return code switch 1079 { 1080 UdfTypeIdentifier.Digest_SHA_3_512 => 1081 UDF.ContentDigestOfDataString( 1082 bds, content, cryptoAlgorithmId: 1083 CryptoAlgorithmId.SHA_3_512), 1084 _ => UDF.ContentDigestOfDataString( 1085 bds, content, cryptoAlgorithmId: 1086 CryptoAlgorithmId.SHA_2_512), 1087 }; 1089 For example: 1091 [To be specified] 1093 6.3. Proof of Knowledge of PIN 1095 Mesh Message classes that are subclasses of "MessagePinValidated" MAY 1096 be authenticated by means of a PIN. Currently two such messages are 1097 defined: "MessageContact" used in contact exchange and 1098 "RequestConnection" message used in device connection. 1100 The PIN codes used to authenticate "MessagePinValidated" messages are 1101 UDF Authenticator strings. The type code of the identifier specifies 1102 the algorithm to be used to authenticate the PIN code and the Binary 1103 Data Sequence value specifies the key. 1105 The inputs to the PIN proof of knowledge functions are: 1107 PIN: string A UDF Authenticator. The type code of the identifier 1108 specifies the algorithm to be used to authenticate the PIN code 1109 and the Binary Data Sequence value specifies the key. 1111 Action: string A code determining the specific action that the PIN 1112 code MAY be used to authenticate. By convention this is the name 1113 of the Mesh message type used to perform the action. 1115 Account: string The account for which the PIN code is issued. 1117 ClientNonce: binary Nonce value generated by the client using the 1118 PIN code to authenticate its message. 1120 PayloadDigest: binary The PayloadDigest of a DARE Envelope that 1121 contains the message to be authenticated. Note that if the 1122 envelope is encrypted, this value is calculated over the 1123 ciphertext and does not provide proof of knowledge of the 1124 plaintext. 1126 The following values of Action are currently defined: 1128 +=====================+===================+===================+ 1129 | Code | Mesh Message | Purpose | 1130 +=====================+===================+===================+ 1131 | "MessageContact" | MessageContact | Contact exchange | 1132 +---------------------+-------------------+-------------------+ 1133 | "RequestConnection" | RequestConnection | Device connection | 1134 +---------------------+-------------------+-------------------+ 1136 Table 1 1138 These inputs are used to derive values as follows: 1140 alg = UdfAlg (PIN) 1141 pinData = UdfBDS (PIN) 1142 saltedPINData = MAC (Action, pinData) 1143 saltedPIN = UDFPresent (Authenticator_HMAC_SHA_2_512 + saltedPINData) 1144 PinId = UDFPresent (MAC (Account, saltedPINData)) 1145 witnessData = Account.ToUTF8() + ClientNonce + PayloadDigest 1146 witnessValue = MAC (witnessData , saltedPINData) 1148 Eg. 1150 [To be specified] 1152 Where "MAC(data, key)" is the message authentication code algorithm 1153 specified by the value of "alg". 1155 When an administrative device issues a PIN code, a Message PIN is 1156 appended to the local spool. This has the MessageId PinId and 1157 specifies the value "saltedPIN" in the field of that name. 1159 When PIN code authentication is used, a message of type 1160 MessagePinValidated specifies the values ClientNonce, PinWitness and 1161 PinId in the fields of those names. 1163 [To be specified] 1165 6.4. EARL 1167 The UDF Encrypted Authenticated Resource Locator mechanism is used to 1168 publish data and provide means of authentication and access through a 1169 static identifier such as a QR code. 1171 This mechanism is used to allow contact exchange by means of a QR 1172 code printed on a business card and to connect a device to an account 1173 using a static identifier printed on the device in the form of a QR 1174 code. 1176 In both cases, the information is passed using the EARL format 1177 described in [draft-hallambaker-mesh-udf]. 1179 6.5. Key Agreement 1181 All Mesh Protocol requests except for the HelloRequest and every 1182 response MUST be authenticated under the device key of the host or 1183 device making the request. 1185 Initial authentication is achieved by performing a Key agreement 1186 under the "DeviceAuthentication" key of each of the hosts and 1187 combining the result with nonce values provided by the requestor and 1188 respondent using a KDF function as follows: 1190 Two bindings are currently planned. 1192 DARE Envelope over HTTPS The request or response is encapsulated in 1193 a DARE Envelope that is exchanged by means of a HTTP POST method 1194 over a TLS transport. The shared secret is used as the key on 1195 Message Authentication Code that authenticates the request 1196 payload. 1198 UDP Transport Presents the same information as for the DARE Envelope 1199 over HTTPS case but in a compact encoding using the shared secret 1200 and an authenticated encryption scheme to pass the required 1201 information. 1203 Once authentication has been performed, the same pair of devices MAY 1204 re-authenticate using the previously agreed key. To facilitate 1205 stateless implementation, a host specifies an opaque identifier to be 1206 used to identify the shared secret on subsequent uses which MAY be 1207 used to recover the shared secret from the opaque identifier. 1209 [To be specified] 1211 6.6. Service Cryptographic Operations 1213 A Mesh Service acts as the counterparty for threshold operations 1214 allowing mitigation of the risk of compromise of an individual device 1215 connected to a user account or an insider threat from an individual 1216 member of a group account. 1218 When acting in this role, the Mesh service controls the use of the 1219 cryptographic function but does not have the ability to perform the 1220 action either by itself or by collaborating with other services to 1221 which the account has been bound in the past. 1223 Note that this approach limits rather than eliminates trust in the 1224 service. As with services presenting themselves as 'zero trust', a 1225 Mesh service becomes a trusted service after a sufficient number of 1226 breaches in other parts of the system have occurred. And the user 1227 trusts the service to provide availability of the service. 1229 Three service cryptographic operations are currently specified: 1231 Threshold Key Share A private key share _s_, held by the service is 1232 split into key shares _x_, _y_ such that _a_ = _x_ + _y_. One key 1233 share is encrypted under a decryption key held by the service. 1234 The other is encrypted under a public key specified by the party 1235 making the request. 1237 Threshold Key Agreement A private key share s, held by the service 1238 is used to calculate the value (_sl_+ _c_)._P_ where _l_, _c_ are 1239 integers specified by the requestor and _P_ is a point on the 1240 curve. 1242 Threshold Signature A private key share s, held by the service is 1243 used to calculate a contribution to a threshold signature scheme. 1245 The implementation of the cryptographic operations described above is 1246 described in [draft-hallambaker-threshold] and 1247 [draft-hallambaker-threshold-sigs]. 1249 7. Mesh Assertions 1251 Mesh Assertions are signed DARE Envelopes that contain one of more 1252 claims. Mesh Assertions provide the basis for trust in the 1253 Mathematical Mesh. 1255 Mesh Assertions are divided into two classes. Mesh Profiles are 1256 self-signed assertions. Assertions that are not self-signed are 1257 called declarations. The only type of declaration currently defined 1258 is a Connection Declaration describing the connection of a device to 1259 an account. 1261 (Artwork only available as svg: No external link available, see 1262 draft-hallambaker-mesh-schema-06.html for artwork.) 1264 Figure 1 1266 7.1. Encoding 1268 The payload of a Mesh Assertion is a JSON encoded object that is a 1269 subclass of the Assertion class which defines the following fields: 1271 Identifier An identifier for the assertion. 1273 Updated The date and time at which the assertion was issued or last 1274 updated 1276 NotaryToken An assertion may optionally contain one or more notary 1277 tokens issued by a Mesh Notary service. These establish a proof 1278 that the assertion was signed after the date the notary token was 1279 created. 1281 Conditions A list of conditions that MAY be used to verify the 1282 status of the assertion if the relying party requires. 1284 The implementation of the NotaryToken and Conditions mechanisms is to 1285 be specified in [draft-hallambaker-mesh-notary] at a future date. 1287 Note that the implementation of Conditions differs significantly from 1288 that of SAML. Relying parties are required to process condition 1289 clauses in a SAML assertion to determine validity. Mesh Relying 1290 parties MAY verify the conditions clauses or rely on the 1291 trustworthiness of the provider. 1293 The reason for weakening the processing of conditions clauses in the 1294 Mesh is that it is only ever possible to validate a conditions clause 1295 of any type relative to a ground truth. In SAML applications, the 1296 relying party almost invariably has access to an independent source 1297 of ground truth. A Mesh device connected to a Mesh Service does not. 1298 Thus the types of verification that can be achieved in practice are 1299 limited to verifying the consistency of current and previous 1300 statements from the Mesh Service. 1302 7.2. Mesh Profiles 1304 Mesh Profiles perform a similar role to X.509v3 certificates but with 1305 important differences: 1307 * Profiles describe credentials, they do not make identity 1308 statements 1310 * Profiles do not expire, there is therefore no need to support 1311 renewal processing. 1313 * Profiles may be modified over time, the current and past status of 1314 a profile being recorded in an append only log. 1316 Profiles provide the axioms of trust for the Mesh PKI. Unlike in the 1317 PKIX model in which all trust flows from axioms of trust held by a 1318 small number of Certificate Authorities, every part in the Mesh 1319 contributes their own axiom of trust. 1321 It should be noted however that the role of Certificate Authorities 1322 is redefined rather than eliminated. Rather than making assertions 1323 whose subject is represented by identities which are inherently 1324 mutable and subjective, Certificate Authorities can now make 1325 assertions about immutable cryptographic keys. 1327 Every Profile MUST contain a "SignatureKey" field and MUST be signed 1328 by the key specified in that field. 1330 A Profile is valid if and only if: 1332 * There is a "SignatureKey" field. 1334 * The profile is signed under the key specified in the 1335 "SignatureKey" field. 1337 A profile has the status "current" if and only if: 1339 * The Profile is valid 1341 * Every Conditions clause in the profile is understood by the 1342 relying party and evaluates to "true". 1344 7.3. Mesh Connections 1346 A Mesh connection is an assertion describing the connection of a 1347 device or a member to an account. 1349 Mesh connections provide similar functionality to 'end-entity' 1350 certificates in PKIX but with the important proviso that they are 1351 only used to provide trust between a device connected to an account 1352 and the service to which that account is bound and between the 1353 devices connected to an account. 1355 A connection is valid with respect to an account with profile _P_ if 1356 and only if: 1358 * The profile _P_ is valid 1360 * The "AuthorityUdf" field of the connection is consistent with the 1361 UDF of _P_ 1363 * The profile is signed under the key specified in the 1364 "AdministrationKey" field of _P_. 1366 * Any conditions specified in the profile are met 1368 A connection has the status current with respect to an account with 1369 profile if and only if: 1371 * The connection is valid with respect to the account with profile 1372 _P_. 1374 * The profile "P" is current. 1376 A device is authenticated with respect to an account with profile P 1377 if and only if: 1379 * The connection is valid with respect to the account with profile 1380 _P_. 1382 * The device has presented an appropriate proof of knowledge of the 1383 "DeviceAuthentication" key specified in the connection. 1385 8. Architecture 1387 $$$$$$$$$$$ This has plenty or areas that need to be upgraded to the 1388 single master/account approach. 1390 The Mesh architecture has four principal components: 1392 Mesh Device Management Binds a collection of devices that the owner 1393 of the Mesh uses together to function as a single personal Mesh. 1395 Mesh Account Contains all the information (contacts, calendar 1396 entries, inbound and outbound messages, etc.) related to a 1397 particular persona used by the owner. 1399 Mesh Service Provides a service identifier (e.g. 1400 "alice@example.com") through which devices and other Mesh users 1401 may interact with a Mesh Account. 1403 Mesh Messaging Allows short messages (less than 32KB) to be 1404 exchanged between Mesh devices connected to an account and between 1405 Mesh Accounts. 1407 Device management and Accounts components are defined by a data 1408 schema alone. The Service and Messaging components are defined by a 1409 data schema and a service protocol. 1411 The separation of accounts and services as separate components is a 1412 key distinction between the Mesh and earlier Internet applications. 1413 A Mesh account belongs to the owner of the Mesh and not the Mesh 1414 Service Provider which the user may change at any time of their 1415 choosing. 1417 A Mesh Account May be active or inactive. By definition, an active 1418 Mesh account is serviced by exactly one Mesh Service, an inactive 1419 Mesh account is not serviced by a Mesh Service. A Mesh Service 1420 Provider MAY offer a backup service for accounts hosted by other 1421 providers. In this case the backup provider is connected to the 1422 account as a Mesh device, thus allowing the backup provider to 1423 maintain a copy of the stores contained in the account and 1424 facilitating a rapid transfer of responsibility for servicing the 1425 account should that be desired. The use of backup providers is 1426 described further in [draft-hallambaker-mesh-discovery]. 1428 8.1. Device Management 1430 Device Management provides the foundation for all Mesh functions 1431 allowing a collection of devices belonging to a user to function as a 1432 single personal Mesh. 1434 The device management layer of a personal Mesh consists of exactly 1435 one Master Profile and a catalog containing the entries describing 1436 the connected devices. 1438 8.1.1. Master Profile 1440 A Mesh master profile provides the axiom of trust for a mesh user. 1441 It contains a Master Signature Key and one or more Administration 1442 Signature Keys. The unique identifier of the master profile is the 1443 UDF of the Master Signature Key. 1445 A Master Profile MUST specify an "EscrowEncryption" key. This key 1446 MAY be used to escrow private keys used for encryption of stored 1447 data. They SHOULD NOT be used to escrow authentication keys and MUST 1448 NOT be used to escrow signature keys. 1450 A user should not need to replace their account profile unless they 1451 intend to establish a separate identity. To minimize the risk of 1452 disclosure, the Profile Signature Key is only ever used to sign 1453 updates to the account profile itself. This allows the user to 1454 secure their Profile Signature Key by either keeping it on hardware 1455 token or device dedicated to that purpose or by using the escrow 1456 mechanism and paper recovery keys as described in this document. 1458 8.1.1.1. Creating a ProfileMaster 1460 Creating a "ProfileMaster" comprises the steps of: 1462 0. Creating a Master Signature key. 1464 1. Creating an Online Signing Key 1466 2. Signing the "ProfileMaster" using the Master Signature Key 1468 3. Persisting the "ProfileMaster" on the administration device to 1469 the "CatalogHost". 1471 4. (Optional) Connecting at least one Administration Device and 1472 granting it the "ActivationAdministration" activation. 1474 8.1.1.2. Updating a ProfileMaster 1476 Updating a "ProfileMaster" comprises the steps of: 1478 0. Making the necessary changes. 1480 1. Signing the ProfileMaster using the Master Signature Key 1482 2. Persisting the ProfileMaster on the administration device to the 1483 CatalogHost. 1485 8.1.1.3. The Device Catalog 1487 Each personal Mesh has a Device Catalog "CatalogDevice" associated 1488 with it. The Device Catalog is used to manage the connection of 1489 devices to the Personal Mesh and has a "CatalogEntryDevice" for each 1490 device currently connected to the catalog. 1492 Each Administration Device MUST have access to an up to date copy of 1493 the Device Catalog in order to manage the devices connected to the 1494 Mesh. The Mesh Service protocol MAY be used to synchronize the 1495 Device Catalog between administration devices in the case that there 1496 is more than one administration device. 1498 The "CatalogEntryDevice" contains fields for the device profile, 1499 device private and device connection. 1501 8.1.2. Mesh Devices 1503 The principle of radical distrust requires us to consider the 1504 possibility that a device might be compromised during manufacture. 1505 Once consequence of this possibility is that when an administration 1506 device connects a new device to a user's personal Mesh, we cannot put 1507 our full trust in either the device being connected or the 1508 administration device connecting it. 1510 This concern is resolved by (at minimum) combining keying material 1511 generated from both sources to create the keys to be used in the 1512 context of the user's personal Mesh with the process being fully 1513 verified by both parties. 1515 Additional keying material sources could be added if protection 1516 against the possibility of compromise at both devices was required 1517 but this is not supported by the current specifications. 1519 A device profile provides the axiom of trust and the key 1520 contributions of the device. When bound to an account, the base keys 1521 specified in the Device Profile are combined with the key data 1522 provided in the Activation device to construct the keys the device 1523 will use in the context of the account. 1525 (Artwork only available as svg: No external link available, see 1526 draft-hallambaker-mesh-schema-06.html for artwork.) 1528 Figure 2 1530 Unless exceptional circumstances require, a device should not require 1531 more than one Device profile even if the device supports use by 1532 multiple users under different accounts. But a device MAY have 1533 multiple profiles if this approach is more convenient for 1534 implementation. 1536 The derivation of the Connection encryption and signature keys from 1537 the Profile and Private contributions in this example is shown in 1538 [draft-hallambaker-mesh-cryptography]. 1540 8.1.2.1. Creating a ProfileDevice 1542 Creating a "ProfileDevice" comprises the steps of: 1544 0. Creating the necessary key 1546 1. Signing the "ProfileDevice" using the Master Signature Key 1548 2. Once created, a "ProfileDevice" is never changed. In the 1549 unlikely event that any modification is required, a completely 1550 new "ProfileDevice" MUST be created. 1552 8.1.2.2. Connection to a Personal Mesh 1554 Devices are only connected to a personal Mesh by administration 1555 device. This comprises the steps of: 1557 0. Generating the PrivateDevice keys. 1559 1. Creating the ConnectionDevice data from the public components of 1560 the ProfileDevice and PrivateDevice keys and signing it using the 1561 administration key. 1563 2. Creating the Activations for the device and signing them using 1564 the administration key. 1566 3. Creating the "CatalogEntryDevice" for the device and adding it to 1567 the "CatalogDevice" of the Personal Mesh. 1569 4. If the Personal Mesh has accounts that are connected to a Mesh 1570 Service, synchronizing the "CatalogEntryDevice" to those 1571 services. 1573 8.2. Mesh Accounts 1575 Mesh Accounts contains all the stateful information (contacts, 1576 calendar entries, inbound and outbound messages, etc.) related to a 1577 particular persona used by the owner. 1579 A Mesh Profile MAY be connected to multiple accounts at the same time 1580 allowing the user to maintain separate personas for separate 1581 purposes. 1583 Unlike traditional Internet application accounts, Mesh accounts are 1584 created by and belong to the user, not the Mesh Service provider. A 1585 user MAY change their Mesh Service provider at any time and 1586 disconnect the profile from all Mesh Services (e.g. to archive the 1587 account). 1589 Alice's personal account is connected to two Mesh services: 1591 The account profile specifies the online and offline signature keys 1592 used to maintain the profile and the encryption key to be used by the 1593 account. 1595 Each device connected to the account requires an activation record. 1596 This specifies the key contribtions added to the manufacturer device 1597 profile keys: 1599 The resulting key set is specified in the device connection: 1601 All the above plus the ProfileDevice are combined to form the 1602 CatalogedDevice entry: 1604 8.2.1. Creating a ProfileAccount 1606 Creating a "ProfileAccount" comprises the steps of: 1608 0. [TBS] 1610 1. . 1612 2. Signing the ProfileMaster using the Master Signature Key 1614 8.2.2. Connecting a Device to an Account 1616 Adding a device to an account comprises the steps of: 1618 0. Creating a PrivateAccount instance for the device. 1620 1. Creating a ConnectionAccountDevice for the device using the 1621 public keys from the PrivateAccount instance and the 1622 ProfileDevice. 1624 2. Creating an ActivationAccount for the device containing the 1625 PrivateAccount and ConnectionAccountDevice instances. 1627 3. Adding the ActivationAccount to the "CatalogEntryDevice" of the 1628 device. 1630 4. If the Personal Mesh has accounts that are connected to a Mesh 1631 Service, synchronizing the "CatalogEntryDevice" to those 1632 services. 1634 8.2.3. Binding and Account to a Service 1636 Binding a "ProfileAccount" to a Mesh Service the steps of: 1638 0. [TBS] 1640 1. . 1642 2. Signing the ProfileMaster using the Master Signature Key 1644 8.3. Mesh Services 1646 A service profile provides the axiom of trust and cryptographic keys 1647 for a Mesh Service. A Mesh Service Host SHOULD return a copy of its 1648 ProfileHost and the parent ProfileService in response to a Hello 1649 transaction request. 1651 (Artwork only available as svg: No external link available, see 1652 draft-hallambaker-mesh-schema-06.html for artwork.) 1654 Figure 3 1656 The credentials provided by the ProfileService and ProfileHost are 1657 distinct from those provided by the WebPKI that typically services 1658 TLS requests. WebPKI credentials provide service introduction and 1659 authentication while a Mesh ProfileHost only provides authentication. 1661 Unless exceptional circumstances require, a service should not need 1662 to revise its Service Profile unless it is intended to change its 1663 identity. Service Profiles MAY be countersigned by Trusted Third 1664 Parties to establish accountability. 1666 The service profile 1668 The host also has a profile 1670 And there should be a connection of the host to the service but this 1671 isn't implemented yet: 1673 8.3.1. Creating a ProfileService 1675 [TBS] 1677 Creating a "ProfileService" comprises the steps of: 1679 0. [TBS] 1681 1. . 1683 2. [TBS] 1685 4. Signing the ProfileMaster using the Master Signature Key 1687 8.3.2. Creating a ProfileHost 1689 Creating a "ProfileHost" comprises the steps of: 1691 0. [TBS] 1693 1. . 1695 2. [TBS] 1697 4. Signing the "ConnectionHost" using the Master Signature Key of 1698 the "ProfileService". 1700 8.3.3. Creating a ConnectionHost 1702 Creating a "ConnectionHost" comprises the steps of: 1704 0. [TBS] 1706 1. . 1708 2. Signing the "ConnectionHost" using the Master Signature Key of 1709 the "ProfileService". 1711 8.4. Mesh Messaging 1713 Mesh Messaging is an end-to-end secure messaging system used to 1714 exchange short (32KB) messages between Mesh devices and services. In 1715 cases where exchange of longer messages is required, Mesh Messaging 1716 MAY be used to provide a control plane to advise the intended message 1717 recipient(s) of the type of data being offered and the means of 1718 retrieval (e.g an EARL). 1720 A four-corner messaging model is enforced. Mesh Services only accept 1721 outbound messages from devices connected to accounts that it 1722 services. Inbound messages are only accepted from other Mesh 1723 Services. This model enables access control at both the outbound and 1724 inbound services 1726 (Artwork only available as svg: No external link available, see 1727 draft-hallambaker-mesh-schema-06.html for artwork.) 1728 Figure 4 1730 The outbound Mesh Service checks to see that the request to send a 1731 message does not violate its acceptable use policy. Accounts that 1732 make a large number of message requests that result in complaints 1733 SHOULD be subject to consequences ranging from restriction of the 1734 number and type of messages sent to suspending or terminating 1735 messaging privileges. Services that fail to implement appropriate 1736 controls are likely to be subject to sanctions from either their 1737 users or from other services. 1739 (Artwork only available as svg: No external link available, see 1740 draft-hallambaker-mesh-schema-06.html for artwork.) 1742 Figure 5 1744 The inbound Mesh Service also checks to see that messages received 1745 are consistent with the service Acceptable Use Policy and the user's 1746 personal access control settings. 1748 Mesh Services that fail to police abuse by their account holders 1749 SHOULD be subject to consequences in the same fashion as account 1750 holders. 1752 (Artwork only available as svg: No external link available, see 1753 draft-hallambaker-mesh-schema-06.html for artwork.) 1755 Figure 6 1757 8.4.1. Traffic Analysis 1759 The Mesh Messaging protocol as currently specified provides only 1760 limited protection against traffic analysis attacks. The use of TLS 1761 to encrypt communication between Mesh Services limits the 1762 effectiveness of na?ve traffic analysis mechanisms but does not 1763 prevent timing attacks unless dummy traffic is introduced to 1764 obfuscate traffic flows. 1766 The limitation of the message size is in part intended to facilitate 1767 use of mechanisms capable of providing high levels of traffic 1768 analysis such as mixmaster and onion routing but the current Mesh 1769 Service Protocol does not provide support for such approaches and 1770 there are no immediate plans to do so. 1772 9. Mesh Messages 1774 All communications between Mesh accounts takes the form of a Mesh 1775 Message carried in a Dare Envelope. Mesh Messages are stored in two 1776 spools associated with the account, the "SpoolOutbound" and the 1777 "SpoolInbound" containing the messages sent and received 1778 respectively. 1780 This document only describes the representation of the messages 1781 within the message spool. The Mesh Service protocol by which the 1782 messages are exchanged between devices and services and between 1783 services is described in [draft-hallambaker-mesh-protocol]. 1785 9.1. PIN 1787 One-time use 'PIN' codes are used to provide a means of out of band 1788 authentication in many Mesh Message applications. In particular the 1789 device connection and contact exchange message flows. 1791 For example, when Alice reads the connection request from the device 1792 in the architecture examples, a completion message is added to 1793 Alice's inbound spool so that the device is not activated a second 1794 time by mistake: 1796 { 1797 "MessagePin":{ 1798 "MessageId":"ADWE-3XBF-GGLA-AMCX-XVDM-KMXB-BQRN", 1799 "Account":"alice@example.com", 1800 "Expires":"2020-11-03T17:25:57Z", 1801 "Automatic":true, 1802 "SaltedPin":"ADPA-GPKO-V6TG-BPWJ-42YS-V5K7-NCZD", 1803 "Action":"Device"}} 1805 The details of the presentation and verification of the PIN code are 1806 further described in the section below. 1808 9.2. Completion 1810 Completion messages are dummy messages that are added to a Mesh Spool 1811 to change the status of messages previously posted. Any message that 1812 is in the inbound spool and has not been erased or redacted MAY be 1813 marked as "read", "unread" or "deleted". Any message in the outbound 1814 spool MAY be marked as "sent", "received" or "deleted". 1816 Services MAY erase or redact messages in accordance with local site 1817 policy. Since messages are not removed from the spool on being 1818 marked deleted, they may be undeleted by marking them as read or 1819 unread. Marking a message deleted MAY make it more likely that the 1820 Service will purge the message however. 1822 Having processed a message, a completion message is added to the 1823 spool so that other devices can see that it has been read. 1825 For example, when Alice's administration device uses the PIN 1826 registered above to authenticate a device connection request, a 1827 completion message is added to Alice's inbound spool so that the PIN 1828 cannot be reused to authenticate a second device: 1830 Missing example 25 1832 9.3. Connection 1834 Connection requests are sent by a device requesting connection to a 1835 Mesh Service Account. 1837 The "MessageConnectionRequest" is originally sent by the device 1838 requesting connection to the Mesh Service associated with the 1839 account. 1841 If the connection request is accepted by the Mesh Service, it creates 1842 a "MessageConnectionResponse" containing the ServerNonce and Witness 1843 values used in the authentication of the response together with a 1844 verbatim copy of the original request. The 1845 "MessageConnectionResponse" is then returned to the device that made 1846 the original request and placed on the SpoolInbound of the account to 1847 which the request was directed. 1849 Further details of this mechanism are described in 1850 [draft-hallambaker-mesh-protocol]. 1852 Alice connects a watch to her account. Since the watch has a camera 1853 (to allow for video calls) she can use the dynamic QR code connection 1854 mechanism. 1856 The watch reads the QR code generated on Alice's watch. This 1857 contains the device connection URI. 1859 QR = {Connect.ConnectQRURI} 1860 The URI tells the device the Mesh account to connect to and the PIN 1861 Code to be used to authenticate the request. The device requesting 1862 the connection adds its Profile device to create a RequestConnection 1863 message that will be presented to the service as a Connect 1864 transaction request. 1866 { 1867 "RequestConnection":{ 1868 "MessageId":"NB2K-E33D-IXPK-LR7X-DL5R-7GJW-FLEP", 1869 "AuthenticatedData":[{ 1870 "EnvelopeID":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH", 1871 "dig":"S512", 1872 "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNREpELTdFSkItTEJN 1873 Wi1NQU81LUNHSUUtRERFQi1MUVZIIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZmlsZ 1874 URldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAiQ3 1875 JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI1OjU3WiJ9"}, 1876 "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cmUi 1877 OiB7CiAgICAgICJVZGYiOiAiTURKRC03RUpCLUxCTVotTUFPNS1DR0lFLURERUItT 1878 FFWSCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW 1879 NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA 1880 iUHVibGljIjogImlZajZfbEU2enUta2xxZ0doMGtnMlZBT2o1cENYcEtWMDk0OFJT 1881 ZWJqUkpfdmphS0dKRXoKICBDQll0ZkZzb2tMUUg5aUduWnRfTEd3d0EifX19LAogI 1882 CAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1DUFgtWkhQNC01Nl 1883 NPLVpMT0ktN1FITS1IMkE0LUdYUE0iLAogICAgICAiUHVibGljUGFyYW1ldGVycyI 1884 6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAi 1885 WDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInBnei1ZS3hjdzFrUHJJRzd4ejNlb 1886 0tZZGlsQzZUa3NUTE0tcjhINUNuNFdUY3gtbGtDZUgKICBONmtzcTVPelc1N3laX1 1887 9LZkZlelBhNEEifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgICA 1888 gIlVkZiI6ICJNQ1RVLUVCR1QtQjVDRS1EUlpBLUhOSFEtQ05UVS1ITVBFIiwKICAg 1889 ICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiO 1890 iB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6IC 1891 JaY05LdGhmdUk4QTNibUt1c284dWJzSDkwcG1VUXdBV1FNTGpwcFh1dHh0anVsR2l 1892 pYjZkCiAgU0p3R18tYmh6ZlBUQ0RpY05oSFVXa2NBIn19fSwKICAgICJCYXNlU2ln 1893 bmF0dXJlIjogewogICAgICAiVWRmIjogIk1DNzYtR1VGNy1MRUhYLTNWR0ctS1ZHU 1894 C03TjJLLUNFUVUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC 1895 AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA 1896 gICAgICAgIlB1YmxpYyI6ICJqZG1ibnZKNkM5ajhzbF9pRUlmcDkxMlItQ3lKX1E1 1897 MXdsc1d4X1ZxYWIwd0cwc0JNd21mCiAgbkx2ZFMydWFTTVpBN1RuYTNvWUItdENBI 1898 n19fX19", 1899 { 1900 "signatures":[{ 1901 "alg":"S512", 1902 "kid":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH", 1903 "signature":"ZXggJgXzooa2Ui5zxNXrY6UCNXFFUBgGgpPl5Qe_OC 1904 1o_oJKHJkwEIDBEj45OHQZPGhn1TEl5UwAJxemsop7Rnr5U3DdNc2ERYL4hYHGVVx 1905 5W2PzeQk4U1mviwYdfqp_5V80vRL4RcZiTozviK6sWwwA"} 1906 ], 1907 "PayloadDigest":"JRadknNMvezXjCMPoluxtnw8sUX4QXZ1oSG6HANsJn 1909 IAZwXEzvTjbZwrngywjG82UJ8p6DXBMfcYTR0AhJIBBg"} 1910 ], 1911 "ClientNonce":"-suxzsj-OEQhgNZeuQFfiQ", 1912 "PinId":"ADWE-3XBF-GGLA-AMCX-XVDM-KMXB-BQRN", 1913 "PinWitness":"cRP1Zv5O5NH-GRJi1qv0rZNPJEsix0RyXMxgPLz5XzXsMQOzd 1914 OOgSVDeFrZWoyY2DitMfZdjIharXUL_cWovJA", 1915 "AccountAddress":"alice@example.com"}} 1917 The service generates an AcknowledgeConnection message which is 1918 returned to the device requesting the connection (via the Connect 1919 transaction response) and adds it to the inbound spool of the account 1920 for Alice's approval (or not). 1922 { 1923 "AcknowledgeConnection":{ 1924 "MessageId":"T365-C62P-LUPX-76V5-CUND-IB5M-OE7P", 1925 "EnvelopedRequestConnection":[{ 1926 "EnvelopeID":"MCPK-XGW3-624O-UVCF-G33S-I6VX-U2P7", 1927 "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJOQjJLLUUzM0QtSVhQ 1928 Sy1MUjdYLURMNVItN0dKVy1GTEVQIiwKICAiTWVzc2FnZVR5cGUiOiAiUmVxdWVzd 1929 ENvbm5lY3Rpb24iLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCi 1930 AgIkNyZWF0ZWQiOiAiMjAyMC0xMS0wMlQxNzoyNTo1N1oifQ"}, 1931 "ewogICJSZXF1ZXN0Q29ubmVjdGlvbiI6IHsKICAgICJNZXNzYWdlSWQiOiAi 1932 TkIySy1FMzNELUlYUEstTFI3WC1ETDVSLTdHSlctRkxFUCIsCiAgICAiQXV0aGVud 1933 GljYXRlZERhdGEiOiBbewogICAgICAgICJFbnZlbG9wZUlEIjogIk1ESkQtN0VKQi 1934 1MQk1aLU1BTzUtQ0dJRS1EREVCLUxRVkgiLAogICAgICAgICJkaWciOiAiUzUxMiI 1935 sCiAgICAgICAgIkNvbnRlbnRNZXRhRGF0YSI6ICJld29nSUNKVmJtbHhkV1ZKUkNJ 1936 NklDSk5SRXBFTFRkRlNrSXRURUpOV2kxCiAgTlFVODFMVU5IU1VVdFJFUkZRaTFNV 1937 VZaSUlpd0tJQ0FpVFdWemMyRm5aVlI1Y0dVaU9pQWlVSEp2Wm1sc1oKICBVUmxkbW 1938 xqWlNJc0NpQWdJbU4wZVNJNklDSmhjSEJzYVdOaGRHbHZiaTl0YlcwdmIySnFaV04 1939 wSWl3S0lDQQogIGlRM0psWVhSbFpDSTZJQ0l5TURJd0xURXhMVEF5VkRFM09qSTFP 1940 alUzV2lKOSJ9LAogICAgICAiZXdvZ0lDSlFjbTltYVd4bFJHVjJhV05sSWpvZ2V3b 1941 2dJQ0FnSWxCeWIyWgogIHBiR1ZUYVdkdVlYUjFjbVVpT2lCN0NpQWdJQ0FnSUNKVl 1942 pHWWlPaUFpVFVSS1JDMDNSVXBDTFV4Q1RWb3RUCiAgVUZQTlMxRFIwbEZMVVJFUlV 1943 JdFRGRldTQ0lzQ2lBZ0lDQWdJQ0pRZFdKc2FXTlFZWEpoYldWMFpYSnpJam8KICBn 1944 ZXdvZ0lDQWdJQ0FnSUNKUWRXSnNhV05MWlhsRlEwUklJam9nZXdvZ0lDQWdJQ0FnS 1945 UNBZ0ltTnlkaUk2SQogIENKRlpEUTBPQ0lzQ2lBZ0lDQWdJQ0FnSUNBaVVIVmliR2 1946 xqSWpvZ0ltbFphalpmYkVVMmVuVXRhMnh4WjBkCiAgb01HdG5NbFpCVDJvMWNFTll 1947 jRXRXTURrME9GSlRaV0pxVWtwZmRtcGhTMGRLUlhvS0lDQkRRbGwwWmtaemIKICAy 1948 dE1VVWc1YVVkdVduUmZURWQzZDBFaWZYMTlMQW9nSUNBZ0lrSmhjMlZGYm1OeWVYQ 1949 jBhVzl1SWpvZ2V3bwogIGdJQ0FnSUNBaVZXUm1Jam9nSWsxRFVGZ3RXa2hRTkMwMU 1950 5sTlBMVnBNVDBrdE4xRklUUzFJTWtFMExVZFlVCiAgRTBpTEFvZ0lDQWdJQ0FpVUh 1951 WaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS0lDQWdJQ0FnSUNBaVVIVmliR2wKICBq 1952 UzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjbllpT2lBaVdEUTBPQ0lzQ 1953 2lBZ0lDQWdJQ0FnSQogIENBaVVIVmliR2xqSWpvZ0luQm5laTFaUzNoamR6RnJVSE 1954 pKUnpkNGVqTmxiMHRaWkdsc1F6WlVhM05VVEUwCiAgdGNqaElOVU51TkZkVVkzZ3R 1955 iR3REWlVnS0lDQk9ObXR6Y1RWUGVsYzFOM2xhWDE5TFprWmxlbEJoTkVFaWYKICBY 1956 MTlMQW9nSUNBZ0lrSmhjMlZCZFhSb1pXNTBhV05oZEdsdmJpSTZJSHNLSUNBZ0lDQ 1957 WdJbFZrWmlJNklDSgogIE5RMVJWTFVWQ1IxUXRRalZEUlMxRVVscEJMVWhPU0ZFdF 1958 EwNVVWUzFJVFZCRklpd0tJQ0FnSUNBZ0lsQjFZCiAgbXhwWTFCaGNtRnRaWFJsY25 1959 NaU9pQjdDaUFnSUNBZ0lDQWdJbEIxWW14cFkwdGxlVVZEUkVnaU9pQjdDaUEKICBn 1960 SUNBZ0lDQWdJQ0FpWTNKMklqb2dJbGcwTkRnaUxBb2dJQ0FnSUNBZ0lDQWdJbEIxW 1961 W14cFl5STZJQ0phWQogIDA1TGRHaG1kVWs0UVROaWJVdDFjMjg0ZFdKelNEa3djRz 1962 FWVVhkQlYxRk5UR3B3Y0ZoMWRIaDBhblZzUjJsCiAgcFlqWmtDaUFnVTBwM1IxOHR 1963 ZbWg2WmxCVVEwUnBZMDVvU0ZWWGEyTkJJbjE5ZlN3S0lDQWdJQ0pDWVhObFUKICAy 1964 bG5ibUYwZFhKbElqb2dld29nSUNBZ0lDQWlWV1JtSWpvZ0lrMUROell0UjFWR055M 1965 U1SVWhZTFROV1IwYwogIHRTMVpIVUMwM1RqSkxMVU5GVVZVaUxBb2dJQ0FnSUNBaV 1966 VIVmliR2xqVUdGeVlXMWxkR1Z5Y3lJNklIc0tJCiAgQ0FnSUNBZ0lDQWlVSFZpYkd 1967 salMyVjVSVU5FU0NJNklIc0tJQ0FnSUNBZ0lDQWdJQ0pqY25ZaU9pQWlSV1EKICAw 1968 TkRnaUxBb2dJQ0FnSUNBZ0lDQWdJbEIxWW14cFl5STZJQ0pxWkcxaWJuWktOa001Y 1969 WpoemJGOXBSVWxtYwogIERreE1sSXRRM2xLWDFFMU1YZHNjMWQ0WDFaeFlXSXdkMG 1970 N3YzBKTmQyMW1DaUFnYmt4MlpGTXlkV0ZUVFZwCiAgQk4xUnVZVE52V1VJdGRFTkJ 1971 JbjE5ZlgxOSIsCiAgICAgIHsKICAgICAgICAic2lnbmF0dXJlcyI6IFt7CiAgICAg 1972 ICAgICAgICJhbGciOiAiUzUxMiIsCiAgICAgICAgICAgICJraWQiOiAiTURKRC03R 1973 UpCLUxCTVotTUFPNS1DR0lFLURERUItTFFWSCIsCiAgICAgICAgICAgICJzaWduYX 1974 R1cmUiOiAiWlhnZ0pnWHpvb2EyVWk1enhOWHJZNlVDTlhGRlVCZ0dncFBsNVFlX09 1975 DMW9fb0pLSAogIEprd0VJREJFajQ1T0hRWlBHaG4xVEVsNVV3QUp4ZW1zb3A3Um5y 1976 NVUzRGROYzJFUllMNGhZSEdWVng1VzJQCiAgemVRazRVMW12aXdZZGZxcF81Vjgwd 1977 lJMNFJjWmlUb3p2aUs2c1d3d0EifV0sCiAgICAgICAgIlBheWxvYWREaWdlc3QiOi 1978 AiSlJhZGtuTk12ZXpYakNNUG9sdXh0bnc4c1VYNFFYWjFvU0c2SEFOc0puSUFaCiA 1979 gd1hFenZUamJad3JuZ3l3akc4MlVKOHA2RFhCTWZjWVRSMEFoSklCQmcifV0sCiAg 1980 ICAiQ2xpZW50Tm9uY2UiOiAiLXN1eHpzai1PRVFoZ05aZXVRRmZpUSIsCiAgICAiU 1981 GluSWQiOiAiQURXRS0zWEJGLUdHTEEtQU1DWC1YVkRNLUtNWEItQlFSTiIsCiAgIC 1982 AiUGluV2l0bmVzcyI6ICJjUlAxWnY1TzVOSC1HUkppMXF2MHJaTlBKRXNpeDBSeVh 1983 NeGdQTHo1WHpYc01RT3oKICBkT09nU1ZEZUZyWldveVkyRGl0TWZaZGpJaGFyWFVM 1984 X2NXb3ZKQSIsCiAgICAiQWNjb3VudEFkZHJlc3MiOiAiYWxpY2VAZXhhbXBsZS5jb 1985 20ifX0" 1986 ], 1987 "ServerNonce":"1yJIRnfjOC0JFCCQZAFznw", 1988 "Witness":"T365-C62P-LUPX-76V5-CUND-IB5M-OE7P"}} 1990 Alice's administration device synchronizes to the service and 1991 receives the connection request acknowledgement from the service. 1992 Since the request is authenticated by a PIN code that has been marked 1993 for automatic execution, the service can generate the assertions the 1994 device to participate in the account and appends the corresponding 1995 RespondConnection message to the local delivery spool. 1997 { 1998 "RespondConnection":{ 1999 "MessageId":"MAE6-HCD5-CTU3-T4LW-HW7N-C3SQ-F2OI", 2000 "Result":"Accept", 2001 "CatalogedDevice":{ 2002 "Udf":"MCCR-2BLZ-ME27-SWM4-I73R-A7IA-MTYN", 2003 "DeviceUdf":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH", 2004 "EnvelopedProfileUser":[{ 2005 "EnvelopeID":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 2006 "dig":"S512", 2007 "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNQUlILVFGMk0tUF 2008 ZEMy1OUUpPLUNXR1gtRzY3Uy1KWUVRIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml 2009 sZVVzZXIiLAogICJjdHkiOiAiYXBwbGljYXRpb24vbW1tL29iamVjdCIsCiAgIkNy 2010 ZWF0ZWQiOiAiMjAyMC0xMS0wMlQxNzoyNTo1MVoifQ"}, 2011 "ewogICJQcm9maWxlVXNlciI6IHsKICAgICJQcm9maWxlU2lnbmF0dXJlIj 2012 ogewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HNjdTLUp 2013 ZRVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGlj 2014 S2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgI 2015 lB1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0RzY1dzOV 2016 FqR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19fSwKICA 2017 gICJBY2NvdW50QWRkcmVzcyI6ICJhbGljZUBleGFtcGxlLmNvbSIsCiAgICAiU2Vy 2018 dmljZVVkZiI6ICJNQlNMLUg0NVAtUE0zVy1OVFlJLU5NS0ctTDQ2VC01SFdNIiwKI 2019 CAgICJBY2NvdW50RW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQzJELVdYMj 2020 UtSks1Uy02UjdSLU5QSzUtWE5RNy1PMzM0IiwKICAgICAgIlB1YmxpY1BhcmFtZXR 2021 lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2 2022 IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJhQmJZaGlrLVZEVVBtWjNYa 2023 DdONUxwcGtuX2Y1MDRNTjYtWVdtTW5RQXlpSUpuS2FXdlBUCiAgVEE4ODlJZ0QzZH 2024 gzR2ZCSG1MajFpWE1BIn19fSwKICAgICJBZG1pbmlzdHJhdG9yU2lnbmF0dXJlIjo 2025 gewogICAgICAiVWRmIjogIk1BSUgtUUYyTS1QVkQzLU5RSk8tQ1dHWC1HNjdTLUpZ 2026 RVEiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgICAiUHVibGljS 2027 2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICAgICAgICAgIl 2028 B1YmxpYyI6ICJMUDZmNEEwV1RHeEJHd1ZReEhFZG0wblpFV2szX09sc0RzY1dzOVF 2029 qR01UODJrYTdfVERKCiAgRXFRX3BHdG84MjYwUEQ3QVhFZHN4VVVBIn19fSwKICAg 2030 ICJBY2NvdW50QXV0aGVudGljYXRpb24iOiB7CiAgICAgICJVZGYiOiAiTUFHVS1XT 2031 EdILVFYN0wtUlFLUy1LSFA0LUM1TFItNVJHMiIsCiAgICAgICJQdWJsaWNQYXJhbW 2032 V0ZXJzIjogewogICAgICAgICJQdWJsaWNLZXlFQ0RIIjogewogICAgICAgICAgImN 2033 ydiI6ICJYNDQ4IiwKICAgICAgICAgICJQdWJsaWMiOiAieW9JaTBkdlFCTkk0VXRp 2034 VUNBNUx2WUJpckRIamxFUVhIT2d6VjRrdHNxUUtQd2gtbE40YwogIEVqQ0lpbnlpO 2035 Eo1R1VfUjk0Q0Y1aGUwQSJ9fX0sCiAgICAiQWNjb3VudFNpZ25hdHVyZSI6IHsKIC 2036 AgICAgIlVkZiI6ICJNQlZOLVVDMkgtRUtDMi1HTFpBLUNMU0MtNlhRMi1RWklBIiw 2037 KICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVD 2038 REgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICAgICJQdWJsa 2039 WMiOiAiRXZQWUhHUkNKc1owa21iQk11X3N4Y0d1VUlPSEZYYzRpejBvQ3lZMTlmcF 2040 lVRzVxSnluNAogIDY3V3E4NXp1Vld2aUJsOHpkMy05WF93QSJ9fX19fQ", 2041 { 2042 "signatures":[{ 2043 "alg":"S512", 2044 "kid":"MAIH-QF2M-PVD3-NQJO-CWGX-G67S-JYEQ", 2045 "signature":"PuG3M10QcqNXxUtJzk83C2LkExhO1jYqfBx_pcgl 2046 -_MH9lBPdT5JMiNSyVLsHRM9ZMUO-GVcDMiAITPUt5jG6t-GP3-6bdyEd6hDKavFU 2047 JYr4tWjKvro-3Uh7KP5BvFCz1VNoccCaiNhsrCf6uie4wkA"} 2048 ], 2049 "PayloadDigest":"OmGeYT1GZa5-mNx5fYmK0Jk2AzqPxuEJ-dRnTuoP 2050 LSgOSjHMzLnu8y1q6NTYxZomMK0ZfkuPtfD9Uyemy-npHQ"} 2051 ], 2052 "EnvelopedProfileDevice":[{ 2053 "EnvelopeID":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH", 2054 "dig":"S512", 2055 "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNREpELTdFSkItTE 2056 JNWi1NQU81LUNHSUUtRERFQi1MUVZIIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZml 2057 sZURldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAi 2058 Q3JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI1OjU3WiJ9"}, 2059 "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cm 2060 UiOiB7CiAgICAgICJVZGYiOiAiTURKRC03RUpCLUxCTVotTUFPNS1DR0lFLURERUI 2061 tTFFWSCIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJs 2062 aWNLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgI 2063 CAiUHVibGljIjogImlZajZfbEU2enUta2xxZ0doMGtnMlZBT2o1cENYcEtWMDk0OF 2064 JTZWJqUkpfdmphS0dKRXoKICBDQll0ZkZzb2tMUUg5aUduWnRfTEd3d0EifX19LAo 2065 gICAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1DUFgtWkhQNC01 2066 NlNPLVpMT0ktN1FITS1IMkE0LUdYUE0iLAogICAgICAiUHVibGljUGFyYW1ldGVyc 2067 yI6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOi 2068 AiWDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogInBnei1ZS3hjdzFrUHJJRzd4ejN 2069 lb0tZZGlsQzZUa3NUTE0tcjhINUNuNFdUY3gtbGtDZUgKICBONmtzcTVPelc1N3la 2070 X19LZkZlelBhNEEifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgI 2071 CAgIlVkZiI6ICJNQ1RVLUVCR1QtQjVDRS1EUlpBLUhOSFEtQ05UVS1ITVBFIiwKIC 2072 AgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREg 2073 iOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6 2074 ICJaY05LdGhmdUk4QTNibUt1c284dWJzSDkwcG1VUXdBV1FNTGpwcFh1dHh0anVsR 2075 2lpYjZkCiAgU0p3R18tYmh6ZlBUQ0RpY05oSFVXa2NBIn19fSwKICAgICJCYXNlU2 2076 lnbmF0dXJlIjogewogICAgICAiVWRmIjogIk1DNzYtR1VGNy1MRUhYLTNWR0ctS1Z 2077 HUC03TjJLLUNFUVUiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAg 2078 ICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogI 2079 CAgICAgICAgIlB1YmxpYyI6ICJqZG1ibnZKNkM5ajhzbF9pRUlmcDkxMlItQ3lKX1 2080 E1MXdsc1d4X1ZxYWIwd0cwc0JNd21mCiAgbkx2ZFMydWFTTVpBN1RuYTNvWUItdEN 2081 BIn19fX19", 2082 { 2083 "signatures":[{ 2084 "alg":"S512", 2085 "kid":"MDJD-7EJB-LBMZ-MAO5-CGIE-DDEB-LQVH", 2086 "signature":"ZXggJgXzooa2Ui5zxNXrY6UCNXFFUBgGgpPl5Qe_ 2087 OC1o_oJKHJkwEIDBEj45OHQZPGhn1TEl5UwAJxemsop7Rnr5U3DdNc2ERYL4hYHGV 2088 Vx5W2PzeQk4U1mviwYdfqp_5V80vRL4RcZiTozviK6sWwwA"} 2089 ], 2090 "PayloadDigest":"JRadknNMvezXjCMPoluxtnw8sUX4QXZ1oSG6HANs 2091 JnIAZwXEzvTjbZwrngywjG82UJ8p6DXBMfcYTR0AhJIBBg"} 2092 ], 2093 "EnvelopedConnectionUser":[{ 2094 "dig":"S512", 2095 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW 2096 9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ 2097 DcmVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NThaIn0"}, 2098 "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkRldmljZVNpZ25hdH 2099 VyZSI6IHsKICAgICAgIlVkZiI6ICJNQlFFLU1CTzUtVlNBRy02UVVXLUdBSlUtNEV 2100 HTi1FN1ZYIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1 2101 YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgI 2102 CAgICJQdWJsaWMiOiAieWVVaUgyZ3EydTc4YUQzbER4WXRQUmhZQTM1ZW5vTjBIME 2103 81Z3FLMlhySVhSVzdOVGsxUAogIFpZbFp0a3h4WjZFUlQxcEpQVXdKVlFzQSJ9fX0 2104 sCiAgICAiRGV2aWNlRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQ080LTRN 2105 NDUtT1dPRS1VVVBNLVdJUEstQVNCRS00SjJOIiwKICAgICAgIlB1YmxpY1BhcmFtZ 2106 XRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3 2107 J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICJCVzBBWGZpWE1iVnZrUlp 2108 uTnp5anJucTdSU2FiVjJBSnBsQzJTSzBPUnB6UEpxbmhaeEVxCiAgVHRFZjJ0TzVJ 2109 TlRwcUJPd21MU0ZvLS1BIn19fSwKICAgICJEZXZpY2VBdXRoZW50aWNhdGlvbiI6I 2110 HsKICAgICAgIlVkZiI6ICJNQjZKLTRWWFYtRFhRUS1HVVFWLVkzSlQtWVRUQS1KRU 2111 41IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0t 2112 leUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1 2113 YmxpYyI6ICJhYjVUSGQybmVFOHFjM0hEeW5YRzZMWThiVmp3Z0dpYnUwRGhOS0I5M 2114 XhQOWF4bFpybHA4CiAgYUw2WHA3TVJ3QU9TQU02TjJZY1dKdXFBIn19fX19", 2115 { 2116 "signatures":[{ 2117 "alg":"S512", 2118 "kid":"MBXO-5JKI-OWJH-UH5T-C4SU-YKEE-D3FP", 2119 "signature":"kLHglBYqL6rZPz6Fo7Jz2-pGZMlt6DG1zQVWu-nJ 2120 F0eEmkb2QnGc5GEhiwfiVIBw171_sunZBvqAzQh_hdwrHebrP8Q46kp8emfCksm9b 2121 -BrsjG3YsjuBg7_N98uJOyWoIdQ6j0upKZX6XV2re7JpzwA"} 2122 ], 2123 "PayloadDigest":"5gZs1tch-I8eCUcLBhNLGwv_YFl11hKt-I6rstjF 2124 Xe90lfi4z2KsLmKKcAGY7KpTejpYmGXUVHC1H7ns4YGDkw"} 2125 ], 2126 "EnvelopedActivationDevice":[{ 2127 "enc":"A256CBC", 2128 "dig":"S512", 2129 "kid":"EBQO-I6OP-D6SH-Q2MD-QBBQ-PUKG-BBCE", 2130 "Salt":"Vc0qvABdCE6vS8G3orAiNA", 2131 "recipients":[{ 2132 "kid":"MCPX-ZHP4-56SO-ZLOI-7QHM-H2A4-GXPM", 2133 "epk":{ 2134 "PublicKeyECDH":{ 2135 "crv":"X448", 2136 "Public":"rdeKkVGxewmd5848kt6ysRkl8Fbnjez7Va-TcRb 2137 -acX83owoCknyb9joo38vs_vzBkgEW5yPxXwA"}}, 2138 "wmk":"DnzzAha8AY_-kkv6Qq3M6rvM3LXTH9yQLSujqOkDEyBXnr 2139 ajY4BoUA"} 2140 ], 2141 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0aW 2142 9uRGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJ 2143 DcmVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NThaIn0"}, 2144 "9YI2S_zl1lfnuTYHlFvbZpNonWv-cx75v2P5YXQLl5mKbRQtc6mf6Ub3f3 2145 WFokrzaz1AoOCNk9amIe-OH1Nv1upgxEd9s3X1Q_UUHOzb84HslsjjtCxqYSuaKFj 2146 QoP2oBzXWGCaoh8t4jIPAaMzdW4gZOQ0NNxb0t47pLHEiUe1Jy1ez5m-PK9faJtH2 2147 wXhtogeWlppdJ2IvxkK4ofCpgY-clsl8yT8qdNFLG4GdEr-SFCn8cmDhYKAT9n5i- 2148 THP", 2149 { 2150 "signatures":[{ 2151 "alg":"S512", 2152 "kid":"MBXO-5JKI-OWJH-UH5T-C4SU-YKEE-D3FP", 2153 "signature":"BZMkm5R4Emy2M5Xljebbvwlu94FWRIvV23zi5Yzt 2154 8dobj_JIfrYP9YHfovGVGtNBeuuA3C0VsJ0AWYECXEng9-ysYke93Er_gfNPx-scx 2155 31nhcNozE4uDSL63UrNZ-J0RzFfo1x8ZoNUTNizr79I5j4A", 2156 "witness":"H8uCeAQI1Nffql1X4qGqK_i9-sgQaDshpTebNsBQr_ 2157 w"} 2158 ], 2159 "PayloadDigest":"u8hmjJAqV014X0KwhOvZpcSxbRevKMuBWJgBA1qy 2160 Q7VyF78Iux68V447pfrUa8iLjD2T32LHJv0u9zCzaJQkhQ"} 2161 ], 2162 "EnvelopedActivationAccount":[{ 2163 "dig":"S512", 2164 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJBY3RpdmF0aW 2165 9uQWNjb3VudCIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICA 2166 iQ3JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI1OjU4WiJ9"}, 2167 "ewogICJBY3RpdmF0aW9uQWNjb3VudCI6IHt9fQ", 2168 { 2169 "signatures":[{ 2170 "alg":"S512", 2171 "kid":"MBXO-5JKI-OWJH-UH5T-C4SU-YKEE-D3FP", 2172 "signature":"b5skN0iKRohn0JGfQO9YzVWvPiB9uW4Df-co8k_m 2173 J8HxFGZUnPEJUKhcLcj0YRQIv1mS9VGFptQAR8UCxqNlxDsKPyzgYZSZ8Wfyoa5ZV 2174 voW15G2zBUAx3VjE9neXXVc0HvqD-TWchto0uTFcdK2njYA"} 2175 ], 2176 "PayloadDigest":"xgR5j7NiUbDvKWjP7IjI4HuMAPLD8-ru3cMITmgI 2177 iPuX9gh1llky1cgZPc1zU0wwYGKucV6mGegsV5wg7ZGYoA"} 2178 ]}}} 2180 9.4. Contact 2182 A contact request presents a proposed contact entry and requests that 2183 it be added to the Contacts catalog of the specified Mesh Service 2184 Account. A contact request is usually sent by the party requesting 2185 that their contact be added but this is not necessarily the case. 2187 The MessageContact contains a DARE Envelope containing the Contact 2188 information of the requester. If the request is accepted, this 2189 information will be added to the contact catalog of the relevant 2190 account. If the Reply field has the value 'true', this indicates 2191 that the sender is asking for the recipient to return their own 2192 credentials in reply. 2194 Since the sender requires the user's contact information before the 2195 request can be made, the MessageContact message MAY be encrypted 2196 under either the user's account encryption key (if known) or the Mesh 2197 Service encryption key (which may be obtained from the service on 2198 request. 2200 Bob asks Alice to send her contact details and sends his. 2202 { 2203 "MessageContact":{ 2204 "MessageId":"ND5Y-QMOY-42ZW-TE2Z-HJL2-7G3L-EQQB", 2205 "Sender":"bob@example.com", 2206 "Recipient":"alice@example.com", 2207 "AuthenticatedData":[{ 2208 "dig":"S512", 2209 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb250YWN0UGVy 2210 c29uIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDcmVhd 2211 GVkIjogIjIwMjAtMTEtMDJUMTc6MjU6NTRaIn0"}, 2212 "ewogICJDb250YWN0UGVyc29uIjogewogICAgIkFuY2hvcnMiOiBbewogICAg 2213 ICAgICJVZGYiOiAiTURNWi01UFdXLVUyN1MtSlNNNC1aTU9CLUJQWDMtSFZJTiIsC 2214 iAgICAgICAgIlZhbGlkYXRpb24iOiAiU2VsZiJ9XSwKICAgICJOZXR3b3JrQWRkcm 2215 Vzc2VzIjogW3sKICAgICAgICAiQWRkcmVzcyI6ICJib2JAZXhhbXBsZS5jb20iLAo 2216 gICAgICAgICJFbnZlbG9wZWRQcm9maWxlQWNjb3VudCI6IFt7CiAgICAgICAgICAg 2217 ICJFbnZlbG9wZUlEIjogIk1ETVotNVBXVy1VMjdTLUpTTTQtWk1PQi1CUFgzLUhWS 2218 U4iLAogICAgICAgICAgICAiZGlnIjogIlM1MTIiLAogICAgICAgICAgICAiQ29udG 2219 VudE1ldGFEYXRhIjogImV3b2dJQ0pWYm1seGRXVkpSQ0k2SUNKTlJFMWFMVFZRVjF 2220 jdFZUSTNVeTEKICBLVTAwMExWcE5UMEl0UWxCWU15MUlWa2xPSWl3S0lDQWlUV1Z6 2221 YzJGblpWUjVjR1VpT2lBaVVISnZabWxzWgogIFZWelpYSWlMQW9nSUNKamRIa2lPa 2222 UFpWVhCd2JHbGpZWFJwYjI0dmJXMXRMMjlpYW1WamRDSXNDaUFnSWtOCiAgeVpXRj 2223 BaV1FpT2lBaU1qQXlNQzB4TVMwd01sUXhOem95TlRvMU5Gb2lmUSJ9LAogICAgICA 2224 gICAgImV3b2dJQ0pRY205bWFXeGxWWE5sY2lJNklIc0tJQ0FnSUNKUWNtOW1hV3gK 2225 ICBsVTJsbmJtRjBkWEpsSWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxRVRWb3ROV 2226 kJYVnkxVk1qZFRMVXBUVAogIFRRdFdrMVBRaTFDVUZnekxVaFdTVTRpTEFvZ0lDQW 2227 dJQ0FpVUhWaWJHbGpVR0Z5WVcxbGRHVnljeUk2SUhzCiAgS0lDQWdJQ0FnSUNBaVV 2228 IVmliR2xqUzJWNVJVTkVTQ0k2SUhzS0lDQWdJQ0FnSUNBZ0lDSmpjbllpT2lBaVIK 2229 ICBXUTBORGdpTEFvZ0lDQWdJQ0FnSUNBZ0lsQjFZbXhwWXlJNklDSnZjbUZ2UlVGV 2230 VYwdFFNMnRyTFVOMlF6QgogIElkRkI2YjFSeWFXMXVVbFpYYUVaT1ZGVldjR1JpUk 2231 dORVdqSjRPVWxaYVVScENpQWdhR3BYWjBoQk1UWnZTCiAgVGRIWWxOSlpVZHVSV0V 2232 3WDBGQkluMTlmU3dLSUNBZ0lDSkJZMk52ZFc1MFFXUmtjbVZ6Y3lJNklDSmliMkoK 2233 ICBBWlhoaGJYQnNaUzVqYjIwaUxBb2dJQ0FnSWxObGNuWnBZMlZWWkdZaU9pQWlUV 2234 UpUVEMxSU5EVlFMVkJOTQogIDFjdFRsUlpTUzFPVFV0SExVdzBObFF0TlVoWFRTSX 2235 NDaUFnSUNBaVFXTmpiM1Z1ZEVWdVkzSjVjSFJwYjI0CiAgaU9pQjdDaUFnSUNBZ0l 2236 DSlZaR1lpT2lBaVRVTkNWQzFGU1VKU0xWRk9TVU10VGtSRlFTMVpORU5NTFUwMVYK 2237 ICBsWXRUMVpWV0NJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ 2238 2V3b2dJQ0FnSUNBZ0lDSgogIFFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSU 2239 NBZ0lDQWdJbU55ZGlJNklDSllORFE0SWl3S0lDQWdJCiAgQ0FnSUNBZ0lDSlFkV0p 2240 zYVdNaU9pQWlZV28zY1hvMU9IZFVTVGhEYzB3M1pHcDNRbWhRUmkwMVJXOVZhbVIK 2241 ICBHVnpScldreHBZbVZOVW5WdFZqVkhlbkJoV2xGd01Bb2dJRlZVVFVsT04zUjJXR 2242 XBJV1ZGSlQzSTNZVk5wTgogIEVNMlFTSjlmWDBzQ2lBZ0lDQWlRV1J0YVc1cGMzUn 2243 lZWFJ2Y2xOcFoyNWhkSFZ5WlNJNklIc0tJQ0FnSUNBCiAgZ0lsVmtaaUk2SUNKTlJ 2244 FMWFMVFZRVjFjdFZUSTNVeTFLVTAwMExWcE5UMEl0UWxCWU15MUlWa2xPSWl3S0kK 2245 ICBDQWdJQ0FnSWxCMVlteHBZMUJoY21GdFpYUmxjbk1pT2lCN0NpQWdJQ0FnSUNBZ 2246 0lsQjFZbXhwWTB0bGVVVgogIERSRWdpT2lCN0NpQWdJQ0FnSUNBZ0lDQWlZM0oySW 2247 pvZ0lrVmtORFE0SWl3S0lDQWdJQ0FnSUNBZ0lDSlFkCiAgV0pzYVdNaU9pQWliM0p 2248 oYjBWQlZGZExVRE5yYXkxRGRrTXdTSFJRZW05VWNtbHRibEpXVjJoR1RsUlZWbkIK 2249 ICBrWWtSalJGb3llRGxKV1dsRWFRb2dJR2hxVjJkSVFURTJiMGszUjJKVFNXVkhia 2250 1ZoTUY5QlFTSjlmWDBzQwogIGlBZ0lDQWlRV05qYjNWdWRFRjFkR2hsYm5ScFkyRj 2251 BhVzl1SWpvZ2V3b2dJQ0FnSUNBaVZXUm1Jam9nSWsxCiAgQlRra3RSakpCVUMxTFZ 2252 sbE5MVnBYVDFBdFRFYzNVUzFZVUZKTkxVeFNSMU1pTEFvZ0lDQWdJQ0FpVUhWaWIK 2253 ICBHbGpVR0Z5WVcxbGRHVnljeUk2SUhzS0lDQWdJQ0FnSUNBaVVIVmliR2xqUzJWN 2254 VJVTkVTQ0k2SUhzS0lDQQogIGdJQ0FnSUNBZ0lDSmpjbllpT2lBaVdEUTBPQ0lzQ2 2255 lBZ0lDQWdJQ0FnSUNBaVVIVmliR2xqSWpvZ0luVnVWCiAgbmhmU1haeWVWbGZlamh 2256 EYzJkV2MzaHBSWGR4YlU1VUxWVkdNakEwVEdSbGVVNUZSMlJPUWxGa1drWk1kM3AK 2257 ICBSV1RRS0lDQm1Oa0p4YWtGclltVlhURlF0WkhGV2FXcHJSMFJyVFVFaWZYMTlMQ 2258 W9nSUNBZ0lrRmpZMjkxYgogIG5SVGFXZHVZWFIxY21VaU9pQjdDaUFnSUNBZ0lDSl 2259 ZaR1lpT2lBaVRVSlhXaTFITWpKQ0xVSkdRVlF0UmxkCiAgQlJ5MU9NMFZYTFZwVFV 2260 WY3RNelpQU0NJc0NpQWdJQ0FnSUNKUWRXSnNhV05RWVhKaGJXVjBaWEp6SWpvZ2UK 2261 ICB3b2dJQ0FnSUNBZ0lDSlFkV0pzYVdOTFpYbEZRMFJJSWpvZ2V3b2dJQ0FnSUNBZ 2262 0lDQWdJbU55ZGlJNklDSgogIEZaRFEwT0NJc0NpQWdJQ0FnSUNBZ0lDQWlVSFZpYk 2263 dsaklqb2dJbXRhVldSSVMzVm5XbkZ1T0ZWb2VHcG1UCiAgMlZuZFhNeFRDMDNUelZ 2264 wZDJWelIzazNORTlLZW5sd1RFNDBORlJTVVU5SmVHUUtJQ0J3TTJObU4ybFdiMkYK 2265 ICBHVkRkRGFUZE9SRlJ2UWtsNlZVRWlmWDE5ZlgwIiwKICAgICAgICAgIHsKICAgI 2266 CAgICAgICAgInNpZ25hdHVyZXMiOiBbewogICAgICAgICAgICAgICAgImFsZyI6IC 2267 JTNTEyIiwKICAgICAgICAgICAgICAgICJraWQiOiAiTURNWi01UFdXLVUyN1MtSlN 2268 NNC1aTU9CLUJQWDMtSFZJTiIsCiAgICAgICAgICAgICAgICAic2lnbmF0dXJlIjog 2269 IlQtQUJzanZicGxXMlN3LUFLX0d6eFJ4OXBJb3BjNnZ0UF9FMDVlVmhaZWlpOEtkZ 2270 k4KICBmcGYxMGZTNWFtUkNYLUlCaGJIeXA4aHpONEFyc25aUFNZa25kQnBsTnJ0am 2271 U3NklhYjNpVFp5QUJoeFBVTAogIHpMMThnN1kxSGgyRVB2Rm9GeHFHazM5dWN6WkF 2272 UQlNMc3RUeXhIUjhBIn1dLAogICAgICAgICAgICAiUGF5bG9hZERpZ2VzdCI6ICI4 2273 WHZWaUxjZExra0NfaW5uSlZRelM3Uk5XSGxCVVZmSDREd0Rqc1kweHNlQVkKICB6U 2274 nd4WDJRN2VyR01JLTFOT0NNV3MxSldWN2tabFlPNDBXYnJNMmJ5USJ9XSwKICAgIC 2275 AgICAiUHJvdG9jb2xzIjogW3sKICAgICAgICAgICAgIlByb3RvY29sIjogIm1tbSJ 2276 9XX1dfX0", 2277 { 2278 "signatures":[{ 2279 "alg":"S512", 2280 "kid":"MBWZ-G22B-BFAT-FWAG-N3EW-ZSQW-36OH", 2281 "signature":"wN4bBu-tL_qZ1v74Teo2ZRQnwlxciiQOMRCf_Dgewq 2282 kuqGoWW22CLeDc7HJoYg22pTxKC7gCWFsAJm_kgR64jxSwZCb3JBAoDzuLQ-Qnb9B 2283 c4r4r4ZEDIQgvH45TFdhb5yRP7yqurQds2UMgVOemMS0A"} 2284 ], 2285 "PayloadDigest":"ofJhr9i1k27VRu81sCKWy7qEahxpuw0rtvwrQaYkag 2286 PBvVLkoNY2F6jLGCQ5Y42_9jMYVglcMVXhkB_AvYG52Q"} 2287 ], 2288 "Reply":true, 2289 "Subject":"alice@example.com", 2290 "PIN":"AA3V-CH7O-FGHI-W2DP-VCCY-IRXB-IO2A"}} 2292 Alice responds with her own contact information. Since she already 2293 has Bob's contact information, there is no need to request a response 2294 or provide a PIN code. 2296 The current protocol assumes that all contact management will be 2297 performed end-to-end through the Mesh Services themselves. If the 2298 number of Mesh users were to become exceptionally large, additional 2299 infrastructure to facilitate contact management will be required. 2300 These topics are discussed at a high level in 2301 [draft-hallambaker-mesh-trust]. 2303 In situations where a user is well known and has a very large number 2304 of contacts, they are likely to make use of a tiered approach to 2305 contact management in which they keep separate accounts for their 2306 'public' and 'restricted' personas and delegate management of their 2307 public account to a subordinate or to their Mesh Service provider. 2309 9.5. Confirmation 2311 Confirmation messages are used to provide an improved form of second 2312 factor authentication capability. 2314 Two confirmation messages are specified, a request and response. 2316 A confirmation request is initiated by sending a 2317 "MessageConfirmationRequest" to the Mesh Service hosting the 2318 recipient Mesh Service Account. The request specifies the question 2319 that is to be put to the user. 2321 To respond to a confirmation request, a user generates a 2322 "MessageConfirmationResponse". This MUST be signed by a device 2323 authorized to respond to confirmation requests by a Device Connection 2324 Assertion with the "Confirmation" privilege. 2326 The console generates a confirmation request message: 2328 { 2329 "RequestConfirmation":{ 2330 "MessageId":"NC2K-XDLE-KNN2-GSLN-AEUX-WJXF-RA5B", 2331 "Sender":"console@example.com", 2332 "Recipient":"alice@example.com", 2333 "Text":"start"}} 2335 Alice accepts the request and returns a ResponseConfirmation 2336 confirmation containing both the request and the response: 2338 Missing example 26 2340 10. Publications 2342 Static QR codes MAY be used to allow contact exchange or device 2343 connection. In either case, the QR code contains an EARL providing 2344 the means of locating, decrypting and authenticating the published 2345 data. 2347 10.1. Contact Exchange 2349 When used for contact exchange, the envelope payload is a 2350 CatalogedContact record. 2352 Besides allowing for exchange of contact information on a business 2353 card, a user might have their contact information printed on personal 2354 property to facilitate return of lost property. 2356 10.2. Device Preconfiguration 2358 The static QR code device connection interaction allows a device with 2359 no keyboard, display or other user affordances to be connected to a 2360 Mesh account. 2362 The information necessary to establish communication with the device 2363 and to complete a device connection workflow is provided by means of 2364 a DevicePreconfiguration record accessed by means of an EARL. 2366 For example, Alice's coffee pot was preconfigured for connection to a 2367 Mesh account at the factory and the following DevicePreconfiguration 2368 record created: 2370 { 2371 "DevicePreconfiguration":{ 2372 "EnvelopedProfileDevice":[{ 2373 "EnvelopeID":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV", 2374 "dig":"S512", 2375 "ContentMetaData":"ewogICJVbmlxdWVJRCI6ICJNQ1E3LUZGTjQtM1dD 2376 WS1ORFlVLUNQRlEtWEZINC1FSE5WIiwKICAiTWVzc2FnZVR5cGUiOiAiUHJvZmlsZ 2377 URldmljZSIsCiAgImN0eSI6ICJhcHBsaWNhdGlvbi9tbW0vb2JqZWN0IiwKICAiQ3 2378 JlYXRlZCI6ICIyMDIwLTExLTAyVDE3OjI2OjAwWiJ9"}, 2379 "ewogICJQcm9maWxlRGV2aWNlIjogewogICAgIlByb2ZpbGVTaWduYXR1cmUi 2380 OiB7CiAgICAgICJVZGYiOiAiTUNRNy1GRk40LTNXQ1ktTkRZVS1DUEZRLVhGSDQtR 2381 UhOViIsCiAgICAgICJQdWJsaWNQYXJhbWV0ZXJzIjogewogICAgICAgICJQdWJsaW 2382 NLZXlFQ0RIIjogewogICAgICAgICAgImNydiI6ICJFZDQ0OCIsCiAgICAgICAgICA 2383 iUHVibGljIjogImR5UWdEZVpYMFk3dTVGRWxlckxiekZoYkdVVGozanJrTzViaXV0 2384 bmQ5Q3VodFVQbnBOTTcKICBVRFRrNW90bWxvcmVpSjlPQmxuNzBMMEEifX19LAogI 2385 CAgIkJhc2VFbmNyeXB0aW9uIjogewogICAgICAiVWRmIjogIk1BRkYtNFA1NC1PUl 2386 lGLVNCQU4tNlhRNy1DTzZTLU9YV1EiLAogICAgICAiUHVibGljUGFyYW1ldGVycyI 2387 6IHsKICAgICAgICAiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAi 2388 WDQ0OCIsCiAgICAgICAgICAiUHVibGljIjogIjdyRWpsVGNsRVBBb3l0WkxHSmJmN 2389 S1lTzhtQldMbE5hZXZKM1lBdF9hUmhKQWhlLVJPWUwKICBfQVNmQnVLRUw5ZDBPOH 2390 BDRGxXendBMkEifX19LAogICAgIkJhc2VBdXRoZW50aWNhdGlvbiI6IHsKICAgICA 2391 gIlVkZiI6ICJNQU5CLURZWEUtN0NOQy1XNkxXLTNSNkktQkxBQi0yVEtDIiwKICAg 2392 ICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiO 2393 iB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6IC 2394 JCb1lfd3hMdHhLMU1zRk9oT0VzOExrWTZIWTZONng0NmkwTF9NSkxNQU1rcXdzQXl 2395 peW1SCiAgazZwVjR2dnRDYzZEekJPOExGX01XWWdBIn19fSwKICAgICJCYXNlU2ln 2396 bmF0dXJlIjogewogICAgICAiVWRmIjogIk1BVzctWUlPMy01QTdNLTU1WVUtT1o3V 2397 y1CSkZULVFUSFciLAogICAgICAiUHVibGljUGFyYW1ldGVycyI6IHsKICAgICAgIC 2398 AiUHVibGljS2V5RUNESCI6IHsKICAgICAgICAgICJjcnYiOiAiRWQ0NDgiLAogICA 2399 gICAgICAgIlB1YmxpYyI6ICJQc2Y4dG9qRTZPNFE3SllCWGU0ci1iZExRZHk0RTh0 2400 ek1URTNBRENzNE93WEt5bldydmxxCiAgTzdjeUdjWDFXbjZiZDJWNWhMRjQ4UjhBI 2401 n19fX19", 2402 { 2403 "signatures":[{ 2404 "alg":"S512", 2405 "kid":"MCQ7-FFN4-3WCY-NDYU-CPFQ-XFH4-EHNV", 2406 "signature":"lVcSWqEEVvr-AsnhUeUQ4OwnIa-enZ3ZXre4sc3M3b 2407 JY_tre8U0e_AfM-VFERgN7OQ67OBatfj8AqZLU6SxhaJHira3uZbw1Ha8yQXMXSed 2408 pPm9hefDHb0-zwT80Pr0530SByJmW2uU5sQUh1rxmhiAA"} 2409 ], 2410 "PayloadDigest":"KflhE7fsBB_6jk4XP2sFRVtoqIj5zZ2j3QISDfuLTw 2411 se9bZBKTY8IPcGTlXtnaBTEH4P9smbO6AB6EDy8Nnegw"} 2412 ], 2413 "EnvelopedConnectionDevice":[{ 2414 "dig":"S512", 2415 "ContentMetaData":"ewogICJNZXNzYWdlVHlwZSI6ICJDb25uZWN0aW9u 2416 RGV2aWNlIiwKICAiY3R5IjogImFwcGxpY2F0aW9uL21tbS9vYmplY3QiLAogICJDc 2417 mVhdGVkIjogIjIwMjAtMTEtMDJUMTc6MjY6MDBaIn0"}, 2418 "ewogICJDb25uZWN0aW9uRGV2aWNlIjogewogICAgIkRldmljZVNpZ25hdHVy 2419 ZSI6IHsKICAgICAgIlVkZiI6ICJNQVc3LVlJTzMtNUE3TS01NVlVLU9aN1ctQkpGV 2420 C1RVEhXIiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1Ym 2421 xpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIkVkNDQ4IiwKICAgICAgICA 2422 gICJQdWJsaWMiOiAiUHNmOHRvakU2TzRRN0pZQlhlNHItYmRMUWR5NEU4dHpNVEUz 2423 QURDczRPd1hLeW5XcnZscQogIE83Y3lHY1gxV242YmQyVjVoTEY0OFI4QSJ9fX0sC 2424 iAgICAiRGV2aWNlRW5jcnlwdGlvbiI6IHsKICAgICAgIlVkZiI6ICJNQUZGLTRQNT 2425 QtT1JZRi1TQkFOLTZYUTctQ082Uy1PWFdRIiwKICAgICAgIlB1YmxpY1BhcmFtZXR 2426 lcnMiOiB7CiAgICAgICAgIlB1YmxpY0tleUVDREgiOiB7CiAgICAgICAgICAiY3J2 2427 IjogIlg0NDgiLAogICAgICAgICAgIlB1YmxpYyI6ICI3ckVqbFRjbEVQQW95dFpMR 2428 0piZjUtZU84bUJXTGxOYWV2SjNZQXRfYVJoSkFoZS1ST1lMCiAgX0FTZkJ1S0VMOW 2429 QwTzhwQ0RsV3p3QTJBIn19fSwKICAgICJEZXZpY2VBdXRoZW50aWNhdGlvbiI6IHs 2430 KICAgICAgIlVkZiI6ICJNQUZGLTRQNTQtT1JZRi1TQkFOLTZYUTctQ082Uy1PWFdR 2431 IiwKICAgICAgIlB1YmxpY1BhcmFtZXRlcnMiOiB7CiAgICAgICAgIlB1YmxpY0tle 2432 UVDREgiOiB7CiAgICAgICAgICAiY3J2IjogIlg0NDgiLAogICAgICAgICAgIlB1Ym 2433 xpYyI6ICI3ckVqbFRjbEVQQW95dFpMR0piZjUtZU84bUJXTGxOYWV2SjNZQXRfYVJ 2434 oSkFoZS1ST1lMCiAgX0FTZkJ1S0VMOWQwTzhwQ0RsV3p3QTJBIn19fX19", 2435 { 2436 "signatures":[{ 2437 "alg":"S512", 2438 "kid":"MDJN-Y22I-NBWS-TF2I-7HJV-N4JS-T5GU", 2439 "signature":"3dKPeRJ1OFB-h3Mt99GDJf4slU8XjkmkrmucvEbdlm 2440 dbxl7pf_7Wi8PxjtH2xwCDD8IqamVPGaiAmK6slj2-dHfQfpOAl7hMkyKFE3W5sR2 2441 t9DGrYCqZU9J-rUd1eLc8wUh3kSZ08MDVGEcCcLEZuD4A"} 2442 ], 2443 "PayloadDigest":"rIuHcY2LV8tgbaFHN88oYDGytN5Giv1KTyQGDifkwX 2444 -HBK1IsApCD_pJ4h5jpG9fx9TSIqEiuMIb7iHqheByWg"} 2445 ], 2446 "PrivateKey":{ 2447 "PrivateKeyUDF":{ 2448 "PrivateValue":"ZAAQ-AAQT-ZDDI-IU7M-ORQA-YRRR-MMEH-D4PN-3YP 2449 W-HGJH-FXSR-BZXH-PYMG-KZBC", 2450 "KeyType":"MeshProfileDevice"}}, 2451 "ConnectUri":"mcu://maker@example.com/ECO6-IN3T-HZYJ-S7W4-T4XZ- 2452 JX6R-Y5SO-ATKN-TU2E-MDAF-VJEA-JV6Z-BOXE-G"}} 2454 To connect to the coffee pot, Alice first scans the QR code with her 2455 administrative device which uses the PIN code and service to 2456 retrieve, decrypt and authenticate the DevicePreconfiguration record. 2457 Future versions of the specification will allow this record to 2458 specify means by which the administration device can establish direct 2459 peer-to-peer communication to complete the connection process by any 2460 communication modality supported by both devices (e.g. IR, 2461 Bluetooth, WiFi-Direct, etc.) 2463 11. Schema 2465 11.1. Shared Classes 2467 The following classes are used as common elements in Mesh profile 2468 specifications. 2470 11.1.1. Classes describing keys 2472 11.1.2. Structure: KeyData 2474 The KeyData class is used to describe public key pairs and trust 2475 assertions associated with a public key. 2477 Udf: String (Optional) UDF fingerprint of the public key parameters 2479 X509Certificate: Binary (Optional) List of X.509 Certificates 2481 X509Chain: Binary [0..Many] X.509 Certificate chain. 2483 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 2485 NotBefore: DateTime (Optional) If present specifies a time instant 2486 that use of the private key is not valid before. 2488 NotOnOrAfter: DateTime (Optional) If present specifies a time 2489 instant that use of the private key is not valid on or after. 2491 11.1.3. Structure: CompositePrivate 2493 Inherits: Key 2495 DeviceKeyUdf: String (Optional) UDF fingerprint of the bound device 2496 key (if used). 2498 11.2. Assertion classes 2500 Classes that are derived from an assertion. 2502 11.2.1. Structure: Assertion 2504 Parent class from which all assertion classes are derived 2506 Names: String [0..Many] Fingerprints of index terms for profile 2507 retrieval. The use of the fingerprint of the name rather than the 2508 name itself is a precaution against enumeration attacks and other 2509 forms of abuse. 2511 Updated: DateTime (Optional) The time instant the profile was last 2512 modified. 2514 NotaryToken: String (Optional) A Uniform Notary Token providing 2515 evidence that a signature was performed after the notary token was 2516 created. 2518 11.2.2. Structure: Condition 2520 Parent class from which all condition classes are derived. 2522 [No fields] 2524 11.2.3. Base Classes 2526 Abstract classes from which the Profile, Activation and Connection 2527 classes are derrived. 2529 11.2.4. Structure: Connection 2531 Inherits: Assertion 2533 SubjectUdf: String (Optional) UDF of the connection target. 2535 AuthorityUdf: String (Optional) UDF of the connection source. 2537 11.2.5. Structure: Activation 2539 Inherits: Assertion 2541 Contains the private activation information for a Mesh application 2542 running on a specific device 2544 ActivationKey: String (Optional) Secret seed used to derive keys 2545 that are not explicitly specified. 2547 Entries: ActivationEntry [0..Many] Activation of named resources. 2549 11.2.6. Structure: ActivationEntry 2551 Resource: String (Optional) Name of the activated resource 2553 Key: KeyData (Optional) The activation key or key share 2555 11.2.7. Mesh Profile Classes 2557 Classes describing Mesh Profiles. All Profiles are Assertions 2558 derrived from Assertion. 2560 11.2.8. Structure: Profile 2562 Inherits: Assertion 2564 Parent class from which all profile classes are derived 2566 ProfileSignature: KeyData (Optional) The permanent signature key 2567 used to sign the profile itself. The UDF of the key is used as 2568 the permanent object identifier of the profile. Thus, by 2569 definition, the KeySignature value of a Profile does not change 2570 under any circumstance. 2572 11.2.9. Structure: ProfileDevice 2574 Inherits: Profile 2576 Describes a mesh device. 2578 Description: String (Optional) Description of the device 2580 BaseEncryption: KeyData (Optional) Base key contribution for 2581 encryption keys. Also used to decrypt activation data sent to the 2582 device during connection to an account. 2584 BaseAuthentication: KeyData (Optional) Base key contribution for 2585 authentication keys. Also used to authenticate the device during 2586 connection to an account. 2588 BaseSignature: KeyData (Optional) Base key contribution for 2589 signature keys. 2591 11.2.10. Structure: ProfileAccount 2593 Base class for the account profiles ProfileUser and ProfileGroup. 2594 These subclasses may be merged at some future date. 2596 Inherits: Profile 2598 AccountAddress: String (Optional) The account address. This is 2599 either a DNS service address (e.g. alice@example.com) or a Mesh 2600 Name (@alice). 2602 ServiceUdf: String (Optional) The fingerprint of the service profile 2603 to which the account is currently bound. 2605 EscrowEncryption: KeyData (Optional) Escrow key associated with the 2606 account. 2608 AccountEncryption: KeyData (Optional) Key currently used to encrypt 2609 data under this profile 2611 AdministratorSignature: KeyData (Optional) Key used to sign 2612 connection assertions to the account. 2614 11.2.11. Structure: ProfileUser 2616 Inherits: ProfileAccount 2618 Account assertion. This is signed by the service hosting the 2619 account. 2621 AccountAuthentication: KeyData (Optional) Key used to authenticate 2622 requests made under this user account. 2624 AccountSignature: KeyData (Optional) Key used to sign data under the 2625 account. 2627 11.2.12. Structure: ProfileGroup 2629 Inherits: ProfileAccount 2631 Describes a group. Note that while a group is created by one person 2632 who becomes its first administrator, control of the group may pass to 2633 other administrators over time. 2635 [No fields] 2637 11.2.13. Structure: ProfileService 2639 Inherits: Profile 2641 Profile of a Mesh Service 2643 ServiceAuthentication: KeyData (Optional) Key used to authenticate 2644 service connections. 2646 ServiceEncryption: KeyData (Optional) Key used to encrypt data under 2647 this profile 2649 ServiceSignature: KeyData (Optional) Key used to sign data under the 2650 account. 2652 11.2.14. Structure: ProfileHost 2654 Inherits: Profile 2656 KeyAuthentication: KeyData (Optional) Key used to authenticate 2657 service connections. 2659 KeyEncryption: KeyData (Optional) Key used to pass encrypted data to 2660 the device such as a 2662 11.2.15. Connection Assertions 2664 Connection assertions are used to authenticate and authorize 2665 interactions between devices and the service currently servicing the 2666 account. They SHOULD NOT be visible to external parties. 2668 11.2.16. Structure: ConnectionDevice 2670 Inherits: Connection 2672 Connection assertion used to authenticate service requests made by a 2673 device. 2675 AccountAddress: String (Optional) The account address 2677 DeviceSignature: KeyData (Optional) The signature key for use of the 2678 device under the profile 2680 DeviceEncryption: KeyData (Optional) The encryption key for use of 2681 the device under the profile 2683 DeviceAuthentication: KeyData (Optional) The authentication key for 2684 use of the device under the profile 2686 11.2.17. Structure: ConnectionApplication 2688 Inherits: Connection 2690 Connection assertion stating that a particular device is 2692 [No fields] 2694 11.2.18. Structure: ConnectionGroup 2696 Describes the connection of a member to a group. 2698 Inherits: Connection 2700 [No fields] 2702 11.2.19. Structure: ConnectionService 2704 Inherits: Connection 2706 [No fields] 2708 11.2.20. Structure: ConnectionHost 2710 Inherits: Connection 2712 [No fields] 2714 11.2.21. Activation Assertions 2716 11.2.22. Structure: ActivationDevice 2718 Contains activation data for device specific keys used in the context 2719 of a Mesh account. 2721 Inherits: Activation 2722 AccountUdf: String (Optional) The UDF of the account 2724 11.2.23. Structure: ActivationAccount 2726 Inherits: Activation 2728 ProfileSignature: KeyData (Optional) Grant access to profile online 2729 signing key used to sign updates to the profile. 2731 AdministratorSignature: KeyData (Optional) Grant access to Profile 2732 administration key used to make changes to administrator catalogs. 2734 AccountEncryption: KeyData (Optional) Grant access to ProfileUser 2735 account encryption key 2737 AccountAuthentication: KeyData (Optional) Grant access to 2738 ProfileUser account authentication key 2740 AccountSignature: KeyData (Optional) Grant access to ProfileUser 2741 account signature key 2743 11.2.24. Structure: ActivationApplication 2745 Inherits: Activation 2747 [No fields] 2749 11.3. Data Structures 2751 Classes describing data used in cataloged data. 2753 11.3.1. Structure: Contact 2755 Inherits: Assertion 2757 Base class for contact entries. 2759 Id: String (Optional) The globally unique contact identifier. 2761 Anchors: Anchor [0..Many] Mesh fingerprints associated with the 2762 contact. 2764 NetworkAddresses: NetworkAddress [0..Many] Network address entries 2766 Locations: Location [0..Many] The physical locations the contact is 2767 associated with. 2769 Roles: Role [0..Many] The roles of the contact 2770 Bookmark: Bookmark [0..Many] The Web sites and other online 2771 presences of the contact 2773 Sources: TaggedSource [0..Many] Source(s) from which this contact 2774 was constructed. 2776 11.3.2. Structure: Anchor 2778 Trust anchor 2780 Udf: String (Optional) The trust anchor. 2782 Validation: String (Optional) The means of validation. 2784 11.3.3. Structure: TaggedSource 2786 Source from which contact information was obtained. 2788 LocalName: String (Optional) Short name for the contact information. 2790 Validation: String (Optional) The means of validation. 2792 BinarySource: Binary (Optional) The contact data in binary form. 2794 EnvelopedSource: Enveloped (Optional) The contact data in enveloped 2795 form. If present, the BinarySource property is ignored. 2797 11.3.4. Structure: ContactGroup 2799 Inherits: Contact 2801 Contact for a group, including encryption groups. 2803 [No fields] 2805 11.3.5. Structure: ContactPerson 2807 Inherits: Contact 2809 CommonNames: PersonName [0..Many] List of person names in order of 2810 preference 2812 11.3.6. Structure: ContactOrganization 2814 Inherits: Contact 2816 CommonNames: OrganizationName [0..Many] List of person names in 2817 order of preference 2819 11.3.7. Structure: OrganizationName 2821 The name of an organization 2823 Inactive: Boolean (Optional) If true, the name is not in current 2824 use. 2826 RegisteredName: String (Optional) The registered name. 2828 DBA: String (Optional) Names that the organization uses including 2829 trading names and doing business as names. 2831 11.3.8. Structure: PersonName 2833 The name of a natural person 2835 Inactive: Boolean (Optional) If true, the name is not in current 2836 use. 2838 FullName: String (Optional) The preferred presentation of the full 2839 name. 2841 Prefix: String (Optional) Honorific or title, E.g. Sir, Lord, Dr., 2842 Mr. 2844 First: String (Optional) First name. 2846 Middle: String [0..Many] Middle names or initials. 2848 Last: String (Optional) Last name. 2850 Suffix: String (Optional) Nominal suffix, e.g. Jr., III, etc. 2852 PostNominal: String (Optional) Post nominal letters (if used). 2854 11.3.9. Structure: NetworkAddress 2856 Provides all means of contacting the individual according to a 2857 particular network address 2859 Inactive: Boolean (Optional) If true, the name is not in current 2860 use. 2862 Address: String (Optional) The network address, e.g. 2863 alice@example.com 2865 NetworkCapability: String [0..Many] The capabilities bound to this 2866 address. 2868 EnvelopedProfileAccount: Enveloped (Optional) The account profile 2870 Protocols: NetworkProtocol [0..Many] Public keys associated with the 2871 network address 2873 11.3.10. Structure: NetworkProtocol 2875 Protocol: String (Optional) The IANA protocol|identifier of the 2876 network protocols by which the contact may be reached using the 2877 specified Address. 2879 11.3.11. Structure: Role 2881 OrganizationName: String (Optional) The organization at which the 2882 role is held 2884 Titles: String [0..Many] The titles held with respect to that 2885 organization. 2887 Locations: Location [0..Many] Postal or physical addresses 2888 associated with the role. 2890 11.3.12. Structure: Location 2892 Appartment: String (Optional) 2894 Street: String (Optional) 2896 District: String (Optional) 2898 Locality: String (Optional) 2900 County: String (Optional) 2902 Postcode: String (Optional) 2904 Country: String (Optional) 2906 11.3.13. Structure: Bookmark 2908 Uri: String (Optional) 2910 Title: String (Optional) 2912 Role: String [0..Many] 2914 11.3.14. Structure: Reference 2916 MessageId: String (Optional) The received message to which this is a 2917 response 2919 ResponseId: String (Optional) Message that was generated in response 2920 to the original (optional). 2922 Relationship: String (Optional) The relationship type. This can be 2923 Read, Unread, Accept, Reject. 2925 11.3.15. Structure: Task 2927 Key: String (Optional) Unique key. 2929 Start: DateTime (Optional) 2931 Finish: DateTime (Optional) 2933 StartTravel: String (Optional) 2935 FinishTravel: String (Optional) 2937 TimeZone: String (Optional) 2939 Title: String (Optional) 2941 Description: String (Optional) 2943 Location: String (Optional) 2945 Trigger: String [0..Many] 2947 Conference: String [0..Many] 2949 Repeat: String (Optional) 2951 Busy: Boolean (Optional) 2953 11.4. Catalog Entries 2955 11.4.1. Structure: CatalogedEntry 2957 Base class for cataloged Mesh data. 2959 Labels: String [0..Many] The set of labels describing the entry 2961 11.4.2. Structure: CatalogedDevice 2963 Inherits: CatalogedEntry 2965 Public device entry, indexed under the device ID Hello 2967 Udf: String (Optional) UDF of the signature key of the device in the 2968 Mesh 2970 DeviceUdf: String (Optional) UDF of the offline signature key of the 2971 device 2973 SignatureUdf: String (Optional) UDF of the account online signature 2974 key 2976 EnvelopedProfileUser: Enveloped (Optional) The Mesh profile 2978 EnvelopedProfileDevice: Enveloped (Optional) The device profile 2980 EnvelopedConnectionUser: Enveloped (Optional) The public assertion 2981 demonstrating connection of the Device to the Mesh 2983 EnvelopedActivationDevice: Enveloped (Optional) The activation of 2984 the device within the Mesh account 2986 EnvelopedActivationAccount: Enveloped (Optional) The activation of 2987 the device within the Mesh account 2989 EnvelopedActivationApplication: Enveloped [0..Many] Application 2990 activations granted to the device. 2992 11.4.3. Structure: CatalogedPublication 2994 Inherits: CatalogedEntry 2996 A publication. 2998 Id: String (Optional) Unique identifier code 3000 Authenticator: String (Optional) The witness key value to use to 3001 request access to the record. 3003 EnvelopedData: DareEnvelope (Optional) Dare Envelope containing the 3004 entry data. The data type is specified by the envelope metadata. 3006 NotOnOrAfter: DateTime (Optional) Epiration time (inclusive) 3008 11.4.4. Structure: CatalogedCredential 3010 Inherits: CatalogedEntry 3012 Protocol: String (Optional) 3014 Service: String (Optional) 3016 Username: String (Optional) 3018 Password: String (Optional) 3020 11.4.5. Structure: CatalogedNetwork 3022 Inherits: CatalogedEntry 3024 Protocol: String (Optional) 3026 Service: String (Optional) 3028 Username: String (Optional) 3030 Password: String (Optional) 3032 11.4.6. Structure: CatalogedContact 3034 Inherits: CatalogedEntry 3036 Key: String (Optional) Unique key. 3038 Self: Boolean (Optional) If true, this catalog entry is for the user 3039 who created the catalog. 3041 11.4.7. Structure: CatalogedAccess 3043 Inherits: CatalogedEntry 3045 [No fields] 3047 11.4.8. Structure: CryptographicCapability 3049 Id: String (Optional) The identifier of the capability. If this is 3050 a user capability, MUST match the KeyData identifier. If this is 3051 a serviced capability, MUST match the value of ServiceId on the 3052 corresponding service capability. 3054 KeyData: KeyData (Optional) The key that enables the capability 3055 EnvelopedKeyShares: Enveloped [0..Many] One or more enveloped key 3056 shares. 3058 SubjectId: String (Optional) The identifier of the resource that is 3059 controlled using the key. 3061 SubjectAddress: String (Optional) The address of the resource that 3062 is controlled using the key. 3064 11.4.9. Structure: CapabilityDecrypt 3066 Inherits: CryptographicCapability 3068 The corresponding key is a decryption key 3070 [No fields] 3072 11.4.10. Structure: CapabilityDecryptPartial 3074 Inherits: CapabilityDecrypt 3076 The corresponding key is an encryption key 3078 ServiceId: String (Optional) The identifier used to claim the 3079 capability from the service.[Only present for a partial 3080 capability.] 3082 ServiceAddress: String (Optional) The service account that supports 3083 a serviced capability. [Only present for a partial capability.] 3085 11.4.11. Structure: CapabilityDecryptServiced 3087 Inherits: CapabilityDecrypt 3089 The corresponding key is an encryption key 3091 AuthenticationId: String (Optional) UDF of trust root under which 3092 request to use a serviced capability must be authorized. [Only 3093 present for a serviced capability] 3095 11.4.12. Structure: CapabilitySign 3097 Inherits: CryptographicCapability 3099 The corresponding key is an administration key 3101 [No fields] 3103 11.4.13. Structure: CapabilityKeyGenerate 3105 Inherits: CryptographicCapability 3107 The corresponding key is a key that may be used to generate key 3108 shares. 3110 [No fields] 3112 11.4.14. Structure: CapabilityFairExchange 3114 Inherits: CryptographicCapability 3116 The corresponding key is a decryption key to be used in accordance 3117 with the Micali Fair Electronic Exchange with Invisible Trusted 3118 Parties protocol. 3120 [No fields] 3122 11.4.15. Structure: CatalogedBookmark 3124 Inherits: CatalogedEntry 3126 Uri: String (Optional) 3128 Title: String (Optional) 3130 Path: String (Optional) 3132 11.4.16. Structure: CatalogedTask 3134 Inherits: CatalogedEntry 3136 EnvelopedTask: Enveloped (Optional) 3138 Title: String (Optional) 3140 Key: String (Optional) Unique key. 3142 11.4.17. Structure: CatalogedApplication 3144 Inherits: CatalogedEntry 3146 Key: String (Optional) 3148 EnvelopedCapabilities: DareEnvelope [0..Many] Enveloped keys for use 3149 with Application 3151 11.4.18. Structure: CatalogedMember 3153 ContactAddress: String (Optional) 3155 MemberCapabilityId: String (Optional) 3157 ServiceCapabilityId: String (Optional) 3159 Inherits: CatalogedEntry 3161 11.4.19. Structure: CatalogedGroup 3163 Inherits: CatalogedApplication 3165 EnvelopedProfileGroup: Enveloped (Optional) The Mesh profile 3167 EnvelopedActivationAccount: Enveloped (Optional) The activation of 3168 the device within the Mesh account 3170 11.4.20. Structure: CatalogedApplicationSSH 3172 Inherits: CatalogedApplication 3174 [No fields] 3176 11.4.21. Structure: CatalogedApplicationMail 3178 Inherits: CatalogedApplication 3180 [No fields] 3182 11.4.22. Structure: CatalogedApplicationNetwork 3184 Inherits: CatalogedApplication 3186 [No fields] 3188 11.5. Publications 3190 11.5.1. Structure: DevicePreconfiguration 3192 A data structure that is passed 3194 EnvelopedProfileDevice: Enveloped (Optional) The device profile 3196 EnvelopedConnectionDevice: Enveloped (Optional) The device 3197 connection 3199 ConnectUri: String (Optional) The connection URI. This would 3200 normally be printed on the device as a QR code. 3202 11.6. Messages 3204 11.6.1. Structure: Message 3206 MessageId: String (Optional) Unique per-message ID. When 3207 encapsulating a Mesh Message in a DARE envelope, the envelope 3208 EnvelopeID field MUST be a UDF fingerprint of the MessageId value. 3210 Sender: String (Optional) 3212 Recipient: String (Optional) 3214 11.6.2. Structure: MessageError 3216 Inherits: Message 3218 ErrorCode: String (Optional) 3220 11.6.3. Structure: MessageComplete 3222 Inherits: Message 3224 References: Reference [0..Many] 3226 11.6.4. Structure: MessagePinValidated 3228 Inherits: Message 3230 AuthenticatedData: DareEnvelope (Optional) Enveloped data that is 3231 authenticated by means of the PIN 3233 ClientNonce: Binary (Optional) Nonce provided by the client to 3234 validate the PIN 3236 PinId: String (Optional) Pin identifier value calculated from the 3237 PIN code, action and account address. 3239 PinWitness: Binary (Optional) Witness value calculated as KDF 3240 (Device.Udf + AccountAddress, ClientNonce) 3242 11.6.5. Structure: MessagePin 3244 Account: String (Optional) 3246 Inherits: Message 3247 Expires: DateTime (Optional) 3249 Automatic: Boolean (Optional) If true, authentication against the 3250 PIN code is sufficient to complete the associated action without 3251 further authorization. 3253 SaltedPin: String (Optional) PIN code bound to the specified action. 3255 Action: String (Optional) The action to which this PIN code is 3256 bound. 3258 11.6.6. Structure: RequestConnection 3260 Connection request message. This message contains the information 3262 Inherits: MessagePinValidated 3264 AccountAddress: String (Optional) 3266 11.6.7. Structure: AcknowledgeConnection 3268 Connection request message generated by a service on receipt of a 3269 valid MessageConnectionRequestClient 3271 Inherits: Message 3273 EnvelopedRequestConnection: Enveloped (Optional) The client 3274 connection request. 3276 ServerNonce: Binary (Optional) 3278 Witness: String (Optional) 3280 11.6.8. Structure: RespondConnection 3282 Respond to RequestConnection message to grant or refuse the 3283 connection request. 3285 Inherits: Message 3287 Result: String (Optional) The response to the request. One of 3288 "Accept", "Reject" or "Pending". 3290 CatalogedDevice: CatalogedDevice (Optional) The device information. 3291 MUST be present if the value of Result is "Accept". MUST be 3292 absent or null otherwise. 3294 11.6.9. Structure: MessageContact 3296 Inherits: MessagePinValidated 3298 Reply: Boolean (Optional) If true, requests that the recipient 3299 return their own contact information in reply. 3301 Subject: String (Optional) Optional explanation of the reason for 3302 the request. 3304 PIN: String (Optional) One time authentication code supplied to a 3305 recipient to allow authentication of the response. 3307 11.6.10. Structure: GroupInvitation 3309 Inherits: Message 3311 Text: String (Optional) 3313 11.6.11. Structure: RequestConfirmation 3315 Inherits: Message 3317 Text: String (Optional) 3319 11.6.12. Structure: ResponseConfirmation 3321 Inherits: Message 3323 Request: Enveloped (Optional) 3325 Accept: Boolean (Optional) 3327 11.6.13. Structure: RequestTask 3329 Inherits: Message 3331 [No fields] 3333 11.6.14. Structure: MessageClaim 3335 Inherits: Message 3337 PublicationId: String (Optional) 3339 ServiceAuthenticate: String (Optional) 3341 DeviceAuthenticate: String (Optional) 3342 Expires: DateTime (Optional) 3344 11.6.15. Structure: ProcessResult 3346 For future use, allows logging of operations and results 3348 Inherits: Message 3350 Success: Boolean (Optional) 3352 ErrorReport: String (Optional) The error report code. 3354 12. Security Considerations 3356 The security considerations for use and implementation of Mesh 3357 services and applications are described in the Mesh Security 3358 Considerations guide [draft-hallambaker-mesh-security]. 3360 13. IANA Considerations 3362 All the IANA considerations for the Mesh documents are specified in 3363 this document 3365 14. Acknowledgements 3367 A list of people who have contributed to the design of the Mesh is 3368 presented in [draft-hallambaker-mesh-architecture]. 3370 15. Appendix A: Example Container Organization (not normative) 3372 The means by which profiles are stored on devices is outside the 3373 scope of the specification. Only catalogs that are required to be 3374 shared between machines by means of accounts need to be standardized. 3376 15.1. Device 3378 Host Catalog: Host.dare Catalog of all the Mesh Profiles that the 3379 user has registered with the device and the latest version of the 3380 device profile for this device. 3382 MeshCatalog: [UDF-Mesh].dcat Catalog containing the Account Entries 3383 for the Mesh [UDF-Mesh]. 3385 Account Catalogs: [UDF-Account]/mmm_Device.dcat The device catalog 3386 associated with the specified account 3388 Account Catalogs: [UDF-Account]/[Catalog name].dcat The set of 3389 account catalogs that are shared verbatim between the devices 3390 connected to the account. 3392 15.1.1. Creating a new Mesh 3394 Create new Mesh Profile, Device Profile, Add to Host Catalog 3396 Create MeshCatalog 3398 15.1.2. Adding an Account 3400 Create new Account Profile, Add to MeshCatalog 3402 Create new Account Device Catalog 3404 For each device to be added to the account: Create Account Connection 3405 Assertion, add to Account Device Catalog. 3407 15.1.3. Adding a Device 3409 Create a Device Connection Assertion. 3411 For each account the device is to be added to: Create Account 3412 Connection Assertion, add to Account Device Catalog. 3414 15.2. Service 3416 Master Catalog Catalog of all services on machine 3418 Service Catalog Catalog of accounts in the service. 3420 15.2.1. Creating a Service 3422 Create a Service Description, add to Master Catalog 3424 15.2.2. Adding an Account 3426 Create the account entry, add to Service Catalog 3428 Create the Account Directory 3430 16. Appendix B: Collected Authentication and Encryption Requirements 3431 16.1. Mesh Messaging 3433 +=======================+=========+==================+ 3434 | Message | Signer | Recipients | 3435 +=======================+=========+==================+ 3436 | RequestConnection | Device | Service | 3437 +-----------------------+---------+------------------+ 3438 | AcknowledgeConnection | Service | Device, Receiver | 3439 +-----------------------+---------+------------------+ 3440 | OfferGroup | Sender | Receiver | 3441 +-----------------------+---------+------------------+ 3442 | RequestContact | Sender | Receiver | 3443 +-----------------------+---------+------------------+ 3444 | ReplyContact | Sender | Receiver | 3445 +-----------------------+---------+------------------+ 3446 | RequestConfirmation | Sender | Receiver | 3447 +-----------------------+---------+------------------+ 3448 | ResponseConfirmation | Sender | Receiver | 3449 +-----------------------+---------+------------------+ 3450 | RequestTask | Sender | Receiver | 3451 +-----------------------+---------+------------------+ 3452 | ResponseTask | Sender | Receiver | 3453 +-----------------------+---------+------------------+ 3455 Table 2 3457 17. Normative References 3459 [draft-hallambaker-mesh-architecture] 3460 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 3461 Architecture Guide", Work in Progress, Internet-Draft, 3462 draft-hallambaker-mesh-architecture-14, 27 July 2020, 3463 . 3466 [draft-hallambaker-mesh-cryptography] 3467 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VIII: 3468 Cryptographic Algorithms", Work in Progress, Internet- 3469 Draft, draft-hallambaker-mesh-cryptography-06, 27 July 3470 2020, . 3473 [draft-hallambaker-mesh-discovery] 3474 "[Reference Not Found!]". 3476 [draft-hallambaker-mesh-notary] 3477 "[Reference Not Found!]". 3479 [draft-hallambaker-mesh-protocol] 3480 Hallam-Baker, P., "Mathematical Mesh 3.0 Part V: Protocol 3481 Reference", Work in Progress, Internet-Draft, draft- 3482 hallambaker-mesh-protocol-06, 27 July 2020, 3483 . 3486 [draft-hallambaker-mesh-security] 3487 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 3488 Security Considerations", Work in Progress, Internet- 3489 Draft, draft-hallambaker-mesh-security-05, 27 July 2020, 3490 . 3493 [draft-hallambaker-mesh-udf] 3494 Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform 3495 Data Fingerprint.", Work in Progress, Internet-Draft, 3496 draft-hallambaker-mesh-udf-10, 27 July 2020, 3497 . 3500 [draft-hallambaker-threshold] 3501 Hallam-Baker, P., "Threshold Modes in Elliptic Curves", 3502 Work in Progress, Internet-Draft, draft-hallambaker- 3503 threshold-03, 3 September 2020, 3504 . 3507 [draft-hallambaker-threshold-sigs] 3508 Hallam-Baker, P., "Threshold Signatures in Elliptic 3509 Curves", Work in Progress, Internet-Draft, draft- 3510 hallambaker-threshold-sigs-04, 3 September 2020, 3511 . 3514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3515 Requirement Levels", BCP 14, RFC 2119, 3516 DOI 10.17487/RFC2119, March 1997, 3517 . 3519 18. Informative References 3521 [draft-hallambaker-mesh-developer] 3522 Hallam-Baker, P., "Mathematical Mesh: Reference 3523 Implementation", Work in Progress, Internet-Draft, draft- 3524 hallambaker-mesh-developer-10, 27 July 2020, 3525 . 3528 [draft-hallambaker-mesh-trust] 3529 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VI: The 3530 Trust Mesh", Work in Progress, Internet-Draft, draft- 3531 hallambaker-mesh-trust-06, 27 July 2020, 3532 . 3535 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 3536 RFC 2426, DOI 10.17487/RFC2426, September 1998, 3537 . 3539 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 3540 Core Object Specification (iCalendar)", RFC 5545, 3541 DOI 10.17487/RFC5545, September 2009, 3542 .