idnits 2.17.1 draft-hallambaker-mesh-reference-09.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2018) is 2206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2150 -- Looks like a reference, but probably isn't: '0' on line 1194 == Unused Reference: 'RFC6335' is defined on line 2126, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 2144, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 1 error (**), 0 flaws (~~), 3 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 April 11, 2018 5 Expires: October 13, 2018 7 Mathematical Mesh: Reference 8 draft-hallambaker-mesh-reference-09 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 This document is also available online at 19 http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html 20 [1] . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 13, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Related Specifications . . . . . . . . . . . . . . . . . 5 61 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 5 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Creating a new portal account . . . . . . . . . . . . . . 5 64 3.1.1. Checking Account Identifier for uniqueness . . . . . 5 65 3.2. Creating a new user profile . . . . . . . . . . . . . . . 6 66 3.2.1. Publishing a new user profile . . . . . . . . . . . . 13 67 3.3. Connecting a device profile to a user profile . . . . . . 15 68 3.3.1. Profile Authentication . . . . . . . . . . . . . . . 17 69 3.3.2. Connection request . . . . . . . . . . . . . . . . . 20 70 3.3.3. Administrator Polls Pending Connections . . . . . . . 21 71 3.3.4. Administrator updates and publishes the personal 72 profile. . . . . . . . . . . . . . . . . . . . . . . 23 73 3.3.5. Administrator posts completion request. . . . . . . . 24 74 3.3.6. Connecting device polls for status update. . . . . . 25 75 3.4. Adding an application profile to a user profile . . . . . 26 76 3.5. Creating a recovery profile . . . . . . . . . . . . . . . 27 77 3.6. Recovering a profile . . . . . . . . . . . . . . . . . . 28 78 4. Shared Classes . . . . . . . . . . . . . . . . . . . . . . . 28 79 4.1. Cryptographic Data Classes . . . . . . . . . . . . . . . 28 80 4.1.1. Structure: PublicKey . . . . . . . . . . . . . . . . 28 81 4.1.2. Structure: SignedData . . . . . . . . . . . . . . . . 29 82 4.1.3. Structure: EncryptedData . . . . . . . . . . . . . . 29 83 4.2. Common Application Classes . . . . . . . . . . . . . . . 29 84 4.2.1. Structure: Connection . . . . . . . . . . . . . . . . 29 85 5. Mesh Profile Objects . . . . . . . . . . . . . . . . . . . . 30 86 5.1. Base Profile Objects . . . . . . . . . . . . . . . . . . 30 87 5.1.1. Structure: Entry . . . . . . . . . . . . . . . . . . 30 88 5.1.2. Structure: SignedProfile . . . . . . . . . . . . . . 30 89 5.1.3. Structure: Advice . . . . . . . . . . . . . . . . . . 30 90 5.1.4. Structure: PortalAdvice . . . . . . . . . . . . . . . 30 91 5.1.5. Structure: Profile . . . . . . . . . . . . . . . . . 31 92 5.2. Device Profile Classes . . . . . . . . . . . . . . . . . 31 93 5.2.1. Structure: SignedDeviceProfile . . . . . . . . . . . 31 94 5.2.2. Structure: DeviceProfile . . . . . . . . . . . . . . 31 95 5.2.3. Structure: DevicePrivateProfile . . . . . . . . . . . 32 96 5.3. Master Profile Objects . . . . . . . . . . . . . . . . . 32 97 5.3.1. Structure: SignedMasterProfile . . . . . . . . . . . 32 98 5.3.2. Structure: MasterProfile . . . . . . . . . . . . . . 32 99 5.4. Personal Profile Objects . . . . . . . . . . . . . . . . 33 100 5.4.1. Structure: SignedPersonalProfile . . . . . . . . . . 33 101 5.4.2. Structure: PersonalProfile . . . . . . . . . . . . . 33 102 5.4.3. Structure: ApplicationProfileEntry . . . . . . . . . 33 103 5.5. Application Profile Objects . . . . . . . . . . . . . . . 34 104 5.5.1. Structure: SignedApplicationProfile . . . . . . . . . 34 105 5.5.2. Structure: ApplicationProfile . . . . . . . . . . . . 34 106 5.5.3. Structure: ApplicationProfilePrivate . . . . . . . . 34 107 5.5.4. Structure: ApplicationDevicePublic . . . . . . . . . 34 108 5.5.5. Structure: ApplicationDevicePrivate . . . . . . . . . 34 109 5.6. Key Escrow Objects . . . . . . . . . . . . . . . . . . . 35 110 5.6.1. Structure: EscrowEntry . . . . . . . . . . . . . . . 35 111 5.6.2. Structure: OfflineEscrowEntry . . . . . . . . . . . . 35 112 5.6.3. Structure: OnlineEscrowEntry . . . . . . . . . . . . 35 113 5.6.4. Structure: EscrowedKeySet . . . . . . . . . . . . . . 35 114 6. Portal Connection . . . . . . . . . . . . . . . . . . . . . . 35 115 6.1. Connection Request and Response Structures . . . . . . . 35 116 6.1.1. Structure: ConnectionRequest . . . . . . . . . . . . 35 117 6.1.2. Structure: SignedConnectionRequest . . . . . . . . . 36 118 6.1.3. Structure: ConnectionResult . . . . . . . . . . . . . 36 119 6.1.4. Structure: SignedConnectionResult . . . . . . . . . . 36 120 7. Mesh Portal Service Reference . . . . . . . . . . . . . . . . 36 121 7.1. Request Messages . . . . . . . . . . . . . . . . . . . . 36 122 7.1.1. Message: MeshRequest . . . . . . . . . . . . . . . . 37 123 7.2. Response Messages . . . . . . . . . . . . . . . . . . . . 37 124 7.2.1. Message: MeshResponse . . . . . . . . . . . . . . . . 37 125 7.3. Imported Objects . . . . . . . . . . . . . . . . . . . . 37 126 7.4. Common Structures . . . . . . . . . . . . . . . . . . . . 37 127 7.4.1. Structure: KeyValue . . . . . . . . . . . . . . . . . 37 128 7.4.2. Structure: SearchConstraints . . . . . . . . . . . . 37 129 7.5. Transaction: Hello . . . . . . . . . . . . . . . . . . . 38 130 7.6. Transaction: ValidateAccount . . . . . . . . . . . . . . 38 131 7.6.1. Message: ValidateRequest . . . . . . . . . . . . . . 38 132 7.6.2. Message: ValidateResponse . . . . . . . . . . . . . . 39 133 7.7. Transaction: CreateAccount . . . . . . . . . . . . . . . 40 134 7.7.1. Message: CreateRequest . . . . . . . . . . . . . . . 40 135 7.7.2. Message: CreateResponse . . . . . . . . . . . . . . . 40 136 7.8. Transaction: DeleteAccount . . . . . . . . . . . . . . . 40 137 7.8.1. Message: DeleteRequest . . . . . . . . . . . . . . . 41 138 7.8.2. Message: DeleteResponse . . . . . . . . . . . . . . . 41 139 7.9. Transaction: Get . . . . . . . . . . . . . . . . . . . . 41 140 7.9.1. Message: GetRequest . . . . . . . . . . . . . . . . . 41 141 7.9.2. Message: GetResponse . . . . . . . . . . . . . . . . 42 142 7.10. Transaction: Publish . . . . . . . . . . . . . . . . . . 42 143 7.10.1. Message: PublishRequest . . . . . . . . . . . . . . 42 144 7.10.2. Message: PublishResponse . . . . . . . . . . . . . . 43 146 7.11. Transaction: Status . . . . . . . . . . . . . . . . . . . 43 147 7.11.1. Message: StatusRequest . . . . . . . . . . . . . . . 43 148 7.11.2. Message: StatusResponse . . . . . . . . . . . . . . 43 149 7.12. Transaction: ConnectStart . . . . . . . . . . . . . . . . 44 150 7.12.1. Message: ConnectStartRequest . . . . . . . . . . . . 44 151 7.12.2. Message: ConnectStartResponse . . . . . . . . . . . 44 152 7.13. Transaction: ConnectStatus . . . . . . . . . . . . . . . 44 153 7.13.1. Message: ConnectStatusRequest . . . . . . . . . . . 45 154 7.13.2. Message: ConnectStatusResponse . . . . . . . . . . . 45 155 7.14. Transaction: ConnectPending . . . . . . . . . . . . . . . 45 156 7.14.1. Message: ConnectPendingRequest . . . . . . . . . . . 45 157 7.14.2. Message: ConnectPendingResponse . . . . . . . . . . 46 158 7.15. Transaction: ConnectComplete . . . . . . . . . . . . . . 46 159 7.15.1. Message: ConnectCompleteRequest . . . . . . . . . . 46 160 7.15.2. Message: ConnectCompleteResponse . . . . . . . . . . 46 161 7.16. Transaction: Transfer . . . . . . . . . . . . . . . . . . 47 162 7.16.1. Message: TransferRequest . . . . . . . . . . . . . . 47 163 7.16.2. Message: TransferResponse . . . . . . . . . . . . . 47 164 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 165 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 166 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 167 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 168 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 169 11.2. Informative References . . . . . . . . . . . . . . . . . 48 170 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 48 171 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 173 1. Introduction 175 NB: The reference material in this document is generated from the 176 schema used to derive the source code. The tool used to create this 177 material has not been optimized to produce output for the IETF 178 documentation format at this time. Consequently, the formatting is 179 currently sub-optimal. 181 2. Definitions 183 This section presents the related specifications and standard, the 184 terms that are used as terms of art within the documents and the 185 terms used as requirements language. 187 2.1. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119] . 193 2.2. Defined Terms 195 The terms of art used in this document are described in the Mesh 196 Architecture Guide [draft-hallambaker-mesh-architecture] . 198 2.3. Related Specifications 200 The architecture of the Mathematical Mesh is described in the Mesh 201 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 202 documentation set and related specifications are described in this 203 document. 205 2.4. Implementation Status 207 The implementation status of the reference code base is described in 208 the companion document [draft-hallambaker-mesh-developer] . 210 3. Protocol Overview 212 [Account request does not specify the portal in the request body, 213 only the HTTP package includes this information. This is probably a 214 bug.] 216 3.1. Creating a new portal account 218 A user interacts with a Mesh service through a Mesh portal provider 219 with which she establishes a portal account. 221 For user convenience, a portal account identifier has the familiar 222 @ format established in [~RFC822]. 224 For example Alice selects example.com as her portal provider and 225 chooses the account name alice. Her portal account identifier is 226 alice. 228 A user MAY establish accounts with multiple portal providers and/or 229 change their portal provider at any time they choose. 231 3.1.1. Checking Account Identifier for uniqueness 233 The first step in creating a new account is to check to see if the 234 chosen account identifier is available. This allows a client to 235 validate user input and if necessary warn the user that they need to 236 choose a new account identifier when the data is first entered. 238 The ValidateRequest message contains the requested account identifier 239 and an optional language parameter to allow the service to provide 240 informative error messages in a language the user understands. The 241 Language field contains a list of ISO language identifier codes in 242 order of preference, most preferred first. 244 POST /.well-known/mmm/HTTP/1.1 245 Host: example.com 246 Content-Length: 90 248 { 249 "ValidateRequest": { 250 "Account": "test@prismproof.org", 251 "Language": ["en-uk"]}} 253 Figure 1 255 The ValidateResponse message returns the result of the validation 256 request in the Valid field. Note that even if the value true is 257 returned, a subsequent account creation request MAY still fail. 259 HTTP/1.1 200 OK 260 Date: Mon 04 Dec 2017 03:38:57 261 Content-Length: 190 263 { 264 "ValidateResponse": { 265 "Status": 201, 266 "StatusDescription": "Operation completed successfully", 267 "Valid": true, 268 "Minimum": 1, 269 "InvalidCharacters": ".,:;{}()[]<>?|\\@#"}} 271 Figure 2 273 [Note that for the sake of concise presentation, the HTTP binding 274 information is omitted from future examples.] 276 3.2. Creating a new user profile 278 The first step in creating a new personal profile is to create a 279 Master Profile object. This contains the long term Master Signing 280 Key that will remain constant for the life of the profile, at least 281 one Online Signature Key to be used for administering the personal 282 profile and (optionally), one or more master escrow keys. 284 For convenience, the descriptions of the Master Signing Key, Online 285 Signing Keys and Escrow Keys typically include PKIX certificates 286 signed by the Master Signing Key. This allows PKIX based applications 287 to make use of PKIX certificate chains to express the same trust 288 relationships described in the Mesh. 290 { 291 "MasterProfile": { 292 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 293 "MasterSignatureKey": { 294 "UDF": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 295 "X509Certificate": " 296 MIIFXTCCBEWgAwIBAgIRAMLMDJuKzpOYUgyGu-pFSoswDQYJKoZIhvcNAQENBQAw 297 LjEsMCoGA1UEAxYjTUFMRUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1Qw 298 ... 299 9c8HDZ9z9BHj_XwoShvX9neZiiQ26Pw9rJLNJ70Q7Nsi" 300 , 301 "PublicParameters": { 302 "PublicKeyRSA": { 303 "kid": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 304 "n": " 305 -OVfAVjglTViCa7GRMcZdX8zfuALOIMoVU9itSc6zIZPDNM_D1g_-wI_bM0duKXT 306 Y2B3gtZJBe6tnlLK2PPnwVEqo1srSmIBGTwgRM_wlJmjQ46rET0SMEI1GuVRqvah 307 pxqq59XqfDYqydqOvtDcqavgyW33S1UXI7KVSJgwagk3QFnIoErh8bnK54Gdpz-L 308 BA7EICHqD2Md4pdRVCY1-JFYrG1wX0B5DZzCUQ6fd-TBt4BEBH3ERLQhqQMwIE7x 309 CaEBahklcP_44FgSmeT21sQFSHhBPZxdqmfAEefKPKu9vuo3XETeSRs3HTrtoImF 310 IZj421mieaQc0vTYNWL2pQ" 311 , 312 "e": " 313 AQAB" 314 }}}, 315 "MasterEscrowKeys": [{ 316 "UDF": "MCYWE-GQRSM-NOK5T-3UVLY-AHJF6-T4GZC", 317 "X509Certificate": " 318 MIIFXDCCBESgAwIBAgIQCLpDHbhuyKQxHbawBVlw4TANBgkqhkiG9w0BAQ0FADAu 319 MSwwKgYDVQQDFiNNQUxFSS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVDAe 320 ... 321 mQ46FsAdzE42gLKnIN7IXYHbHr-bbw-5fW1bdQ840O8" 322 , 323 "PublicParameters": { 324 "PublicKeyRSA": { 325 "kid": "MCYWE-GQRSM-NOK5T-3UVLY-AHJF6-T4GZC", 326 "n": " 327 0aPb4XHnVtVIGWXc8t1mvCkf52UC8NRKPZkjNVY0bY8WwNtUNWbn-Tqv5ncS9hVz 328 gaRvQIM9U_4JZgwviuy2srJj0_c1yQtGIbBIRsrWt6wfx_gM0g1YCty_06hCrOu0 329 54JzRMm6wpLcmmws-Ip9rIL931zoNx5HvWEp5bUMFv3qENbYzlAPizobxSDinMLJ 330 R0gfTPz4FwillrnWRWhsWZ3VscDGZxYTsI3wZhi60B7LDdmTkr9KqXiVt7fefUSP 331 bGAYGQLuh_296O_Hh6F6N6V2UhvncD0K9F4t6DBt7_H06HojqLrUWsD1juVilE3h 332 dfFYaMEgyo9bxMIefKeQXQ" 333 , 334 "e": " 335 AQAB" 336 }}}], 337 "OnlineSignatureKeys": [{ 338 "UDF": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT", 339 "X509Certificate": " 340 MIIFXDCCBESgAwIBAgIQPcM0MUJ9c57N4f_Z_9uSsDANBgkqhkiG9w0BAQ0FADAu 341 MSwwKgYDVQQDFiNNQUxFSS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVDAe 342 ... 343 eljXhyaFB_QYGvKRAtyaSnU9m51xLX28D5bNq8LO53M" 344 , 345 "PublicParameters": { 346 "PublicKeyRSA": { 347 "kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT", 348 "n": " 349 yVcObdfLYL_Gh36yY_bprL8W7rEgax8Nbe2KFSZWkWayGps79C16pqOV0Doapko1 350 Lnbb-uB0BTS-Qw6A0F_0ZQyEaWzBMycvPT0Gr87unC-Ow3IaYeA2TbKNMg8Yvd_d 351 LB4nwWqWianYhV2nSbG4Tfem9zyYvrhG-DcKeMgQmSV6WgdwMCVEdKuuBxl5SL2D 352 GvmLwDwfRRX3tk0QGraagjywOCjmBd5F2WPaUtKV8HZtT9H9hI6YyztKrL_mp12P 353 itds_krRRLWf2OFNFMQau93zYxtNObu3xshu3hDzDHL_81pmXzMQ_AZ0vjF7-PA1 354 dC0VpPs3xxbXRNw64Kf_3Q" 355 , 356 "e": " 357 AQAB" 358 }}}]}} 360 Figure 3 362 The Master Profile is always signed using the Master Signing Key: 364 { 365 "SignedMasterProfile": { 366 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 367 "SignedData": { 368 "unprotected": { 369 "dig": "S512"}, 370 "payload": " 371 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFMRUkt 372 R1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIk1hc3RlclNpZ25h 373 ... 374 In19fV19fQ" 375 , 376 "signatures": [{ 377 "header": { 378 "kid": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT"}, 379 "protected": " 380 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnpuZERBMjFPSkZtZk1pdWV6 381 RWV6dThHWUJzWEVOSXVKZmFOMjJwWV9hTzNHeGl6ZjM3emJVVzFPNEVReDJFZ0IK 382 cURmRXJwVDdpX2VPVzBYWGk5VmdDUSJ9" 383 , 384 "signature": " 385 D0cg0pN4-50S1ilo9wrfI6u-R5NvAuZo8j5-XIBr1AylzMDWZk5YpdtoUM1q8FIR 386 sXVzetQ_6l8zc6fVzUJt7fMN8yBvc9v6owcFBNrujJSHsBU2u_DGxdhH1DW_4MU4 387 rTGXzek3__8jxo-q8LyzBfX2Wl3jzZz5VP_LhPdRjNFKTuU1e-KlLU43imvn8WTB 388 TYQas3JVWUgdsyH3OZ-FQ7Z06tNUtmza6qCK2HqRaUmJZ9P35835MaJbZX8D87WB 389 7R3KHWPNCO8bBkzXJCaM86E0wmYna3u1BuJ1Bg1bPY3t-iqVxv59FPHLB24TVMWP 390 WQIhxuUIJt5QYj_BhjmeBg" 391 }]}}} 393 Figure 4 395 Since the device used to create the personal profile is typically 396 connected to the profile, a Device profile entry is created for it. 397 This contains a Device Signing Key, a Device Encryption Key and a 398 Device Authentication Key: 400 { 401 "JoseWebSignature": { 402 "unprotected": { 403 "dig": "S512"}, 404 "payload": " 405 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURLVVIt 406 VFBaUU8tNlo3U1AtUUNFUjYtN0tRU0QtQ05STlEiLAogICAgIk5hbWVzIjogWyJE 407 ... 408 OUxjUVpRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 409 , 410 "signatures": [{ 411 "header": { 412 "kid": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ"}, 413 "protected": " 414 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjFUX0ExbGFSY1M4OWszbFpk 415 aklSNUx5LVBJWlM5QUM4XzJlWmUyLUF3SXJVMzIwbFNKakhCcU1VRnBTczBTczcK 416 dzdva1dlV0YtV1VQcll3WjJUU2JFZyJ9" 417 , 418 "signature": " 419 PUZrcYPUfJRxvKMnPJ6U6mgSx3lJoyY_Q-Takf0ZrnRMbjKi1Nn2nLFlfTi_htVO 420 Rn45WrLIR-hnZbKLWFkwsNg2HZ55MELcF0Cnvbzb8nj0roy3vc6FSJF5aZiFEn6u 421 hAAimDiA8HHta0J7nzlStYPeqrb_s0XDiNfpp7aSqckVdGZC2XKhx1RgQuF5ctp3 422 zLOGzV0Y5No312QmIagOXcLFLXG0awxhvEHhyhsALnQX8rd0z4AZmZavKCHufbcE 423 n-nRts8GzgcKmnRpmOuPdGhtT-PI8Gn7-sxfb4R95Taf_7_fvLLNG0Sot4DMTMuP 424 xovBNY1eA23ZHtw9AvmTAg" 425 }]}} 427 Figure 5 429 The Device Profile is signed using the Device Signing Key: 431 { 432 "SignedDeviceProfile": { 433 "Identifier": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ", 434 "SignedData": { 435 "unprotected": { 436 "dig": "S512"}, 437 "payload": " 438 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURLVVIt 439 VFBaUU8tNlo3U1AtUUNFUjYtN0tRU0QtQ05STlEiLAogICAgIk5hbWVzIjogWyJE 440 ... 441 OUxjUVpRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 442 , 443 "signatures": [{ 444 "header": { 445 "kid": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ"}, 446 "protected": " 447 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjFUX0ExbGFSY1M4OWszbFpk 448 aklSNUx5LVBJWlM5QUM4XzJlWmUyLUF3SXJVMzIwbFNKakhCcU1VRnBTczBTczcK 449 dzdva1dlV0YtV1VQcll3WjJUU2JFZyJ9" 450 , 451 "signature": " 452 PUZrcYPUfJRxvKMnPJ6U6mgSx3lJoyY_Q-Takf0ZrnRMbjKi1Nn2nLFlfTi_htVO 453 Rn45WrLIR-hnZbKLWFkwsNg2HZ55MELcF0Cnvbzb8nj0roy3vc6FSJF5aZiFEn6u 454 hAAimDiA8HHta0J7nzlStYPeqrb_s0XDiNfpp7aSqckVdGZC2XKhx1RgQuF5ctp3 455 zLOGzV0Y5No312QmIagOXcLFLXG0awxhvEHhyhsALnQX8rd0z4AZmZavKCHufbcE 456 n-nRts8GzgcKmnRpmOuPdGhtT-PI8Gn7-sxfb4R95Taf_7_fvLLNG0Sot4DMTMuP 457 xovBNY1eA23ZHtw9AvmTAg" 458 }]}}} 460 Figure 6 462 A personal profile would typically contain at least one application 463 when first created. For the sake of demonstration, we will do this 464 later. 466 The personal profile thus consists of the master profile and the 467 device profile: 469 { 470 "PersonalProfile": { 471 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 472 "SignedMasterProfile": { 473 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 474 "SignedData": { 475 "unprotected": { 476 "dig": "S512"}, 477 "payload": " 478 ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFMRUkt 479 R1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIk1hc3RlclNpZ25h 480 ... 481 In19fV19fQ" 482 , 483 "signatures": [{ 484 "header": { 485 "kid": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT"}, 486 "protected": " 487 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnpuZERBMjFPSkZtZk1pdWV6 488 RWV6dThHWUJzWEVOSXVKZmFOMjJwWV9hTzNHeGl6ZjM3emJVVzFPNEVReDJFZ0IK 489 cURmRXJwVDdpX2VPVzBYWGk5VmdDUSJ9" 490 , 491 "signature": " 492 D0cg0pN4-50S1ilo9wrfI6u-R5NvAuZo8j5-XIBr1AylzMDWZk5YpdtoUM1q8FIR 493 sXVzetQ_6l8zc6fVzUJt7fMN8yBvc9v6owcFBNrujJSHsBU2u_DGxdhH1DW_4MU4 494 rTGXzek3__8jxo-q8LyzBfX2Wl3jzZz5VP_LhPdRjNFKTuU1e-KlLU43imvn8WTB 495 TYQas3JVWUgdsyH3OZ-FQ7Z06tNUtmza6qCK2HqRaUmJZ9P35835MaJbZX8D87WB 496 7R3KHWPNCO8bBkzXJCaM86E0wmYna3u1BuJ1Bg1bPY3t-iqVxv59FPHLB24TVMWP 497 WQIhxuUIJt5QYj_BhjmeBg" 498 }]}}, 499 "Devices": [{ 500 "Identifier": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ", 501 "SignedData": { 502 "unprotected": { 503 "dig": "S512"}, 504 "payload": " 505 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURLVVIt 506 VFBaUU8tNlo3U1AtUUNFUjYtN0tRU0QtQ05STlEiLAogICAgIk5hbWVzIjogWyJE 507 ... 508 OUxjUVpRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19" 509 , 510 "signatures": [{ 511 "header": { 512 "kid": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ"}, 513 "protected": " 514 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjFUX0ExbGFSY1M4OWszbFpk 515 aklSNUx5LVBJWlM5QUM4XzJlWmUyLUF3SXJVMzIwbFNKakhCcU1VRnBTczBTczcK 516 dzdva1dlV0YtV1VQcll3WjJUU2JFZyJ9" 517 , 518 "signature": " 519 PUZrcYPUfJRxvKMnPJ6U6mgSx3lJoyY_Q-Takf0ZrnRMbjKi1Nn2nLFlfTi_htVO 520 Rn45WrLIR-hnZbKLWFkwsNg2HZ55MELcF0Cnvbzb8nj0roy3vc6FSJF5aZiFEn6u 521 hAAimDiA8HHta0J7nzlStYPeqrb_s0XDiNfpp7aSqckVdGZC2XKhx1RgQuF5ctp3 522 zLOGzV0Y5No312QmIagOXcLFLXG0awxhvEHhyhsALnQX8rd0z4AZmZavKCHufbcE 523 n-nRts8GzgcKmnRpmOuPdGhtT-PI8Gn7-sxfb4R95Taf_7_fvLLNG0Sot4DMTMuP 524 xovBNY1eA23ZHtw9AvmTAg" 525 }]}}], 526 "Applications": []}} 527 Figure 7 529 The personal profile is then signed using the Online Signing Key: 531 { 532 "SignedPersonalProfile": { 533 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 534 "SignedData": { 535 "unprotected": { 536 "dig": "S512"}, 537 "payload": " 538 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQUxF 539 SS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVCIsCiAgICAiU2lnbmVkTWFz 540 ... 541 b25zIjogW119fQ" 542 , 543 "signatures": [{ 544 "header": { 545 "kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"}, 546 "protected": " 547 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhhR1g4Z2hibUlhc2FXVEtm 548 UjBhQ0QyLU5Fckh3Z0RXRkIwM2diSk1hZFhSVkpyZmpYc1RxNXFZeEhyRDRDTzQK 549 d0JoWXBkejVyRXJVSmtaUVFQYl9lUSJ9" 550 , 551 "signature": " 552 v0aUBSoxs6FMtFsbWMZViJvVNh3GNliu7CEnw2Ajj-3mRwEtgTFY0H5RiB9AIbI2 553 TODq7JPKm7-6CCUEugXGdh4ZOnu5A2pAbwtotdAZBpNlhTQTuN6EE-OXwZmZSQyG 554 DZil2tIjLxYSlsX6vWB4M00HPPYx44TLvbbNVbTVJpw5gnWTceSw5nzIsUqT3gVE 555 8mCtN2Vo4EWKcMEhUJMx9nUkIaclW9orbA51S3B8QeMGP179cyZ_X_y6TKC3wIB6 556 AUm6ZQtpa_gBRnAmkbJj6-H_zI_OQIUO_IO2ANL3jI7TSiGPA7VhKsTYDTihMPHs 557 wfDAwuxZ2a5enFCczaywlg" 558 }]}}} 560 Figure 8 562 3.2.1. Publishing a new user profile 564 Once the signed personal profile is created, the client can finaly 565 make the request for the service to create the account. The request 566 object contains the requested account identifier and profile: 568 { 569 "CreateRequest": { 570 "Account": "test@prismproof.org", 571 "Profile": { 572 "SignedPersonalProfile": { 573 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 574 "SignedData": { 575 "unprotected": { 576 "dig": "S512"}, 577 "payload": " 578 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQUxF 579 SS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVCIsCiAgICAiU2lnbmVkTWFz 580 ... 581 b25zIjogW119fQ" 582 , 583 "signatures": [{ 584 "header": { 585 "kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"}, 586 "protected": " 587 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhhR1g4Z2hibUlhc2FXVEtm 588 UjBhQ0QyLU5Fckh3Z0RXRkIwM2diSk1hZFhSVkpyZmpYc1RxNXFZeEhyRDRDTzQK 589 d0JoWXBkejVyRXJVSmtaUVFQYl9lUSJ9" 590 , 591 "signature": " 592 v0aUBSoxs6FMtFsbWMZViJvVNh3GNliu7CEnw2Ajj-3mRwEtgTFY0H5RiB9AIbI2 593 TODq7JPKm7-6CCUEugXGdh4ZOnu5A2pAbwtotdAZBpNlhTQTuN6EE-OXwZmZSQyG 594 DZil2tIjLxYSlsX6vWB4M00HPPYx44TLvbbNVbTVJpw5gnWTceSw5nzIsUqT3gVE 595 8mCtN2Vo4EWKcMEhUJMx9nUkIaclW9orbA51S3B8QeMGP179cyZ_X_y6TKC3wIB6 596 AUm6ZQtpa_gBRnAmkbJj6-H_zI_OQIUO_IO2ANL3jI7TSiGPA7VhKsTYDTihMPHs 597 wfDAwuxZ2a5enFCczaywlg" 598 }]}}}}} 600 Figure 9 602 The service reports the success (or failure) of the account creation 603 request: 605 { 606 "CreateResponse": { 607 "Status": 201, 608 "StatusDescription": "Operation completed successfully"}} 610 Figure 10 612 3.3. Connecting a device profile to a user profile 614 Connecting a device to a profile requires the client on the new 615 device to interact with a client on a device that has administration 616 capabilities, i.e. it has access to an Online Signing Key. Since 617 clients cannot interact directly with other clients, a service is 618 required to mediate the connection. This service is provided by a 619 Mesh portal provider. 621 All service transactions are initiated by the clients. First the 622 connecting device posts ConnectStart, after which it may poll for the 623 outcome of the connection request using ConnectStatus. 625 Periodically, the Administration Device polls for a list of pending 626 connection requests using ConnectPending. After posting a request, 627 the administration device posts the result using ConnectComplete: 629 Connecting Mesh Administration 630 Device Service Device 632 | | | 633 | ConnectStart | | 634 | ----------------------> | | 635 | | ConnectPending | 636 | | <---------------------- | 637 | | | 638 | | ConnectComplete | 639 | | <---------------------- | 640 | ConnectStatus | | 641 | ----------------------> | | 643 Figure 11 645 The first step in the process is for the client to generate a device 646 profile. Ideally the device profile is bound to the device in a 647 read-only fashion such that applications running on the device can 648 make use of the deencryption and authentication keys but these 649 private keys cannot be extracted from the device: 651 { 652 "DeviceProfile": { 653 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 654 "Names": ["Default"], 655 "Description": "Unknown", 656 "DeviceSignatureKey": { 657 "UDF": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 658 "PublicParameters": { 659 "PublicKeyRSA": { 660 "kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 661 "n": " 662 8cxQYz71dYg24QyipvRGE6MAaoWBuFHASmD9LwSFs_A3P-CkxJ9MULvg_VNLpME_ 663 HeNMZPNUDzZEjaUCftNUo77fhHP55xA2s9qlf0l-iYzeJjw9F0nEGNSaQOvJzKV1 664 VitQuAw546tSNle4I2iNI1caqnDG0567I8mYwZRmifXKuLfXRB3dG-ZiAleeP3R9 665 5l4aQX3DXpqSMgyl9R5NA5-m9Lv6gjBEuQ2j5BESulXKjiSH8BNjrSIbrFTdesv4 666 25RNY19gsfOppwvCBp1Fqv5aSc5uAdP6gtkgZ0S2KNPvnlrSl-LKfTy_CPH9kyzy 667 J8atJh_8pvVgr3LnVD5H-Q" 668 , 669 "e": " 670 AQAB" 671 }}}, 672 "DeviceAuthenticationKey": { 673 "UDF": "MBVAM-ERHD2-PPPG3-7VWRP-U4AY2-7VOQ5", 674 "PublicParameters": { 675 "PublicKeyRSA": { 676 "kid": "MBVAM-ERHD2-PPPG3-7VWRP-U4AY2-7VOQ5", 677 "n": " 678 tYv9FY3ON556ZCFQKm1aevnjOaAzezXV5k60B39GTZPyBoM7cfXeUpvxcvvUyE1q 679 G_w0bBg58PckKZqfDR9dX5cH-MpLprtoXGMlSLLLS4wXkaaKxeHVWWLhoMNpYnSp 680 xzpTTEikofzJZp5RitOr1hnbfTZ7PRmpBrLajpKgg-ACRDQJ03mIa75D04EoLx77 681 6Ccu4pK0G3K81nu2Lc4Or3Syu_GR4cepAATudiXOU1pg7dpeBruy8jXespyjXUdQ 682 -wr32yH8qfJWdvsU6vCKbYXH6Hmf_SbCz8r4px5qpNwRb6Vrq1NEA7CbK9arIPgE 683 6P_D3SybJ0lKc-Qz7wjqlQ" 684 , 685 "e": " 686 AQAB" 687 }}}, 688 "DeviceEncryptiontionKey": { 689 "UDF": "MDT3C-LKVOS-EYFGZ-GML2P-YY2IK-OJJIS", 690 "PublicParameters": { 691 "PublicKeyRSA": { 692 "kid": "MDT3C-LKVOS-EYFGZ-GML2P-YY2IK-OJJIS", 693 "n": " 694 8O0fFIjO5vMCjtvJN9nZ6eBc-EeNAvHOlvLyFZNELiY0OGYXEcjmRnN91qSaiR2I 695 98vQ3GMWzbA0UoLE08kSoz99za-c2mJx_OPxTKL1ZWSXF7IalPwG8KKBBkg7IQSb 696 OV1UWFB1jHCmDLn02E-zwO9AhHtIvcTgOLqCzCZv7QyMkQ0r7iJft-HbkFotDG8L 697 XYz-RJ0UeA2jbmx6PbYkMoGpXZe5KwIssOJhyTOkJtqOSpSgRdhgn37yZ6U1mu79 698 18bLcufFqQ2THnkmDBG-HNKZtcw53EBGYTSTBr1m34DkUn7oCWIKjPWbubxQt1jd 699 Rg1q1TRnZFETq6DVvuB1_Q" 700 , 701 "e": " 702 AQAB" 703 }}}}} 705 Figure 12 707 The device profile is then signed: 709 { 710 "SignedDeviceProfile": { 711 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 712 "SignedData": { 713 "unprotected": { 714 "dig": "S512"}, 715 "payload": " 716 ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUM1WFot 717 UUxPUFUtNkNLNFktM0lTWjUtS0hJTFYtQURQSEkiLAogICAgIk5hbWVzIjogWyJE 718 ... 719 ICAgICAgICAgImUiOiAiCkFRQUIifX19fX0" 720 , 721 "signatures": [{ 722 "header": { 723 "kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"}, 724 "protected": " 725 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhYUVk0VkI5VU04bzd0cUdY 726 aUdack1nQlVnNm5mWXpLVWhBU1E1VHJKWUE5dGVKcTRQTGhqSDVPQWcyN3hLNEEK 727 b2RVYjJwT2RZaTFJUkJRRXA4VGlaQSJ9" 728 , 729 "signature": " 730 P7yjwhMYFUqupGsqcZyokfaDZV2o8-vLpXbHEQKihw_9gRokbMvqkwhhQt4RjeL8 731 DMBj1CgtpauMKbtmaqrpolJfX5IjQPnULTCdeEDvrGuyzw6zVAL8j0xBKCOqWxz- 732 pmk_kGA7svNBukfQ4wVAI1-PQw8c-garvpRZWFAD1oSkFhMQxhEG1zn0B3abJRmI 733 Bf9Fukqp1B5HdmOUOEp0MHJ56SaGHOSxKKmp5L3LtDsgmvJ-LumVrYpcaAAvSqI0 734 4qaUcWSWIGkEZ0pbXAm6O2rQYZjO2YAbLwPIasuukTHf2ukWM4DKIP8sp2qLS35A 735 EOTudNFW1ImVOiOKWBt-0A" 736 }]}}} 738 Figure 13 740 3.3.1. Profile Authentication 742 One of the main architecutral principles of the Mesh is bilateral 743 authentication. Every device that is connected to a Mesh profile 744 MUST authenticate the profile it is connecting to and every Mesh 745 profile administrator MUST authenticate devices that are connected. 747 Having created the necessary profile, the device MUST verify that it 748 is connecting to the correct Mesh profile. The best mechanism for 749 achieving this purpose depends on the capabilities of the device 750 being connected. The administration device obviously requires some 751 means of communicating with the user to serve its function. But the 752 device being connected may have a limited display capability or no 753 user interaction capability at all. 755 3.3.1.1. Interactive Devices 757 If the device has user input and display capabilities, it can verify 758 that it is connecting to the correct display by first requesting the 759 user enter the portal account of the profile they wish to connect to, 760 retreiving the profile associated with the device and displaying the 761 profile fingerprint. 763 The client requests the profile for the requested account name: 765 { 766 "GetRequest": { 767 "Account": "test@prismproof.org", 768 "Multiple": false}} 770 Figure 14 772 The response contains the requested profile information. 774 { 775 "GetResponse": { 776 "Status": 201, 777 "StatusDescription": "Operation completed successfully", 778 "Entries": [{ 779 "SignedPersonalProfile": { 780 "Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT", 781 "SignedData": { 782 "unprotected": { 783 "dig": "S512"}, 784 "payload": " 785 ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQUxF 786 SS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVCIsCiAgICAiU2lnbmVkTWFz 787 ... 788 b25zIjogW119fQ" 789 , 790 "signatures": [{ 791 "header": { 792 "kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"}, 793 "protected": " 794 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhhR1g4Z2hibUlhc2FXVEtm 795 UjBhQ0QyLU5Fckh3Z0RXRkIwM2diSk1hZFhSVkpyZmpYc1RxNXFZeEhyRDRDTzQK 796 d0JoWXBkejVyRXJVSmtaUVFQYl9lUSJ9" 797 , 798 "signature": " 799 v0aUBSoxs6FMtFsbWMZViJvVNh3GNliu7CEnw2Ajj-3mRwEtgTFY0H5RiB9AIbI2 800 TODq7JPKm7-6CCUEugXGdh4ZOnu5A2pAbwtotdAZBpNlhTQTuN6EE-OXwZmZSQyG 801 DZil2tIjLxYSlsX6vWB4M00HPPYx44TLvbbNVbTVJpw5gnWTceSw5nzIsUqT3gVE 802 8mCtN2Vo4EWKcMEhUJMx9nUkIaclW9orbA51S3B8QeMGP179cyZ_X_y6TKC3wIB6 803 AUm6ZQtpa_gBRnAmkbJj6-H_zI_OQIUO_IO2ANL3jI7TSiGPA7VhKsTYDTihMPHs 804 wfDAwuxZ2a5enFCczaywlg" 805 }]}}}]}} 807 Figure 15 809 Having received the profile data, the user can then verify that the 810 device is attempting to connect to the correct profile by verifying 811 that the fingerprint shown by the device attempting to connect is 812 correct. 814 3.3.1.2. Constrained Interaction Devices 816 Connection of an Internet of Things 'IoT' device that does not have 817 the ability to accept user input requires a mechanism by which the 818 user can identify the device they wish to connect to their profile 819 and a mechanism to authenticate the profile to the device. 821 If the connecting device has a wired communication capability such as 822 a USB port, this MAY be used to effect the device connection using a 823 standardized interaction profile. But an increasing number of 824 constrained IoT devices are only capable of wireless communication. 826 Configuration of such devices for the purpose of the Mesh requires 827 that we also consider configuration of the wireless networking 828 capabilities at the same time. The precise mechanism by which this 829 is achieved is therefore outside the scope of this particular 830 document. However prototypes have been built and are being 831 considered that make use of some or all of the following 832 communication techniques: 834 o DHCP signalling. 836 o Machine readable device identifiers (barcodes, QRCodes). 838 o Default device profile installed during manufacture. 840 o Optical communication path using camera on administrative device 841 and status light on connecting device to communicate the device 842 identifier, challenge nonce and confirm profile fingerprint. 844 o Speech output on audio capable connecting device. 846 3.3.2. Connection request 848 After the user verifies the device fingerprint as correct, the client 849 posts a device connection request to the portal: 851 { 852 "ConnectStartRequest": { 853 "SignedRequest": { 854 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 855 "SignedData": { 856 "unprotected": { 857 "dig": "S512"}, 858 "payload": " 859 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUFM 860 RUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIkRldmljZSI6 861 ... 862 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 863 , 864 "signatures": [{ 865 "header": { 866 "kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"}, 867 "protected": " 868 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm54cTR3NzdoN2FSdk5weC1r 869 MDNGTTF3b1hEN1lLMTN6RGxzcWltVWRCUjUxWkFzNU0wVnZOOFRwQ3F6aXEzcS0K 870 T1hwbU9FM0xXLXVkSzJSUmVIdmVQZyJ9" 871 , 872 "signature": " 873 GzjZPfI5yYIR1g69NWQOU2zKKAl_AY2wPfLHJohJ_cK1NGBqkfXDQMMhWfmkvkb1 874 qqSja0e1zeNkZbd6HYPy-dXNPIcy-6Bf3sV1IqvVn2-TZQbJO_1VnYdj7Xzj7YG9 875 8FMCiMvtHXUuWtUJdaUzKhxVGlqGPzkROBgODb8CvMV3NVUwykaP5_myvSk9OXIA 876 OSub_jZ3OX4RPklHMXuffqea0AjF_ezixgsMv01ZcvL3mFKnpk_FoRFZjYH9vP-t 877 w7fjP7BmRnN2qB7c3GdfLnbovfw1Fcmi7l2MYZymn9BObm2QVvffiz_UVgJBU-qk 878 PJMj9rTfd4XzjR7Bwf1f6Q" 879 }]}}, 880 "AccountID": "test@prismproof.org"}} 882 Figure 16 884 The portal verifies that the request is accepable and returns the 885 transaction result: 887 { 888 "ConnectStartResponse": {}} 890 Figure 17 892 3.3.3. Administrator Polls Pending Connections 894 The client can poll the portal for the status of pending requests at 895 any time (modulo any service throttling restrictions at the service 896 side). But the request status will only change when an update is 897 posted by an administration device. 899 Since the user is typically connecting a device to their profile, the 900 next step in connecting the device is to start the administration 901 client. When started, the client polls for pending connection 902 requests using ConnectPendingRequest. 904 { 905 "ConnectPendingRequest": { 906 "AccountID": "test@prismproof.org"}} 908 Figure 18 910 The service responds with a list of pending requests: 912 { 913 "ConnectPendingResponse": { 914 "Pending": [{ 915 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 916 "SignedData": { 917 "unprotected": { 918 "dig": "S512"}, 919 "payload": " 920 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUFM 921 RUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIkRldmljZSI6 922 ... 923 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 924 , 925 "signatures": [{ 926 "header": { 927 "kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"}, 928 "protected": " 929 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm54cTR3NzdoN2FSdk5weC1r 930 MDNGTTF3b1hEN1lLMTN6RGxzcWltVWRCUjUxWkFzNU0wVnZOOFRwQ3F6aXEzcS0K 931 T1hwbU9FM0xXLXVkSzJSUmVIdmVQZyJ9" 932 , 933 "signature": " 934 GzjZPfI5yYIR1g69NWQOU2zKKAl_AY2wPfLHJohJ_cK1NGBqkfXDQMMhWfmkvkb1 935 qqSja0e1zeNkZbd6HYPy-dXNPIcy-6Bf3sV1IqvVn2-TZQbJO_1VnYdj7Xzj7YG9 936 8FMCiMvtHXUuWtUJdaUzKhxVGlqGPzkROBgODb8CvMV3NVUwykaP5_myvSk9OXIA 937 OSub_jZ3OX4RPklHMXuffqea0AjF_ezixgsMv01ZcvL3mFKnpk_FoRFZjYH9vP-t 938 w7fjP7BmRnN2qB7c3GdfLnbovfw1Fcmi7l2MYZymn9BObm2QVvffiz_UVgJBU-qk 939 PJMj9rTfd4XzjR7Bwf1f6Q" 940 }]}}]}} 942 Figure 19 944 3.3.4. Administrator updates and publishes the personal profile. 946 The device profile is added to the Personal profile which is then 947 signed by the online signing key. The administration client 948 publishes the updated profile to the Mesh through the portal: 950 { 951 "ConnectPendingRequest": { 952 "AccountID": "test@prismproof.org"}} 954 Figure 20 956 As usual, the service returns the response code: 958 { 959 "ConnectPendingResponse": { 960 "Pending": [{ 961 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 962 "SignedData": { 963 "unprotected": { 964 "dig": "S512"}, 965 "payload": " 966 ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUFM 967 RUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIkRldmljZSI6 968 ... 969 fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0" 970 , 971 "signatures": [{ 972 "header": { 973 "kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"}, 974 "protected": " 975 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm54cTR3NzdoN2FSdk5weC1r 976 MDNGTTF3b1hEN1lLMTN6RGxzcWltVWRCUjUxWkFzNU0wVnZOOFRwQ3F6aXEzcS0K 977 T1hwbU9FM0xXLXVkSzJSUmVIdmVQZyJ9" 978 , 979 "signature": " 980 GzjZPfI5yYIR1g69NWQOU2zKKAl_AY2wPfLHJohJ_cK1NGBqkfXDQMMhWfmkvkb1 981 qqSja0e1zeNkZbd6HYPy-dXNPIcy-6Bf3sV1IqvVn2-TZQbJO_1VnYdj7Xzj7YG9 982 8FMCiMvtHXUuWtUJdaUzKhxVGlqGPzkROBgODb8CvMV3NVUwykaP5_myvSk9OXIA 983 OSub_jZ3OX4RPklHMXuffqea0AjF_ezixgsMv01ZcvL3mFKnpk_FoRFZjYH9vP-t 984 w7fjP7BmRnN2qB7c3GdfLnbovfw1Fcmi7l2MYZymn9BObm2QVvffiz_UVgJBU-qk 985 PJMj9rTfd4XzjR7Bwf1f6Q" 986 }]}}]}} 988 Figure 21 990 3.3.5. Administrator posts completion request. 992 Having accepted the device and connected it to the profile, the 993 administration client creates and signs a connection completion 994 result which is posted to the portal using ConnectCompleteRequest: 996 { 997 "ConnectCompleteRequest": { 998 "Result": { 999 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 1000 "SignedData": { 1001 "unprotected": { 1002 "dig": "S512"}, 1003 "payload": " 1004 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1005 IklkZW50aWZpZXIiOiAiTUM1WFotUUxPUFUtNkNLNFktM0lTWjUtS0hJTFYtQURQ 1006 ... 1007 CmhCcXZGM2NzWEdKOERfLTVhZlY5OWcifV19fX19fQ" 1008 , 1009 "signatures": [{ 1010 "header": { 1011 "kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"}, 1012 "protected": " 1013 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmhiZENhZXQ3MXNzaWlqVkpV 1014 TWduTUNIcExyVjUwNmx5ejZKU25SaFpBNG1YU19FcXluLUNfUjhGQkFSamRMR3EK 1015 TVRsaVBEMDZuM0ZsRk1OdXppMTFmQSJ9" 1016 , 1017 "signature": " 1018 tGk7QPnDx9AinDZbkMHUnSKHDDO0SOTBBDRt-ia3WimTmnpbfPXvdyWhKSwtpyWE 1019 sYx7pQMwufCxtA3v1f02dOMGsJTmQQ44rAmE5InSuFFrWSWoXXZfcfdveiGZg9vj 1020 Mg0_RBDD3pdASLa7ZFQhM1hqmXVCT-zsITzqGHejO3oUWAhRFtWIHycaBWRw4TDM 1021 B4lmQy3qEdgWhbqvllIUPDAw-sBZzRnNRnc4p3SyYXUWAisvdOhjn9ICS9iSeHEY 1022 IvDtR7-Lal2N8mzfRubLEKMtEtj6CEShqTva2sCCgJJEHxyLqcZTUXhE-YGR2nQD 1023 p9KsdZpdLo-RpDVkMnqmQA" 1024 }]}}, 1025 "AccountID": "test@prismproof.org"}} 1027 Figure 22 1029 Again, the service returns the response code: 1031 { 1032 "ConnectCompleteResponse": {}} 1034 Figure 23 1036 3.3.6. Connecting device polls for status update. 1038 As stated previously, the connecting device polls the portal 1039 periodically to determine the status of the pending request using 1040 ConnectStatusRequest: 1042 { 1043 "ConnectStatusRequest": { 1044 "AccountID": "test@prismproof.org", 1045 "DeviceID": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"}} 1047 Figure 24 1049 If the response is that the connection status has not changed, the 1050 service MAY return a response that specifies a minimum retry 1051 interval. In this case however there is a connection result: 1053 { 1054 "ConnectStatusResponse": { 1055 "Result": { 1056 "Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI", 1057 "SignedData": { 1058 "unprotected": { 1059 "dig": "S512"}, 1060 "payload": " 1061 ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg 1062 IklkZW50aWZpZXIiOiAiTUM1WFotUUxPUFUtNkNLNFktM0lTWjUtS0hJTFYtQURQ 1063 ... 1064 CmhCcXZGM2NzWEdKOERfLTVhZlY5OWcifV19fX19fQ" 1065 , 1066 "signatures": [{ 1067 "header": { 1068 "kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"}, 1069 "protected": " 1070 ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmhiZENhZXQ3MXNzaWlqVkpV 1071 TWduTUNIcExyVjUwNmx5ejZKU25SaFpBNG1YU19FcXluLUNfUjhGQkFSamRMR3EK 1072 TVRsaVBEMDZuM0ZsRk1OdXppMTFmQSJ9" 1073 , 1074 "signature": " 1075 tGk7QPnDx9AinDZbkMHUnSKHDDO0SOTBBDRt-ia3WimTmnpbfPXvdyWhKSwtpyWE 1076 sYx7pQMwufCxtA3v1f02dOMGsJTmQQ44rAmE5InSuFFrWSWoXXZfcfdveiGZg9vj 1077 Mg0_RBDD3pdASLa7ZFQhM1hqmXVCT-zsITzqGHejO3oUWAhRFtWIHycaBWRw4TDM 1078 B4lmQy3qEdgWhbqvllIUPDAw-sBZzRnNRnc4p3SyYXUWAisvdOhjn9ICS9iSeHEY 1079 IvDtR7-Lal2N8mzfRubLEKMtEtj6CEShqTva2sCCgJJEHxyLqcZTUXhE-YGR2nQD 1080 p9KsdZpdLo-RpDVkMnqmQA" 1081 }]}}}} 1083 Figure 25 1085 [Should probably unpack further.] 1087 3.4. Adding an application profile to a user profile 1089 Application profiles are published separately from the personal 1090 profile to which they are linked. This allows a device to be given 1091 administration capability for a particular application without 1092 granting administration capability for the profile itself and the 1093 ability to connect additional profiles and devices. 1095 Another advantage of this separation is that an application profile 1096 might be managed by a separate party. In an enterprise, the 1097 application profile for a user's corporate email account could be 1098 managed by the corporate IT department. 1100 A user MAY have multiple application profiles for the same 1101 application. If a user has three email accounts, they would have 1102 three email application profiles, one for each account. 1104 In this example, the user has requested a PaswordProfile to be 1105 created. When populated, this records the usernames and passwords 1106 for the various Web sites that the user has created accounts at and 1107 has requested the Web browser store in the Mesh. 1109 Unlike a traditional password management service, the data stored the 1110 Password Profile is encrypted end to end and can only be decrypted by 1111 the devices that hold a decryption key. 1113 {Example.PasswordProfile1} 1115 Figure 26 1117 The application profile is published to the Mesh in the same way as 1118 any other profile update, via a a Publish transaction: 1120 % Point = Example.Traces.Get (Example.LabelApplicationWeb1); 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 UDF: String (Optional) UDF fingerprint of the public key parameters/ 1222 X509Certificate: Binary (Optional) List of X.509 Certificates 1224 X509Chain: Binary [0..Many] X.509 Certificate chain. 1226 X509CSR: Binary (Optional) X.509 Certificate Signing Request. 1228 4.1.2. Structure: SignedData 1230 Container for JOSE signed data and related attributes. 1232 Data: Binary (Optional) The signed data 1234 4.1.3. Structure: EncryptedData 1236 Container for JOSE encrypted data and related attributes. 1238 Data: Binary (Optional) The encrypted data 1240 4.2. Common Application Classes 1242 4.2.1. Structure: Connection 1244 Describes network connection parameters for an application 1246 ServiceName: String (Optional) DNS address of the server 1248 Port: Integer (Optional) TCP/UDP Port number 1250 Prefix: String (Optional) DNS service prefix as described in 1251 [!RFC6335] 1253 Security: String [0..Many] Describes the security mode to use. 1254 Valid choices are Direct/Upgrade/None 1256 UserName: String (Optional) Username to present to the service for 1257 authentication 1259 Password: String (Optional) Password to present to the service for 1260 authentication 1262 URI: String (Optional) Service connection parameters in URI format 1264 Authentication: String (Optional) List of the supported/acceptable 1265 authentication mechanisms, preferred mechanism first. 1267 TimeOut: Integer (Optional) Service timeout in seconds. 1269 Polling: Boolean (Optional) If set, the client should poll the 1270 specified service intermittently for updates. 1272 5. Mesh Profile Objects 1274 5.1. Base Profile Objects 1276 5.1.1. Structure: Entry 1278 Base class for all Mesh Profile objects. 1280 Identifier: String (Optional) Globally unique identifier that 1281 remains constant for the lifetime of the entry. 1283 5.1.2. Structure: SignedProfile 1285 Inherits: Entry 1287 Contains a signed profile entry 1289 SignedData: JoseWebSignature (Optional) The signed profile. 1291 Note that each child of SignedProfile requires that the Payload 1292 field of the SignedData object contain an object of a specific 1293 type. For example, a SignedDeviceProfile object MUST contain a 1294 Payload field that contains a DeviceProfile object. 1296 Unauthenticated: Advice (Optional) Additional data that is not 1297 authenticated. 1299 5.1.3. Structure: Advice 1301 Additional data bound to a signed profile that is not authenticated. 1303 Default: DateTime (Optional) If specified, the profile was the 1304 default profile at the specified date and time. The current 1305 default for that type of profile is the profile with the most 1306 recent Default timestamp. 1308 5.1.4. Structure: PortalAdvice 1310 Describes the portal(s) at which the profile is registered. 1312 Inherits: Advice 1314 Inherits: Advice 1316 PortalAddress: String [0..Many] A portal address at which this 1317 profile is registered. 1319 5.1.5. Structure: Profile 1321 Inherits: Entry 1323 Parent class from which all profile types are derived 1325 Names: String [0..Many] Fingerprints of index terms for profile 1326 retrieval. The use of the fingerprint of the name rather than the 1327 name itself is a precaution against enumeration attacks and other 1328 forms of abuse. 1330 Updated: DateTime (Optional) The time instant the profile was last 1331 modified. 1333 NotaryToken: String (Optional) A Uniform Notary Token providing 1334 evidence that a signature was performed after the notary token was 1335 created. 1337 5.2. Device Profile Classes 1339 5.2.1. Structure: SignedDeviceProfile 1341 Inherits: SignedProfile 1343 Contains a signed device profile 1345 [No fields] 1347 5.2.2. Structure: DeviceProfile 1349 Inherits: Profile 1351 Describes a mesh device. 1353 Description: String (Optional) Description of the device 1355 DeviceSignatureKey: PublicKey (Optional) Key used to sign 1356 certificates for the DAK and DEK. The fingerprint of the DSK is 1357 the UniqueID of the Device Profile 1359 DeviceAuthenticationKey: PublicKey (Optional) Key used to 1360 authenticate requests made by the device. 1362 DeviceEncryptiontionKey: PublicKey (Optional) Key used to pass 1363 encrypted data to the device such as a DeviceUseEntry 1365 5.2.3. Structure: DevicePrivateProfile 1367 Private portion of device encryption profile. 1369 DeviceSignatureKey: Key (Optional) Private portion of the 1370 DeviceSignatureKey 1372 DeviceAuthenticationKey: Key (Optional) Private portion of the 1373 DeviceAuthenticationKey 1375 DeviceEncryptiontionKey: Key (Optional) Private portion of the 1376 DeviceEncryptiontionKey 1378 5.3. Master Profile Objects 1380 5.3.1. Structure: SignedMasterProfile 1382 Inherits: SignedProfile 1384 Contains a signed Personal master profile 1386 [No fields] 1388 5.3.2. Structure: MasterProfile 1390 Inherits: Profile 1392 Describes the long term parameters associated with a personal 1393 profile. 1395 MasterSignatureKey: PublicKey (Optional) The root of trust for the 1396 Personal PKI, the public key of the PMSK is presented as a self- 1397 signed X.509v3 certificate with Certificate Signing use enabled. 1398 The PMSK is used to sign certificates for the PMEK, POSK and PKEK 1399 keys. 1401 MasterEscrowKeys: PublicKey [0..Many] A Personal Profile MAY contain 1402 one or more PMEK keys to enable escrow of private keys used for 1403 stored data. 1405 OnlineSignatureKeys: PublicKey [0..Many] A Personal profile contains 1406 at least one POSK which is used to sign device administration 1407 application profiles. 1409 5.4. Personal Profile Objects 1411 5.4.1. Structure: SignedPersonalProfile 1413 Inherits: SignedProfile 1415 Contains a signed Personal current profile 1417 [No fields] 1419 5.4.2. Structure: PersonalProfile 1421 Inherits: Profile 1423 Describes the current applications and devices connected to a 1424 personal master profile. 1426 SignedMasterProfile: SignedMasterProfile (Optional) The 1427 corresponding master profile. The profile MUST be signed by the 1428 PMSK. 1430 Devices: SignedDeviceProfile [0..Many] The set of device profiles 1431 connected to the profile. The profile MUST be signed by the DSK 1432 in the profile. 1434 Applications: ApplicationProfileEntry [0..Many] Application profiles 1435 connected to this profile. 1437 5.4.3. Structure: ApplicationProfileEntry 1439 Personal profile entry describing the privileges of specific devices. 1441 Identifier: String (Optional) The unique identifier of the 1442 application 1444 Type: String (Optional) The application type 1446 Friendly: String (Optional) Optional friendly name identifying the 1447 application. 1449 AdminDeviceUDF: String [0..Many] List of devices authorized to sign 1450 application profiles 1452 DecryptDeviceUDF: String [0..Many] List of devices authorized to 1453 read private parts of application profiles. 1455 AccountID: String (Optional) The account at which the profile is 1456 located. 1458 5.5. Application Profile Objects 1460 5.5.1. Structure: SignedApplicationProfile 1462 Inherits: SignedProfile 1464 Contains a signed device profile 1466 [No fields] 1468 5.5.2. Structure: ApplicationProfile 1470 Inherits: Profile 1472 Parent class from which all application profiles inherit. 1474 [No fields] 1476 5.5.3. Structure: ApplicationProfilePrivate 1478 Inherits: Entry 1480 The base class for all private profiles. 1482 [No fields] 1484 5.5.4. Structure: ApplicationDevicePublic 1486 Inherits: Entry 1488 Describes the public per device data 1490 DeviceDescription: String (Optional) Description of the device for 1491 convenience of the user. 1493 DeviceUDF: String (Optional) Fingerprint of device that this key 1494 corresponds to. 1496 5.5.5. Structure: ApplicationDevicePrivate 1498 Inherits: Entry 1500 Describes the private per device data 1502 [No fields] 1504 5.6. Key Escrow Objects 1506 5.6.1. Structure: EscrowEntry 1508 Inherits: Entry 1510 Contains escrowed data 1512 EncryptedData: JoseWebEncryption (Optional) The encrypted escrow 1513 data 1515 5.6.2. Structure: OfflineEscrowEntry 1517 Inherits: EscrowEntry 1519 Contains data escrowed using the offline escrow mechanism. 1521 [No fields] 1523 5.6.3. Structure: OnlineEscrowEntry 1525 Inherits: EscrowEntry 1527 Contains data escrowed using the online escrow mechanism. 1529 [No fields] 1531 5.6.4. Structure: EscrowedKeySet 1533 A set of escrowed keys. 1535 [No fields] 1537 6. Portal Connection 1539 6.1. Connection Request and Response Structures 1541 6.1.1. Structure: ConnectionRequest 1543 Describes a connection request. 1545 ParentUDF: String (Optional) UDF of Mesh Profile to which connection 1546 is requested. 1548 Device: SignedDeviceProfile (Optional) The Device profile to be 1549 connected 1551 6.1.2. Structure: SignedConnectionRequest 1553 Inherits: SignedProfile 1555 Contains a ConnectionRequest signed by the corresponding device 1556 signature key. 1558 [No fields] 1560 6.1.3. Structure: ConnectionResult 1562 Describes the result of a connection request. 1564 Inherits: ConnectionRequest 1566 Inherits: ConnectionRequest 1568 Result: String (Optional) The result of the connection request. 1569 Valid responses are: Accepted, Refused, Query. 1571 6.1.4. Structure: SignedConnectionResult 1573 Inherits: SignedProfile 1575 Contains a signed connection result 1577 [No fields] 1579 7. Mesh Portal Service Reference 1581 HTTP Well Known Service Prefix: /.well-known/mmm 1583 Every Mesh Portal Service transaction consists of exactly one request 1584 followed by exactly one response. Mesh Service transactions MAY 1585 cause modification of the data stored in the Mesh Portal or the Mesh 1586 itself but do not cause changes to the connection state. The 1587 protocol itself is thus idempotent. There is no set sequence in 1588 which operations are required to be performed. It is not necessary 1589 to perform a Hello transaction prior to a ValidateAccount, Publish or 1590 any other transaction. 1592 7.1. Request Messages 1594 A Mesh Portal Service request consists of a payload object that 1595 inherits from the MeshRequest class. When using the HTTP binding, 1596 the request MUST specify the portal DNS address in the HTTP Host 1597 field. 1599 7.1.1. Message: MeshRequest 1601 Base class for all request messages. 1603 Portal: String (Optional) Name of the Mesh Portal Service to which 1604 the request is directed. 1606 7.2. Response Messages 1608 A Mesh Portal Service response consists of a payload object that 1609 inherits from the MeshResponse class. When using the HTTP binding, 1610 the response SHOULD report the Status response code in the HTTP 1611 response message. However the response code returned in the payload 1612 object MUST always be considered authoritative. 1614 7.2.1. Message: MeshResponse 1616 Base class for all response messages. Contains only the status code 1617 and status description fields. 1619 [No fields] 1621 7.3. Imported Objects 1623 The Mesh Service protocol makes use of JSON objects defined in the 1624 JOSE Signatgure and Encryption specifications. 1626 7.4. Common Structures 1628 The following common structures are used in the protocol messages: 1630 7.4.1. Structure: KeyValue 1632 Describes a Key/Value structure used to make queries for records 1633 matching one or more selection criteria. 1635 Key: String (Optional) The data retrieval key. 1637 Value: String (Optional) The data value to match. 1639 7.4.2. Structure: SearchConstraints 1641 Specifies constraints to be applied to a search result. These allow 1642 a client to limit the number of records returned, the quantity of 1643 data returned, the earliest and latest data returned, etc. 1645 NotBefore: DateTime (Optional) Only data published on or after the 1646 specified time instant is requested. 1648 Before: DateTime (Optional) Only data published before the specified 1649 time instant is requested. This excludes data published at the 1650 specified time instant. 1652 MaxEntries: Integer (Optional) Maximum number of data entries to 1653 return. 1655 MaxBytes: Integer (Optional) Maximum number of data bytes to return. 1657 PageKey: String (Optional) Specifies a page key returned in a 1658 previous search operation in which the number of responses 1659 exceeded the specified bounds. 1661 When a page key is specified, all the other search parameters 1662 except for MaxEntries and MaxBytes are ignored and the service 1663 returns the next set of data responding to the earlier query. 1665 7.5. Transaction: Hello 1667 Request: HelloRequest 1669 Request: HelloRequest 1671 Response: HelloResponse 1673 Report service and version information. 1675 The Hello transaction provides a means of determining which protocol 1676 versions, message encodings and transport protocols are supported by 1677 the service. 1679 7.6. Transaction: ValidateAccount 1681 Request: ValidateRequest 1683 Request: ValidateRequest 1685 Response: ValidateResponse 1687 Request validation of a proposed name for a new account. 1689 For validation of a user's account name during profile creation. 1691 7.6.1. Message: ValidateRequest 1693 Inherits: MeshRequest 1694 Describes the proposed account properties. Currently, these are 1695 limited to the account name but could be extended in future versions 1696 of the protocol. 1698 Account: String (Optional) Account name requested 1700 Reserve: Boolean (Optional) If true, request a reservation for the 1701 specified account name. Note that the service is not obliged to 1702 honor reservation requests. 1704 Language: String [0..Many] List of ISO language codes in order of 1705 preference. For creating explanatory text. 1707 7.6.2. Message: ValidateResponse 1709 Inherits: MeshResponse 1711 States whether the proposed account properties are acceptable and 1712 (optional) returns an indication of what properties are valid. 1714 Note that receiving a 'Valid' responseto a Validate Request does not 1715 guarantee creation of the account. In addition to the possibility 1716 that the account namecould be requested by another user between the 1717 Validate and Create transactions, a portal service MAY perform more 1718 stringent validation criteria when an account is actually being 1719 created. For example, checking with the authoritative list of 1720 current accounts rather than a cached copy. 1722 Valid: Boolean (Optional) If true, the specified account identifier 1723 is acceptable. If false, the account identifier is rejected. 1725 Minimum: Integer (Optional) Specifies the minimum length of an 1726 account name. 1728 Maximum: Integer (Optional) Specifies the maximum length of an 1729 account name. 1731 InvalidCharacters: String (Optional) A list of characters that the 1732 service does not accept in account names. The list of characters 1733 MAY not be exhaustive but SHOULD include any illegal characters in 1734 the proposed account name. 1736 Reason: String (Optional) Text explaining the reason an account name 1737 was rejected. 1739 7.7. Transaction: CreateAccount 1741 Request: CreateRequest 1743 Request: CreateRequest 1745 Response: CreateResponse 1747 Request creation of a new portal account. 1749 Unlike a profile, a mesh account is specific to a particular Mesh 1750 portal. A mesh account must be created and accepted before a profile 1751 can be published. 1753 7.7.1. Message: CreateRequest 1755 Request creation of a new portal account. The request specifies the 1756 requested account identifier and the Mesh profile to be associated 1757 with the account. 1759 Inherits: MeshRequest 1761 Inherits: MeshRequest 1763 Account: String (Optional) Account identifier requested. 1765 7.7.2. Message: CreateResponse 1767 Inherits: MeshResponse 1769 Reports the success or failure of a Create transaction. 1771 [No fields] 1773 7.8. Transaction: DeleteAccount 1775 Request: DeleteRequest 1777 Request: DeleteRequest 1779 Response: DeleteResponse 1781 Request deletion of a portal account. 1783 Deletes a portal account but not the underlying profile. Once 1784 registered, profiles are permanent. 1786 7.8.1. Message: DeleteRequest 1788 Request deletion of a new portal account. The request specifies the 1789 requested account identifier. 1791 Inherits: MeshRequest 1793 Inherits: MeshRequest 1795 Account: String (Optional) Account identifier to be deleted. 1797 7.8.2. Message: DeleteResponse 1799 Inherits: MeshResponse 1801 Reports the success or failure of a Delete transaction. 1803 [No fields] 1805 7.9. Transaction: Get 1807 Request: GetRequest 1809 Request: GetRequest 1811 Response: GetResponse 1813 Search for data in the mesh that matches a set of properties 1814 described by a sequence of key/value pairs. 1816 7.9.1. Message: GetRequest 1818 Describes the Portal or Mesh data to be retreived. 1820 Inherits: MeshRequest 1822 Inherits: MeshRequest 1824 Identifier: String (Optional) Lookup by profile ID 1826 Account: String (Optional) Lookup by Account ID 1828 KeyValues: KeyValue [0..Many] List of KeyValue pairs specifying the 1829 conditions to be met 1831 SearchConstraints: SearchConstraints (Optional) Constrain the search 1832 to a specific time interval and/or limit the number and/or total 1833 size of data records returned. 1835 Multiple: Boolean (Optional) If true return multiple responses if 1836 available 1838 Full: Boolean (Optional) If true, the client requests that the full 1839 Mesh data record be returned containing both the Mesh entry itself 1840 and the Mesh metadata that allows the date and time of the 1841 publication of the Mesh entry to be verified. 1843 7.9.2. Message: GetResponse 1845 Reports the success or failure of a Get transaction. If a Mesh entry 1846 matching the specified profile is found, containsthe list of entries 1847 matching the request. 1849 Inherits: MeshResponse 1851 Inherits: MeshResponse 1853 DataItems: DataItem [0..Many] List of mesh data records matching the 1854 request. 1856 PageKey: String (Optional) If non-null, indicates that the number 1857 and/or size of the data records returned exceeds either the 1858 SearchConstraints specified in the request or internal server 1859 limits. 1861 7.10. Transaction: Publish 1863 Request: PublishRequest 1865 Request: PublishRequest 1867 Response: PublishResponse 1869 Publish a profile or key escrow entry to the mesh. 1871 7.10.1. Message: PublishRequest 1873 Requests publication of the specified Mesh entry. 1875 Inherits: MeshRequest 1877 [No fields] 1879 7.10.2. Message: PublishResponse 1881 Reports the success or failure of a Publish transaction. 1883 Inherits: MeshResponse 1885 [No fields] 1887 7.11. Transaction: Status 1889 Request: StatusRequest 1891 Request: StatusRequest 1893 Response: StatusResponse 1895 Request the current status of the mesh as seen by the portal to which 1896 it is directed. 1898 The response to the status request contains the last signed 1899 checkpoint and proof chains for each of the peer portals that have 1900 been checkpointed. 1902 [Not currently implemented] 1904 7.11.1. Message: StatusRequest 1906 Inherits: MeshRequest 1908 Initiates a status transaction. 1910 [No fields] 1912 7.11.2. Message: StatusResponse 1914 Reports the success or failure of a Status transaction. 1916 Inherits: MeshResponse 1918 Inherits: MeshResponse 1920 LastWriteTime: DateTime (Optional) Time that the last write update 1921 was made to the Mesh 1923 LastCheckpointTime: DateTime (Optional) Time that the last Mesh 1924 checkpoint was calculated. 1926 NextCheckpointTime: DateTime (Optional) Time at which the next Mesh 1927 checkpoint should be calculated. 1929 CheckpointValue: String (Optional) Last checkpoint value. 1931 7.12. Transaction: ConnectStart 1933 Request: ConnectStartRequest 1935 Request: ConnectStartRequest 1937 Response: ConnectStartResponse 1939 Request connection of a new device to a mesh profile 1941 7.12.1. Message: ConnectStartRequest 1943 Inherits: MeshRequest 1945 Initial device connection request. 1947 SignedRequest: SignedConnectionRequest (Optional) Device connection 1948 request signed by thesignature key of the device requesting 1949 connection. 1951 AccountID: String (Optional) Account identifier of account to which 1952 the device is requesting connection. 1954 7.12.2. Message: ConnectStartResponse 1956 Reports the success or failure of a ConnectStart transaction. 1958 Inherits: MeshRequest 1960 [No fields] 1962 7.13. Transaction: ConnectStatus 1964 Request: ConnectStatusRequest 1966 Request: ConnectStatusRequest 1968 Response: ConnectStatusResponse 1970 Request status of pending connection request of a new device to a 1971 mesh profile 1973 7.13.1. Message: ConnectStatusRequest 1975 Inherits: MeshRequest 1977 Request status information for a pending request posted previously. 1979 AccountID: String (Optional) Account identifier for which pending 1980 connection information is requested. 1982 DeviceID: String (Optional) Device identifier of device requesting 1983 status information. 1985 7.13.2. Message: ConnectStatusResponse 1987 Reports the success or failure of a ConnectStatus transaction. 1989 Inherits: MeshRequest 1991 Inherits: MeshRequest 1993 Result: SignedConnectionResult (Optional) The signed 1994 ConnectionResult object. 1996 7.14. Transaction: ConnectPending 1998 Request: ConnectPendingRequest 2000 Request: ConnectPendingRequest 2002 Response: ConnectPendingResponse 2004 Request a list of pending requests for an administration profile. 2006 7.14.1. Message: ConnectPendingRequest 2008 Inherits: MeshRequest 2010 Specify the criteria for pending requests. 2012 AccountID: String (Optional) The account identifier of the account 2013 for which pending connection requests are requested. 2015 SearchConstraints: SearchConstraints (Optional) Constrain the search 2016 to a specific time interval and/or limit the number and/or total 2017 size of data records returned. 2019 7.14.2. Message: ConnectPendingResponse 2021 Reports the success or failure of a ConnectPending transaction. 2023 Inherits: MeshRequest 2025 Inherits: MeshRequest 2027 Pending: SignedConnectionRequest [0..Many] A list of pending 2028 requests satisfying the criteria set out in the request. 2030 PageKey: String (Optional) If non-null, indicates that the number 2031 and/or size of the data records returned exceeds either the 2032 SearchConstraints specified in the request or internal server 2033 limits. 2035 7.15. Transaction: ConnectComplete 2037 Request: ConnectCompleteRequest 2039 Request: ConnectCompleteRequest 2041 Response: ConnectCompleteResponse 2043 Post response to a pending connection request. 2045 7.15.1. Message: ConnectCompleteRequest 2047 Reports the success or failure of a ConnectComplete transaction. 2049 Inherits: MeshRequest 2051 Inherits: MeshRequest 2053 Result: SignedConnectionResult (Optional) The connection result to 2054 be posted to the portal. The result MUST be signed by a valid 2055 administration key for the Mesh profile. 2057 AccountID: String (Optional) The account identifier to which the 2058 connection result is posted. 2060 7.15.2. Message: ConnectCompleteResponse 2062 Inherits: MeshRequest 2064 Reports the success or failure of a ConnectComplete transaction. 2066 [No fields] 2068 7.16. Transaction: Transfer 2070 Request: TransferRequest 2072 Request: TransferRequest 2074 Response: TransferResponse 2076 Perform a bulk transfer of the log between the specified transaction 2077 identifiers. Requires appropriate authorization 2079 [Not currently implemented] 2081 7.16.1. Message: TransferRequest 2083 Request a bulk transfer of the log between the specified transaction 2084 identifiers. Requires appropriate authorization 2086 Inherits: MeshRequest 2088 Inherits: MeshRequest 2090 SearchConstraints: SearchConstraints (Optional) Constrain the search 2091 to a specific time interval and/or limit the number and/or total 2092 size of data records returned. 2094 7.16.2. Message: TransferResponse 2096 Inherits: MeshResponse 2098 Reports the success or failure of a Transfer transaction. If 2099 successful, contains the list of Mesh records to be transferred. 2101 DataItems: DataItem [0..Many] List of mesh data records matching the 2102 request. 2104 PageKey: String (Optional) If non-null, indicates that the number 2105 and/or size of the data records returned exceeds either the 2106 SearchConstraints specified in the request or internal server 2107 limits. 2109 8. Security Considerations 2111 9. IANA Considerations 2113 All the IANA considerations for the Mesh documents are specified in 2114 this document 2116 10. Acknowledgements 2118 11. References 2120 11.1. Normative References 2122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2123 Requirement Levels", BCP 14, RFC 2119, 2124 DOI 10.17487/RFC2119, March 1997. 2126 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2127 Cheshire, "Internet Assigned Numbers Authority (IANA) 2128 Procedures for the Management of the Service Name and 2129 Transport Protocol Port Number Registry", BCP 165, 2130 RFC 6335, DOI 10.17487/RFC6335, August 2011. 2132 11.2. Informative References 2134 [draft-hallambaker-mesh-architecture] 2135 Hallam-Baker, P., "Mathematical Mesh: Architecture", 2136 draft-hallambaker-mesh-architecture-04 (work in progress), 2137 September 2017. 2139 [draft-hallambaker-mesh-developer] 2140 Hallam-Baker, P., "Mathematical Mesh: Reference 2141 Implementation", draft-hallambaker-mesh-developer-06 (work 2142 in progress), April 2018. 2144 [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 2145 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, 2146 August 1982. 2148 11.3. URIs 2150 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 2151 reference.html 2153 Author's Address 2155 Phillip Hallam-Baker 2156 Comodo Group Inc. 2158 Email: philliph@comodo.com