| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Intended status: Informational | April 10, 2018 |
| Expires: October 12, 2018 |
Mathematical Mesh: Reference
draft-hallambaker-mesh-reference-08
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.
This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-reference.html .
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
NB: The reference material in this document is generated from the schema used to derive the source code. The tool used to create this material has not been optimized to produce output for the IETF documentation format at this time. Consequently, the formatting is currently sub-optimal.
This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
The terms of art used in this document are described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] .
The architecture of the Mathematical Mesh is described in the Mesh Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh documentation set and related specifications are described in this document.
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer] .
[Account request does not specify the portal in the request body, only the HTTP package includes this information. This is probably a bug.]
A user interacts with a Mesh service through a Mesh portal provider with which she establishes a portal account.
For user convenience, a portal account identifier has the familiar <username>@<domain> format established in [~RFC822].
For example Alice selects example.com as her portal provider and chooses the account name alice. Her portal account identifier is alice.
A user MAY establish accounts with multiple portal providers and/or change their portal provider at any time they choose.
The first step in creating a new account is to check to see if the chosen account identifier is available. This allows a client to validate user input and if necessary warn the user that they need to choose a new account identifier when the data is first entered.
The ValidateRequest message contains the requested account identifier and an optional language parameter to allow the service to provide informative error messages in a language the user understands. The Language field contains a list of ISO language identifier codes in order of preference, most preferred first.
POST /.well-known/mmm/HTTP/1.1
Host: example.com
Content-Length: 90
{
"ValidateRequest": {
"Account": "test@prismproof.org",
"Language": ["en-uk"]}}
Figure 1
The ValidateResponse message returns the result of the validation request in the Valid field. Note that even if the value true is returned, a subsequent account creation request MAY still fail.
HTTP/1.1 200 OK
Date: Mon 04 Dec 2017 03:38:57
Content-Length: 190
{
"ValidateResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully",
"Valid": true,
"Minimum": 1,
"InvalidCharacters": ".,:;{}()[]<>?|\\@#"}}
Figure 2
[Note that for the sake of concise presentation, the HTTP binding information is omitted from future examples.]
The first step in creating a new personal profile is to create a Master Profile object. This contains the long term Master Signing Key that will remain constant for the life of the profile, at least one Online Signature Key to be used for administering the personal profile and (optionally), one or more master escrow keys.
For convenience, the descriptions of the Master Signing Key, Online Signing Keys and Escrow Keys typically include PKIX certificates signed by the Master Signing Key. This allows PKIX based applications to make use of PKIX certificate chains to express the same trust relationships described in the Mesh.
{
"MasterProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"MasterSignatureKey": {
"UDF": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"X509Certificate": "
MIIFXTCCBEWgAwIBAgIRAMLMDJuKzpOYUgyGu-pFSoswDQYJKoZIhvcNAQENBQAw
LjEsMCoGA1UEAxYjTUFMRUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1Qw
...
9c8HDZ9z9BHj_XwoShvX9neZiiQ26Pw9rJLNJ70Q7Nsi"
,
"PublicParameters": {
"PublicKeyRSA": {
"kid": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"n": "
-OVfAVjglTViCa7GRMcZdX8zfuALOIMoVU9itSc6zIZPDNM_D1g_-wI_bM0duKXT
Y2B3gtZJBe6tnlLK2PPnwVEqo1srSmIBGTwgRM_wlJmjQ46rET0SMEI1GuVRqvah
pxqq59XqfDYqydqOvtDcqavgyW33S1UXI7KVSJgwagk3QFnIoErh8bnK54Gdpz-L
BA7EICHqD2Md4pdRVCY1-JFYrG1wX0B5DZzCUQ6fd-TBt4BEBH3ERLQhqQMwIE7x
CaEBahklcP_44FgSmeT21sQFSHhBPZxdqmfAEefKPKu9vuo3XETeSRs3HTrtoImF
IZj421mieaQc0vTYNWL2pQ"
,
"e": "
AQAB"
}}},
"MasterEscrowKeys": [{
"UDF": "MCYWE-GQRSM-NOK5T-3UVLY-AHJF6-T4GZC",
"X509Certificate": "
MIIFXDCCBESgAwIBAgIQCLpDHbhuyKQxHbawBVlw4TANBgkqhkiG9w0BAQ0FADAu
MSwwKgYDVQQDFiNNQUxFSS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVDAe
...
mQ46FsAdzE42gLKnIN7IXYHbHr-bbw-5fW1bdQ840O8"
,
"PublicParameters": {
"PublicKeyRSA": {
"kid": "MCYWE-GQRSM-NOK5T-3UVLY-AHJF6-T4GZC",
"n": "
0aPb4XHnVtVIGWXc8t1mvCkf52UC8NRKPZkjNVY0bY8WwNtUNWbn-Tqv5ncS9hVz
gaRvQIM9U_4JZgwviuy2srJj0_c1yQtGIbBIRsrWt6wfx_gM0g1YCty_06hCrOu0
54JzRMm6wpLcmmws-Ip9rIL931zoNx5HvWEp5bUMFv3qENbYzlAPizobxSDinMLJ
R0gfTPz4FwillrnWRWhsWZ3VscDGZxYTsI3wZhi60B7LDdmTkr9KqXiVt7fefUSP
bGAYGQLuh_296O_Hh6F6N6V2UhvncD0K9F4t6DBt7_H06HojqLrUWsD1juVilE3h
dfFYaMEgyo9bxMIefKeQXQ"
,
"e": "
AQAB"
}}}],
"OnlineSignatureKeys": [{
"UDF": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT",
"X509Certificate": "
MIIFXDCCBESgAwIBAgIQPcM0MUJ9c57N4f_Z_9uSsDANBgkqhkiG9w0BAQ0FADAu
MSwwKgYDVQQDFiNNQUxFSS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVDAe
...
eljXhyaFB_QYGvKRAtyaSnU9m51xLX28D5bNq8LO53M"
,
"PublicParameters": {
"PublicKeyRSA": {
"kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT",
"n": "
yVcObdfLYL_Gh36yY_bprL8W7rEgax8Nbe2KFSZWkWayGps79C16pqOV0Doapko1
Lnbb-uB0BTS-Qw6A0F_0ZQyEaWzBMycvPT0Gr87unC-Ow3IaYeA2TbKNMg8Yvd_d
LB4nwWqWianYhV2nSbG4Tfem9zyYvrhG-DcKeMgQmSV6WgdwMCVEdKuuBxl5SL2D
GvmLwDwfRRX3tk0QGraagjywOCjmBd5F2WPaUtKV8HZtT9H9hI6YyztKrL_mp12P
itds_krRRLWf2OFNFMQau93zYxtNObu3xshu3hDzDHL_81pmXzMQ_AZ0vjF7-PA1
dC0VpPs3xxbXRNw64Kf_3Q"
,
"e": "
AQAB"
}}}]}}
Figure 3
The Master Profile is always signed using the Master Signing Key:
{
"SignedMasterProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFMRUkt
R1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIk1hc3RlclNpZ25h
...
In19fV19fQ"
,
"signatures": [{
"header": {
"kid": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnpuZERBMjFPSkZtZk1pdWV6
RWV6dThHWUJzWEVOSXVKZmFOMjJwWV9hTzNHeGl6ZjM3emJVVzFPNEVReDJFZ0IK
cURmRXJwVDdpX2VPVzBYWGk5VmdDUSJ9"
,
"signature": "
D0cg0pN4-50S1ilo9wrfI6u-R5NvAuZo8j5-XIBr1AylzMDWZk5YpdtoUM1q8FIR
sXVzetQ_6l8zc6fVzUJt7fMN8yBvc9v6owcFBNrujJSHsBU2u_DGxdhH1DW_4MU4
rTGXzek3__8jxo-q8LyzBfX2Wl3jzZz5VP_LhPdRjNFKTuU1e-KlLU43imvn8WTB
TYQas3JVWUgdsyH3OZ-FQ7Z06tNUtmza6qCK2HqRaUmJZ9P35835MaJbZX8D87WB
7R3KHWPNCO8bBkzXJCaM86E0wmYna3u1BuJ1Bg1bPY3t-iqVxv59FPHLB24TVMWP
WQIhxuUIJt5QYj_BhjmeBg"
}]}}}
Figure 4
Since the device used to create the personal profile is typically connected to the profile, a Device profile entry is created for it. This contains a Device Signing Key, a Device Encryption Key and a Device Authentication Key:
{
"JoseWebSignature": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURLVVIt
VFBaUU8tNlo3U1AtUUNFUjYtN0tRU0QtQ05STlEiLAogICAgIk5hbWVzIjogWyJE
...
OUxjUVpRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19"
,
"signatures": [{
"header": {
"kid": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjFUX0ExbGFSY1M4OWszbFpk
aklSNUx5LVBJWlM5QUM4XzJlWmUyLUF3SXJVMzIwbFNKakhCcU1VRnBTczBTczcK
dzdva1dlV0YtV1VQcll3WjJUU2JFZyJ9"
,
"signature": "
PUZrcYPUfJRxvKMnPJ6U6mgSx3lJoyY_Q-Takf0ZrnRMbjKi1Nn2nLFlfTi_htVO
Rn45WrLIR-hnZbKLWFkwsNg2HZ55MELcF0Cnvbzb8nj0roy3vc6FSJF5aZiFEn6u
hAAimDiA8HHta0J7nzlStYPeqrb_s0XDiNfpp7aSqckVdGZC2XKhx1RgQuF5ctp3
zLOGzV0Y5No312QmIagOXcLFLXG0awxhvEHhyhsALnQX8rd0z4AZmZavKCHufbcE
n-nRts8GzgcKmnRpmOuPdGhtT-PI8Gn7-sxfb4R95Taf_7_fvLLNG0Sot4DMTMuP
xovBNY1eA23ZHtw9AvmTAg"
}]}}
Figure 5
The Device Profile is signed using the Device Signing Key:
{
"SignedDeviceProfile": {
"Identifier": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURLVVIt
VFBaUU8tNlo3U1AtUUNFUjYtN0tRU0QtQ05STlEiLAogICAgIk5hbWVzIjogWyJE
...
OUxjUVpRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19"
,
"signatures": [{
"header": {
"kid": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjFUX0ExbGFSY1M4OWszbFpk
aklSNUx5LVBJWlM5QUM4XzJlWmUyLUF3SXJVMzIwbFNKakhCcU1VRnBTczBTczcK
dzdva1dlV0YtV1VQcll3WjJUU2JFZyJ9"
,
"signature": "
PUZrcYPUfJRxvKMnPJ6U6mgSx3lJoyY_Q-Takf0ZrnRMbjKi1Nn2nLFlfTi_htVO
Rn45WrLIR-hnZbKLWFkwsNg2HZ55MELcF0Cnvbzb8nj0roy3vc6FSJF5aZiFEn6u
hAAimDiA8HHta0J7nzlStYPeqrb_s0XDiNfpp7aSqckVdGZC2XKhx1RgQuF5ctp3
zLOGzV0Y5No312QmIagOXcLFLXG0awxhvEHhyhsALnQX8rd0z4AZmZavKCHufbcE
n-nRts8GzgcKmnRpmOuPdGhtT-PI8Gn7-sxfb4R95Taf_7_fvLLNG0Sot4DMTMuP
xovBNY1eA23ZHtw9AvmTAg"
}]}}}
Figure 6
A personal profile would typically contain at least one application when first created. For the sake of demonstration, we will do this later.
The personal profile thus consists of the master profile and the device profile:
{
"PersonalProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"SignedMasterProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJNYXN0ZXJQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUFMRUkt
R1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIk1hc3RlclNpZ25h
...
In19fV19fQ"
,
"signatures": [{
"header": {
"kid": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCnpuZERBMjFPSkZtZk1pdWV6
RWV6dThHWUJzWEVOSXVKZmFOMjJwWV9hTzNHeGl6ZjM3emJVVzFPNEVReDJFZ0IK
cURmRXJwVDdpX2VPVzBYWGk5VmdDUSJ9"
,
"signature": "
D0cg0pN4-50S1ilo9wrfI6u-R5NvAuZo8j5-XIBr1AylzMDWZk5YpdtoUM1q8FIR
sXVzetQ_6l8zc6fVzUJt7fMN8yBvc9v6owcFBNrujJSHsBU2u_DGxdhH1DW_4MU4
rTGXzek3__8jxo-q8LyzBfX2Wl3jzZz5VP_LhPdRjNFKTuU1e-KlLU43imvn8WTB
TYQas3JVWUgdsyH3OZ-FQ7Z06tNUtmza6qCK2HqRaUmJZ9P35835MaJbZX8D87WB
7R3KHWPNCO8bBkzXJCaM86E0wmYna3u1BuJ1Bg1bPY3t-iqVxv59FPHLB24TVMWP
WQIhxuUIJt5QYj_BhjmeBg"
}]}},
"Devices": [{
"Identifier": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTURLVVIt
VFBaUU8tNlo3U1AtUUNFUjYtN0tRU0QtQ05STlEiLAogICAgIk5hbWVzIjogWyJE
...
OUxjUVpRIiwKICAgICAgICAgICJlIjogIgpBUUFCIn19fX19"
,
"signatures": [{
"header": {
"kid": "MDKUR-TPZQO-6Z7SP-QCER6-7KQSD-CNRNQ"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjFUX0ExbGFSY1M4OWszbFpk
aklSNUx5LVBJWlM5QUM4XzJlWmUyLUF3SXJVMzIwbFNKakhCcU1VRnBTczBTczcK
dzdva1dlV0YtV1VQcll3WjJUU2JFZyJ9"
,
"signature": "
PUZrcYPUfJRxvKMnPJ6U6mgSx3lJoyY_Q-Takf0ZrnRMbjKi1Nn2nLFlfTi_htVO
Rn45WrLIR-hnZbKLWFkwsNg2HZ55MELcF0Cnvbzb8nj0roy3vc6FSJF5aZiFEn6u
hAAimDiA8HHta0J7nzlStYPeqrb_s0XDiNfpp7aSqckVdGZC2XKhx1RgQuF5ctp3
zLOGzV0Y5No312QmIagOXcLFLXG0awxhvEHhyhsALnQX8rd0z4AZmZavKCHufbcE
n-nRts8GzgcKmnRpmOuPdGhtT-PI8Gn7-sxfb4R95Taf_7_fvLLNG0Sot4DMTMuP
xovBNY1eA23ZHtw9AvmTAg"
}]}}],
"Applications": []}}
Figure 7
The personal profile is then signed using the Online Signing Key:
{
"SignedPersonalProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQUxF
SS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVCIsCiAgICAiU2lnbmVkTWFz
...
b25zIjogW119fQ"
,
"signatures": [{
"header": {
"kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhhR1g4Z2hibUlhc2FXVEtm
UjBhQ0QyLU5Fckh3Z0RXRkIwM2diSk1hZFhSVkpyZmpYc1RxNXFZeEhyRDRDTzQK
d0JoWXBkejVyRXJVSmtaUVFQYl9lUSJ9"
,
"signature": "
v0aUBSoxs6FMtFsbWMZViJvVNh3GNliu7CEnw2Ajj-3mRwEtgTFY0H5RiB9AIbI2
TODq7JPKm7-6CCUEugXGdh4ZOnu5A2pAbwtotdAZBpNlhTQTuN6EE-OXwZmZSQyG
DZil2tIjLxYSlsX6vWB4M00HPPYx44TLvbbNVbTVJpw5gnWTceSw5nzIsUqT3gVE
8mCtN2Vo4EWKcMEhUJMx9nUkIaclW9orbA51S3B8QeMGP179cyZ_X_y6TKC3wIB6
AUm6ZQtpa_gBRnAmkbJj6-H_zI_OQIUO_IO2ANL3jI7TSiGPA7VhKsTYDTihMPHs
wfDAwuxZ2a5enFCczaywlg"
}]}}}
Figure 8
Once the signed personal profile is created, the client can finaly make the request for the service to create the account. The request object contains the requested account identifier and profile:
{
"CreateRequest": {
"Account": "test@prismproof.org",
"Profile": {
"SignedPersonalProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQUxF
SS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVCIsCiAgICAiU2lnbmVkTWFz
...
b25zIjogW119fQ"
,
"signatures": [{
"header": {
"kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhhR1g4Z2hibUlhc2FXVEtm
UjBhQ0QyLU5Fckh3Z0RXRkIwM2diSk1hZFhSVkpyZmpYc1RxNXFZeEhyRDRDTzQK
d0JoWXBkejVyRXJVSmtaUVFQYl9lUSJ9"
,
"signature": "
v0aUBSoxs6FMtFsbWMZViJvVNh3GNliu7CEnw2Ajj-3mRwEtgTFY0H5RiB9AIbI2
TODq7JPKm7-6CCUEugXGdh4ZOnu5A2pAbwtotdAZBpNlhTQTuN6EE-OXwZmZSQyG
DZil2tIjLxYSlsX6vWB4M00HPPYx44TLvbbNVbTVJpw5gnWTceSw5nzIsUqT3gVE
8mCtN2Vo4EWKcMEhUJMx9nUkIaclW9orbA51S3B8QeMGP179cyZ_X_y6TKC3wIB6
AUm6ZQtpa_gBRnAmkbJj6-H_zI_OQIUO_IO2ANL3jI7TSiGPA7VhKsTYDTihMPHs
wfDAwuxZ2a5enFCczaywlg"
}]}}}}}
Figure 9
The service reports the success (or failure) of the account creation request:
{
"CreateResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully"}}
Figure 10
Connecting a device to a profile requires the client on the new device to interact with a client on a device that has administration capabilities, i.e. it has access to an Online Signing Key. Since clients cannot interact directly with other clients, a service is required to mediate the connection. This service is provided by a Mesh portal provider.
All service transactions are initiated by the clients. First the connecting device posts ConnectStart, after which it may poll for the outcome of the connection request using ConnectStatus.
Periodically, the Administration Device polls for a list of pending connection requests using ConnectPending. After posting a request, the administration device posts the result using ConnectComplete:
Connecting Mesh Administration Device Service Device | | | | ConnectStart | | | ----------------------> | | | | ConnectPending | | | <---------------------- | | | | | | ConnectComplete | | | <---------------------- | | ConnectStatus | | | ----------------------> | |
Figure 11
The first step in the process is for the client to generate a device profile. Ideally the device profile is bound to the device in a read-only fashion such that applications running on the device can make use of the deencryption and authentication keys but these private keys cannot be extracted from the device:
{
"DeviceProfile": {
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"Names": ["Default"],
"Description": "Unknown",
"DeviceSignatureKey": {
"UDF": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"PublicParameters": {
"PublicKeyRSA": {
"kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"n": "
8cxQYz71dYg24QyipvRGE6MAaoWBuFHASmD9LwSFs_A3P-CkxJ9MULvg_VNLpME_
HeNMZPNUDzZEjaUCftNUo77fhHP55xA2s9qlf0l-iYzeJjw9F0nEGNSaQOvJzKV1
VitQuAw546tSNle4I2iNI1caqnDG0567I8mYwZRmifXKuLfXRB3dG-ZiAleeP3R9
5l4aQX3DXpqSMgyl9R5NA5-m9Lv6gjBEuQ2j5BESulXKjiSH8BNjrSIbrFTdesv4
25RNY19gsfOppwvCBp1Fqv5aSc5uAdP6gtkgZ0S2KNPvnlrSl-LKfTy_CPH9kyzy
J8atJh_8pvVgr3LnVD5H-Q"
,
"e": "
AQAB"
}}},
"DeviceAuthenticationKey": {
"UDF": "MBVAM-ERHD2-PPPG3-7VWRP-U4AY2-7VOQ5",
"PublicParameters": {
"PublicKeyRSA": {
"kid": "MBVAM-ERHD2-PPPG3-7VWRP-U4AY2-7VOQ5",
"n": "
tYv9FY3ON556ZCFQKm1aevnjOaAzezXV5k60B39GTZPyBoM7cfXeUpvxcvvUyE1q
G_w0bBg58PckKZqfDR9dX5cH-MpLprtoXGMlSLLLS4wXkaaKxeHVWWLhoMNpYnSp
xzpTTEikofzJZp5RitOr1hnbfTZ7PRmpBrLajpKgg-ACRDQJ03mIa75D04EoLx77
6Ccu4pK0G3K81nu2Lc4Or3Syu_GR4cepAATudiXOU1pg7dpeBruy8jXespyjXUdQ
-wr32yH8qfJWdvsU6vCKbYXH6Hmf_SbCz8r4px5qpNwRb6Vrq1NEA7CbK9arIPgE
6P_D3SybJ0lKc-Qz7wjqlQ"
,
"e": "
AQAB"
}}},
"DeviceEncryptiontionKey": {
"UDF": "MDT3C-LKVOS-EYFGZ-GML2P-YY2IK-OJJIS",
"PublicParameters": {
"PublicKeyRSA": {
"kid": "MDT3C-LKVOS-EYFGZ-GML2P-YY2IK-OJJIS",
"n": "
8O0fFIjO5vMCjtvJN9nZ6eBc-EeNAvHOlvLyFZNELiY0OGYXEcjmRnN91qSaiR2I
98vQ3GMWzbA0UoLE08kSoz99za-c2mJx_OPxTKL1ZWSXF7IalPwG8KKBBkg7IQSb
OV1UWFB1jHCmDLn02E-zwO9AhHtIvcTgOLqCzCZv7QyMkQ0r7iJft-HbkFotDG8L
XYz-RJ0UeA2jbmx6PbYkMoGpXZe5KwIssOJhyTOkJtqOSpSgRdhgn37yZ6U1mu79
18bLcufFqQ2THnkmDBG-HNKZtcw53EBGYTSTBr1m34DkUn7oCWIKjPWbubxQt1jd
Rg1q1TRnZFETq6DVvuB1_Q"
,
"e": "
AQAB"
}}}}}
Figure 12
The device profile is then signed:
{
"SignedDeviceProfile": {
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJEZXZpY2VQcm9maWxlIjogewogICAgIklkZW50aWZpZXIiOiAiTUM1WFot
UUxPUFUtNkNLNFktM0lTWjUtS0hJTFYtQURQSEkiLAogICAgIk5hbWVzIjogWyJE
...
ICAgICAgICAgImUiOiAiCkFRQUIifX19fX0"
,
"signatures": [{
"header": {
"kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhYUVk0VkI5VU04bzd0cUdY
aUdack1nQlVnNm5mWXpLVWhBU1E1VHJKWUE5dGVKcTRQTGhqSDVPQWcyN3hLNEEK
b2RVYjJwT2RZaTFJUkJRRXA4VGlaQSJ9"
,
"signature": "
P7yjwhMYFUqupGsqcZyokfaDZV2o8-vLpXbHEQKihw_9gRokbMvqkwhhQt4RjeL8
DMBj1CgtpauMKbtmaqrpolJfX5IjQPnULTCdeEDvrGuyzw6zVAL8j0xBKCOqWxz-
pmk_kGA7svNBukfQ4wVAI1-PQw8c-garvpRZWFAD1oSkFhMQxhEG1zn0B3abJRmI
Bf9Fukqp1B5HdmOUOEp0MHJ56SaGHOSxKKmp5L3LtDsgmvJ-LumVrYpcaAAvSqI0
4qaUcWSWIGkEZ0pbXAm6O2rQYZjO2YAbLwPIasuukTHf2ukWM4DKIP8sp2qLS35A
EOTudNFW1ImVOiOKWBt-0A"
}]}}}
Figure 13
One of the main architecutral principles of the Mesh is bilateral authentication. Every device that is connected to a Mesh profile MUST authenticate the profile it is connecting to and every Mesh profile administrator MUST authenticate devices that are connected.
Having created the necessary profile, the device MUST verify that it is connecting to the correct Mesh profile. The best mechanism for achieving this purpose depends on the capabilities of the device being connected. The administration device obviously requires some means of communicating with the user to serve its function. But the device being connected may have a limited display capability or no user interaction capability at all.
If the device has user input and display capabilities, it can verify that it is connecting to the correct display by first requesting the user enter the portal account of the profile they wish to connect to, retreiving the profile associated with the device and displaying the profile fingerprint.
The client requests the profile for the requested account name:
{
"GetRequest": {
"Account": "test@prismproof.org",
"Multiple": false}}
Figure 14
The response contains the requested profile information.
{
"GetResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully",
"Entries": [{
"SignedPersonalProfile": {
"Identifier": "MALEI-GTV3E-5W7JR-6NMEY-7G52U-6K3OT",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJQZXJzb25hbFByb2ZpbGUiOiB7CiAgICAiSWRlbnRpZmllciI6ICJNQUxF
SS1HVFYzRS01VzdKUi02Tk1FWS03RzUyVS02SzNPVCIsCiAgICAiU2lnbmVkTWFz
...
b25zIjogW119fQ"
,
"signatures": [{
"header": {
"kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCjhhR1g4Z2hibUlhc2FXVEtm
UjBhQ0QyLU5Fckh3Z0RXRkIwM2diSk1hZFhSVkpyZmpYc1RxNXFZeEhyRDRDTzQK
d0JoWXBkejVyRXJVSmtaUVFQYl9lUSJ9"
,
"signature": "
v0aUBSoxs6FMtFsbWMZViJvVNh3GNliu7CEnw2Ajj-3mRwEtgTFY0H5RiB9AIbI2
TODq7JPKm7-6CCUEugXGdh4ZOnu5A2pAbwtotdAZBpNlhTQTuN6EE-OXwZmZSQyG
DZil2tIjLxYSlsX6vWB4M00HPPYx44TLvbbNVbTVJpw5gnWTceSw5nzIsUqT3gVE
8mCtN2Vo4EWKcMEhUJMx9nUkIaclW9orbA51S3B8QeMGP179cyZ_X_y6TKC3wIB6
AUm6ZQtpa_gBRnAmkbJj6-H_zI_OQIUO_IO2ANL3jI7TSiGPA7VhKsTYDTihMPHs
wfDAwuxZ2a5enFCczaywlg"
}]}}}]}}
Figure 15
Having received the profile data, the user can then verify that the device is attempting to connect to the correct profile by verifying that the fingerprint shown by the device attempting to connect is correct.
Connection of an Internet of Things 'IoT' device that does not have the ability to accept user input requires a mechanism by which the user can identify the device they wish to connect to their profile and a mechanism to authenticate the profile to the device.
If the connecting device has a wired communication capability such as a USB port, this MAY be used to effect the device connection using a standardized interaction profile. But an increasing number of constrained IoT devices are only capable of wireless communication.
Configuration of such devices for the purpose of the Mesh requires that we also consider configuration of the wireless networking capabilities at the same time. The precise mechanism by which this is achieved is therefore outside the scope of this particular document. However prototypes have been built and are being considered that make use of some or all of the following communication techniques:
After the user verifies the device fingerprint as correct, the client posts a device connection request to the portal:
{
"ConnectStartRequest": {
"SignedRequest": {
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUFM
RUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIkRldmljZSI6
...
fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0"
,
"signatures": [{
"header": {
"kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm54cTR3NzdoN2FSdk5weC1r
MDNGTTF3b1hEN1lLMTN6RGxzcWltVWRCUjUxWkFzNU0wVnZOOFRwQ3F6aXEzcS0K
T1hwbU9FM0xXLXVkSzJSUmVIdmVQZyJ9"
,
"signature": "
GzjZPfI5yYIR1g69NWQOU2zKKAl_AY2wPfLHJohJ_cK1NGBqkfXDQMMhWfmkvkb1
qqSja0e1zeNkZbd6HYPy-dXNPIcy-6Bf3sV1IqvVn2-TZQbJO_1VnYdj7Xzj7YG9
8FMCiMvtHXUuWtUJdaUzKhxVGlqGPzkROBgODb8CvMV3NVUwykaP5_myvSk9OXIA
OSub_jZ3OX4RPklHMXuffqea0AjF_ezixgsMv01ZcvL3mFKnpk_FoRFZjYH9vP-t
w7fjP7BmRnN2qB7c3GdfLnbovfw1Fcmi7l2MYZymn9BObm2QVvffiz_UVgJBU-qk
PJMj9rTfd4XzjR7Bwf1f6Q"
}]}},
"AccountID": "test@prismproof.org"}}
Figure 16
The portal verifies that the request is accepable and returns the transaction result:
{
"ConnectStartResponse": {}}
Figure 17
The client can poll the portal for the status of pending requests at any time (modulo any service throttling restrictions at the service side). But the request status will only change when an update is posted by an administration device.
Since the user is typically connecting a device to their profile, the next step in connecting the device is to start the administration client. When started, the client polls for pending connection requests using ConnectPendingRequest.
{
"ConnectPendingRequest": {
"AccountID": "test@prismproof.org"}}
Figure 18
The service responds with a list of pending requests:
{
"ConnectPendingResponse": {
"Pending": [{
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUFM
RUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIkRldmljZSI6
...
fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0"
,
"signatures": [{
"header": {
"kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm54cTR3NzdoN2FSdk5weC1r
MDNGTTF3b1hEN1lLMTN6RGxzcWltVWRCUjUxWkFzNU0wVnZOOFRwQ3F6aXEzcS0K
T1hwbU9FM0xXLXVkSzJSUmVIdmVQZyJ9"
,
"signature": "
GzjZPfI5yYIR1g69NWQOU2zKKAl_AY2wPfLHJohJ_cK1NGBqkfXDQMMhWfmkvkb1
qqSja0e1zeNkZbd6HYPy-dXNPIcy-6Bf3sV1IqvVn2-TZQbJO_1VnYdj7Xzj7YG9
8FMCiMvtHXUuWtUJdaUzKhxVGlqGPzkROBgODb8CvMV3NVUwykaP5_myvSk9OXIA
OSub_jZ3OX4RPklHMXuffqea0AjF_ezixgsMv01ZcvL3mFKnpk_FoRFZjYH9vP-t
w7fjP7BmRnN2qB7c3GdfLnbovfw1Fcmi7l2MYZymn9BObm2QVvffiz_UVgJBU-qk
PJMj9rTfd4XzjR7Bwf1f6Q"
}]}}]}}
Figure 19
The device profile is added to the Personal profile which is then signed by the online signing key. The administration client publishes the updated profile to the Mesh through the portal:
{
"ConnectPendingRequest": {
"AccountID": "test@prismproof.org"}}
Figure 20
As usual, the service returns the response code:
{
"ConnectPendingResponse": {
"Pending": [{
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJDb25uZWN0aW9uUmVxdWVzdCI6IHsKICAgICJQYXJlbnRVREYiOiAiTUFM
RUktR1RWM0UtNVc3SlItNk5NRVktN0c1MlUtNkszT1QiLAogICAgIkRldmljZSI6
...
fX0sCiAgICAiRGV2aWNlRGF0YSI6IFtdfX0"
,
"signatures": [{
"header": {
"kid": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCm54cTR3NzdoN2FSdk5weC1r
MDNGTTF3b1hEN1lLMTN6RGxzcWltVWRCUjUxWkFzNU0wVnZOOFRwQ3F6aXEzcS0K
T1hwbU9FM0xXLXVkSzJSUmVIdmVQZyJ9"
,
"signature": "
GzjZPfI5yYIR1g69NWQOU2zKKAl_AY2wPfLHJohJ_cK1NGBqkfXDQMMhWfmkvkb1
qqSja0e1zeNkZbd6HYPy-dXNPIcy-6Bf3sV1IqvVn2-TZQbJO_1VnYdj7Xzj7YG9
8FMCiMvtHXUuWtUJdaUzKhxVGlqGPzkROBgODb8CvMV3NVUwykaP5_myvSk9OXIA
OSub_jZ3OX4RPklHMXuffqea0AjF_ezixgsMv01ZcvL3mFKnpk_FoRFZjYH9vP-t
w7fjP7BmRnN2qB7c3GdfLnbovfw1Fcmi7l2MYZymn9BObm2QVvffiz_UVgJBU-qk
PJMj9rTfd4XzjR7Bwf1f6Q"
}]}}]}}
Figure 21
Having accepted the device and connected it to the profile, the administration client creates and signs a connection completion result which is posted to the portal using ConnectCompleteRequest:
{
"ConnectCompleteRequest": {
"Result": {
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg
IklkZW50aWZpZXIiOiAiTUM1WFotUUxPUFUtNkNLNFktM0lTWjUtS0hJTFYtQURQ
...
CmhCcXZGM2NzWEdKOERfLTVhZlY5OWcifV19fX19fQ"
,
"signatures": [{
"header": {
"kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmhiZENhZXQ3MXNzaWlqVkpV
TWduTUNIcExyVjUwNmx5ejZKU25SaFpBNG1YU19FcXluLUNfUjhGQkFSamRMR3EK
TVRsaVBEMDZuM0ZsRk1OdXppMTFmQSJ9"
,
"signature": "
tGk7QPnDx9AinDZbkMHUnSKHDDO0SOTBBDRt-ia3WimTmnpbfPXvdyWhKSwtpyWE
sYx7pQMwufCxtA3v1f02dOMGsJTmQQ44rAmE5InSuFFrWSWoXXZfcfdveiGZg9vj
Mg0_RBDD3pdASLa7ZFQhM1hqmXVCT-zsITzqGHejO3oUWAhRFtWIHycaBWRw4TDM
B4lmQy3qEdgWhbqvllIUPDAw-sBZzRnNRnc4p3SyYXUWAisvdOhjn9ICS9iSeHEY
IvDtR7-Lal2N8mzfRubLEKMtEtj6CEShqTva2sCCgJJEHxyLqcZTUXhE-YGR2nQD
p9KsdZpdLo-RpDVkMnqmQA"
}]}},
"AccountID": "test@prismproof.org"}}
Figure 22
Again, the service returns the response code:
{
"ConnectCompleteResponse": {}}
Figure 23
As stated previously, the connecting device polls the portal periodically to determine the status of the pending request using ConnectStatusRequest:
{
"ConnectStatusRequest": {
"AccountID": "test@prismproof.org",
"DeviceID": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI"}}
Figure 24
If the response is that the connection status has not changed, the service MAY return a response that specifies a minimum retry interval. In this case however there is a connection result:
{
"ConnectStatusResponse": {
"Result": {
"Identifier": "MC5XZ-QLOPU-6CK4Y-3ISZ5-KHILV-ADPHI",
"SignedData": {
"unprotected": {
"dig": "S512"},
"payload": "
ewogICJDb25uZWN0aW9uUmVzdWx0IjogewogICAgIkRldmljZSI6IHsKICAgICAg
IklkZW50aWZpZXIiOiAiTUM1WFotUUxPUFUtNkNLNFktM0lTWjUtS0hJTFYtQURQ
...
CmhCcXZGM2NzWEdKOERfLTVhZlY5OWcifV19fX19fQ"
,
"signatures": [{
"header": {
"kid": "MCWKN-SFJ2G-CDZQ4-ZPT4S-GS6LU-Y3COT"},
"protected": "
ewogICJhbGciOiAiUlM1MTIiLAogICJ2YWwiOiAiCmhiZENhZXQ3MXNzaWlqVkpV
TWduTUNIcExyVjUwNmx5ejZKU25SaFpBNG1YU19FcXluLUNfUjhGQkFSamRMR3EK
TVRsaVBEMDZuM0ZsRk1OdXppMTFmQSJ9"
,
"signature": "
tGk7QPnDx9AinDZbkMHUnSKHDDO0SOTBBDRt-ia3WimTmnpbfPXvdyWhKSwtpyWE
sYx7pQMwufCxtA3v1f02dOMGsJTmQQ44rAmE5InSuFFrWSWoXXZfcfdveiGZg9vj
Mg0_RBDD3pdASLa7ZFQhM1hqmXVCT-zsITzqGHejO3oUWAhRFtWIHycaBWRw4TDM
B4lmQy3qEdgWhbqvllIUPDAw-sBZzRnNRnc4p3SyYXUWAisvdOhjn9ICS9iSeHEY
IvDtR7-Lal2N8mzfRubLEKMtEtj6CEShqTva2sCCgJJEHxyLqcZTUXhE-YGR2nQD
p9KsdZpdLo-RpDVkMnqmQA"
}]}}}}
Figure 25
[Should probably unpack further.]
Application profiles are published separately from the personal profile to which they are linked. This allows a device to be given administration capability for a particular application without granting administration capability for the profile itself and the ability to connect additional profiles and devices.
Another advantage of this separation is that an application profile might be managed by a separate party. In an enterprise, the application profile for a user's corporate email account could be managed by the corporate IT department.
A user MAY have multiple application profiles for the same application. If a user has three email accounts, they would have three email application profiles, one for each account.
In this example, the user has requested a PaswordProfile to be created. When populated, this records the usernames and passwords for the various Web sites that the user has created accounts at and has requested the Web browser store in the Mesh.
Unlike a traditional password management service, the data stored the Password Profile is encrypted end to end and can only be decrypted by the devices that hold a decryption key.
{Example.PasswordProfile1}
Figure 26
The application profile is published to the Mesh in the same way as any other profile update, via a a Publish transaction:
% Point = Example.Traces.Get (Example.LabelApplicationWeb1); {Point.Messages[0].String()}
The service returns a status response.
{Point.Messages[1].String()}
Note that the degree of verification to be performed by the service when an application profile is published is an open question.
Having created the application profile, the administration client adds it to the personal profile and publishes it:
{Point.Messages[0].String()}
Note that if the publication was to happen in the reverse order, with the personal profile being published before the application profile, the personal profile might be rejected by the portal for inconsistency as it links to a non existent application profile. Though the value of such a check is debatable. It might well be preferable to not make such checks as it permits an application profile to have a degree of anonymity.
{Point.Messages[1].String()}
The Mesh invites users to put all their data eggs in one cryptographic basket. If the private keys in their master profile are lost, they could lose all their digital assets.
The debate over the desirability of key escrow is a complex one. Not least because voluntary key escrow by the user to protect the user's digital assets is frequently conflated with mechanisms to support 'Lawful Access' through government managed backdoors.
Accidents happen and so do disasters. For most users and most applications, data loss is a much more important concern than data disclosure. The option of using a robust key recovery mechanism is therefore essential for use of strong cryptography is to become ubiquitous.
There are of course circumstances in which some users may prefer to risk losing some of their data rather than risk disclosure. Since any key recovery infrastructure necessarily introduces the risk of coercion, the choice of whether to use key recovery or not is left to the user to decide.
The Mesh permits users to escrow their private keys in the Mesh itself in an OfflineEscrowEntry. Such entries are encrypted using the strongest degree of encryption available under a symmetric key. The symmetric key is then in turn split using Shamir secret sharing using an n of m threshold scheme.
The OfflineEscrowEntry identifier is a UDF fingerprint of the symmetric key used to encrypt the data. This guarantees that a party that has the decryption key has the ability to locate the corresponding Escrow entry.
The OfflineEscrowEntry is published using the usual Publish transaction:
{Point.Messages[0].String()}
The response indicates success or failure:
{Point.Messages[1].String()}
To recover a profile, the user MUST supply the necessary number of secret shares. These are then used to calculate the UDF fingerprint to use as the locator in a Get transaction:
{Point.Messages[0].String()}
If the transaction succeeds, GetResponse is returned with the requested data.
{Point.Messages[1].String()}
The client can now decrypt the OfflineEscrowEntry to recover the private key(s).
The following classes are used as common elements in Mesh profile specifications.a
Most Mesh objects are signed and/or encrypted. For consistency all Mesh classes make use of the cryptographic data classes described in this section.
The PublicKey class is used to describe public key pairs and trust assertions associated with a public key.
Container for JOSE signed data and related attributes.
Container for JOSE encrypted data and related attributes.
Describes network connection parameters for an application
Base class for all Mesh Profile objects.
Contains a signed profile entry
Additional data bound to a signed profile that is not authenticated.
Describes the portal(s) at which the profile is registered.
Parent class from which all profile types are derived
Contains a signed device profile
[No fields]
Describes a mesh device.
Private portion of device encryption profile.
Contains a signed Personal master profile
[No fields]
Describes the long term parameters associated with a personal profile.
Contains a signed Personal current profile
[No fields]
Describes the current applications and devices connected to a personal master profile.
Personal profile entry describing the privileges of specific devices.
Contains a signed device profile
[No fields]
Parent class from which all application profiles inherit.
[No fields]
The base class for all private profiles.
[No fields]
Describes the public per device data
Describes the private per device data
[No fields]
Contains escrowed data
Contains data escrowed using the offline escrow mechanism.
[No fields]
Contains data escrowed using the online escrow mechanism.
[No fields]
A set of escrowed keys.
[No fields]
Describes a connection request.
Contains a ConnectionRequest signed by the corresponding device signature key.
[No fields]
Describes the result of a connection request.
Contains a signed connection result
[No fields]
Every Mesh Portal Service transaction consists of exactly one request followed by exactly one response. Mesh Service transactions MAY cause modification of the data stored in the Mesh Portal or the Mesh itself but do not cause changes to the connection state. The protocol itself is thus idempotent. There is no set sequence in which operations are required to be performed. It is not necessary to perform a Hello transaction prior to a ValidateAccount, Publish or any other transaction.
A Mesh Portal Service request consists of a payload object that inherits from the MeshRequest class. When using the HTTP binding, the request MUST specify the portal DNS address in the HTTP Host field.
Base class for all request messages.
A Mesh Portal Service response consists of a payload object that inherits from the MeshResponse class. When using the HTTP binding, the response SHOULD report the Status response code in the HTTP response message. However the response code returned in the payload object MUST always be considered authoritative.
Base class for all response messages. Contains only the status code and status description fields.
[No fields]
The Mesh Service protocol makes use of JSON objects defined in the JOSE Signatgure and Encryption specifications.
The following common structures are used in the protocol messages:
Describes a Key/Value structure used to make queries for records matching one or more selection criteria.
Specifies constraints to be applied to a search result. These allow a client to limit the number of records returned, the quantity of data returned, the earliest and latest data returned, etc.
Report service and version information.
The Hello transaction provides a means of determining which protocol versions, message encodings and transport protocols are supported by the service.
Request validation of a proposed name for a new account.
For validation of a user's account name during profile creation.
Describes the proposed account properties. Currently, these are limited to the account name but could be extended in future versions of the protocol.
States whether the proposed account properties are acceptable and (optional) returns an indication of what properties are valid.
Note that receiving a 'Valid' responseto a Validate Request does not guarantee creation of the account. In addition to the possibility that the account namecould be requested by another user between the Validate and Create transactions, a portal service MAY perform more stringent validation criteria when an account is actually being created. For example, checking with the authoritative list of current accounts rather than a cached copy.
Request creation of a new portal account.
Unlike a profile, a mesh account is specific to a particular Mesh portal. A mesh account must be created and accepted before a profile can be published.
Request creation of a new portal account. The request specifies the requested account identifier and the Mesh profile to be associated with the account.
Reports the success or failure of a Create transaction.
[No fields]
Request deletion of a portal account.
Deletes a portal account but not the underlying profile. Once registered, profiles are permanent.
Request deletion of a new portal account. The request specifies the requested account identifier.
Reports the success or failure of a Delete transaction.
[No fields]
Search for data in the mesh that matches a set of properties described by a sequence of key/value pairs.
Describes the Portal or Mesh data to be retreived.
Reports the success or failure of a Get transaction. If a Mesh entry matching the specified profile is found, containsthe list of entries matching the request.
Publish a profile or key escrow entry to the mesh.
Requests publication of the specified Mesh entry.
[No fields]
Reports the success or failure of a Publish transaction.
[No fields]
Request the current status of the mesh as seen by the portal to which it is directed.
The response to the status request contains the last signed checkpoint and proof chains for each of the peer portals that have been checkpointed.
[Not currently implemented]
Initiates a status transaction.
[No fields]
Reports the success or failure of a Status transaction.
Request connection of a new device to a mesh profile
Initial device connection request.
Reports the success or failure of a ConnectStart transaction.
[No fields]
Request status of pending connection request of a new device to a mesh profile
Request status information for a pending request posted previously.
Reports the success or failure of a ConnectStatus transaction.
Request a list of pending requests for an administration profile.
Specify the criteria for pending requests.
Reports the success or failure of a ConnectPending transaction.
Post response to a pending connection request.
Reports the success or failure of a ConnectComplete transaction.
Reports the success or failure of a ConnectComplete transaction.
[No fields]
Perform a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization
[Not currently implemented]
Request a bulk transfer of the log between the specified transaction identifiers. Requires appropriate authorization
Reports the success or failure of a Transfer transaction. If successful, contains the list of Mesh records to be transferred.
All the IANA considerations for the Mesh documents are specified in this document
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6335] | Cotton, M., Eggert, L., Touch, J., Westerlund, M. and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011. |
| [draft-hallambaker-mesh-architecture] | Hallam-Baker, P., "Mathematical Mesh: Architecture", Internet-Draft draft-hallambaker-mesh-architecture-04, September 2017. |
| [draft-hallambaker-mesh-developer] | Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Internet-Draft draft-hallambaker-mesh-developer-05, September 2017. |
| [RFC822] | Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822, August 1982. |