idnits 2.17.1 draft-hallambaker-mesh-reference-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 18, 2017) is 2436 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1194 -- Looks like a reference, but probably isn't: '1' on line 1199 == Missing Reference: 'None' is mentioned on line 2145, but not defined == Unused Reference: 'RFC6335' is defined on line 2204, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 2222, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational August 18, 2017 5 Expires: February 19, 2018 7 Mathematical Mesh: Reference 8 draft-hallambaker-mesh-reference-05 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 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 19, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 57 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 58 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Creating a new portal account . . . . . . . . . . . . . . 5 60 3.1.1. Checking Account Identifier for uniqueness . . . . . 5 61 3.2. Creating a new user profile . . . . . . . . . . . . . . . 6 62 3.2.1. Publishing a new user profile . . . . . . . . . . . . 13 63 3.3. Connecting a device profile to a user profile . . . . . . 15 64 3.3.1. Profile Authentication . . . . . . . . . . . . . . . 17 65 3.3.2. Connection request . . . . . . . . . . . . . . . . . 20 66 3.3.3. Administrator Polls Pending Connections . . . . . . . 21 67 3.3.4. Administrator updates and publishes the personal 68 profile. . . . . . . . . . . . . . . . . . . . . . . 23 69 3.3.5. Administrator posts completion request. . . . . . . . 24 70 3.3.6. Connecting device polls for status update. . . . . . 25 71 3.4. Adding an application profile to a user profile . . . . . 26 72 3.5. Creating a recovery profile . . . . . . . . . . . . . . . 27 73 3.6. Recovering a profile . . . . . . . . . . . . . . . . . . 28 74 4. Shared Classes . . . . . . . . . . . . . . . . . . . . . . . 28 75 4.1. Cryptographic Data Classes . . . . . . . . . . . . . . . 28 76 4.1.1. Structure: PublicKey . . . . . . . . . . . . . . . . 28 77 4.1.2. Structure: SignedData . . . . . . . . . . . . . . . . 29 78 4.1.3. Structure: EncryptedData . . . . . . . . . . . . . . 29 79 4.2. Common Application Classes . . . . . . . . . . . . . . . 29 80 4.2.1. Structure: Connection . . . . . . . . . . . . . . . . 29 81 5. Mesh Profile Objects . . . . . . . . . . . . . . . . . . . . 30 82 5.1. Base Profile Objects . . . . . . . . . . . . . . . . . . 30 83 5.1.1. Structure: Entry . . . . . . . . . . . . . . . . . . 30 84 5.1.2. Structure: SignedProfile . . . . . . . . . . . . . . 30 85 5.1.3. Structure: Advice . . . . . . . . . . . . . . . . . . 31 86 5.1.4. Structure: PortalAdvice . . . . . . . . . . . . . . . 31 87 5.1.5. Structure: Profile . . . . . . . . . . . . . . . . . 31 88 5.2. Device Profile Classes . . . . . . . . . . . . . . . . . 32 89 5.2.1. Structure: SignedDeviceProfile . . . . . . . . . . . 32 90 5.2.2. Structure: DeviceProfile . . . . . . . . . . . . . . 32 91 5.2.3. Structure: DevicePrivateProfile . . . . . . . . . . . 32 92 5.3. Master Profile Objects . . . . . . . . . . . . . . . . . 33 93 5.3.1. Structure: SignedMasterProfile . . . . . . . . . . . 33 94 5.3.2. Structure: MasterProfile . . . . . . . . . . . . . . 33 95 5.4. Personal Profile Objects . . . . . . . . . . . . . . . . 33 96 5.4.1. Structure: SignedPersonalProfile . . . . . . . . . . 33 97 5.4.2. Structure: PersonalProfile . . . . . . . . . . . . . 34 98 5.4.3. Structure: ApplicationProfileEntry . . . . . . . . . 34 99 5.5. Application Profile Objects . . . . . . . . . . . . . . . 35 100 5.5.1. Structure: SignedApplicationProfile . . . . . . . . . 35 101 5.5.2. Structure: ApplicationProfile . . . . . . . . . . . . 35 102 5.5.3. Structure: ApplicationProfilePrivate . . . . . . . . 35 103 5.5.4. Structure: ApplicationDevicePublic . . . . . . . . . 35 104 5.5.5. Structure: ApplicationDevicePrivate . . . . . . . . . 35 105 5.6. Key Escrow Objects . . . . . . . . . . . . . . . . . . . 36 106 5.6.1. Structure: EscrowEntry . . . . . . . . . . . . . . . 36 107 5.6.2. Structure: OfflineEscrowEntry . . . . . . . . . . . . 36 108 5.6.3. Structure: OnlineEscrowEntry . . . . . . . . . . . . 36 109 5.6.4. Structure: EscrowedKeySet . . . . . . . . . . . . . . 36 110 6. Portal Connection . . . . . . . . . . . . . . . . . . . . . . 36 111 6.1. Connection Request and Response Structures . . . . . . . 36 112 6.1.1. Structure: ConnectionRequest . . . . . . . . . . . . 36 113 6.1.2. Structure: SignedConnectionRequest . . . . . . . . . 37 114 6.1.3. Structure: ConnectionResult . . . . . . . . . . . . . 37 115 6.1.4. Structure: SignedConnectionResult . . . . . . . . . . 37 116 7. Mesh Portal Service Reference . . . . . . . . . . . . . . . . 37 117 7.1. Request Messages . . . . . . . . . . . . . . . . . . . . 38 118 7.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 38 119 7.2. Response Messages . . . . . . . . . . . . . . . . . . . . 38 120 7.2.1. Message: MeshResponse . . . . . . . . . . . . . . . . 38 121 7.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 38 122 7.4. Common Structures . . . . . . . . . . . . . . . . . . . . 38 123 7.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . . 38 124 7.4.2. Structure: SearchConstraints . . . . . . . . . . . . 39 125 7.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 39 126 7.6. Transaction: ValidateAccount . . . . . . . . . . . . . . 40 127 7.6.1. Message: ValidateRequest . . . . . . . . . . . . . . 40 128 7.6.2. Message: ValidateResponse . . . . . . . . . . . . . . 40 129 7.7. Transaction: CreateAccount . . . . . . . . . . . . . . . 41 130 7.7.1. Message: CreateRequest . . . . . . . . . . . . . . . 41 131 7.7.2. Message: CreateResponse . . . . . . . . . . . . . . . 42 132 7.8. Transaction: DeleteAccount . . . . . . . . . . . . . . . 42 133 7.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 42 134 7.8.2. Message: DeleteResponse . . . . . . . . . . . . . . . 42 135 7.9. Transaction: Get . . . . . . . . . . . . . . . . . . . . 42 136 7.9.1. Message: GetRequest . . . . . . . . . . . . . . . . . 43 137 7.9.2. Message: GetResponse . . . . . . . . . . . . . . . . 43 138 7.10. Transaction: Publish . . . . . . . . . . . . . . . . . . 44 139 7.10.1. Message: PublishRequest . . . . . . . . . . . . . . 44 140 7.10.2. Message: PublishResponse . . . . . . . . . . . . . . 44 141 7.11. Transaction: Status . . . . . . . . . . . . . . . . . . . 44 142 7.11.1. Message: StatusRequest . . . . . . . . . . . . . . . 44 143 7.11.2. Message: StatusResponse . . . . . . . . . . . . . . 45 144 7.12. Transaction: ConnectStart . . . . . . . . . . . . . . . . 45 145 7.12.1. Message: ConnectStartRequest . . . . . . . . . . . . 45 146 7.12.2. Message: ConnectStartResponse . . . . . . . . . . . 46 147 7.13. Transaction: ConnectStatus . . . . . . . . . . . . . . . 46 148 7.13.1. Message: ConnectStatusRequest . . . . . . . . . . . 46 149 7.13.2. Message: ConnectStatusResponse . . . . . . . . . . . 46 150 7.14. Transaction: ConnectPending . . . . . . . . . . . . . . . 46 151 7.14.1. Message: ConnectPendingRequest . . . . . . . . . . . 47 152 7.14.2. Message: ConnectPendingResponse . . . . . . . . . . 47 153 7.15. Transaction: ConnectComplete . . . . . . . . . . . . . . 47 154 7.15.1. Message: ConnectCompleteRequest . . . . . . . . . . 47 155 7.15.2. Message: ConnectCompleteResponse . . . . . . . . . . 48 156 7.16. Transaction: Transfer . . . . . . . . . . . . . . . . . . 48 157 7.16.1. Message: TransferRequest . . . . . . . . . . . . . . 48 158 7.16.2. Message: TransferResponse . . . . . . . . . . . . . 48 159 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 160 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 161 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 162 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 163 11.1. Normative References . . . . . . . . . . . . . . . . . . 49 164 11.2. Informative References . . . . . . . . . . . . . . . . . 49 165 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 167 1. Introduction 169 NB: The reference material in this document is generated from the 170 schema used to derive the source code. The tool used to create this 171 material has not been optimized to produce output for the IETF 172 documentation format at this time. Consequently, the formatting is 173 currently sub-optimal. 175 2. Definitions 177 This section presents the related specifications and standard, the 178 terms that are used as terms of art within the documents and the 179 terms used as requirements language. 181 2.1. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119] [RFC2119] . 187 2.2. Defined Terms 189 The terms of art used in this document are described in the Mesh 190 Architecture Guide [draft-hallambaker-mesh-architecture] 191 [draft-hallambaker-mesh-architecture] . 193 2.3. Related Specifications 195 The architecture of the Mathematical Mesh is described in the Mesh 196 Architecture Guide [draft-hallambaker-mesh-architecture] 197 [draft-hallambaker-mesh-architecture] . The Mesh documentation set 198 and related specifications are described in this document. 200 2.4. Implementation Status 202 The implementation status of the reference code base is described in 203 the companion document [draft-hallambaker-mesh-developer] 204 [draft-hallambaker-mesh-developer] . 206 3. Protocol Overview 208 [Account request does not specify the portal in the request body, 209 only the HTTP package includes this information. This is probably a 210 bug.] 212 3.1. Creating a new portal account 214 A user interacts with a Mesh service through a Mesh portal provider 215 with which she establishes a portal account. 217 For user convenience, a portal account identifier has the familiar 218 @ format established in [~RFC822]. 220 For example Alice selects example.com as her portal provider and 221 chooses the account name alice. Her portal account identifier is 222 alice. 224 A user MAY establish accounts with multiple portal providers and/or 225 change their portal provider at any time they choose. 227 3.1.1. Checking Account Identifier for uniqueness 229 The first step in creating a new account is to check to see if the 230 chosen account identifier is available. This allows a client to 231 validate user input and if necessary warn the user that they need to 232 choose a new account identifier when the data is first entered. 234 The ValidateRequest message contains the requested account identifier 235 and an optional language parameter to allow the service to provide 236 informative error messages in a language the user understands. The 237 Language field contains a list of ISO language identifier codes in 238 order of preference, most preferred first. 240 POST /.well-known/mmm/HTTP/1.1 241 Host: example.com 242 Content-Length: 90 244 { 245 "ValidateRequest": { 246 "Account": "test@prismproof.org", 247 "Language": ["en-uk"]}} 249 Figure 1 251 The ValidateResponse message returns the result of the validation 252 request in the Valid field. Note that even if the value true is 253 returned, a subsequent account creation request MAY still fail. 255 HTTP/1.1 200 OK 256 Date: Sat 19 Aug 2017 01:29:33 257 Content-Length: 190 259 { 260 "ValidateResponse": { 261 "Status": 201, 262 "StatusDescription": "Operation completed successfully", 263 "Valid": true, 264 "Minimum": 1, 265 "InvalidCharacters": ".,:;{}()[]<>?|\\@#"}} 267 Figure 2 269 [Note that for the sake of concise presentation, the HTTP binding 270 information is omitted from future examples.] 272 3.2. Creating a new user profile 274 The first step in creating a new personal profile is to create a 275 Master Profile object. This contains the long term Master Signing 276 Key that will remain constant for the life of the profile, at least 277 one Online Signature Key to be used for administering the personal 278 profile and (optionally), one or more master escrow keys. 280 For convenience, the descriptions of the Master Signing Key, Online 281 Signing Keys and Escrow Keys typically include PKIX certificates 282 signed by the Master Signing Key. This allows PKIX based applications 283 to make use of PKIX certificate chains to express the same trust 284 relationships described in the Mesh. 286 { 287 "MasterProfile": { 288 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 289 "MasterSignatureKey": { 290 "UDF": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 291 "X509Certificate": " 292 MIIFXTCCBEWgAwIBAgIRAOTDeMIxZ2CZjzhjGSSFbWEwDQYJKoZIhvcNAQENBQAw 293 LjEsMCoGA1UEAxYjTUM3V1YtUlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4w 294 ... 295 GoMqzbUEN8B8Jici8tmiLAbw7vhXSGxmlB3TTZyRneIQ" 296 , 297 "PublicParameters": { 298 "PublicKeyRSA": { 299 "kid": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 300 "n": " 301 mgP7xdMUiyMMSLKXvx01_5ztGN5Sxp_u92V6u5o_UEzz9Jk-m0bf5k9RPqf8lzGn 302 Y_rYm3MT648v_3KbEOvU7Kw2evC_b8kdpnkUJdDY5T0mWrLKlHLFBHvG-77MVDY6 303 P4gLqRQo48AB5FIiLPPig2KpMdgL7KBozDeLtHySd6RJJR8F_S5TXGdLTE0znx8X 304 fVo7WgAvWvSjZF4DBBFVD5fVmaqhDLv1dx_ZwmEL9Et2fZAAHR7jATZaN_wWnutl 305 6YHqSxTVpp6yaS4zkOPB4Ttdlge3EOWr9Zbze0S9kMIHoVE4MXp3RPAbgYhaaCkU 306 YZKmXNhJK8Wqgs6eaOa17Q" 307 , 308 "e": " 309 AQAB" 310 }}}, 311 "MasterEscrowKeys": [{ 312 "UDF": "MAYGU-KOZIK-U7ZFR-WNSG5-I5N75-HWCZQ", 313 "X509Certificate": " 314 MIIFXTCCBEWgAwIBAgIRAIJ_5SV70cXF3CFbLzfdiW4wDQYJKoZIhvcNAQENBQAw 315 LjEsMCoGA1UEAxYjTUM3V1YtUlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4w 316 ... 317 F1dm2JNIyvjGgHHLRfEb5CdAcxHeWW9LiVuA-i8ysbhn" 318 , 319 "PublicParameters": { 320 "PublicKeyRSA": { 321 "kid": "MAYGU-KOZIK-U7ZFR-WNSG5-I5N75-HWCZQ", 322 "n": " 323 zzeXpXZTHcCybpgByPzvdVPfjd7we3MI1AmKAFiQmZJxePhnOff2fBdJm8H3O2Ga 324 SmhgOgeoURGC3ZmOtABoYC2K9vqvu-zQbcic8Qh5TqS9MGIJAV4gzG_xTRkX8ehV 325 MaUnPBP2_eapGthgBXNO0Tx-b1FIKmLvUC76QI2M-R2_V6OuoyGsob27mTW8zLEJ 326 F2fSZUUHWvWPmDajk_SJBR7owdVVNR0GEh20TOl08BvOqg9g-9bAX8LPiMp8T2PC 327 EmqC5x3BsInOEpzMIjAiWQkXTIvm5bZRMh20GDsLqRPzVxY2gu3P0vxKd4qpwJxI 328 Rl_HdBsqmRC3khtp8ONZ6Q" 329 , 330 "e": " 331 AQAB" 332 }}}], 333 "OnlineSignatureKeys": [{ 334 "UDF": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI", 335 "X509Certificate": " 337 MIIFXDCCBESgAwIBAgIQWP5WHkoX9RH33gRvG1WR4zANBgkqhkiG9w0BAQ0FADAu 338 MSwwKgYDVQQDFiNNQzdXVi1SVlhTSy1WUUFBUS00VURYVC00NE1ZRy1TWlpQTjAe 339 ... 340 yc-hLXmMaNlKgW_jIcY5lodRjxQ3VQfgr6g9II-jWeY" 341 , 342 "PublicParameters": { 343 "PublicKeyRSA": { 344 "kid": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI", 345 "n": " 346 ooX--9-NAkimIZU57kKh4WcRrXztA8FYvNWz7Ja33yZBhOhHegU4WlHF5TZM2c20 347 Jcr7nCi1NEzr-grWnNs36AKgLOZdY1RfcYPEnpftldUpbr776a8n1gWNKtUPC8oW 348 xV3FHZvFpzXNe3qVEoVoRH5947SNSIfG1i3iSlwwMDIFIDQ6_SRFXxMZ_jEbFrbS 349 NpNDC4ZXNlghbEmFfetPtqtjXMYskZsZd7gdUw3SLExQF7e6ubk-a-zNsZO0MgB- 350 D_HAYtEWafCZ8pfkJEMxWeIQKCGRTe6ACh1Hczj2dKuvIobgamGJyo-xIPF-Bn96 351 EHIUh2Mv57zMgayJIxTZMQ" 352 , 353 "e": " 354 AQAB" 355 }}}]}} 357 Figure 3 359 The Master Profile is always signed using the Master Signing Key: 361 { 362 "SignedMasterProfile": { 363 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 364 "SignedData": { 365 "unprotected": { 366 "dig": "S512"}, 367 "payload": " 368 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUM3V1Yt 369 UlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4iLAogICAgIk1hc3RlclNpZ25h 370 ... 371 QiJ9fX1dfX0" 372 , 373 "signatures": [{ 374 "header": { 375 "kid": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN"}, 376 "protected": " 377 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmdqSE9hYjM4SHZUNUhZd3l2 378 NEc0cFVuRVlDMUZQUzUtLTZEQ19XOUM0UDgwbGhYWXl1M2p0cFNoNkMyWHFTN0kK 379 QUwyaWhPaGEtcXBiUlpJNDJnM2h2USJ9" 380 , 381 "signature": " 382 HFcnfDnxT_2epMRm_yUf1bjLeaIc6TmLaHkJPQWZFqWDVH4UZmeAi0NJxmEWZQ56 383 PEgsBIAfGaONbaqPeY6DFr9acQreAEEubBvkRuFo7KDAl2e1t91T2Cb3PcEcMtEM 384 OOjs2e-VOBZm-PNgZUeJ_EtoDACW-Cq6LBML-1sMCRG7VE8rK-T7N6AgSBPMehG4 385 AIIGUQAuTJcpxyafH5CWASEFpzzl3cWy9jY0Ip1X5J_OkwOkJS5lGWgHW3VLHKPD 386 ns04-I_41ZJBeExHlIYexIN8A37CAhs6_8kn-7xLePS-_FsvPoJHmotsjflQy6H3 387 LTOVO3SN3yRwRyiGMDMkVg" 388 }]}}} 390 Figure 4 392 Since the device used to create the personal profile is typically 393 connected to the profile, a Device profile entry is created for it. 394 This contains a Device Signing Key, a Device Encryption Key and a 395 Device Authentication Key: 397 { 398 "JoseWebSignature": { 399 "unprotected": { 400 "dig": "S512"}, 401 "payload": " 402 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFOR0gt 403 TzRBNVUtWEVSMzItSjNJUE8tS0RHM0ctV01ZU0MiLAogICAgIk5hbWVzIjogWyJE 404 ... 405 UlVLakRRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 406 , 407 "signatures": [{ 408 "header": { 409 "kid": "MANGH-O4A5U-XER32-J3IPO-KDG3G-WMYSC"}, 410 "protected": " 411 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiClg0alV1OEF1RXdkbnllZzNJ 412 c01ZdFpNNUdDV2U4V0s4OHplOWVDZFl1emRVZW1EQWVtOF9mZDhaTWtNa2JDTTEK 413 U1ZCajMyc0ZvM0k0Y3R4VlBLdUZTQSJ9" 414 , 415 "signature": " 416 ZwDQQrMxeiYgRvArdztwsdEYxrQciSv6dAijVHxhgY84YWPHVAVBuQSNqQ5kf8IQ 417 Rh1vkclw_4bM7E3SAkMwP6hVVEy-ApLwA_C8GcUFfCq0OyGUQjm1w9lp7fNmuGEx 418 CnMLPBTM0jTTKJaEOYTYVUx17WGNgT4Uj3nVmXmyEo1wCMOuv4Ihncg7RV2QEmvq 419 XRAey8umSywia7vbusWNV4eQ2ha41xuVfd-N7cpQCDXw1ZW-PawMStf_knD2Q0T6 420 CRj7y3pOq1yJvHW_3H-z7YnalRLpAEupvzKovt68fEl9ZROvHk1XEuMhqo8TwVQU 421 QDRTMCZFvdndRNwVCbvaFg" 422 }]}} 424 Figure 5 426 The Device Profile is signed using the Device Signing Key: 428 { 429 "SignedDeviceProfile": { 430 "Identifier": "MANGH-O4A5U-XER32-J3IPO-KDG3G-WMYSC", 431 "SignedData": { 432 "unprotected": { 433 "dig": "S512"}, 434 "payload": " 435 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFOR0gt 436 TzRBNVUtWEVSMzItSjNJUE8tS0RHM0ctV01ZU0MiLAogICAgIk5hbWVzIjogWyJE 437 ... 438 UlVLakRRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 439 , 440 "signatures": [{ 441 "header": { 442 "kid": "MANGH-O4A5U-XER32-J3IPO-KDG3G-WMYSC"}, 443 "protected": " 444 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiClg0alV1OEF1RXdkbnllZzNJ 445 c01ZdFpNNUdDV2U4V0s4OHplOWVDZFl1emRVZW1EQWVtOF9mZDhaTWtNa2JDTTEK 446 U1ZCajMyc0ZvM0k0Y3R4VlBLdUZTQSJ9" 447 , 448 "signature": " 449 ZwDQQrMxeiYgRvArdztwsdEYxrQciSv6dAijVHxhgY84YWPHVAVBuQSNqQ5kf8IQ 450 Rh1vkclw_4bM7E3SAkMwP6hVVEy-ApLwA_C8GcUFfCq0OyGUQjm1w9lp7fNmuGEx 451 CnMLPBTM0jTTKJaEOYTYVUx17WGNgT4Uj3nVmXmyEo1wCMOuv4Ihncg7RV2QEmvq 452 XRAey8umSywia7vbusWNV4eQ2ha41xuVfd-N7cpQCDXw1ZW-PawMStf_knD2Q0T6 453 CRj7y3pOq1yJvHW_3H-z7YnalRLpAEupvzKovt68fEl9ZROvHk1XEuMhqo8TwVQU 454 QDRTMCZFvdndRNwVCbvaFg" 455 }]}}} 457 Figure 6 459 A personal profile would typically contain at least one application 460 when first created. For the sake of demonstration, we will do this 461 later. 463 The personal profile thus consists of the master profile and the 464 device profile: 466 { 467 "PersonalProfile": { 468 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 469 "SignedMasterProfile": { 470 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 471 "SignedData": { 472 "unprotected": { 473 "dig": "S512"}, 474 "payload": " 475 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUM3V1Yt 476 UlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4iLAogICAgIk1hc3RlclNpZ25h 477 ... 478 QiJ9fX1dfX0" 479 , 480 "signatures": [{ 481 "header": { 482 "kid": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN"}, 483 "protected": " 484 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmdqSE9hYjM4SHZUNUhZd3l2 485 NEc0cFVuRVlDMUZQUzUtLTZEQ19XOUM0UDgwbGhYWXl1M2p0cFNoNkMyWHFTN0kK 486 QUwyaWhPaGEtcXBiUlpJNDJnM2h2USJ9" 487 , 488 "signature": " 489 HFcnfDnxT_2epMRm_yUf1bjLeaIc6TmLaHkJPQWZFqWDVH4UZmeAi0NJxmEWZQ56 490 PEgsBIAfGaONbaqPeY6DFr9acQreAEEubBvkRuFo7KDAl2e1t91T2Cb3PcEcMtEM 491 OOjs2e-VOBZm-PNgZUeJ_EtoDACW-Cq6LBML-1sMCRG7VE8rK-T7N6AgSBPMehG4 492 AIIGUQAuTJcpxyafH5CWASEFpzzl3cWy9jY0Ip1X5J_OkwOkJS5lGWgHW3VLHKPD 493 ns04-I_41ZJBeExHlIYexIN8A37CAhs6_8kn-7xLePS-_FsvPoJHmotsjflQy6H3 494 LTOVO3SN3yRwRyiGMDMkVg" 495 }]}}, 496 "Devices": [{ 497 "Identifier": "MANGH-O4A5U-XER32-J3IPO-KDG3G-WMYSC", 498 "SignedData": { 499 "unprotected": { 500 "dig": "S512"}, 501 "payload": " 502 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFOR0gt 503 TzRBNVUtWEVSMzItSjNJUE8tS0RHM0ctV01ZU0MiLAogICAgIk5hbWVzIjogWyJE 504 ... 505 UlVLakRRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 506 , 507 "signatures": [{ 508 "header": { 509 "kid": "MANGH-O4A5U-XER32-J3IPO-KDG3G-WMYSC"}, 510 "protected": " 511 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiClg0alV1OEF1RXdkbnllZzNJ 512 c01ZdFpNNUdDV2U4V0s4OHplOWVDZFl1emRVZW1EQWVtOF9mZDhaTWtNa2JDTTEK 513 U1ZCajMyc0ZvM0k0Y3R4VlBLdUZTQSJ9" 514 , 515 "signature": " 516 ZwDQQrMxeiYgRvArdztwsdEYxrQciSv6dAijVHxhgY84YWPHVAVBuQSNqQ5kf8IQ 517 Rh1vkclw_4bM7E3SAkMwP6hVVEy-ApLwA_C8GcUFfCq0OyGUQjm1w9lp7fNmuGEx 518 CnMLPBTM0jTTKJaEOYTYVUx17WGNgT4Uj3nVmXmyEo1wCMOuv4Ihncg7RV2QEmvq 519 XRAey8umSywia7vbusWNV4eQ2ha41xuVfd-N7cpQCDXw1ZW-PawMStf_knD2Q0T6 520 CRj7y3pOq1yJvHW_3H-z7YnalRLpAEupvzKovt68fEl9ZROvHk1XEuMhqo8TwVQU 521 QDRTMCZFvdndRNwVCbvaFg" 522 }]}}], 523 "Applications": []}} 524 Figure 7 526 The personal profile is then signed using the Online Signing Key: 528 { 529 "SignedPersonalProfile": { 530 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 531 "SignedData": { 532 "unprotected": { 533 "dig": "S512"}, 534 "payload": " 535 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQzdX 536 Vi1SVlhTSy1WUUFBUS00VURYVC00NE1ZRy1TWlpQTiIsCiAgICAiU2lnbmVkTWFz 537 ... 538 aW9ucyI6IFtdfX0" 539 , 540 "signatures": [{ 541 "header": { 542 "kid": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI"}, 543 "protected": " 544 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjk4MEhfWnp3emxzeWtLQ0lF 545 N1pBRUo5Z2dMRTc5cTRyQ3IwRjMwaVp2S1lKTldnaWlhTmdKOEhfZmFPbGZFWHkK 546 YXoyNmdFQmtsbS1VTTdUMDJpVjJ0QSJ9" 547 , 548 "signature": " 549 aS--SDvXmNWvwpWkbvhSAQOWX0B5IOGf93RpLX-QE8PYEGbORkd155Mg0Vl7QBhG 550 UhQlCAd4R-pDN3-1rE5YP0OXHCwG44nXBgap-IqZ6ZPAvSOS6AruMqLsJLGmtYPK 551 4mdY8ZLnrwM88C0EgqsVhv_T2D0-roAImUHIqNu-9vJh3tL1jRqfubDappHWnF3S 552 9FiIK-cS_5Zo_ZB5OTSq_RJWCFmTXAK23onQ0cyJEq52cCF39KL5wKDQ3FcmEdTq 553 SInUgfB6gJ5zkibWJIZWwR3HZqmi-2fNFCqimgNN1cvk2fzaA5c-AnRhQOTlXI1D 554 nqRrjDbDLB2LdU_GLVarIg" 555 }]}}} 557 Figure 8 559 3.2.1. Publishing a new user profile 561 Once the signed personal profile is created, the client can finaly 562 make the request for the service to create the account. The request 563 object contains the requested account identifier and profile: 565 { 566 "CreateRequest": { 567 "Account": "test@prismproof.org", 568 "Profile": { 569 "SignedPersonalProfile": { 570 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 571 "SignedData": { 572 "unprotected": { 573 "dig": "S512"}, 574 "payload": " 575 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQzdX 576 Vi1SVlhTSy1WUUFBUS00VURYVC00NE1ZRy1TWlpQTiIsCiAgICAiU2lnbmVkTWFz 577 ... 578 aW9ucyI6IFtdfX0" 579 , 580 "signatures": [{ 581 "header": { 582 "kid": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI"}, 583 "protected": " 584 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjk4MEhfWnp3emxzeWtLQ0lF 585 N1pBRUo5Z2dMRTc5cTRyQ3IwRjMwaVp2S1lKTldnaWlhTmdKOEhfZmFPbGZFWHkK 586 YXoyNmdFQmtsbS1VTTdUMDJpVjJ0QSJ9" 587 , 588 "signature": " 589 aS--SDvXmNWvwpWkbvhSAQOWX0B5IOGf93RpLX-QE8PYEGbORkd155Mg0Vl7QBhG 590 UhQlCAd4R-pDN3-1rE5YP0OXHCwG44nXBgap-IqZ6ZPAvSOS6AruMqLsJLGmtYPK 591 4mdY8ZLnrwM88C0EgqsVhv_T2D0-roAImUHIqNu-9vJh3tL1jRqfubDappHWnF3S 592 9FiIK-cS_5Zo_ZB5OTSq_RJWCFmTXAK23onQ0cyJEq52cCF39KL5wKDQ3FcmEdTq 593 SInUgfB6gJ5zkibWJIZWwR3HZqmi-2fNFCqimgNN1cvk2fzaA5c-AnRhQOTlXI1D 594 nqRrjDbDLB2LdU_GLVarIg" 595 }]}}}}} 597 Figure 9 599 The service reports the success (or failure) of the account creation 600 request: 602 { 603 "CreateResponse": { 604 "Status": 201, 605 "StatusDescription": "Operation completed successfully"}} 607 Figure 10 609 3.3. Connecting a device profile to a user profile 611 Connecting a device to a profile requires the client on the new 612 device to interact with a client on a device that has administration 613 capabilities, i.e. it has access to an Online Signing Key. Since 614 clients cannot interact directly with other clients, a service is 615 required to mediate the connection. This service is provided by a 616 Mesh portal provider. 618 All service transactions are initiated by the clients. First the 619 connecting device posts ConnectStart, after which it may poll for the 620 outcome of the connection request using ConnectStatus. 622 Periodically, the Administration Device polls for a list of pending 623 connection requests using ConnectPending. After posting a request, 624 the administration device posts the result using ConnectComplete: 626 Connecting Mesh Administration 627 Device Service Device 629 | | | 630 | ConnectStart | | 631 | ----------------------> | | 632 | | ConnectPending | 633 | | <---------------------- | 634 | | | 635 | | ConnectComplete | 636 | | <---------------------- | 637 | ConnectStatus | | 638 | ----------------------> | | 640 Figure 11 642 The first step in the process is for the client to generate a device 643 profile. Ideally the device profile is bound to the device in a 644 read-only fashion such that applications running on the device can 645 make use of the deencryption and authentication keys but these 646 private keys cannot be extracted from the device: 648 { 649 "DeviceProfile": { 650 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 651 "Names": ["Default"], 652 "Description": "Unknown", 653 "DeviceSignatureKey": { 654 "UDF": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 655 "PublicParameters": { 656 "PublicKeyRSA": { 657 "kid": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 658 "n": " 659 ueeCAkqDQ-y7uc2TByy1r_OoKNFRAACtr4EbWkL2caJu5sYA6BaZD7LHh0RS9lFq 660 hyV4BAS1PGjmXYvVJ5quvMkHussQiJUDBEu6Pk6bK1m4pRBI5-5BpfPNijrTjg2O 661 TXv9tbmxPVI3X9Emg7WDETN_NCrv6vEA1ONaTmUznE4ilCTkti4gQoeHAJ8KUtO3 662 zrATmUXzRbQxxS2clalq9OkaPz05kDeuZYlGqIaUXlSb_oKnMFPhOgPLARddEHYS 663 jhbGsI5hWDH_TrhDZgK0sTAibroEsPaAvXx1nHzPgzVOAZQI7n8wWWmPQdRkWJkO 664 eIMgrO-elI0RGs3Ju4mStQ" 665 , 666 "e": " 667 AQAB" 668 }}}, 669 "DeviceAuthenticationKey": { 670 "UDF": "MCEA7-TTV2M-UYGTD-KUW4W-WZBHO-WU7QN", 671 "PublicParameters": { 672 "PublicKeyRSA": { 673 "kid": "MCEA7-TTV2M-UYGTD-KUW4W-WZBHO-WU7QN", 674 "n": " 675 tqWSDHavRC5cILmPI8bFqaek70-vaC2gFoNEPVTxs5BNgjMwSE5jjtpFmFSAZOL- 676 xo_rMhQqwSqK4SUgjKSrk9pMWFPTUGcb4o4AY6JhERfo92Gx0owv3qQmt06BdXBH 677 K9Wth9ARbpOLJF0G1ymEgrO_X22A1yMsYzT915mZwXnxzN-ICyIwQ2K4qdB_8g_p 678 KPgWod5jSb4PtKwu26Cx0dTOjzAbFyloU8lxIWuGMgZWPUzi7cFzL9A4hIw4eM7d 679 oEtzD4STncKEq0Or60YJ4Kkw7E25aVrlk9jrKF3YGu7TRoUIHXMa06x8r-c-UKNf 680 oxCundz4aAisHXsg2i9nlQ" 681 , 682 "e": " 683 AQAB" 684 }}}, 685 "DeviceEncryptiontionKey": { 686 "UDF": "MCWBO-ERCF5-TYEHN-573FA-WZYNG-UKX4N", 687 "PublicParameters": { 688 "PublicKeyRSA": { 689 "kid": "MCWBO-ERCF5-TYEHN-573FA-WZYNG-UKX4N", 690 "n": " 691 2FTQmwHHfwPl7OvKlyYwEHIF3VKsjSqsCh1ZOVw_SI8oITPQTaJ_VIeIrokOTZ7i 692 0IosAlWD9MpIWUmn1qw2B_VbSOuiKtMVs6RWt0DAFpC6gedQy8WRGQlatskSYYJ- 693 14Mlv87bGGMo1P815SP53yQ28MNgO8g1ZGVqBSs5_KLHcWakNDd0hKAFgF8KVcvF 694 EyCmOGyIV-WtuJ44bagnX9JO1WuBwRVqlhkLqvp0CblJjQPiedTI2WjdeogyAbqr 695 EfLtJzqayrGhzJa-xud4PipcI-ebpTrbD2XEB_4UKbV-Wuo5oFIXYQbNNDM-WPUE 696 OqBgaurX7yuoanb8FQELXQ" 697 , 698 "e": " 699 AQAB" 700 }}}}} 702 Figure 12 704 The device profile is then signed: 706 { 707 "SignedDeviceProfile": { 708 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 709 "SignedData": { 710 "unprotected": { 711 "dig": "S512"}, 712 "payload": " 713 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFRVE4t 714 WUZJQlEtQ0s0QlctVFZURTMtR0ZQWTUtWUdKQkQiLAogICAgIk5hbWVzIjogWyJE 715 ... 716 ICAgICAgICAgImUiOiAiCkFRQUIifX19fX0" 717 , 718 "signatures": [{ 719 "header": { 720 "kid": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD"}, 721 "protected": " 722 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCkFhX0kzUUNvakpFekxRNVN3 723 MmxGLVBibnY2c3hKal8yTjBHUmJ5N1JYSmxBaXdWQ1NiY0lJWkpDVkowVkdYcjkK 724 WVJJanNLT05qSFhLeExuOG5KTlRZdyJ9" 725 , 726 "signature": " 727 ZpO0YsoYwnf_rAVEZMVjqvcFEI2PnCgX6xcVOvuIu7hi5z53bSSxAkVxUGWJxHax 728 11eTiS37iYDOqP3pWg19HS6hl55bWAwL9A6X3bJXFsj8Zm7Iw4UyzYGFRkon_TKL 729 mFVzcsbgvLehgCaLsM9tNXuv6po_imD6ibacK2QpOQjM4E0xUUvr6rFM76zVcLJ_ 730 Ki5EXrulsex4COciNkeNCacJOaMIS8JFlQG-3FNND9FL8DW1_pZOGSJX_t3LWpCS 731 qbU4yKlIooE964wFivE21nm96SnpNhCiJTkGGgYZgtZ6RQZSKul1yfSs6qJrMuII 732 LF4gj2QwhQCwi5Y4L3FNng" 733 }]}}} 735 Figure 13 737 3.3.1. Profile Authentication 739 One of the main architecutral principles of the Mesh is bilateral 740 authentication. Every device that is connected to a Mesh profile 741 MUST authenticate the profile it is connecting to and every Mesh 742 profile administrator MUST authenticate devices that are connected. 744 Having created the necessary profile, the device MUST verify that it 745 is connecting to the correct Mesh profile. The best mechanism for 746 achieving this purpose depends on the capabilities of the device 747 being connected. The administration device obviously requires some 748 means of communicating with the user to serve its function. But the 749 device being connected may have a limited display capability or no 750 user interaction capability at all. 752 3.3.1.1. Interactive Devices 754 If the device has user input and display capabilities, it can verify 755 that it is connecting to the correct display by first requesting the 756 user enter the portal account of the profile they wish to connect to, 757 retreiving the profile associated with the device and displaying the 758 profile fingerprint. 760 The client requests the profile for the requested account name: 762 { 763 "GetRequest": { 764 "Account": "test@prismproof.org", 765 "Multiple": false}} 767 Figure 14 769 The response contains the requested profile information. 771 { 772 "GetResponse": { 773 "Status": 201, 774 "StatusDescription": "Operation completed successfully", 775 "Entries": [{ 776 "SignedPersonalProfile": { 777 "Identifier": "MC7WV-RVXSK-VQAAQ-4UDXT-44MYG-SZZPN", 778 "SignedData": { 779 "unprotected": { 780 "dig": "S512"}, 781 "payload": " 782 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQzdX 783 Vi1SVlhTSy1WUUFBUS00VURYVC00NE1ZRy1TWlpQTiIsCiAgICAiU2lnbmVkTWFz 784 ... 785 aW9ucyI6IFtdfX0" 786 , 787 "signatures": [{ 788 "header": { 789 "kid": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI"}, 790 "protected": " 791 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjk4MEhfWnp3emxzeWtLQ0lF 792 N1pBRUo5Z2dMRTc5cTRyQ3IwRjMwaVp2S1lKTldnaWlhTmdKOEhfZmFPbGZFWHkK 793 YXoyNmdFQmtsbS1VTTdUMDJpVjJ0QSJ9" 794 , 795 "signature": " 796 aS--SDvXmNWvwpWkbvhSAQOWX0B5IOGf93RpLX-QE8PYEGbORkd155Mg0Vl7QBhG 797 UhQlCAd4R-pDN3-1rE5YP0OXHCwG44nXBgap-IqZ6ZPAvSOS6AruMqLsJLGmtYPK 798 4mdY8ZLnrwM88C0EgqsVhv_T2D0-roAImUHIqNu-9vJh3tL1jRqfubDappHWnF3S 799 9FiIK-cS_5Zo_ZB5OTSq_RJWCFmTXAK23onQ0cyJEq52cCF39KL5wKDQ3FcmEdTq 800 SInUgfB6gJ5zkibWJIZWwR3HZqmi-2fNFCqimgNN1cvk2fzaA5c-AnRhQOTlXI1D 801 nqRrjDbDLB2LdU_GLVarIg" 802 }]}}}]}} 804 Figure 15 806 Having received the profile data, the user can then verify that the 807 device is attempting to connect to the correct profile by verifying 808 that the fingerprint shown by the device attempting to connect is 809 correct. 811 3.3.1.2. Constrained Interaction Devices 813 Connection of an Internet of Things 'IoT' device that does not have 814 the ability to accept user input requires a mechanism by which the 815 user can identify the device they wish to connect to their profile 816 and a mechanism to authenticate the profile to the device. 818 If the connecting device has a wired communication capability such as 819 a USB port, this MAY be used to effect the device connection using a 820 standardized interaction profile. But an increasing number of 821 constrained IoT devices are only capable of wireless communication. 823 Configuration of such devices for the purpose of the Mesh requires 824 that we also consider configuration of the wireless networking 825 capabilities at the same time. The precise mechanism by which this 826 is achieved is therefore outside the scope of this particular 827 document. However prototypes have been built and are being 828 considered that make use of some or all of the following 829 communication techniques: 831 o Wired serial connection (RS232, RS485). 833 o DHCP signalling. 835 o Machine readable device identifiers (barcodes, QRCodes). 837 o Default device profile installed during manufacture. 839 o Optical communication path using camera on administrative device 840 and status light on connecting device to communicate the device 841 identifier, challenge nonce and confirm profile fingerprint. 843 o Speech output on audio capable connecting device. 845 3.3.2. Connection request 847 After the user verifies the device fingerprint as correct, the client 848 posts a device connection request to the portal: 850 { 851 "ConnectStartRequest": { 852 "SignedRequest": { 853 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 854 "SignedData": { 855 "unprotected": { 856 "dig": "S512"}, 857 "payload": " 858 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUM3 859 V1YtUlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4iLAogICAgIkRldmljZSI6 860 ... 861 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 862 , 863 "signatures": [{ 864 "header": { 865 "kid": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD"}, 866 "protected": " 867 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnl5NFB5VlczNE4yOWxtRXJ6 868 QndLaTc5R0FMcGN1YkZTdnJOYlljMUVwNFY3WFJPdG44dF9fTUVCVE43VzNPdGUK 869 ZzdmOUNvUV80QW11aml6N25nczJhQSJ9" 870 , 871 "signature": " 872 PP0nYt9eMq4ckofi5r0RHLyeV7mlF3oe0G-t_OJoclMqbZrUc4dwSPlQ0JT6ZWg- 873 aJqmg1bZu48lnB-9-oe9wHXSJSboUBoZYqH_983tINQU2-k4ljFkr8Ff71g3LHYv 874 840yUAAVyiN1r2ftz-rRfJQSvxPztvbRcJ7OQBbsmMl3B4woVfdX-KB8GrvVs7Rg 875 jMi8wgN8EnTiSCZ2d7IllHvUmCiVnmTuEf4kwOqCLq2a-bMTdQnXyFPEFSHIq1pY 876 vCeNbidTcSDpjLqxDXqiW1r8hYbRmLqd-jKTT7SDpmbKzfK0OGjIC-0sRfrPK1uC 877 B9RuP0Youg2eeioBPdHlVQ" 878 }]}}, 879 "AccountID": "test@prismproof.org"}} 881 Figure 16 883 The portal verifies that the request is accepable and returns the 884 transaction result: 886 { 887 "ConnectStartResponse": {}} 889 Figure 17 891 3.3.3. Administrator Polls Pending Connections 893 The client can poll the portal for the status of pending requests at 894 any time (modulo any service throttling restrictions at the service 895 side). But the request status will only change when an update is 896 posted by an administration device. 898 Since the user is typically connecting a device to their profile, the 899 next step in connecting the device is to start the administration 900 client. When started, the client polls for pending connection 901 requests using ConnectPendingRequest. 903 { 904 "ConnectPendingRequest": { 905 "AccountID": "test@prismproof.org"}} 907 Figure 18 909 The service responds with a list of pending requests: 911 { 912 "ConnectPendingResponse": { 913 "Pending": [{ 914 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 915 "SignedData": { 916 "unprotected": { 917 "dig": "S512"}, 918 "payload": " 919 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUM3 920 V1YtUlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4iLAogICAgIkRldmljZSI6 921 ... 922 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 923 , 924 "signatures": [{ 925 "header": { 926 "kid": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD"}, 927 "protected": " 928 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnl5NFB5VlczNE4yOWxtRXJ6 929 QndLaTc5R0FMcGN1YkZTdnJOYlljMUVwNFY3WFJPdG44dF9fTUVCVE43VzNPdGUK 930 ZzdmOUNvUV80QW11aml6N25nczJhQSJ9" 931 , 932 "signature": " 933 PP0nYt9eMq4ckofi5r0RHLyeV7mlF3oe0G-t_OJoclMqbZrUc4dwSPlQ0JT6ZWg- 934 aJqmg1bZu48lnB-9-oe9wHXSJSboUBoZYqH_983tINQU2-k4ljFkr8Ff71g3LHYv 935 840yUAAVyiN1r2ftz-rRfJQSvxPztvbRcJ7OQBbsmMl3B4woVfdX-KB8GrvVs7Rg 936 jMi8wgN8EnTiSCZ2d7IllHvUmCiVnmTuEf4kwOqCLq2a-bMTdQnXyFPEFSHIq1pY 937 vCeNbidTcSDpjLqxDXqiW1r8hYbRmLqd-jKTT7SDpmbKzfK0OGjIC-0sRfrPK1uC 938 B9RuP0Youg2eeioBPdHlVQ" 939 }]}}]}} 941 Figure 19 943 3.3.4. Administrator updates and publishes the personal profile. 945 The device profile is added to the Personal profile which is then 946 signed by the online signing key. The administration client 947 publishes the updated profile to the Mesh through the portal: 949 { 950 "ConnectPendingRequest": { 951 "AccountID": "test@prismproof.org"}} 953 Figure 20 955 As usual, the service returns the response code: 957 { 958 "ConnectPendingResponse": { 959 "Pending": [{ 960 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 961 "SignedData": { 962 "unprotected": { 963 "dig": "S512"}, 964 "payload": " 965 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUM3 966 V1YtUlZYU0stVlFBQVEtNFVEWFQtNDRNWUctU1paUE4iLAogICAgIkRldmljZSI6 967 ... 968 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 969 , 970 "signatures": [{ 971 "header": { 972 "kid": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD"}, 973 "protected": " 974 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnl5NFB5VlczNE4yOWxtRXJ6 975 QndLaTc5R0FMcGN1YkZTdnJOYlljMUVwNFY3WFJPdG44dF9fTUVCVE43VzNPdGUK 976 ZzdmOUNvUV80QW11aml6N25nczJhQSJ9" 977 , 978 "signature": " 979 PP0nYt9eMq4ckofi5r0RHLyeV7mlF3oe0G-t_OJoclMqbZrUc4dwSPlQ0JT6ZWg- 980 aJqmg1bZu48lnB-9-oe9wHXSJSboUBoZYqH_983tINQU2-k4ljFkr8Ff71g3LHYv 981 840yUAAVyiN1r2ftz-rRfJQSvxPztvbRcJ7OQBbsmMl3B4woVfdX-KB8GrvVs7Rg 982 jMi8wgN8EnTiSCZ2d7IllHvUmCiVnmTuEf4kwOqCLq2a-bMTdQnXyFPEFSHIq1pY 983 vCeNbidTcSDpjLqxDXqiW1r8hYbRmLqd-jKTT7SDpmbKzfK0OGjIC-0sRfrPK1uC 984 B9RuP0Youg2eeioBPdHlVQ" 985 }]}}]}} 987 Figure 21 989 3.3.5. Administrator posts completion request. 991 Having accepted the device and connected it to the profile, the 992 administration client creates and signs a connection completion 993 result which is posted to the portal using ConnectCompleteRequest: 995 { 996 "ConnectCompleteRequest": { 997 "Result": { 998 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 999 "SignedData": { 1000 "unprotected": { 1001 "dig": "S512"}, 1002 "payload": " 1003 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1004 IklkZW50aWZpZXIiOiAiTUFRVE4tWUZJQlEtQ0s0QlctVFZURTMtR0ZQWTUtWUdK 1005 ... 1006 dUIKa2RZenBiV3kzNTZiY2oyZDZoUmtmZyJ9XX19fX19" 1007 , 1008 "signatures": [{ 1009 "header": { 1010 "kid": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI"}, 1011 "protected": " 1012 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCi1ZUjc5bXREeWFYS0hrRXJU 1013 NUJKSzJsbi11ZjZpUVN2eXkxYWtoc0lQZTBuVWR5N1dqZ2lLSElmcDJ6MVhsOTIK 1014 NllDbjBjaGoxZVBxV0RaOTM1R2JuZyJ9" 1015 , 1016 "signature": " 1017 bMdM4wiG6kin76JJ6QOgGEpKsVduOqk5UG-l2JYCcsDhAkyLa-v9tJbA8AlYfOq1 1018 w2NwwfOR5c7fiT9OGOa5HVMFc1MY6vjbOjsn_op18PRruc3uFM5SEmW6rW6wWA8e 1019 q31B0wmK14uLpFp8X7nLO71DyuoTXnq0EDlIaY01ysGASBVve0qlo0G5QZvyU4oV 1020 KspDsQJJ0bl2fizkg50tBPWxOZ1KM4jGSEGkvrAB2D5CLozT3p-TYlHObAjz5O2i 1021 vLy_uH6YdZlbsHf1deOAeJ1qsF75ahXtf_pSjYVX10jKDW1lzAaTXD-FxkVmxM8i 1022 p-zPsos3ednASLWIf6dIpw" 1023 }]}}, 1024 "AccountID": "test@prismproof.org"}} 1026 Figure 22 1028 Again, the service returns the response code: 1030 { 1031 "ConnectCompleteResponse": {}} 1033 Figure 23 1035 3.3.6. Connecting device polls for status update. 1037 As stated previously, the connecting device polls the portal 1038 periodically to determine the status of the pending request using 1039 ConnectStatusRequest: 1041 { 1042 "ConnectStatusRequest": { 1043 "AccountID": "test@prismproof.org", 1044 "DeviceID": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD"}} 1046 Figure 24 1048 If the response is that the connection status has not changed, the 1049 service MAY return a response that specifies a minimum retry 1050 interval. In this case however there is a connection result: 1052 { 1053 "ConnectStatusResponse": { 1054 "Result": { 1055 "Identifier": "MAQTN-YFIBQ-CK4BW-TVTE3-GFPY5-YGJBD", 1056 "SignedData": { 1057 "unprotected": { 1058 "dig": "S512"}, 1059 "payload": " 1060 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1061 IklkZW50aWZpZXIiOiAiTUFRVE4tWUZJQlEtQ0s0QlctVFZURTMtR0ZQWTUtWUdK 1062 ... 1063 dUIKa2RZenBiV3kzNTZiY2oyZDZoUmtmZyJ9XX19fX19" 1064 , 1065 "signatures": [{ 1066 "header": { 1067 "kid": "MBDWG-CNYIB-KC3ZL-6HMY7-UAF6J-LOCXI"}, 1068 "protected": " 1069 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCi1ZUjc5bXREeWFYS0hrRXJU 1070 NUJKSzJsbi11ZjZpUVN2eXkxYWtoc0lQZTBuVWR5N1dqZ2lLSElmcDJ6MVhsOTIK 1071 NllDbjBjaGoxZVBxV0RaOTM1R2JuZyJ9" 1072 , 1073 "signature": " 1074 bMdM4wiG6kin76JJ6QOgGEpKsVduOqk5UG-l2JYCcsDhAkyLa-v9tJbA8AlYfOq1 1075 w2NwwfOR5c7fiT9OGOa5HVMFc1MY6vjbOjsn_op18PRruc3uFM5SEmW6rW6wWA8e 1076 q31B0wmK14uLpFp8X7nLO71DyuoTXnq0EDlIaY01ysGASBVve0qlo0G5QZvyU4oV 1077 KspDsQJJ0bl2fizkg50tBPWxOZ1KM4jGSEGkvrAB2D5CLozT3p-TYlHObAjz5O2i 1078 vLy_uH6YdZlbsHf1deOAeJ1qsF75ahXtf_pSjYVX10jKDW1lzAaTXD-FxkVmxM8i 1079 p-zPsos3ednASLWIf6dIpw" 1080 }]}}}} 1082 Figure 25 1084 [Should probably unpack further.] 1086 3.4. Adding an application profile to a user profile 1088 Application profiles are published separately from the personal 1089 profile to which they are linked. This allows a device to be given 1090 administration capability for a particular application without 1091 granting administration capability for the profile itself and the 1092 ability to connect additional profiles and devices. 1094 Another advantage of this separation is that an application profile 1095 might be managed by a separate party. In an enterprise, the 1096 application profile for a user's corporate email account could be 1097 managed by the corporate IT department. 1099 A user MAY have multiple application profiles for the same 1100 application. If a user has three email accounts, they would have 1101 three email application profiles, one for each account. 1103 In this example, the user has requested a PaswordProfile to be 1104 created. When populated, this records the usernames and passwords 1105 for the various Web sites that the user has created accounts at and 1106 has requested the Web browser store in the Mesh. 1108 Unlike a traditional password management service, the data stored the 1109 Password Profile is encrypted end to end and can only be decrypted by 1110 the devices that hold a decryption key. 1112 { 1113 "PasswordProfile": { 1114 "Identifier": "MBMBD-JYUK7-3BQG2-NZKFE-CMW5J-IUSRB-A"}} 1116 Figure 26 1118 The application profile is published to the Mesh in the same way as 1119 any other profile update, via a a Publish transaction: 1121 {Point.Messages[0].String()} 1123 The service returns a status response. 1125 {Point.Messages[1].String()} 1127 Note that the degree of verification to be performed by the service 1128 when an application profile is published is an open question. 1130 Having created the application profile, the administration client 1131 adds it to the personal profile and publishes it: 1133 {Point.Messages[0].String()} 1135 Note that if the publication was to happen in the reverse order, with 1136 the personal profile being published before the application profile, 1137 the personal profile might be rejected by the portal for 1138 inconsistency as it links to a non existent application profile. 1139 Though the value of such a check is debatable. It might well be 1140 preferable to not make such checks as it permits an application 1141 profile to have a degree of anonymity. 1143 {Point.Messages[1].String()} 1145 3.5. Creating a recovery profile 1147 The Mesh invites users to put all their data eggs in one 1148 cryptographic basket. If the private keys in their master profile 1149 are lost, they could lose all their digital assets. 1151 The debate over the desirability of key escrow is a complex one. Not 1152 least because voluntary key escrow by the user to protect the user's 1153 digital assets is frequently conflated with mechanisms to support 1154 'Lawful Access' through government managed backdoors. 1156 Accidents happen and so do disasters. For most users and most 1157 applications, data loss is a much more important concern than data 1158 disclosure. The option of using a robust key recovery mechanism is 1159 therefore essential for use of strong cryptography is to become 1160 ubiquitous. 1162 There are of course circumstances in which some users may prefer to 1163 risk losing some of their data rather than risk disclosure. Since 1164 any key recovery infrastructure necessarily introduces the risk of 1165 coercion, the choice of whether to use key recovery or not is left to 1166 the user to decide. 1168 The Mesh permits users to escrow their private keys in the Mesh 1169 itself in an OfflineEscrowEntry. Such entries are encrypted using 1170 the strongest degree of encryption available under a symmetric key. 1171 The symmetric key is then in turn split using Shamir secret sharing 1172 using an n of m threshold scheme. 1174 The OfflineEscrowEntry identifier is a UDF fingerprint of the 1175 symmetric key used to encrypt the data. This guarantees that a party 1176 that has the decryption key has the ability to locate the 1177 corresponding Escrow entry. 1179 The OfflineEscrowEntry is published using the usual Publish 1180 transaction: 1182 {Point.Messages[0].String()} 1184 The response indicates success or failure: 1186 {Point.Messages[1].String()} 1188 3.6. Recovering a profile 1190 To recover a profile, the user MUST supply the necessary number of 1191 secret shares. These are then used to calculate the UDF fingerprint 1192 to use as the locator in a Get transaction: 1194 {Point.Messages[0].String()} 1196 If the transaction succeeds, GetResponse is returned with the 1197 requested data. 1199 {Point.Messages[1].String()} 1201 The client can now decrypt the OfflineEscrowEntry to recover the 1202 private key(s). 1204 4. Shared Classes 1206 The following classes are used as common elements in Mesh profile 1207 specifications.a 1209 4.1. Cryptographic Data Classes 1211 Most Mesh objects are signed and/or encrypted. For consistency all 1212 Mesh classes make use of the cryptographic data classes described in 1213 this section. 1215 4.1.1. Structure: PublicKey 1217 The PublicKey class is used to describe public key pairs and trust 1218 assertions associated with a public key. 1220 String (Optional) 1222 UDF fingerprint of the public key parameters/ 1224 Binary (Optional) 1226 List of X.509 Certificates 1228 Binary [0..Many] 1230 X.509 Certificate chain. 1232 Binary (Optional) 1234 X.509 Certificate Signing Request. 1236 4.1.2. Structure: SignedData 1238 Container for JOSE signed data and related attributes. 1240 Binary (Optional) 1242 The signed data 1244 4.1.3. Structure: EncryptedData 1246 Container for JOSE encrypted data and related attributes. 1248 Binary (Optional) 1250 The encrypted data 1252 4.2. Common Application Classes 1254 4.2.1. Structure: Connection 1256 Describes network connection parameters for an application 1258 String (Optional) 1260 DNS address of the server 1262 Integer (Optional) 1264 TCP/UDP Port number 1266 String (Optional) 1268 DNS service prefix as described in [!RFC6335] 1270 String [0..Many] 1272 Describes the security mode to use. Valid choices are 1273 Direct/Upgrade/None 1275 String (Optional) 1277 Username to present to the service for authentication 1278 String (Optional) 1280 Password to present to the service for authentication 1282 String (Optional) 1284 Service connection parameters in URI format 1286 String (Optional) 1288 List of the supported/acceptable authentication mechanisms, preferred 1289 mechanism first. 1291 Integer (Optional) 1293 Service timeout in seconds. 1295 Boolean (Optional) 1297 If set, the client should poll the specified service intermittently 1298 for updates. 1300 5. Mesh Profile Objects 1302 5.1. Base Profile Objects 1304 5.1.1. Structure: Entry 1306 Base class for all Mesh Profile objects. 1308 String (Optional) 1310 Globally unique identifier that remains constant for the lifetime of 1311 the entry. 1313 5.1.2. Structure: SignedProfile 1315 o Inherits: Entry 1317 Contains a signed profile entry 1319 JoseWebSignature (Optional) 1321 The signed profile. 1323 Note that each child of SignedProfile requires that the Payload field 1324 of the SignedData object contain an object of a specific type. For 1325 example, a SignedDeviceProfile object MUST contain a Payload field 1326 that contains a DeviceProfile object. 1328 Advice (Optional) 1330 Additional data that is not authenticated. 1332 5.1.3. Structure: Advice 1334 Additional data bound to a signed profile that is not authenticated. 1336 DateTime (Optional) 1338 If specified, the profile was the default profile at the specified 1339 date and time. The current default for that type of profile is the 1340 profile with the most recent Default timestamp. 1342 5.1.4. Structure: PortalAdvice 1344 o Inherits: Advice 1346 String [0..Many] 1348 A portal address at which this profile is registered. 1350 5.1.5. Structure: Profile 1352 o Inherits: Entry 1354 Parent class from which all profile types are derived 1356 String [0..Many] 1358 Fingerprints of index terms for profile retrieval. The use of the 1359 fingerprint of the name rather than the name itself is a precaution 1360 against enumeration attacks and other forms of abuse. 1362 DateTime (Optional) 1364 The time instant the profile was last modified. 1366 String (Optional) 1368 A Uniform Notary Token providing evidence that a signature was 1369 performed after the notary token was created. 1371 5.2. Device Profile Classes 1373 5.2.1. Structure: SignedDeviceProfile 1375 o Inherits: SignedProfile 1377 Contains a signed device profile 1379 [None] 1381 5.2.2. Structure: DeviceProfile 1383 o Inherits: Profile 1385 Describes a mesh device. 1387 String (Optional) 1389 Description of the device 1391 PublicKey (Optional) 1393 Key used to sign certificates for the DAK and DEK. The fingerprint 1394 of the DSK is the UniqueID of the Device Profile 1396 PublicKey (Optional) 1398 Key used to authenticate requests made by the device. 1400 PublicKey (Optional) 1402 Key used to pass encrypted data to the device such as a 1403 DeviceUseEntry 1405 5.2.3. Structure: DevicePrivateProfile 1407 Private portion of device encryption profile. 1409 Key (Optional) 1411 Private portion of the DeviceSignatureKey 1413 Key (Optional) 1415 Private portion of the DeviceAuthenticationKey 1417 Key (Optional) 1419 Private portion of the DeviceEncryptiontionKey 1421 5.3. Master Profile Objects 1423 5.3.1. Structure: SignedMasterProfile 1425 o Inherits: SignedProfile 1427 Contains a signed Personal master profile 1429 [None] 1431 5.3.2. Structure: MasterProfile 1433 o Inherits: Profile 1435 Describes the long term parameters associated with a personal 1436 profile. 1438 PublicKey (Optional) 1440 The root of trust for the Personal PKI, the public key of the PMSK is 1441 presented as a self-signed X.509v3 certificate with Certificate 1442 Signing use enabled. The PMSK is used to sign certificates for the 1443 PMEK, POSK and PKEK keys. 1445 PublicKey [0..Many] 1447 A Personal Profile MAY contain one or more PMEK keys to enable escrow 1448 of private keys used for stored data. 1450 PublicKey [0..Many] 1452 A Personal profile contains at least one POSK which is used to sign 1453 device administration application profiles. 1455 5.4. Personal Profile Objects 1457 5.4.1. Structure: SignedPersonalProfile 1459 o Inherits: SignedProfile 1461 Contains a signed Personal current profile 1463 [None] 1465 5.4.2. Structure: PersonalProfile 1467 o Inherits: Profile 1469 Describes the current applications and devices connected to a 1470 personal master profile. 1472 SignedMasterProfile (Optional) 1474 The corresponding master profile. The profile MUST be signed by the 1475 PMSK. 1477 SignedDeviceProfile [0..Many] 1479 The set of device profiles connected to the profile. The profile 1480 MUST be signed by the DSK in the profile. 1482 ApplicationProfileEntry [0..Many] 1484 Application profiles connected to this profile. 1486 5.4.3. Structure: ApplicationProfileEntry 1488 Personal profile entry describing the privileges of specific devices. 1490 String (Optional) 1492 The unique identifier of the application 1494 String (Optional) 1496 The application type 1498 String (Optional) 1500 Optional friendly name identifying the application. 1502 String [0..Many] 1504 List of devices authorized to sign application profiles 1506 String [0..Many] 1508 List of devices authorized to read private parts of application 1509 profiles 1511 5.5. Application Profile Objects 1513 5.5.1. Structure: SignedApplicationProfile 1515 o Inherits: SignedProfile 1517 Contains a signed device profile 1519 [None] 1521 5.5.2. Structure: ApplicationProfile 1523 o Inherits: Profile 1525 Parent class from which all application profiles inherit. 1527 [None] 1529 5.5.3. Structure: ApplicationProfilePrivate 1531 o Inherits: Entry 1533 The base class for all private profiles. 1535 [None] 1537 5.5.4. Structure: ApplicationDevicePublic 1539 o Inherits: Entry 1541 Describes the public per device data 1543 String (Optional) 1545 Description of the device for convenience of the user. 1547 String (Optional) 1549 Fingerprint of device that this key corresponds to. 1551 5.5.5. Structure: ApplicationDevicePrivate 1553 o Inherits: Entry 1555 Describes the private per device data 1557 [None] 1559 5.6. Key Escrow Objects 1561 5.6.1. Structure: EscrowEntry 1563 o Inherits: Entry 1565 Contains escrowed data 1567 JoseWebEncryption (Optional) 1569 The encrypted escrow data 1571 5.6.2. Structure: OfflineEscrowEntry 1573 o Inherits: EscrowEntry 1575 Contains data escrowed using the offline escrow mechanism. 1577 [None] 1579 5.6.3. Structure: OnlineEscrowEntry 1581 o Inherits: EscrowEntry 1583 Contains data escrowed using the online escrow mechanism. 1585 [None] 1587 5.6.4. Structure: EscrowedKeySet 1589 A set of escrowed keys. 1591 [None] 1593 6. Portal Connection 1595 6.1. Connection Request and Response Structures 1597 6.1.1. Structure: ConnectionRequest 1599 Describes a connection request. 1601 String (Optional) 1603 UDF of Mesh Profile to which connection is requested. 1605 SignedDeviceProfile (Optional) 1607 The Device profile to be connected 1609 6.1.2. Structure: SignedConnectionRequest 1611 o Inherits: SignedProfile 1613 Contains a ConnectionRequest signed by the corresponding device 1614 signature key. 1616 [None] 1618 6.1.3. Structure: ConnectionResult 1620 Describes the result of a connection request. 1622 o Inherits: ConnectionRequest 1624 String (Optional) 1626 The result of the connection request. Valid responses are: Accepted, 1627 Refused, Query. 1629 6.1.4. Structure: SignedConnectionResult 1631 o Inherits: SignedProfile 1633 Contains a signed connection result 1635 [None] 1637 7. Mesh Portal Service Reference 1639 _mmm._tcp 1641 /.well-known/mmm 1643 Every Mesh Portal Service transaction consists of exactly one request 1644 followed by exactly one response. Mesh Service transactions MAY 1645 cause modification of the data stored in the Mesh Portal or the Mesh 1646 itself but do not cause changes to the connection state. The 1647 protocol itself is thus idempotent. There is no set sequence in 1648 which operations are required to be performed. It is not necessary 1649 to perform a Hello transaction prior to a ValidateAccount, Publish or 1650 any other transaction. 1652 7.1. Request Messages 1654 A Mesh Portal Service request consists of a payload object that 1655 inherits from the MeshRequest class. When using the HTTP binding, 1656 the request MUST specify the portal DNS address in the HTTP Host 1657 field. 1659 7.1.1. Message: MeshRequest 1661 Base class for all request messages. 1663 String (Optional) 1665 Name of the Mesh Portal Service to which the request is directed. 1667 7.2. Response Messages 1669 A Mesh Portal Service response consists of a payload object that 1670 inherits from the MeshResponse class. When using the HTTP binding, 1671 the response SHOULD report the Status response code in the HTTP 1672 response message. However the response code returned in the payload 1673 object MUST always be considered authoritative. 1675 7.2.1. Message: MeshResponse 1677 Base class for all response messages. Contains only the status code 1678 and status description fields. 1680 [None] 1682 7.3. Imported Objects 1684 The Mesh Service protocol makes use of JSON objects defined in the 1685 JOSE Signatgure and Encryption specifications. 1687 7.4. Common Structures 1689 The following common structures are used in the protocol messages: 1691 7.4.1. Structure: KeyValue 1693 Describes a Key/Value structure used to make queries for records 1694 matching one or more selection criteria. 1696 String (Optional) 1698 The data retrieval key. 1700 String (Optional) 1702 The data value to match. 1704 7.4.2. Structure: SearchConstraints 1706 Specifies constraints to be applied to a search result. These allow 1707 a client to limit the number of records returned, the quantity of 1708 data returned, the earliest and latest data returned, etc. 1710 DateTime (Optional) 1712 Only data published on or after the specified time instant is 1713 requested. 1715 DateTime (Optional) 1717 Only data published before the specified time instant is requested. 1718 This excludes data published at the specified time instant. 1720 Integer (Optional) 1722 Maximum number of data entries to return. 1724 Integer (Optional) 1726 Maximum number of data bytes to return. 1728 String (Optional) 1730 Specifies a page key returned in a previous search operation in which 1731 the number of responses exceeded the specified bounds. 1733 When a page key is specified, all the other search parameters except 1734 for MaxEntries and MaxBytes are ignored and the service returns the 1735 next set of data responding to the earlier query. 1737 7.5. Transaction: Hello 1739 Request: HelloRequest 1741 Response: HelloResponse 1743 Report service and version information. 1745 The Hello transaction provides a means of determining which protocol 1746 versions, message encodings and transport protocols are supported by 1747 the service. 1749 7.6. Transaction: ValidateAccount 1751 Request: ValidateRequest 1753 Response: ValidateResponse 1755 Request validation of a proposed name for a new account. 1757 For validation of a user's account name during profile creation. 1759 7.6.1. Message: ValidateRequest 1761 o Inherits: MeshRequest 1763 Describes the proposed account properties. Currently, these are 1764 limited to the account name but could be extended in future versions 1765 of the protocol. 1767 String (Optional) 1769 Account name requested 1771 Boolean (Optional) 1773 If true, request a reservation for the specified account name. Note 1774 that the service is not obliged to honor reservation requests. 1776 String [0..Many] 1778 List of ISO language codes in order of preference. For creating 1779 explanatory text. 1781 7.6.2. Message: ValidateResponse 1783 o Inherits: MeshResponse 1785 States whether the proposed account properties are acceptable and 1786 (optional) returns an indication of what properties are valid. 1788 Note that receiving a 'Valid' responseto a Validate Request does not 1789 guarantee creation of the account. In addition to the possibility 1790 that the account namecould be requested by another user between the 1791 Validate and Create transactions, a portal service MAY perform more 1792 stringent validation criteria when an account is actually being 1793 created. For example, checking with the authoritative list of 1794 current accounts rather than a cached copy. 1796 Boolean (Optional) 1798 If true, the specified account identifier is acceptable. If false, 1799 the account identifier is rejected. 1801 Integer (Optional) 1803 Specifies the minimum length of an account name. 1805 Integer (Optional) 1807 Specifies the maximum length of an account name. 1809 String (Optional) 1811 A list of characters that the service does not accept in account 1812 names. The list of characters MAY not be exhaustive but SHOULD 1813 include any illegal characters in the proposed account name. 1815 String (Optional) 1817 Text explaining the reason an account name was rejected. 1819 7.7. Transaction: CreateAccount 1821 Request: CreateRequest 1823 Response: CreateResponse 1825 Request creation of a new portal account. 1827 Unlike a profile, a mesh account is specific to a particular Mesh 1828 portal. A mesh account must be created and accepted before a profile 1829 can be published. 1831 7.7.1. Message: CreateRequest 1833 Request creation of a new portal account. The request specifies the 1834 requested account identifier and the Mesh profile to be associated 1835 with the account. 1837 o Inherits: MeshRequest 1839 String (Optional) 1841 Account identifier requested. 1843 7.7.2. Message: CreateResponse 1845 o Inherits: MeshResponse 1847 Reports the success or failure of a Create transaction. 1849 [None] 1851 7.8. Transaction: DeleteAccount 1853 Request: DeleteRequest 1855 Response: DeleteResponse 1857 Request deletion of a portal account. 1859 Deletes a portal account but not the underlying profile. Once 1860 registered, profiles are permanent. 1862 7.8.1. Message: DeleteRequest 1864 Request deletion of a new portal account. The request specifies the 1865 requested account identifier. 1867 o Inherits: MeshRequest 1869 String (Optional) 1871 Account identifier to be deleted. 1873 7.8.2. Message: DeleteResponse 1875 o Inherits: MeshResponse 1877 Reports the success or failure of a Delete transaction. 1879 [None] 1881 7.9. Transaction: Get 1883 Request: GetRequest 1885 Response: GetResponse 1887 Search for data in the mesh that matches a set of properties 1888 described by a sequence of key/value pairs. 1890 7.9.1. Message: GetRequest 1892 Describes the Portal or Mesh data to be retreived. 1894 o Inherits: MeshRequest 1896 String (Optional) 1898 Lookup by profile ID 1900 String (Optional) 1902 Lookup by Account ID 1904 KeyValue [0..Many] 1906 List of KeyValue pairs specifying the conditions to be met 1908 SearchConstraints (Optional) 1910 Constrain the search to a specific time interval and/or limit the 1911 number and/or total size of data records returned. 1913 Boolean (Optional) 1915 If true return multiple responses if available 1917 Boolean (Optional) 1919 If true, the client requests that the full Mesh data record be 1920 returned containing both the Mesh entry itself and the Mesh metadata 1921 that allows the date and time of the publication of the Mesh entry to 1922 be verified. 1924 7.9.2. Message: GetResponse 1926 Reports the success or failure of a Get transaction. If a Mesh entry 1927 matching the specified profile is found, containsthe list of entries 1928 matching the request. 1930 o Inherits: MeshResponse 1932 DataItem [0..Many] 1934 List of mesh data records matching the request. 1936 String (Optional) 1938 If non-null, indicates that the number and/or size of the data 1939 records returned exceeds either the SearchConstraints specified in 1940 the request or internal server limits. 1942 7.10. Transaction: Publish 1944 Request: PublishRequest 1946 Response: PublishResponse 1948 Publish a profile or key escrow entry to the mesh. 1950 7.10.1. Message: PublishRequest 1952 Requests publication of the specified Mesh entry. 1954 o Inherits: MeshRequest 1956 [None] 1958 7.10.2. Message: PublishResponse 1960 Reports the success or failure of a Publish transaction. 1962 o Inherits: MeshResponse 1964 [None] 1966 7.11. Transaction: Status 1968 Request: StatusRequest 1970 Response: StatusResponse 1972 Request the current status of the mesh as seen by the portal to which 1973 it is directed. 1975 The response to the status request contains the last signed 1976 checkpoint and proof chains for each of the peer portals that have 1977 been checkpointed. 1979 [Not currently implemented] 1981 7.11.1. Message: StatusRequest 1983 o Inherits: MeshRequest 1985 Initiates a status transaction. 1987 [None] 1989 7.11.2. Message: StatusResponse 1991 Reports the success or failure of a Status transaction. 1993 o Inherits: MeshResponse 1995 DateTime (Optional) 1997 Time that the last write update was made to the Mesh 1999 DateTime (Optional) 2001 Time that the last Mesh checkpoint was calculated. 2003 DateTime (Optional) 2005 Time at which the next Mesh checkpoint should be calculated. 2007 String (Optional) 2009 Last checkpoint value. 2011 7.12. Transaction: ConnectStart 2013 Request: ConnectStartRequest 2015 Response: ConnectStartResponse 2017 Request connection of a new device to a mesh profile 2019 7.12.1. Message: ConnectStartRequest 2021 o Inherits: MeshRequest 2023 Initial device connection request. 2025 SignedConnectionRequest (Optional) 2027 Device connection request signed by thesignature key of the device 2028 requesting connection. 2030 String (Optional) 2032 Account identifier of account to which the device is requesting 2033 connection. 2035 7.12.2. Message: ConnectStartResponse 2037 Reports the success or failure of a ConnectStart transaction. 2039 o Inherits: MeshRequest 2041 [None] 2043 7.13. Transaction: ConnectStatus 2045 Request: ConnectStatusRequest 2047 Response: ConnectStatusResponse 2049 Request status of pending connection request of a new device to a 2050 mesh profile 2052 7.13.1. Message: ConnectStatusRequest 2054 o Inherits: MeshRequest 2056 Request status information for a pending request posted previously. 2058 String (Optional) 2060 Account identifier for which pending connection information is 2061 requested. 2063 String (Optional) 2065 Device identifier of device requesting status information. 2067 7.13.2. Message: ConnectStatusResponse 2069 Reports the success or failure of a ConnectStatus transaction. 2071 o Inherits: MeshRequest 2073 SignedConnectionResult (Optional) 2075 The signed ConnectionResult object. 2077 7.14. Transaction: ConnectPending 2079 Request: ConnectPendingRequest 2081 Response: ConnectPendingResponse 2082 Request a list of pending requests for an administration profile. 2084 7.14.1. Message: ConnectPendingRequest 2086 o Inherits: MeshRequest 2088 Specify the criteria for pending requests. 2090 String (Optional) 2092 The account identifier of the account for which pending connection 2093 requests are requested. 2095 SearchConstraints (Optional) 2097 Constrain the search to a specific time interval and/or limit the 2098 number and/or total size of data records returned. 2100 7.14.2. Message: ConnectPendingResponse 2102 Reports the success or failure of a ConnectPending transaction. 2104 o Inherits: MeshRequest 2106 SignedConnectionRequest [0..Many] 2108 A list of pending requests satisfying the criteria set out in the 2109 request. 2111 String (Optional) 2113 If non-null, indicates that the number and/or size of the data 2114 records returned exceeds either the SearchConstraints specified in 2115 the request or internal server limits. 2117 7.15. Transaction: ConnectComplete 2119 Request: ConnectCompleteRequest 2121 Response: ConnectCompleteResponse 2123 Post response to a pending connection request. 2125 7.15.1. Message: ConnectCompleteRequest 2127 Reports the success or failure of a ConnectComplete transaction. 2129 o Inherits: MeshRequest 2130 SignedConnectionResult (Optional) 2132 The connection result to be posted to the portal. The result MUST be 2133 signed by a valid administration key for the Mesh profile. 2135 String (Optional) 2137 The account identifier to which the connection result is posted. 2139 7.15.2. Message: ConnectCompleteResponse 2141 o Inherits: MeshRequest 2143 Reports the success or failure of a ConnectComplete transaction. 2145 [None] 2147 7.16. Transaction: Transfer 2149 Request: TransferRequest 2151 Response: TransferResponse 2153 Perform a bulk transfer of the log between the specified transaction 2154 identifiers. Requires appropriate authorization 2156 [Not currently implemented] 2158 7.16.1. Message: TransferRequest 2160 Request a bulk transfer of the log between the specified transaction 2161 identifiers. Requires appropriate authorization 2163 o Inherits: MeshRequest 2165 SearchConstraints (Optional) 2167 Constrain the search to a specific time interval and/or limit the 2168 number and/or total size of data records returned. 2170 7.16.2. Message: TransferResponse 2172 o Inherits: MeshResponse 2174 Reports the success or failure of a Transfer transaction. If 2175 successful, contains the list of Mesh records to be transferred. 2177 DataItem [0..Many] 2179 List of mesh data records matching the request. 2181 String (Optional) 2183 If non-null, indicates that the number and/or size of the data 2184 records returned exceeds either the SearchConstraints specified in 2185 the request or internal server limits. 2187 8. Security Considerations 2189 9. IANA Considerations 2191 All the IANA considerations for the Mesh documents are specified in 2192 this document 2194 10. Acknowledgements 2196 11. References 2198 11.1. Normative References 2200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2201 Requirement Levels", BCP 14, RFC 2119, 2202 DOI 10.17487/RFC2119, March 1997. 2204 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2205 Cheshire, "Internet Assigned Numbers Authority (IANA) 2206 Procedures for the Management of the Service Name and 2207 Transport Protocol Port Number Registry", BCP 165, 2208 RFC 6335, DOI 10.17487/RFC6335, August 2011. 2210 11.2. Informative References 2212 [draft-hallambaker-mesh-architecture] 2213 Hallam-Baker, P., "Mathematical Mesh: Architecture", 2214 draft-hallambaker-mesh-architecture-03 (work in progress), 2215 May 2017. 2217 [draft-hallambaker-mesh-developer] 2218 Hallam-Baker, P., "Mathematical Mesh: Developer's Guide", 2219 draft-hallambaker-mesh-developer-02 (work in progress), 2220 September 2016. 2222 [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 2223 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 2224 August 1982. 2226 Author's Address 2228 Phillip Hallam-Baker 2229 Comodo Group Inc. 2231 Email: philliph@comodo.com