diff --git a/assets/css/main.css.map b/assets/css/main.css.map
index 5b27f2304..0565c70be 100644
--- a/assets/css/main.css.map
+++ b/assets/css/main.css.map
@@ -3,59 +3,59 @@
 	"file": "main.css",
 	"sources": [
 		"main.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/skins/_air.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_variables.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_context.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_helpers.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_parsers.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/_query.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/_single.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/single/_default.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/_double.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default-pair.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_double-string.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/_triple.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/triple/_default.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/_resolution.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/parsers/resolution/_resolution.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_no-query.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_respond-to.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/breakpoint/_legacy-settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/magnific-popup/_magnific-popup.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/magnific-popup/_settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/_susy.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/_susy-prefix.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_utilities.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_su-validate.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_normalize.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_parse.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_api.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_mixins.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_reset.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_base.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_forms.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_tables.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_animations.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_buttons.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_notices.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_masthead.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_navigation.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_footer.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_search.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_syntax.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_utilities.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_page.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_archive.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_sidebar.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240206-1795-1t1pkp/_sass/minimal-mistakes/_print.scss"
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/skins/_air.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_variables.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_context.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_helpers.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_parsers.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/_query.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/_single.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/single/_default.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/_double.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default-pair.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_double-string.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/_triple.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/triple/_default.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/_resolution.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/parsers/resolution/_resolution.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_no-query.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_respond-to.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/breakpoint/_legacy-settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/magnific-popup/_magnific-popup.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/magnific-popup/_settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/_susy.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/_susy-prefix.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_utilities.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_su-validate.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_normalize.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_parse.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_api.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_mixins.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_reset.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_base.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_forms.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_tables.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_animations.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_buttons.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_notices.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_masthead.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_navigation.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_footer.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_search.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_syntax.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_utilities.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_page.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_archive.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_sidebar.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240209-1860-zolrw7/_sass/minimal-mistakes/_print.scss"
 	],
 	"sourcesContent": [
 		"@charset \"utf-8\";\n\n@import \"minimal-mistakes/skins/air\"; // skin\n@import \"minimal-mistakes\"; // main partials",
diff --git a/explore.html b/explore.html
index 54f683cbd..da15ff6d2 100644
--- a/explore.html
+++ b/explore.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Explore enmeshed">
     <meta itemprop="description" content="Welcome to the “Explore enmeshed” section of our website, your gateway to understanding the intricate world of enmeshed. Here, we embark on a journey through the various facets of enmeshed, from its fundamental workings to advanced technical insights.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -330,7 +330,7 @@ <h2 id="expert-corner">Expert Corner</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/addresses.html b/explore/addresses.html
index a7a45ff3a..57e3af22c 100644
--- a/explore/addresses.html
+++ b/explore/addresses.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Enmeshed Addresses">
     <meta itemprop="description" content="The Address is the primary identifier for an enmeshed Identity. It is public and created out of the Identity’s Signature Public Key. Thus, the Identity’s root signature key and its corresponding Address are interlinked with each other and cannot be changed. Nobody is able to change the public key for a corresponding Address and everybody has the possibility to check, if a given public key matches a given Address without having to trust someone. Both are important security features.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -401,7 +401,7 @@ <h2 id="examples">Examples</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/app.html b/explore/app.html
index d99618024..edecf5fd8 100644
--- a/explore/app.html
+++ b/explore/app.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Enmeshed App">
     <meta itemprop="description" content="App Building Blocks">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -349,7 +349,7 @@ <h2 id="app-runtime">App Runtime</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/backbone.html b/explore/backbone.html
index 2b7ac8e4c..dcb2f01d6 100644
--- a/explore/backbone.html
+++ b/explore/backbone.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Enmeshed Backbone">
     <meta itemprop="description" content="Backbone Building Blocks">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -403,7 +403,7 @@ <h2 id="backbone-services-and-libraries-designtime">Backbone Services and Librar
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/blockchain.html b/explore/blockchain.html
index 4b58d0b21..cdc7545e7 100644
--- a/explore/blockchain.html
+++ b/explore/blockchain.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Why we do not use a blockchain">
     <meta itemprop="description" content="The new world of identities">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -361,7 +361,7 @@ <h2 id="is-there-really-a-decentral-platform">Is there really a decentral platfo
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/connector.html b/explore/connector.html
index 7940421e2..868efa99e 100644
--- a/explore/connector.html
+++ b/explore/connector.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Enmeshed Connector">
     <meta itemprop="description" content="Connector Building Blocks">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -366,7 +366,7 @@ <h2 id="so-how-does-my-organization-get-started">So how does my organization get
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/cryptography.html b/explore/cryptography.html
index 14a643974..a2f2cb9ef 100644
--- a/explore/cryptography.html
+++ b/explore/cryptography.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Cryptography">
     <meta itemprop="description" content="Backbone Layer Encryption">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -409,7 +409,7 @@ <h2 id="relationship-keys">Relationship Keys</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/example-scenarios.html b/explore/example-scenarios.html
index ab8042a0e..d26aec449 100644
--- a/explore/example-scenarios.html
+++ b/explore/example-scenarios.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Example Scenarios">
     <meta itemprop="description" content="Enmeshed supports many possible business scenarios within various lines of businesses or industries. But not only enterprises, companies or organizations benefit of these approaches. Also leisure activities with clubs or communities can make use of enmeshed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -370,7 +370,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/faq.html b/explore/faq.html
index 400998d78..8353c9dbc 100644
--- a/explore/faq.html
+++ b/explore/faq.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Frequently Asked Questions">
     <meta itemprop="description" content="Can you read my data?">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -334,7 +334,7 @@ <h1 id="why-do-you-need-the-backbone">Why do you need the Backbone?</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/features.html b/explore/features.html
index 1a10a964f..1f03df9b4 100644
--- a/explore/features.html
+++ b/explore/features.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Features">
     <meta itemprop="description" content="Features included with enmeshed:">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -338,7 +338,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/how_does_enmeshed_work.html b/explore/how_does_enmeshed_work.html
index b3276c368..2cc15f515 100644
--- a/explore/how_does_enmeshed_work.html
+++ b/explore/how_does_enmeshed_work.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="How does enmeshed work?">
     <meta itemprop="description" content="Enmeshed introduces an overarching solution, securely connecting users and organizations without the use of decentralized technologies like blockchains. However, it makes use of the decentralized mindset, like decentralized identities.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -370,7 +370,7 @@ <h2 id="enmeshed-connector">Enmeshed Connector</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/integration.html b/explore/integration.html
index 9c2801cf0..2f8b221e0 100644
--- a/explore/integration.html
+++ b/explore/integration.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Integration Considerations">
     <meta itemprop="description" content="Enmeshed does not only enable users taking part of the digitalization process. Organizations also benefit of enmeshed as well, as they usually need to invest heavily to stay up to date in today’s technological race.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -314,7 +314,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/backbone.html b/explore/layers/backbone.html
index b38e76325..2aa21b4cd 100644
--- a/explore/layers/backbone.html
+++ b/explore/layers/backbone.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Backbone Layer">
     <meta itemprop="description" content="From a user perspective, the deepest layer is the backbone layer. It handles the “untrusted” communication with the Backbone and the processing of data within the Backbone. Payload sent to and received from the Backbone is encrypted.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -656,7 +656,7 @@ <h2 id="relationship-templates">Relationship Templates</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/consumption.html b/explore/layers/consumption.html
index 69267fd70..421d24b56 100644
--- a/explore/layers/consumption.html
+++ b/explore/layers/consumption.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Consumption Layer">
     <meta itemprop="description" content="The consumption layer contains processes, logic and data structures either for personal or organizational identities. It sits on top of the transport layer and exposes its functionality to either the user experience or the integration layer.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -343,7 +343,7 @@ <h2 id="data-log">Data Log</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/integration.html b/explore/layers/integration.html
index d8d88a0e4..0e916dfb2 100644
--- a/explore/layers/integration.html
+++ b/explore/layers/integration.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Integration Layer">
     <meta itemprop="description" content="The integration layer is only available within the Connector and sits on top of the transport and consumption layers. It is responsible for providing integration capabilities to other systems. It acts for a single identity only, which is usually an organization.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -348,7 +348,7 @@ <h2 id="monitoring-and-logging-capabilities">Monitoring and Logging Capabilities
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/transport.html b/explore/layers/transport.html
index e1edc7968..2e7b8ba63 100644
--- a/explore/layers/transport.html
+++ b/explore/layers/transport.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Transport Layer">
     <meta itemprop="description" content="The transport layer is located between the backbone layer and the consumption layer. Thus it acts as the interface between the trusted environment (own device/network) and the untrusted environment (Backbone). It is usually hosted as a REST API by the Connector or programmatically accessed by the App. The Runtime is the primary technical building block, containing the transport library, the content library and the crypto library.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -646,7 +646,7 @@ <h3 id="token-structure">Token Structure</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/user-experience.html b/explore/layers/user-experience.html
index bbba0070a..6b6ed7679 100644
--- a/explore/layers/user-experience.html
+++ b/explore/layers/user-experience.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="User-Experience Layer">
     <meta itemprop="description" content="The user experience layer is only available within the App and sits on top of the transport and consumption layers. It exposes the functionality of underlying layers for the user, meaning it is rendering out user interfaces and handling interactions. It acts for a single identity only, which is usually a person. However, it might make sense to use an App for organization identities as well, for example for small companies or freelancers.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -318,7 +318,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/privacy.html b/explore/privacy.html
index ddb50b01e..293685714 100644
--- a/explore/privacy.html
+++ b/explore/privacy.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Privacy Considerations">
     <meta itemprop="description" content="Privacy stands as one of the main pillars of the digital strategies adopted by institutions. It holds a significant and paramount position.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -434,7 +434,7 @@ <h1 id="comparison-to-decentralized-technologies">Comparison to decentralized te
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/runtime.html b/explore/runtime.html
index a568fd70b..c1e608863 100644
--- a/explore/runtime.html
+++ b/explore/runtime.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Enmeshed Runtime">
     <meta itemprop="description" content="Enmeshed Runtime GitHub Repository">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -439,7 +439,7 @@ <h3 id="message-module">Message Module</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/explore/security.html b/explore/security.html
index ae5994fab..73672cfff 100644
--- a/explore/security.html
+++ b/explore/security.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -280,7 +280,7 @@ <h3>Explore enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Security Considerations">
     <meta itemprop="description" content="Security is one of the main pillars of digitalization approaches. It might be the most important one.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -385,7 +385,7 @@ <h1 id="law-enforcement-compliance">Law Enforcement Compliance</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/feed.xml b/feed.xml
index c083b62a4..645c28868 100644
--- a/feed.xml
+++ b/feed.xml
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.2.2">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2024-02-06T08:06:12+01:00</updated><id>/feed.xml</id><title type="html">enmeshed</title><subtitle>Enmeshed is a home of various open source components, making the digital life of users and organizations easier.</subtitle><author><name>Enmeshed Team</name></author><entry><title type="html">FerretDB compatibility for the enmeshed Connector</title><link href="/blog/announcing-ferretdb-compatibility" rel="alternate" type="text/html" title="FerretDB compatibility for the enmeshed Connector" /><published>2023-04-06T00:00:00+02:00</published><updated>2023-04-06T00:00:00+02:00</updated><id>/blog/announcing-ferretdb-compatibility</id><content type="html" xml:base="/blog/announcing-ferretdb-compatibility"><![CDATA[<p>At enmeshed, we believe in the importance of open-source software and the freedom it gives developers.</p>
+<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.2.2">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2024-02-09T09:55:06+01:00</updated><id>/feed.xml</id><title type="html">enmeshed</title><subtitle>Enmeshed is a home of various open source components, making the digital life of users and organizations easier.</subtitle><author><name>Enmeshed Team</name></author><entry><title type="html">FerretDB compatibility for the enmeshed Connector</title><link href="/blog/announcing-ferretdb-compatibility" rel="alternate" type="text/html" title="FerretDB compatibility for the enmeshed Connector" /><published>2023-04-06T00:00:00+02:00</published><updated>2023-04-06T00:00:00+02:00</updated><id>/blog/announcing-ferretdb-compatibility</id><content type="html" xml:base="/blog/announcing-ferretdb-compatibility"><![CDATA[<p>At enmeshed, we believe in the importance of open-source software and the freedom it gives developers.</p>
 
 <p>MongoDB is licensed under the Server Side Public License (SSPL) and from the start of our project we knew that we needed to find an alternative database solution for the enmeshed Connector. After researching and testing several options, we found <a href="https://www.ferretdb.io/">FerretDB</a> to be a suitable truly open source replacement for MongoDB.</p>
 
diff --git a/integrate.html b/integrate.html
index a5fddc3d5..7024694f5 100644
--- a/integrate.html
+++ b/integrate.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Integrate enmeshed">
     <meta itemprop="description" content="You want to seamlessly use enmeshed with your processes, solutions and software components? No worries, you are good to go!">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -571,7 +571,7 @@ <h2 id="requesting-consent-of-users">Requesting Consent of Users</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/access-the-connector.html b/integrate/access-the-connector.html
index 420353c4c..1cbb691d1 100644
--- a/integrate/access-the-connector.html
+++ b/integrate/access-the-connector.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Access the Connector">
     <meta itemprop="description" content="The primary integration capability of the Connector is the REST API. In order to use it, you should have received an API-Key for the respective Connector. An API-Key so far has all authorizations for accessing the API.Hosted API tooling by the (development) ConnectorIn order to use the hosted api tooling, it must be activated in the Connector configuration.You can access the REST API documentation through the Connector’s designated HTTP endpoints. Swagger and Rapidoc serve as interactive platforms hosted on the Connector, enabling you to explore and experiment with the various APIs interactively.Swagger  /docs/swagger : The Swagger UI of the Connector’s OpenAPI specificationNote: For Swagger the authorization is on the top right (Authorize button with a lock symbol).Rapidoc  /docs/rapidoc : The Rapidoc UI of the Connector’s OpenAPI specificationNote: For Rapidoc the authorization is usually the third heading called “Authentication” and can also be found on the left navigation.Accessing the Connector with external API tools (e.g. Postman or Insomnia)To fetch the Open API documentation of the Connector’s REST API, visit the following URIs:  /docs/yaml : The Connector’s OpenAPI specification in YAML format  /docs/json : The Connector’s OpenAPI specification in JSON formatYou can view these files with the Swagger Editor or automatically import them within your favorite API Clients (e.g. Postman or Insomnia).Accessing the Connector by Software Development Kits (SDK)To achieve a better developer experience and type safety, preferably a Software Development Kit (SDK) should be used. The following SDKs are available for this purpose:We work on keeping this list as updated as possible. Please let us know, if some SDKs are outdated or new SDKs are available for the community.TypeScript SDKWe offer an SDK developed in TypeScript that facilitates communication with your Connector from your TypeScript or JavaScript application. You can find it readily available on npmjs.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -416,7 +416,7 @@ <h2 id="typescript-sdk">TypeScript SDK</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/attribute-values.html b/integrate/attribute-values.html
index 11b506d42..f47a42e67 100644
--- a/integrate/attribute-values.html
+++ b/integrate/attribute-values.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Attribute Values">
     <meta itemprop="description" content="Each Attribute contains an instance of an Attribute Value within its value property. There are different types of Attribute Values. The types define the value’s structural definition, rendering information and validators. For example, an email address with the value address@company.corp is stored with the Attribute Value type EMailAddress, which defines  the data type of the actual value (a String)  how it is validated (the pattern of an email address and a maximum length)  information about how it can be rendered on the UIEnmeshed defines a standard set of possible Attribute Value types for Identities within the enmeshed ecosystem and its meaning for the Identities. And every Identity can understand/use/fill/query these Attribute Value types of other Identities.Most Attribute Value types are atomic, which means that they have only one property called value (e.g. EMailAddress, DisplayName, PhoneNumber). But there are also more complex Attribute Value types which consist of multiple properties with a strong correlation (e.g. StreetAddress, PersonName). These properties can (but don’t have to) contain other Attribute Values.Identity AttributesThe Attribute Values in this chapter can only be used in an Identity Attribute.AffiliationA complex Attribute Value type which defines the affiliation of a person to an organization. Inside of the organization the person can have a role and it can be assigned to a specific unit inside of the organization.Properties            Name      Type      Required      Validation                  @type      &quot;Affiliation&quot;      ✓                     role      string      ✗      see AffiliationRole              organization      string      ✓      see AffiliationOrganization              unit      string      ✗      see AffiliationUnit      AffiliationOrganizationThe organization the person is affiliated to.It is not recommended to send an AffiliationOrganization to another Identity by its own. Instead, send an Affiliation with the organization property set.Properties            Name      Type      Required      Validation                  @type      &quot;AffiliationOrganization&quot;      ✓                     value      string      ✓      max. length: 100      ValidationAffiliationRoleThe role the person has in the organization.It is not recommended to send an AffiliationRole to another Identity by its own. Instead, send an Affiliation with the role property set.Properties            Name      Type      Required      Validation                  @type      &quot;AffiliationRole&quot;      ✓                     value      string      ✓      max. length: 100      AffiliationUnitThe organization unit the person is affiliated to.It is not recommended to send an AffiliationUnit to another Identity by its own. Instead, send an Affiliation with the unit property set.Properties            Name      Type      Required      Validation                  @type      &quot;AffiliationUnit&quot;      ✓                     value      string      ✓      max. length: 100      BirthCityThe city of birth.It is not recommended to send a BirthCity to another Identity by its own. Instead, send a BirthPlace with the city property set.Properties            Name      Type      Required      Validation                  @type      &quot;BirthCity&quot;      ✓                     value      string      ✓      max. length: 100      BirthCountryThe country of birth.It is not recommended to send a BirthCountry to another Identity by its own. Instead, send a BirthPlace with the country property set.Properties            Name      Type      Required      Validation                  @type      &quot;BirthCountry&quot;      ✓                     value      string      ✓      only ISO 3166-1 alpha-2 country codes      BirthDateThe birth date of a natural person.Properties            Name      Type      Required      Validation                  @type      &quot;BirthDate&quot;      ✓                     day      number      ✓      see BirthDay              month      number      ✓      see BirthMonth              year      number      ✓      see BirthYear      BirthDayThe day of birth.It is not recommended to send a BirthDay to another Identity by its own. Instead, send a BirthDate with the day property set.            Name      Type      Required      Validation                  @type      &quot;BirthDay&quot;      ✓                     value      number      ✓      min: 1max: 31must be an integer      BirthMonthThe day of month.It is not recommended to send a BirthMonth to another Identity by its own. Instead, send a BirthDate with the month property set.            Name      Type      Required      Validation                  @type      &quot;BirthMonth&quot;      ✓                     value      number      ✓      min: 1max: 12must be an integer      BirthNameThe BirthName is the surname of the person at birth. Some countries allow changing the surname, thus the BirthName is also used as the identification. The BirthName is innate depending on your surname at birth.If this value is set, there has been a change of the surname throughout the life of the person.Properties            Name      Type      Required      Validation                  @type      &quot;BirthName&quot;      ✓                     value      string      ✓      max. length: 100      BirthPlaceThe BirthPlace consists of the BirthCity and BirthCountry and can optionally include a BirthState (e.g. if the BirthCity is ambiguous within the BirthCountry).Properties            Name      Type      Required      Validation                  @type      &quot;BirthPlace&quot;      ✓                     city      string      ✓ see      BirthCity              country      string      ✓ see      BirthCountry              state      string      ✗ see      BirthState      BirthStateThe state of birth.It is not recommended to send a BirthState to another Identity by its own. Instead, send a BirthPlace with the state property set.Properties            Name      Type      Required      Validation                  @type      &quot;BirthState&quot;      ✓                     value      string      ✓      max. length: 100      BirthYearThe year of birth in the Gregorian calendar.It is not recommended to send a BirthYear to another Identity by its own. Instead, send a BirthDate with the year property set.            Name      Type      Required      Validation                  @type      &quot;BirthYear&quot;      ✓                     value      number      ✓      min: 1max: 9999must be an integer      CitizenshipThe Citizenship defines which country currently recognizes you as a citizen. Thus, the Citizenship usually refers to the country you have a passport from.Properties            Name      Type      Required      Validation                  @type      &quot;Citizenship&quot;      ✓                     value      string      ✓      only ISO 3166-1 alpha-2 country codes      CityThe name of a city. This is usually used as part of a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress.It is not recommended to send a City to another Identity by its own. Instead, send a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress with the city property set.Properties            Name      Type      Required      Validation                  @type      &quot;City&quot;      ✓                     value      string      ✓      max. length: 100      CommunicationLanguageThe CommunicationLanguage is an officially recognized language the person can communicate with.Properties            Name      Type      Required      Validation                  @type      &quot;CommunicationLanguage&quot;      ✓                     value      string      ✓      only ISO-639-1 language codes      CountryA country code according to the standard “ISO 3166-1 alpha-2”. This is usually used as part of a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress.It is not recommended to send a Country to another Identity by its own. Instead, send a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress with the country property set.Properties            Name      Type      Required      Validation                  @type      &quot;Country&quot;      ✓                     value      string      ✓      only ISO 3166-1 alpha-2 country codes      DeliveryBoxAddressA complex Attribute Value defining the components of a delivery box address.Properties            Name      Type      Required      Validation                  @type      &quot;DeliveryBoxAddress&quot;      ✓                     recipient      string      ✓      max. length: 100              deliveryBoxId      string      ✓      max. length: 100              userId      string      ✓      max. length: 100              zipCode      string      ✓      see ZipCode              city      string      ✓      see City              country      string      ✓      see Country              phoneNumber      string      ✗      see PhoneNumber              state      string      ✗      see State      DisplayNameThe Display Name is the textual representation of the natural or legal person. It is usually combined out of titles, names or legal statuses.Properties            Name      Type      Required      Validation                  @type      &quot;DisplayName&quot;      ✓                     value      string      ✓      max. length: 100      EMailAddressThe email address which can be used to reach the Identity over email systems.Properties            Name      Type      Required      Validation                  @type      &quot;EMailAddress&quot;      ✓                     value      string      ✓      min. length: 3max. length: 100must match ^[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,}$      FaxNumberThe telephone number which can be used to reach the Identity via fax systems.Properties            Name      Type      Required      Validation                  @type      &quot;FaxNumber&quot;      ✓                     value      string      ✓      min. length: 3max. length: 100must match ^[\d+\-x#*()/[\] ]{3,100}$      IdentityFileReferenceA IdentityFileReference is a link to an enmeshed File and can be used to add a File as an Attribute of an Identity. One example for a use case is some kind of certificate.Properties            Name      Type      Required      Validation                  @type      &quot;IdentityFileReference&quot;      ✓                     value      string      ✓      max. length: 100      GivenNameThe Given Name, also called first name or forename, is the name given to a person at birth which differentiates it from other family, tribe or community members.It is not recommended to send a GivenName to another Identity by its own. Instead, send a PersonName with the givenName property set.Properties            Name      Type      Required      Validation                  @type      &quot;GivenName&quot;      ✓                     value      string      ✓      max. length: 100      HonorificPrefixThe honorific prefix of a person, e.g. ‘Sir’.It is not recommended to send a HonorificPrefix to another Identity by its own. Instead, send a PersonName with the honorificPrefix property set.Properties            Name      Type      Required      Validation                  @type      &quot;HonorificPrefix&quot;      ✓                     value      string      ✓      max. length: 100      HonorificSuffixThe honorific suffix of a person, e.g. ‘PhD’It is not recommended to send a HonorificSuffix to another Identity by its own. Instead, send a PersonName with the honorificSuffix property set.Properties            Name      Type      Required      Validation                  @type      &quot;HonorificSuffix&quot;      ✓                     value      string      ✓      max. length: 100      HouseNumberA house number. This is usually used as part of a StreetAddress.It is not recommended to send a HouseNumber to another Identity by its own. Instead, send a StreetAddress with the houseNumber property set.Properties            Name      Type      Required      Validation                  @type      &quot;HouseNumber&quot;      ✓                     value      string      ✓      max. length: 100      JobTitleA short phrase that describes the position an employee has within an organization. (e.g. “Senior Developer” in case of a software company).Properties            Name      Type      Required      Validation                  @type      &quot;JobTitle&quot;      ✓                     value      string      ✓      max. length: 100      MiddleNameIn various cultures, a middle name is a portion of a personal name that is written between the person’s first given name and their surname.It is not recommended to send a MiddleName to another Identity by its own. Instead, send a PersonName with the middleName property set.Properties            Name      Type      Required      Validation                  @type      &quot;MiddleName&quot;      ✓                     value      string      ✓      max. length: 100      NationalityThe Nationality is the citizenship of a person at birth. One cannot change the Nationality because it’s innate. Thus, the Nationality refers usually to the country where you are born.Properties            Name      Type      Required      Validation                  @type      &quot;Nationality&quot;      ✓                     value      string      ✓      only ISO 3166-1 alpha-2 country codes      PersonNameThe PersonName is a complex Attribute Value type consisting of the GivenName, MiddleName, Surname, HonorificSuffix and HonorificPrefix of a person.Properties            Name      Type      Required      Validation                  @type      &quot;PersonName&quot;      ✓                     givenName      string      ✓      see GivenName              middleName      string      ✗      see MiddleName              surname      string      ✓      see Surname              honorificSuffix      string      ✗      see HonorificSuffix              honorificPrefix      string      ✗      see HonorificPrefix      PhoneNumberThe telephone number which can be used to reach the Identity via telephone.Properties            Name      Type      Required      Validation                  @type      &quot;PhoneNumber&quot;      ✓                     value      string      ✓      max. length: 100      PostOfficeBoxAddressA complex Attribute Value defining the components of a post office box address.Properties            Name      Type      Required      Validation                  @type      &quot;PostOfficeBoxAddress&quot;      ✓                     recipient      string      ✓      max. length: 100              boxId      string      ✓      max. length: 100              zipCode      string      ✓      see ZipCode              city      string      ✓      see City              country      string      ✓      see Country              state      string      ✗      see State      PseudonymThe officially registered pseudonym of a person.Properties            Name      Type      Required      Validation                  @type      &quot;Pseudonym&quot;      ✓                     value      string      ✓      max. length: 100      SchematizedXMLSchematizedXML can be used to exchange files in XML format. The exchange of XML files is also possible via IdentityFileReference, but SchematizedXML has the advantage that it is possible to validate the XML and display the attributes in the wallet.Properties            Name      Type      Required      Validation                  @type      &quot;SchematizedXML&quot;      ✓                     value      string      ✓      max. length: 50000 must be a valid XML encoded string              schemaURL      string      ✓      min. length: 3max. length: 1024must be a valid URL      SexThe Sex is the biological, medical, or public gender of a natural person.Please be advised that the possible values are defined by the public laws and technical passport measures between countries.We embrace the person’s own definition of its/her/his sexual and gender orientations. Therefore we have no “Gender” AttributeValueType (yet). We look forward in hearing your comments about this.Properties            Name      Type      Required      Validation                  @type      &quot;Sex&quot;      ✓                     value      string      ✓      one of: &quot;intersex&quot;, &quot;female&quot;, &quot;male&quot;      StateThe name of a state. This is usually used as part of a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress.It is not recommended to send a State to another Identity by its own. Instead, send a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress with the state property set.Properties            Name      Type      Required      Validation                  @type      &quot;State&quot;      ✓                     value      string      ✓      max. length: 100      StatementThe statement allows a very generic digital mapping of factsProperties            Name      Type      Required      Validation                  @type      &quot;Statement&quot;      ✓                     value      string      ✓      see StatementSubject              predicate      string      ✓      see StatementPredicate              object      string      ✓      see StatementObject              issuer      string      ✓      see DigitalIdentityDescriptor              issuerConditions      string      ✓      see StatementIssuerConditions      Statement DigitalIdentitydescriptorThe issuer of a statement.It is not recommended to send a DigitalIdentityDescriptor to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;DigitalIdentityDescriptor&quot;      ✓                     address      string      ✓      The address of the identity that owns the statement.              attributes      string []      ✗      see Identity Attributes      StatementAuthorityTypeThe authority type in StatementIssuerConditionsIt is not recommended to send a StatementAuthorityType to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;Statement&quot;      ✓                     value      string      ✓      one of: &quot;ownAuthority&quot;, &quot;trustedAuthority&quot;, &quot;publicAuthority&quot;,&quot;relayedOwnAuthority&quot;, &quot;relayedTrustedAuthority&quot;, &quot;relayedPublicAuthority&quot;      StatementEvidenceThe evidence in StatementIssuerConditionsIt is not recommended to send a StatementEvidence to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;StatementEvidence&quot;      ✓                     value      string      ✓      one of: &quot;ownFact&quot;, &quot;digitalPublicIDCard&quot;, &quot;digitalPublicDocument&quot;,&quot;digitalDocument&quot;, &quot;sightCheckOfPublicIDCard&quot;, &quot;sightCheckOfPublicDocument&quot;,&quot;sightCheckOfDocument&quot;, &quot;mediaOfPublicIDCard&quot;, &quot;mediaOfPublicDocument&quot;, &quot;mediaOfDocument&quot;      StatementIssuerConditionsThe issuer conditions in a StatementIt is not recommended to send a StatementIssuerConditions to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;StatementIssuerConditions&quot;      ✓                     validFrom      string      ✓      The date from which on the Attribute is valid.              validTo      string      ✓      The date until this Attribute is valid              evidence      string      ✓      see StatementEvidence              authorityType      string      ✓      see StatementAuthorityType              relayedParty      string      ✗      see DigitalIdentityDescriptor      StatementObjectThe object of a statement.It is not recommended to send a object to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;StatementObject&quot;      ✓                     address      string      ✓      The address of the identity that owns the statement.              attributes      string []      ✗      see Identity Attributes      StatementPredicateThe predicate of a statement.It is not recommended to send a predicate to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;StatementPredicate&quot;      ✓                     value      string      ✓      one of: &quot;hasAttribute&quot;, &quot;relatesTo&quot;, &quot;isRelatedTo&quot; or any string starting with “z-“      StatementSubjectThe subject of a statement.It is not recommended to send a subject to another Identity by its own. Instead, send a statementProperties            Name      Type      Required      Validation                  @type      &quot;StatementSubject&quot;      ✓                     address      string      ✓      The address of the identity that owns the statement.              attributes      string []      ✗      see Identity Attributes      StreetA street name. This is usually used as part of a StreetAddress.It is not recommended to send a Street to another Identity by its own. Instead, send a StreetAddress with the street property set.Properties            Name      Type      Required      Validation                  @type      &quot;Street&quot;      ✓                     value      string      ✓      max. length: 100      StreetAddressA complex Attribute Value defining the components of a “normal” address.Properties            Name      Type      Required      Validation                  @type      &quot;StreetAddress&quot;      ✓                     recipient      string      ✓      max. length: 100              street      string      ✓      see Street              houseNo      string      ✓      see HouseNumber              zipCode      string      ✓      see ZipCode              city      string      ✓      see City              country      string      ✓      see Country              state      string | undefined      ✓      see State      SurnameThe Surname, also called family name or last name, is the portion of the personal name that indicates the family, tribe or community.It is not recommended to send a Surname to another Identity by its own. Instead, send a PersonName with the surname property set.Properties            Name      Type      Required      Validation                  @type      &quot;Surname&quot;      ✓                     value      string      ✓      max. length: 100      WebsiteThe website of the person which can be used to get more information about the person.Properties            Name      Type      Required      Validation                  @type      &quot;Website&quot;      ✓                     value      string      ✓      min. length: 3max. length: 1024must be a valid URL      ZipCodeA zip code. This is usually used as part of a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress.It is not recommended to send a ZipCode to another Identity by its own. Instead, send a DeliveryBoxAddress, PostOfficeBoxAddress or StreetAddress with the zipCode property set.Properties            Name      Type      Required      Validation                  @type      &quot;ZipCode&quot;      ✓                     value      string      ✓      max. length: 100      Relationship AttributesThe Attribute Values in this chapter can only be used in a Relationship Attribute. Most of them are generic. You can recognize those by the prefix Proprietary (e.g. ProprietaryInteger, ProprietaryString, …). In order to add some validation, you have the option to add valueHints.ConsentRepresents the consent of a person to a specific topic. If you want to obtain a consent, you can send a ReadAttributeRequestItem with a Consent-RelationshipAttribute where the owner is the peer.Properties            Name      Type      Required      Validation                  @type      &quot;Consent&quot;      ✓                     consent      string      ✓      max. length: 2000              valueHintsOverride      ValueHintsOverride      ✗                     link      string      ✗      min. length: 3max. length: 1024must be a valid URL      ProprietaryBooleanAn arbitrary boolean value.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryBoolean&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      boolean      ✓             ProprietaryCountryA two-letter country code according to ISO 3166-1 alpha-2.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryCountry&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      only ISO 3166-1 alpha-2 country codes      ProprietaryEMailAddressAn email address.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryEMailAddress&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      min. length: 3max. length: 100must match ^[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,}$      ProprietaryFileReferenceA FileReference is a link to an enmeshed File and can be used to add a File as an Attribute of a Relationship.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryFileReference&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      max. length: 100      ProprietaryFloatAn arbitrary floating-point number.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryFloat&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      number      ✓             ProprietaryHEXColorA hexadecimal color code.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryHEXColor&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      min.length: 4 must match ^#([0-9A-F]{3}){1,2}$max. length: 100      ProprietaryIntegerAn arbitrary integer number.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryInteger&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      number      ✓      must be an integer      ProprietaryJSONAn arbitrary JSON value. The value property can contain any valid JSON structure (except null).For validation purposes, the value property is stringified using JSON.stringify. That string must not exceed the maximum length of 4096 characters.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryJSON&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              value      unknown      ✓      max. length: 4096      Examples{  &quot;@type&quot;: &quot;ProprietaryJSON&quot;,  &quot;title&quot;: &quot;My JSON&quot;,  // length: 94  &quot;value&quot;: {    &quot;foo&quot;: &quot;bar&quot;,    &quot;baz&quot;: 123,    &quot;qux&quot;: true,    &quot;quux&quot;: {      &quot;corge&quot;: &quot;grault&quot;    },    &quot;garply&quot;: [&quot;waldo&quot;, &quot;fred&quot;, &quot;plugh&quot;]  }}{  &quot;@type&quot;: &quot;ProprietaryJSON&quot;,  &quot;title&quot;: &quot;My JSON&quot;,  // length: 8  &quot;value&quot;: &quot;a string&quot;}{  &quot;@type&quot;: &quot;ProprietaryJSON&quot;,  &quot;title&quot;: &quot;My JSON&quot;,  // length: 28  &quot;value&quot;: [&quot;a string&quot;, 1, { &quot;foo&quot;: &quot;bar&quot; }]}ProprietaryLanguageA two-letter ISO-639-1 language code.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryLanguage&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      only ISO-639-1 language codes      ProprietaryPhoneNumberA phone number.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryPhoneNumber&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      min. length: 3max. length: 100must match ^[\d+\-x#*()/[\] ]{3,100}$      ProprietaryStringAn arbitrary string.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryString&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      max. length: 100      ProprietaryURLA URL.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryURL&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      min. length: 3max. length: 1024must be a valid URL      ProprietaryXMLA XML.Properties            Name      Type      Required      Validation                  @type      &quot;ProprietaryXML&quot;      ✓                     title      string      ✓      max. length: 100              description      string      ✗      max. length: 1000              valueHintsOverride      ValueHintsOverride      ✗                     value      string      ✓      max. length: 50000 must be a valid XML encoded string              schemaURL      string      ✗      min. length: 3max. length: 1024must be a valid URL      ">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -2921,7 +2921,7 @@ <h2 id="proprietaryxml">ProprietaryXML</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/connector-events.html b/integrate/connector-events.html
index af7c0cf25..8853424ea 100644
--- a/integrate/connector-events.html
+++ b/integrate/connector-events.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Connector Events">
     <meta itemprop="description" content="            Event      Data      Description (This event is triggered when …)                  consumption.attributeCreated      LocalAttribute      … an Attribute was created manually or through a Request.              consumption.attributeDeleted      LocalAttribute      … an Attribute was deleted manually or through a Request.              consumption.attributeSucceeded      LocalAttribute      … an Attribute was succeeded manually or through a Request.              consumption.attributeUpdated      LocalAttribute      … an Attribute was updated manually or through a Request.              consumption.incomingRequestReceived      LocalRequest      … an incoming Request was received either by loading a Relationship Template or by receiving a Message              consumption.incomingRequestStatusChanged      RequestStatusChangedEventData      … the status of an incoming Request has changed.              consumption.messageProcessed      MessageProcessedEventData      … a Message was processed by Modules like the RequestModule or DeciderModule.              consumption.outgoingRequestCreated      LocalRequest      … any outgoing Request was created by the Connector API or Connector Module.              consumption.outgoingRequestCreatedAndCompleted      LocalRequest      … any outgoing Request was transferred via a template.This event could either be triggered: • by an incoming relationship creation change using the onNewRelationship property within the RelationshipTemplateContent • by an incoming message using the onExistingRelationship property within the RelationshipTemplateContent, if the user already has a relationship with the template creator              consumption.outgoingRequestFromRelationshipCreationChangeCreatedAndCompleted      LocalRequest      … a consumption.outgoingRequestCreatedAndCompleted event is fired and it was fired due to a RelationshipCreation Change. This convenience event is especially useful to act on incoming RelationshipRequests.              consumption.outgoingRequestStatusChanged      RequestStatusChangedEventData      … the status of an outgoing Request has changed.              consumption.relationshipTemplateProcessed      RelationshipTemplateProcessedEventData      … a RelationshipTemplate was processed by Modules like the RequestModule or DeciderModule.              consumption.sharedAttributeCopyCreated      LocalAttribute      … an Attribute is copied for sharing with another identity.              transport.messageReceived      Message      … a Message is received during synchronization.              transport.messageSent      Message      … a Message was sent.              transport.peerRelationshipTemplateLoaded      RelationshipTemplate      … a Relationship Template was loaded that belongs to another identity.              transport.relationshipChanged      Relationship      … a Relationship has changed. This can be due to one of the following cases: • you create a Relationship • you accept, reject or revoke a Relationship Change • a Relationship Change is received during synchronization      Event structureEvery event is structured as follows (TData depends on the actual event, e.g. LocalAttribute):interface Event&lt;TData&gt; {  namespace: string;  eventTargetAddress: string;  data: TData;}RequestStatusChangedEventData  LocalRequestexport interface RequestStatusChangedEventData {  request: LocalRequest;  oldStatus: LocalRequestStatus;  newStatus: LocalRequestStatus;}MessageProcessedEventData  Messageexport interface MessageProcessedEventData {  message: MessageDTO;  result: &quot;ManualRequestDecisionRequired&quot; | &quot;NoRequest&quot; | &quot;Error&quot;;}RelationshipTemplateProcessedEventData  RelationshipTemplateexport interface RelationshipTemplateProcessedEventData {  template: RelationshipTemplateDTO;  result: &quot;ManualRequestDecisionRequired&quot; | &quot;NonCompletedRequestExists&quot; | &quot;RelationshipExists&quot; | &quot;NoRequest&quot; | &quot;Error&quot;;}">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -516,7 +516,7 @@ <h3 id="relationshiptemplateprocessedeventdata">RelationshipTemplateProcessedEve
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/create-attribute-for-peer.html b/integrate/create-attribute-for-peer.html
index c887ec6d9..4ff670ca4 100644
--- a/integrate/create-attribute-for-peer.html
+++ b/integrate/create-attribute-for-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create Attribute for peer">
     <meta itemprop="description" content="There are many situations in which an Identity wants to create an IdentityAttribute or a RelationshipAttribute for another Identity, for example:  A university wants to send a graduate their degree certificate.  A company wants to provide an employee with their business email address at the start of their employment.We will now explain how a Connector, hereinafter referred to as the Sender, can create an Attribute for another Connector, the so-called Recipient. Since understanding this creation process requires knowledge about Requests and how to use them in general, you should take a look at our Request and Response introduction before continuing reading this guide.Please note that the general procedure is the same if the Connector wants to create an Attribute for an App user instead of another Connector. For reasons of clarity, this guide focuses on the creation process with two Connectors.The Sender has several options for requesting an Attribute creation. This guide covers how it can request the creation of an Attribute for the Recipient so that the Attribute Value is only set by the Sender itself and cannot be modified by the Recipient when accepting the Request.If the Recipient should be able to adjust the Attribute offered for creation, the Propose Attribute to peer guide must be consulted instead. Also, it is possible for the Sender to ask the Recipient for an Attribute of a specific Attribute Value Type without offering an Attribute by following the Read Attribute from peer guide. If the Recipient complies with this request by using the newAttribute parameter of the AcceptReadAttributeRequestItemParameters,this leads to the creation of an Attribute of the Recipient whose Attribute Value was chosen completely freely by it.Request for creating AttributesThe Sender wants to create an Attribute for the Recipient. To do this, the Sender must first create a suitable Request, which it can then send to the Recipient. In the following subsections, we describe the general appearance of a Request for creating Attributes.Role of CreateAttributeRequestItemFor requesting the creation of a single Attribute for the Recipient, a single RequestItem of type CreateAttributeRequestItem must be inserted into the items property of the Request. It is possible to request the creation of an IdentityAttribute or a RelationshipAttribute, which must be inserted into the attribute property of the CreateAttributeRequestItem. Depending on whether an IdentityAttribute or a RelationshipAttribute is to be created for the Recipient, the Sender has a different number of input options when defining the prospective owner of the Attribute. More details on the various input options when creating a Request for creating Attributes and the corresponding application scenarios can be found in the table of the Combinations and usage scenarios of the CreateAttributeRequestItem.Combinations and usage scenarios of CreateAttributeRequestItemThe following table provides an overview of the possible kinds of Attributes that the Sender can create for the Recipient using the CreateAttributeRequestItem. It must be taken into account whether the Attribute is an IdentityAttribute or a RelationshipAttribute and which Identity is its owner.            Attribute Type      Attribute Owner      Possible?      Automation      Examples/Reason                  Identity      Sender      ✗      N/A      Use ShareAttributeRequestItem instead.              Identity      Recipient      ✓      USER_DECISION      University sends student their certificate (Propose would be inappropriate in this case, because the student should not be able to return their own value).              Identity      &lt;empty&gt;      ✓      USER_DECISION      An empty owner defaults to an Attribute with owner=&lt;Recipient&gt;. This is needed for Requests inside of RelationshipTemplates, since you don’t know the enmeshed Address of your peer before the Relationship is established.              Relationship      Sender      ✓      AUTO_ACCEPT      Company sends new customer their customer number.              Relationship      Recipient      ✓      USER_DECISION      With this combination the Sender asks the Recipient for the one-time permission to write a RelationshipAttribute once and the Sender defined a value which can either be accepted and stored, or rejected. Thus, the user cannot change the value by itself.              Relationship      &lt;empty&gt;      ✓      USER_DECISION      An empty owner defaults to an Attribute with owner=&lt;Recipient&gt;. This is needed for Requests inside of RelationshipTemplates, since you don’t know the enmeshed Address of your peer before the Relationship is established.      Example of creating an IdentityAttributeWe assume that the Integrator of the Sender wants to create an IdentityAttribute of type EMailAddress for the Recipient. To request the creation of this IdentityAttribute for the Recipient, the Sender needs to insert it into the attribute property of the CreateAttributeRequestItem contained within the items property of the Request for creating Attributes. In our example, we have chosen to set the value of the mustBeAccepted property of the CreateAttributeRequestItem to true. Please note that the &lt;...&gt; notation is used as a placeholder for the actual data as usual.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;CreateAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&lt;Address of Recipient&gt;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;EMailAddress&quot;,          &quot;value&quot;: &quot;&lt;email address that the Sender wants to create for the Recipient&gt;&quot;        }      }    }  ]}Example of creating a RelationshipAttributeWe now consider the case in which the Sender has an active Relationship with the Recipient and wants to create a RelationshipAttribute of type ProprietaryString for this Relationship that is owned by the Recipient. The Sender can request the creation of this RelationshipAttribute by inserting it into the attribute property of the CreateAttributeRequestItem included in the items property of the Request for creating Attributes. In our example, we have chosen to set the value of the mustBeAccepted property of the CreateAttributeRequestItem to true and the value of the confidentiality property of the RelationshipAttribute to &quot;public&quot;.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;CreateAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;RelationshipAttribute&quot;,        &quot;owner&quot;: &quot;&lt;Address of Recipient&gt;&quot;,        &quot;key&quot;: &quot;&lt;key of RelationshipAttribute&gt;&quot;,        &quot;confidentiality&quot;: &quot;public&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;ProprietaryString&quot;,          &quot;title&quot;: &quot;&lt;title of RelationshipAttribute&gt;&quot;,          &quot;value&quot;: &quot;&lt;actual value of RelationshipAttribute&gt;&quot;        }      }    }  ]}It would also be possible to specify the Address of the Sender as the value for the owner property if you want the RelationshipAttribute to be owned by the Sender instead of the Recipient.Create multiple AttributesRequesting the creation of Attributes for a peer is not limited to just a single Attribute, but it is possible to request the creation of multiple Attributes at the same time. For this purpose, several CreateAttributeRequestItems or suitable RequestItemGroups can be inserted into the items property of the Request for creating Attributes. If you want to use a RequestItemGroup in order to create multiple Attributes for the Recipient at the same time, you must insert corresponding CreateAttributeRequestItems into the items property of it.Send and receive the RequestThe Sender that wants to create an Attribute for the Recipient may or may not already have a Relationship with the Recipient. Depending on which is the case, a different method can be used to send the Request for creating Attributes. There are two ways to send the Request for creating Attributes created by the Sender to the Recipient.Request over TemplateIf there is currently no Relationship between the Sender and the Recipient, this approach must be used. However, it is also possible for the Sender to use a RelationshipTemplate to send a Request to the Recipient if there is already an active Relationship between them. All details on how to send and receive a Request via a RelationshipTemplate in general can be found in the Requests over Templates guide.Request over MessageThe Sender only has the option of sending a Request to the Recipient via a Message if there is already an active Relationship between them. All information on how to send and receive a Request via a Message can be found in the Requests over Messages guide.Accept the Request and create the AttributesAfter the Recipient has received the Request for creating Attributes, it can accept it to create all or some of the Attributes that were offered for creation by the Sender. To do this, proceed as described in the Accept incoming Request use case documentation and specify the id of the received Request. Also, you need to decide and specify for each CreateAttributeRequestItem and RequestItemGroup contained in the Request for creating Attributes whether you want to accept or reject it.If the Recipient does not want to create any of the Attributes offered by the Sender and, therefore, does not want to accept the Request for creating Attributes of the Sender, it can reject it as a whole as well. For that, follow the instructions of the Reject incoming Request use case.Accept a CreateAttributeRequestItemIf the Recipient agrees to the creation of one of the Attributes offered by the Sender, it can accept the associated CreateAttributeRequestItem contained in the Request for creating Attributes. The AcceptRequestItemParameters must be used for that. The acceptance of a CreateAttributeRequestItem leads to the creation of a corresponding LocalAttribute with a LocalAttributeShareInfo contained within its shareInfo property. The content of the LocalAttribute is the underlying attribute of the CreateAttributeRequestItem. Based on this, an appropriate AcceptResponseItem of type CreateAttributeAcceptResponseItem is generated, which incorporates the id of the LocalAttribute with the LocalAttributeShareInfo in its attributeId property. This will be contained within the items property of the Response to the Request for creating Attributes that will be transferred to the Sender. If the underlying attribute of the accepted CreateAttributeRequestItem is an IdentityAttribute, a corresponding LocalAttribute without a LocalAttributeShareInfo is additionally created for the Recipient beforehand.Reject a CreateAttributeRequestItemEven if the Recipient accepts the Request for creating Attributes as a whole, it may decide not to accept all of the Attributes offered by the Sender. To be more precise, the Recipient has the option of rejecting CreateAttributeRequestItems that have the value false specified in their mustBeAccepted property. To reject a CreateAttributeRequestItem, use the RejectRequestItemParameters. The rejection of a CreateAttributeRequestItem leads to the creation of a corresponding ResponseItem of type RejectResponseItem. This will be contained within the items property of the Response to the Request for creating Attributes.Example of accepting a RequestItemGroupLet’s look at an example where the Sender wants to create an EMailAddress, a BirthDate and a BirthPlace for the Recipient. For this purpose, the Sender creates a Request for creating Attributes, which contains a CreateAttributeRequestItem belonging to the EMailAddress and a RequestItemGroup belonging to the birth information in its items property. The RequestItemGroup itself includes two CreateAttributeRequestItems in its items property, namely one for the BirthDate and one for the BirthPlace.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;CreateAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&lt;Address of Recipient&gt;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;EMailAddress&quot;,          &quot;value&quot;: &quot;&lt;email address that the Sender wants to create for the Recipient&gt;&quot;        }      }    },    {      &quot;@type&quot;: &quot;RequestItemGroup&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;items&quot;: [        {          &quot;@type&quot;: &quot;CreateAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: true,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&lt;Address of Recipient&gt;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;BirthDate&quot;,              &quot;day&quot;: &lt;day of birth date that the Sender wants to create for the Recipient&gt;,              &quot;month&quot;: &lt;month of birth date that the Sender wants to create for the Recipient&gt;,              &quot;year&quot;: &lt;year of birth date that the Sender wants to create for the Recipient&gt;            }          }        },        {          &quot;@type&quot;: &quot;CreateAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: false,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&lt;Address of Recipient&gt;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;BirthPlace&quot;,              &quot;city&quot;: &quot;&lt;city of birth place that the Sender wants to create for the Recipient&gt;&quot;,              &quot;country&quot;: &quot;&lt;country of birth place that the Sender wants to create for the Recipient&gt;&quot;            }          }        }      ]    }  ]}In our example, the Sender only requires the Recipient to accept the EMailAddress and the BirthDate, which is why the individual CreateAttributeRequestItems and the RequestItemGroup within the Request have specified corresponding values in their mustBeAccepted property. We assume that the Recipient wants to accept the Request and all its CreateAttributeRequestItems with the exception of the BirthPlace.If the Recipient wants to accept the Request for creating Attributes, it must accept all CreateAttributeRequestItems for which the mustBeAccepted property is set to true. It is therefore not permitted for the Recipient to refuse to accept the EMailAddress or the BirthDate offered by the Sender.The Recipient accepts the EMailAddress of the Sender and accepts at least one CreateAttributeRequestItem of the RequestItemGroup. Also, the Recipient accepts the BirthDate and rejects the BirthPlace of the Sender. It therefore responds to the Request for creating Attributes as follows:{  &quot;items&quot;: [    {      // Accept EMailAddress      &quot;accept&quot;: true    },    {      // Accept RequestItemGroup      &quot;accept&quot;: true,      &quot;items&quot;: [        {          // Accept BirthDate          &quot;accept&quot;: true        },        {          // Reject BirthPlace          &quot;accept&quot;: false        }      ]    }  ]}Note that it is important to respond to RequestItems and RequestItemGroups in the same order in which they were received.Receive the Response to the RequestWe now assume that the Recipient has accepted the Request for creating Attributes of the Sender. In order for the Sender to receive the Response of the Recipient, it needs to synchronize the updates of the Backbone. Please note that this synchronization can also be automated by using the Sync Module.To view the Response to the Request, search for it in the synchronization result or proceed as described in the Query outgoing Requests use case documentation and use the following query parameter:  If the Request was sent via a Template: Specify &lt;ID of RelationshipTemplate&gt; as the value for the source.reference query parameter.  If the Request was sent via a Message: Specify &lt;ID of Request&gt; as the value for the id query parameter.The Integrator of the Sender can now get the Response of the Recipient from the response.content property of the result. In the items property of the Response is a CreateAttributeAcceptResponseItem for each accepted CreateAttributeRequestItem and a RejectResponseItem for each rejected CreateAttributeRequestItem included. Note that each accepted CreateAttributeRequestItem leads to the creation of an appropriate LocalAttribute with a LocalAttributeShareInfo of the Sender. The content of the LocalAttribute is the underlying attribute of the CreateAttributeRequestItem.In case of an error, ErrorResponseItems can also be included in the Response. If the Request for creating Attributes contains a RequestItemGroup in its items property, the Response to this Request contains a corresponding ResponseItemGroup in its items property.What’s next?As already mentioned, this guide covers how an Identity can request the creation of an Attribute for a peer so that the Attribute Value is only set by the Identity itself and cannot be modified by the peer when accepting the Request. In many cases, it makes more sense if the peer can adjust the Attribute that was offered for creation. For that, take a look at the Propose Attribute to peer guide.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -647,7 +647,7 @@ <h2 id="whats-next">What’s next?</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/creating-complex-requests.html b/integrate/creating-complex-requests.html
index fefe9da84..12d146b37 100644
--- a/integrate/creating-complex-requests.html
+++ b/integrate/creating-complex-requests.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Creating complex requests">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.FlowOne enmeshed Request can contain several semantically different RequestItems. Each RequestItem is atomic in how the RequestItem is processed by enmeshed. The Request itself is then the transactional boundary: Either the whole Request is accepted as a complete construct or it is rejected (same as expiry). This also means that all required fields from all RequestItems inside the Request must be filled.Optional RequestItems can be flagged with the help of the mustBeAccepted property for every RequestItem: If a RequestItem must be accepted, it means it is a required item which needs to be filled out. If mustBeAccepted is false, the RequestItem is counted as optional and thus can be omitted. A Request must contain at least one mustBeAccepted RequestItem, otherwise the Request wouldn’t make sense.There is also the option to use RequestItemGroups to semantically cluster a big Request into several parts. For example, one could split up a Request into semantic groups like “things I’d like to share”, “things I need to know”, “things I’d like to know” and “things we must agree on”.Examples  The very first Request between two Identities is a very important one, as Attributes should be shared between each other and at least some privacy consent should be given. Only if the user agrees to this Request, the actual Relationship is created.  Upgrading a contract or moving a user to a different role, might require personal information and consents to be shared as a whole. Only if the Identity agrees to this Request, the actual contract or role can be switched.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -392,7 +392,7 @@ <h1 id="examples">Examples</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/data-model-overview.html b/integrate/data-model-overview.html
index b585ef3e7..94a4f3819 100644
--- a/integrate/data-model-overview.html
+++ b/integrate/data-model-overview.html
@@ -10,7 +10,7 @@
     <meta charset="utf-8">
 
 <!-- begin _includes/seo.html --><title>Data Model Overview - enmeshed</title>
-<meta name="description" content="The enmeshed data model can be divided into three parts:     Transport types   Local types   Content types   The following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.   (note that you can click on each type in order to navigate to the paragraph with the corresponding description)  At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.  Transport Types  Transport types like RelationshipTemplate, Token or File are types that are “exchanged” between Identities via the Backbone. They are created and updated by the Transport Layer. In most cases they have a content property, which contains the actual payload that should be transferred between the Identities. This payload is being encrypted when it is sent to the Backbone, and decrypted by the other Identity when it is received. The following sections describe the different Transport types and their properties.  Note that the properties of the types are the ones that exist locally (aka on the Connector/in the App). The Backbone does not necessarily know about them. The properties that only exist locally are marked accordingly in the tables below. Further there are properties that are confidential and are therefore encrypted before sent to the Backbone, in order to enable end-to-end encryption. Both kinds of these properties are marked accordingly in the “Remarks” column of the property tables below.  Token  Tokens can be used to save arbitrary structured data on the Backbone, which is encrypted with a random symmetric key. You can then pass the ID of the Token, together with the random key, to another Identity, which can then retrieve the token and decrypt it, e.g. inside of a QR Code, which you send to the recipient via letter. Tokens can be handy in a lot of scenarios, for example:     You want to share secret information with someone you don’t have a Relationship with.   The enmeshed App currently uses a Token to save a Backup of the Identity. ID and secret key are then encoded in a QR Code, which the user can print out and scan later in order to restore the Identity on a new device.   A Token has the following properties:                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Token starts with the letters “TOK”. This way you can tell apart a Token ID from any other ID just by looking at the prefix.                         createdBy       string       The Address of the Identity that created the Token.                         createdByDevice       string       The ID of the Device that created the Token. You can use this information to track back who exactly did what.                         content       unknown       The content of the Token. You can add whatever you want here.       will be encrypted before sent to the Backbone                 createdAt       string       A timestamp that describes when the Token was created                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.                         secretKey       string       The key with which the Token was encrypted.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the Token. You can use it to share the Token with someone else.       saved only locally                 isEphemeral       boolean       If set to true the Token will not be cached in the database and only displayed once. You will not be able to fetch this Token unless you remember its id and secretKey.                   RelationshipTemplate  A Relationship Template serves two purposes:     It represents the permission to establish a Relationship. When sending a Relationship request, the sender has to attach the ID of a valid Relationship Template created by the recipient. Otherwise the Backbone blocks the Relationship request. And since the IDs are randomly generated, you can only obtain such an ID from the recipient.   It can contain data which is of interest for the one who uses the Relationship Template. The enmeshed App for example expects a Relationship Template content which contains a Request which contains e.g. Attributes about the creator of the Template as well as queries for Attributes that the Template creator wants to receive together with the Relationship request.                  Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Template starts with the letters “RLT”. This way you can tell apart a Relationship Template ID from any other ID just by looking at the prefix.                         isOwn       boolean       true if the Relationship Template was created by yourself, false if it was created by someone else.       saved only locally                 createdBy       string       The Address of the Identity that created the Relationship Template.                         createdByDevice       string       The ID of the Device that created the Relationship Template. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Token was created                         content       RelationshipTemplateContent | unknown       The content of the Relationship Template. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, RelationshipTemplateContent has to be used. Otherwise feel free to insert whatever you want or need.                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.       will be encrypted before sent to the Backbone                 maxNumberOfAllocations       number | undefined       Can be set to limit the number of allocations of this template. A Relationship Template is allocated by another Identity when it is first retrieved by it from the Backbone. After this value is reached, the Backbone rejects each request of any new Identity that wants to retrieve it. Identities that already allocated it will still be able to retrieve it.                         truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the RelationshipTemplate. You can use it to share the RelationshipTemplate with someone else.                   Relationship  A Relationship between two Identities is the prerequisite for them to exchange Messages. If there is no Relationship, the Backbone blocks all Messages that are tried to be sent. This ensures that you only receive Messages from Identities you know, so you are protected from any harmful Messages like spam or phishing mails.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship starts with the letters “REL”. This way you can tell apart a Relationship ID from any other ID just by looking at the prefix.                         template       RelationshipTemplate       The Relationship Template that was used to establish this Relationship.                         status       &quot;Pending&quot; | &quot;Active&quot; | &quot;Rejected&quot; | &quot;Revoked&quot;       The status of this Relationship. Pending: the Relationship was created, but not yet accepted the recipient. In this state you cannot send Messages yet.Active: this means that the Relationship is active. As long as it is active, both participants can exchange Messages.Rejected: the Relationship was rejected by the recipient.Revoked: the Relationship was revoked by the sender.                         changes       RelationshipChange[]       The history of changes made to this Relationship. You can find the definition of a Relationship Change below.                         peer       string       The Address of the Identity with which you have this Relationship.       saved only locally           RelationshipChange  Since a Relationship “belongs” to two Identities, each change on such a Relationship demands for the agreement of both parties. That’s where Relationship Changes come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a Relationship Change to the other party, which has to accept it in order for the change to take effect. If the other party doesn’t want to accept it, it can also reject it. And if the party that created the Relationship Change changes its mind, it can revoke the Relationship Change. The Backbone makes sure that a Relationship Change can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a Relationship Change that is already revoked, you will receive an error.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Change starts with the letters “RCH”. This way you can tell apart a Relationship Change ID from any other ID just by looking at the prefix.                         status       &quot;Pending&quot; |&quot;Accepted&quot; |&quot;Rejected&quot; |&quot;Revoked&quot;       The current status of the Relationship Change.                         type       &quot;Creation&quot;       The type of the Relationship Change. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second Relationship Change type.                         request       RelationshipChangeRequest       Information about the request of the Relationship Change.                         response       RelationshipChangeResponse | undefined       Information about the response of the Relationship Change.                   Note that RelationshipChangeRequest and RelationshipChangeResponse have nothing to do with Requests and Responses, which we will discuss later.  RelationshipChangeRequest                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Request.                         createdByDevice       string       The ID of the Device that created the Relationship Change Request. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Request was created                         content       RelationshipCreationChangeRequestContent | unknown       The content of the Relationship Change Request. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the Relationship Change is Creation, RelationshipCreationChangeRequestContent has to be used. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone           RelationshipChangeResponse                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Response.                         createdByDevice       string       The ID of the Device that created the Relationship Change Response. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Response was created                         content       unknown       The content of the Relationship Change Response. You can add whatever you want here. Since the enmeshed App doesn’t expect any special content here, there is no need to watch out.       will be encrypted before sent to the Backbone           Message  A Message is a piece of data that can be sent to one or more recipients. The sender is completely free in what the content of the Message looks like. Though in order to enable a normalized communication, enmeshed defines some content structures for Messages, and in the future there will be more of those. Consider that the enmeshed App only supports those normalized Message contents. Currently there are:     Mail   Request   ResponseWrapper   You can read more details about each of these in the corresponding sections of the “Content Types” chapter.  But if you are communicating with another Connector, feel free to settle on any content structure that fits your needs.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Message starts with the letters “MSG”. This way you can tell apart a Message ID from any other ID just by looking at the prefix.                         content       unknown       The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either Mail, Request or Response. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone                 createdBy       string       The Address of the Identity that created the Message.                         createdByDevice       string       The ID of the Device that created the Message. You can use this information to track back who exactly did what.                         recipients       Recipient[]       An array of recipients of this Message.                         createdAt       string       A timestamp that describes when the Message was created                         attachments       string[]       An array of File IDs you want to attach to your Message. You receive the File ID after you uploaded a file to the Backbone. By attaching a File to a Message, you share the secret key used to encrypt/decrypt the File, which cannot be undone.                   Recipient                 Name       Type       Description       Remarks                       address       string       The Address of the recipient of the Message.                         relationshipId       string       The ID of the Relationship between the recipient and the sender of the Message.       saved only locally                 receivedAt       string | undefined       A timestamp that describes when the recipient retrieved the Message from the Backbone. undefined when the Message wasn’t received yet. Caution: “received” does not mean that it was read, so don’t mix this up with a read receipt.                         receivedByDevice       string | undefined       The ID of the Device that first retrieved the Message. undefined when the Message wasn’t received yet. This is of no interest for the sender of the Message, but rather for the recipient itself, since they can use it for audit purposes. sender                   File  The Backbone allows you to upload files, which are saved as - you guessed it - Files.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each File starts with the letters “FIL”. This way you can tell apart a File ID from any other ID just by looking at the prefix.                         createdAt       string       A timestamp that describes when the File was created                         createdBy       string       The Address of the Identity that created the File.                         createdByDevice       string       The ID of the Device that created the File. You can use this information to track back who exactly did what.                         expiresAt       string       A timestamp that describes when the File expires on the Backbone. An expired File cannot be fetched from the Backbone anymore. However, the cached version of the File on Connector and App will still be accesible.                         filename       string       The name of the file as it was on the device that uploaded it.       will be encrypted before sent to the Backbone                 filesize       number       The size of the plaintext file in bytes.       will be encrypted before sent to the Backbone                 mimetype       string       The mimetype of the file.       will be encrypted before sent to the Backbone                 title       string       A human readable title of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 description       string | undefined       A human readable description of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 secretKey       string       The key that was used to encrypt the File.       saved only locally                 isOwn       boolean       true if the File was created by yourself, false if it was created by someone else.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the File. You can use it to share the File with someone else.       saved only locally           A File further has its content, of course. But since this is not a JSON property, it is not included in this table. You can download the content of the File separately.  Local Types  In addition to the types that are shared between Identities via the Backbone, there are certain types that only exist within one Identity. These types usually contain metadata about Content types that should not be transferred to other Identities. They are created and updated by the Consumption Layer.  Currently there are three main Local types:     LocalRequest   LocalNotification   LocalAttribute   Each of them further describes some sub types.  This chapter explains all of those types, together with their properties.  LocalRequest  A LocalRequest contains the local metadata for a Request.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalRequest starts with the letters “REQ”. This way you can tell apart a LocalRequest ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Request, false if you received it.                 peer       string       The Identity that sent you the corresponding Request/that you sent the Request to.                 createdAt       string       A timestamp that describes when the LocalRequest was created                 status       LocalRequestStatus       The current status of the Request. See below for a list of all possible values.                 content       Request       The actual Content object this LocalRequest defines the metadata for.                 source       LocalRequestSource | undefined       Information about the Transport object with which the Request came in/was sent. This property is undefined if the Request is not sent yet.                 response       LocalResponse | undefined       Metadata + Content object of the response. If there is no response yet, this property is undefined.           LocalRequestStatus  Depending on whether it is an incoming or an outgoing Request, there can be different statuses. The following state diagram shows which status exists in both cases and when there are transitions from one state to another:       Draft   This status only exists for outgoing Requests. It means that the LocalRequest was created, but not yet sent.   Open   In case of an outgoing Request, Open means that the Request was sent. The transition to Open happens automatically when you send the Request with a Message.   In case of an incoming Request, Open means that the LocalRequest was received.   DecisionRequired   After the prerequisites of the Request and all of its RequestItems were checked, a decision can be made. At first, the Decider Module tries to make an automatic decision. It therefore checks all LocalRequests in status DecisionRequired.   ManualDecisionRequired   If the Decider Module cannot make a decision, it moves the LocalRequest to ManualDecisionRequired. When the LocalRequest is in this status, it’s the User’s turn to decide whether they want to accept or reject the Request.   Decided   When the User or the Decider Module accepts or rejects the Request, the Response and ResponseItems are generated based on the passed parameters. This Response is saved in the response property of the LocalRequest, but not yet sent.   Completed   In case of an incoming Request, the Runtime Module listens to an Event saying that a Request moved to status Decided. It then checks on which way the Request was received (Message/RelationshipTemplate) and sends the Response on the corresponding way (by sending a message or creating a Relationship). After the Response was successfully sent, it moves the LocalRequest to Completed.   In case of an outgoing Request, the Runtime Module listens to the MessageReceivedEvent and checks the content of the sent Message for a Response. If there is one, it moves the corresponding LocalRequest to Completed.   Expired   When the timestamp in expiresAt of a Request is reached, the Request automatically moves to the status Expired.   LocalRequestSource  With the information in this type you can clearly identify the Transport object the Request was sent/received in. Currently there are only two possibilities: Message and Relationship Template.                 Name       Type       Description                       type       “Message” | “RelationshipTemplate”       The type of Transport object the Request was sent/received in.                 reference       string       The ID of the Transport object the Request was sent/received in.           LocalResponse  When a LocalRequest is decided/received, a Local Response is generated, which contains the Response, together with some metadata.                 Name       Type       Description                       createdAt       string       A timestamp that describes when the LocalResponse was created                 content       Response       The actual Content object this Local Response defines the metadata for.                 source       LocalResponseSource | undefined       Information about the Transport object with which the Response came in/was sent. This property is undefined if the Response is not sent/received yet.           LocalResponseSource  With the information in this type you can clearly identify the Transport object the Response was sent/received in. Currently there are only two possibilities: Message and Relationship Change.                 Name       Type       Description                       type       “Message” | “RelationshipChange”       The type of Transport object the Response was sent/received in.                 reference       string       The ID of the Transport object the Response was sent/received in.           LocalNotification  A LocalNotification contains the local metadata for a Notification.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalNotification starts with the letters “NOT”. This way you can tell apart a LocalNotification ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Notification, false if you received it.                 peer       string       The Identity that sent you the corresponding Notification/that you sent the Notification to.                 createdAt       string       A timestamp that describes when the LocalNotification was created                 status       LocalNotificationStatus       The current status of the Notification. See below for a list of all possible values.                 content       Notification       The actual Content object this LocalNotification defines the metadata for.                 source       LocalNotificationSource       Information about the Transport object with which the Notification came in/was sent.                 receivedByDevice       string | undefined       The ID of the device that received the Notification. For reasons of consistence, the Notification can only be processed by this device.           LocalNotificationStatus  Depending on whether it is an incoming or an outgoing Notification, there can be different statuses.     Sent   This is the only valid status on sender side. If a Notification is sent and, therefore, a LocalNotification is created, its status will be set to Sent.   Open   Receiving a Notification, a LocalNotification is created with status Open.   Completed   After receiving a Notification, its items will be processed internally. If all processes finish successfully, the status of the LocalNotification will be set to Completed.   Error   If an error occurs while processing the items of a received Notification, the status of the LocalNotification will be set to Error.   LocalNotificationSource  With the information in this type you can clearly identify the Transport object the Notification was sent/received in. Currently, the only possibility for transmitting Notifications are Messages.                 Name       Type       Description                       type       “Message”       The type of Transport object the Notification was sent/received in. So far, Notifications can only be transmitted via Messages.                 reference       string       The id of the Transport object the Notification was sent/received in.           LocalAttribute  A LocalAttribute contains the local metadata for an Attribute. There are three situations a LocalAttribute is created in the database:     The Identity maintains an Attribute about itself (e.g. sets its first name). We call such a LocalAttribute “RepositoryAttribute”.   The Identity shares an Attribute of itself with another Identity (e.g. sends it in a Request). In that case, a copy of the original LocalAttribute is created, where the shareInfo property is set.   The Identity receives an Attribute from another Identity (e.g. receives it in a Request). In that case a new LocalAttribute is created, where the shareInfo is set.                  Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttribute starts with the letters “ATT”. This way you can tell apart a LocalAttribute ID from any other ID just by looking at the prefix.                 parentId       string | undefined       If the Attribute referenced by this LocalAttribute is a component of a composite Attribute, the parentId property is set to the id of the composite Attribute. Example: if a LocalAttribute is created with the content StreetAddress, for each property of the StreetAddress an additional LocalAttribute is created. And each of these will have parentId set to the id of the LocalAttribute for the StreetAddress.                 createdAt       string       A timestamp that describes when the LocalAttribute was created                 content       IdentityAttribute | RelationshipAttribute       The actual Content object this LocalAttribute defines the metadata for.                 succeeds       string | undefined       The ID of the LocalAttribute that succeeds the current one.                 succeededBy       string | undefined       The ID of the LocalAttribute that is succeeded by the current one.                 shareInfo       LocalAttributeShareInfo | undefined       Information about the peer this LocalAttribute was received from/shared with, as well as via which LocalRequest it was received/sent. If the LocalAttribute refers to a RepositoryAttribute, this property is undefined.           LocalAttributeShareInfo  The LocalAttributeShareInfo helps to keep track of how the LocalAttribute was received/sent, from whom it was received/who sent it, as well as which LocalAttribute it was copied from (in case of a shared IdentityAttribute). For example, this enables us to track back who we shared a certain IdentityAttribute with, so we are able to notify each of them when changing it. The Attribute can be either transmitted via Request or Notification. Hence, only one of requestReference and notificationReference can be set.                 Name       Type       Description                       peer       string       The Address of the Identity the LocalAttribute was received from/shared with.                 requestReference       string | undefined       The id of the LocalRequest the LocalAttribute was received in/sent with. If this is set, notificationReference must be undefined.                 notificationReference       string | undefined       The id of the LocalNotification the LocalAttribute was received in/sent with. If this is set, requestReference must be undefined.                 sourceAttribute       string | undefined       If the LocalAttribute is a copy of a RepositoryAttribute, then this property contains the id of the RepositoryAttribute.           LocalAttributeListener  A LocalAttributeListener is created when you accept an incoming Request with a RegisterAttributeListenerRequestItem. It is used to keep track of which Attribute Listeners currently exist and what they are listening for.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttributeListener starts with the letters “ATL”. This way you can tell apart a LocalAttributeListener ID from any other ID just by looking at the prefix.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The query the Attribute that is listened to must match. Note that you cannot send a RelationshipAttributeQuery here, because it doesn’t make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it.                 peer       string       The Address of the peer that requested the Attribute Listener.           Content Types  Content Types can be seen as a data contract between Identities. The medium through which this data is exchanged are the Transport types (e.g. Messages, Tokens, …). This chapter shows all the Content types and describes their intended usage.  Request  A Request allows you to ask another Identity to do something. What this “something” is depends on which of the so called RequestItems were added to the Request (e.g. CreateAttributeRequestItem, ReadAttributeRequestItem, …). The Request is then sent to the peer via Message or Relationship Template. The peer can then review the Request and decide whether they want to accept or reject it. And if they accept it, they can even choose which of the Items they want to accept. You can also put multiple Items into a group in order to ensure that they can only be accepted/rejected as a unit.                 Name       Type       Description                       @type       “Request”                         id       string | undefined       Unique identifier of this object. This property is undefined if the Request is inside of a Relationship Template. Remark: the ID of each Request starts with the letters “REQ”. This way you can tell apart a Request ID from any other ID just by looking at the prefix.                 title       string | undefined       An optional, human readable title for the Request.                 description       string | undefined       An optional, human readable description for the Request.                 expiresAt       string | undefined       A timestamp that describes when the Request expires on the Backbone. An expired Request cannot be fetched from the Backbone anymore. However, the cached version of the Request on Connector and App will still be accesible.                 items       (RequestItemGroup | \*RequestItem)[]       An array of RequestItems and Groups that are part of the Request. There must be at least one Item or Group per Request.                 metadata       string | undefined       Optional custom metadata that can be sent together with the Request. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Request.           RequestItems  RequestItems can be sent inside of a Request and specify what should be done when the Request is accepted.  AuthenticationRequestItem                 Name       Type       Description                       @type       &quot;AuthenticationRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ConsentRequestItem                 Name       Type       Description                       @type       &quot;ConsentRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 consent       string       The textual consent the user needs to give. This is different to the title and description of the RequestItem, as the consent would be the actual statement the user agrees to.                 link       string | undefined       A valid URL linking to a website which contains more information, like the EULA or privacy terms.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           CreateAttributeRequestItem                 Name       Type       Description                       @type       &quot;CreateAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to create for the peer within the Identity of the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           FreeTextRequestItem                 Name       Type       Description                       @type       &quot;FreeTextRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 freeText       string       The free text you want to send to the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ProposeAttributeRequestItem                 Name       Type       Description                       @type       &quot;ProposeAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ReadAttributeRequestItem                 Name       Type       Description                       @type       &quot;ReadAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | ThirdPartyRelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RegisterAttributeListenerRequestItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The structured query of the Attribute the sender would like to query.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ShareAttributeRequestItem                 Name       Type       Description                       @type       &quot;ShareAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to share. This is not the LocalAttribute but the content data structure of the Attribute. The owner of the Attribute which should be shared can only be the sender Identity.                 sourceAttributeId       string       The id of the LocalAttribute which is the source of the shared Attribute. This will be used later to reference the sourceAttribute from its shared copy.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RequestItemGroup                 Name       Type       Description                       @type       &quot;RequestItemGroup&quot;                         title       string | undefined       An optional, human readable title for the RequestItem Group.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       Optional metadata that can be sent together with this RequestItem. The intended usage is the same as of the metadata property of the Request.                 mustBeAccepted       boolean       If set to true, then this RequestItem Group has to be accepted when the Request is accepted.                 items       *RequestItem[]       The items inside of this Group. There has to be at least one RequestItem per Group. Note that we do not support nested Groups at the moment. If you need this feature, you can raise a feature request.           Response                 Name       Type       Description                       @type       &quot;Response&quot;                         result       &quot;Accepted&quot; | &quot;Rejected&quot;       Whether the Response was accepted or rejected by the recipient of the Request.                 requestId       string       The id of the Request this Response belongs to. The Sender of the Request needs this information to map the Response to the corresponding Request.                 items       (ResponseItemGroup\|ResponseItem)[]       An array of Response Items and Groups that are part of the Response. For each RequestItem (Group) of the Request, there must be one Response Item (Group) in the Response. Note that the indices have to be the same for matching Request and Response Items.           ResponseItems  Response Items are sent inside of a Response. They contain the response data that is sent by the recipient of the Request. There are three different kinds of Response Items: AcceptResponseItem, RejectResponseItem and ErrorResponseItem. Depending on the actual RequestItem, there can be different derivations of these three items. For example, in case of a CreateAttributeRequestItem, there is a special CreateAttributeAcceptResponseItem, while for an AuthenticationRequestItem, the AcceptResponseItem can be used, because there is no additional information necessary next to whether it was accepted or rejected.  AcceptResponseItem                 Name       Type       Description                       @type       &quot;AcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.           CreateAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;CreateAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.           FreeTextAcceptResponseItem                 Name       Type       Description                       @type       &quot;FreeTextAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 freeText       string       The free text that is used to answer the RequestItem.           ProposeAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ProposeAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.The owner of the Attribute which is proposed can only be the recipient Identity.           ReadAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ReadAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the returned LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute that will be shared to the peer.           RegisterAttributeListenerAcceptResponseItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 listenerId       string       The id of the created AttributeListener.           ShareAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ShareAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the shared LocalAttribute.           RejectResponseItem                 Name       Type       Description                       @type       &quot;RejectResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Rejected&quot;       The only possible value here is the string &quot;Rejected&quot;.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           ErrorResponseItem  The ErrorResponseItem is only created by the enmeshed Runtime, in case something happens which hinders you from further processing of the RequestItem. It will never be created manually. The properties are:                 Name       Type       Description                       @type       &quot;ErrorResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Error&quot;       The only possible value here is the string &quot;Error&quot;.                 code       string       An error code telling the sender about the kind of error that occurred.                 message       string       A human readable error message with details about the error.           ResponseItemGroup                 Name       Type       Description                       @type       &quot;ResponseItemGroup&quot;                         items       ResponseItem[]       The items inside of this Group. For each RequestItem of the RequestItem Group, there must be one Response Item in the Response Item Group. Note that the indices have to be the same for matching Request and Response Items.           ResponseWrapper  The ResponseWrapper is a wrapper around the Response that is sent by the recipient of the Request. It contains the Response itself, but also some additional information that is required for the Request to be processed correctly.                 Name       Type       Description                       @type       &quot;ResponseWrapper&quot;                         requestId       string       The id of the Request this Response belongs to.                 requestSourceReference       string       The reference to the Message or RelationshipTemplate the Request was received with.                 requestSourceType       &quot;Message&quot; | &quot;RelationshipTemplate&quot;       Specifies if the Request was transferred via Message or RelationshipTemplate.                 response       Response       The Response that is sent by the recipient of the Request.           Notification  Notifications provide you with the possibility to notify a peer about something, e.g. the succession of one of your Attributes. However, unlike Requests they don’t offer the option to make a decision whether or not they want to accept this change. In the example of Attribute succession, the peer can not decide to accept or reject the updated value, but is simply informed about it.                 Name       Type       Description                       @type       &quot;Notification&quot;                         id       string       Unique identifier of this object. Remark: the ID of each Notification starts with the letters “NOT”. This way you can tell apart a Notification ID from any other ID just by looking at the prefix.                 items       NotificationItem[]       An array of NotificationItems that are part of the Notification. There must be at least one Item per Notification.           NotificationItems  NotificationItems are sent inside a Notification and specify which processes should be triggered when receiving the Notification.  PeerSharedAttributeSucceededNotificationItem  A PeerSharedAttributeSucceededNotificationItem will be sent, if an Attribute, a peer shared with you, was succeeded by them and they choose to notify you about it. Internally, the succeeded version will then be created at your side as successor for your previously received Attribute.                 Name       Type       Description                       @type       &quot;PeerSharedAttributeSucceededNotificationItem&quot;                         predecessorId       string       The id of the LocalAttribute that was succeeded                 successorId       string       The id of the LocalAttribute it was succeeded by                 successorContent       IdentityAttribute | RelationshipAttribute       The updated content of the LocalAttribute           Attributes  An Attribute is some piece of information about an Identity itself (e.g. its name, address, birth date, etc.) or about an Identity in the context of a Relationship (e.g. the customer id the of the user the Relationship). Since the two scenarios differ quite a lot, there are two different types for them: IdentityAttribute and RelationshipAttribute.  IdentityAttribute  IdentityAttributes describe an Identity itself. Their values are strongly normalized. There is a list of available values here.                 Name       Type       Description                       @type       &quot;IdentityAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 value       IdentityAttributeValue       The Attribute’s value.                 tags       string[] | undefined       To specify additional information.           RelationshipAttribute  RelationshipAttributes describe an Identity in the context of a Relationship. While there are some types that can be used as a value for a RelationshipAttribute, these types are rather generic (e.g. ProprietaryString, ProprietaryInteger, …).                 Name       Type       Description                       @type       &quot;RelationshipAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 key       string       An arbitrary key that is set by the creator of this Attribute. It is used to identify the Attribute in a query, especially by a third party. Example: you could set something like customerId in case of a customer id.                 isTechnical       boolean | undefined       Defines whether the RelationshipAttribute contains data that is actually relevant for the user (isTechnical=false) or whether it should be hidden in the UI (isTechnical=true).                 value       RelationshipAttributeValue       The Attribute’s value.                 confidentiality       &quot;public&quot; | &quot;protected&quot; | &quot;private&quot; | When this property is set to &quot;private&quot;, it means that third parties are not able to query this RelationshipAttribute. It therefore only exists in the Relationship it was created in. If the confidentiality is &quot;protected&quot;, third parties can query the RelationshipAttribute, but the App shows a warning saying that you should only share it with someone you trust. If the confidentiality is &quot;public&quot;, everybody can query the Attribute, without anything special to happen.                   AttributeQueries  One of the main features of enmeshed is sharing Attributes. For this, an Identity either proactively sends its Attributes to a peer. Or, if let’s say a company wants to know the birth date of its customer, it can ask for it. Depending on the exact use case, the latter can be achieved with one of a bunch of RequestItems, like for example a ReadAttributeRequestItem, or a CreateAttributeListenerRequestItem. All of them have in common that they define a query property, which contains either an IdentityAttributeQuery or a RelationshipAttributeQuery.  IdentityAttributeQuery  An IdentityAttributeQuery is used to query for IdentityAttributes. For that, it defines the following properties:                 Name       Type       Description                       @type       &quot;IdentityAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 valueType       string       The type of value that should be queried, e.g. &quot;StreetAddress&quot;, &quot;BirthDate&quot; or &quot;Nationality&quot;.                 tags       string[] | undefined       To specify additional information.           You can only query IdentityAttributes owned by the recipient of the query.  RelationshipAttributeQuery  There are cases in which you want to query some data from your peer that is not an IdentityAttribute. An example for this is when an electricity provider asks for the electric meter number of a new customer. Since this information is only relevant in the context of the Relationship, an IdentityAttribute wouldn’t make any sense here. That’s why you would send a RelationshipAttributeQuery. Its properties are:                 Name       Type       Description                       @type       &quot;RelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute.                 attributeCreationHints       RelationshipAttributeCreationHints       Contains information about the value that will be created, like the value type or its confidentiality.           RelationshipAttributeCreationHints                 Name       Type       Description                       title       string       A short text describing the purpose of the Attribute that is about to be created.                 description       string | undefined       A long text describing the purpose of the Attribute that is about to be created.                 valueType       string       The value type of the Attribute to be created (e.g. &quot;ProprietaryInteger&quot;, &quot;ProprietaryString&quot;, …)                 confidentiality       &quot;public&quot; |&quot;protected&quot; |&quot;private&quot;       The confidentiality of the Attribute to be created. See RelationshipAttribute for a more detailed description of confidentialities.                 valueHints       ValueHints | undefined       Hints for validating the value, e.g. a regular expression or a min/max length.           ValueHints                 Name       Type       Description                       @type       &quot;ValueHints&quot;                         editHelp       string | undefined       A help text you can use to describe the purpose of the Attribute.                 min       number | undefined       In case of a string: the minimum length of the string. In case of an integer: the minimum value.                 max       number | undefined       In case of a string: the maximum length of the string. In case of an integer: the maximum value.                 pattern       string | undefined       A regular expression that is used to validate the value. Only applicable if the value is a string.                 values       ValueHintsValue[] | undefined       An array of allowed values.                 defaultValue       string | number | boolean | undefined       The default value that is used if no value is provided.                 propertyHints       Record&lt;string, ValueHints&gt; | undefined       A set of Value Hints of all properties. The key is the name of the property and the value a ValueHints object. Only applicable if the value is complex.           ValueHintsOverride  ValueHintsOverride has the same properties as ValueHints, except that all of them are optional. This type is used for some RelationshipAttribute values  ValueHintsValue                 Name       Type       Description                       key       string | number | boolean       The actual value.                 displayName       string       How the value should be displayed on the UI.           ThirdPartyRelationshipAttributeQuery  If you want to query Attributes the user has in the context of a Relationship with a third party, you can use the ThirdPartyRelationshipAttributeQuery. An example would be the query for the number of a bonus card managed by another company (like Payback). A ThirdPartyRelationshipAttributeQuery has the following properties:                 Name       Type       Description                       @type       &quot;ThirdPartyRelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute. Can be an empty string (&quot;&quot;), if the owner is unknown or you are querying from multiple thirdParties that could own the attribute.                 thirdParty       string[]       The Address of the third parties the RelationshipAttribute should be queried from.           IQLQuery  If you want to query Attributes by their content, you can use the IQLQuery. It allows you to specify conditions the Attribute must match and which may be chained using binary operations. Every property of the Attribute’s content may be queried, independend of whether it is nested or not, by formulating it as a lowercase key. Furthermore, using an uppercase term is a shortcut for comparing the term to the value.@type property and using # refers to the tag property. For example, if you want to query a StreetAddress in Germany which is tagged as [Primary Address] the queryString would be StreetAddress &amp;&amp; value.country.value == Germany &amp;&amp; #&quot;Primary Address&quot;. If no corresponding Attribute exists at the peer’s side, you are given the possibility to add attributeCreationHints, suggesting to create an Attribute which matches a specific valueType and optionally tags.                 Name       Type       Description                       @type       &quot;IQLQuery&quot;                         queryString       string       The condition the attribute must fulfill. It is made up of terms of the form &lt;key&gt; &lt;operator&gt; &lt;value&gt;, which may be chained using binary operations. Uppercase expressions refer to the property value@type and # to tags.                 attributeCreationHints       IQLQueryCreationHints | undefined       Suggestions for creating a new Attribute, if the query returns empty.           IQLQueryCreationHints                 Name       Type       Description                       valueType       AttributeValues.Identity.TypeName       The value.@type of the Attribute, which should be created.                 tags       string[] | undefined       The tags for the Attribute, which should be created.           RelationshipTemplateContent  Theoretically you can send any kind of data in a Relationship Template. However, if your peer uses the enmeshed App, it will only be able to process Relationship Templates that contain a RelationshipTemplateContent, which looks like this:                 Name       Type       Description                       @type       &quot;RelationshipTemplateContent&quot;                         title       string | undefined       An optional, human readable title that should be rendered in the UI.                 metadata       object | undefined       Optional custom metadata that can be sent together with the Relationship Template. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Template.                 onNewRelationship       Request       The Request that should pop up to the user in case there is no Relationship yet. In this Request you can send Attributes of yourself the user needs to in order to know who’s Template it is (e.g. company name, address, …), as ask for Attributes of the user you need to know in the Relationship, or send some information you already know about the user, so it can be saved in its wallet (e.g. the customer id).                 onExistingRelationship       Request | undefined       The Request that should pop up to the user in case a Relationship already exists. An example usage is a Request with an AuthenticationRequestItem for the sake of two-factor authentication.           RelationshipCreationChangeRequestContent  The naming on this one in combination with its response property is a bit confusing. Even though the RelationshipCreationChangeRequestContent contains the word “Request”, it has a response property. This is because in the context of Relationships, there are Relationship Changes, which have a request and a response property. But caution: these have nothing to do with the Content-types Request and Response.                 Name       Type       Description                       @type       &quot;RelationshipCreationChangeRequestContent&quot;                         response       Response       The Response to the Request that was contained in the RelationshipTemplateContent (either in the onExistingRelationship property or in the onNewRelationship property).           Mail  A Mail can be sent as the content of a Message. It is comparable with the classic email, so its properties should not contain any surprise.                 Name       Type       Description                       @type       &quot;Mail&quot;                         to       string[]       The enmeshed Addresses of the main recipients of this Mail.                 cc       string[] | undefined       The enmeshed Addresses that should receive a copy of this Mail, additionally to the ones specified in to.                 subject       string       The subject of the Mail.                 body       string       The body of the Mail.           Consumption  DecideRequestItemParameters  In order to answer a Request, the Response must be formulated appropriately. As an easier interface to do so various DecideRequestItemParameters are provided. If you want to reject any RequestItem, you must use the RejectRequestItemParameters. If you want to accept a RequestItem, however, depending on its kind you might need different parameters. For example, an AuthenticationRequestItem can be accepted using the AcceptRequestItemParameters, but for a FreeTextRequestItem AcceptFreeTextRequestItemParameters are required.  RejectRequestItemParameters                 Name       Type       Description                       accept       &quot;false&quot;       The only possible value here is the string “false”.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           AcceptRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.           AcceptFreeTextRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 freeText       string       The free text that is used to answer the RequestItem.           AcceptProposeAttributeRequestItemParameters  The parameters to accept a ProposeAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ProposeAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.           AcceptReadAttributeRequestItemParameters  The parameters to accept a ReadAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 existingAttributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ReadAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 newAttribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.">
+<meta name="description" content="The enmeshed data model can be divided into three parts:     Transport types   Local types   Content types   The following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.   (note that you can click on each type in order to navigate to the paragraph with the corresponding description)  At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.  Transport Types  Transport types like RelationshipTemplate, Token or File are types that are “exchanged” between Identities via the Backbone. They are created and updated by the Transport Layer. In most cases they have a content property, which contains the actual payload that should be transferred between the Identities. This payload is being encrypted when it is sent to the Backbone, and decrypted by the other Identity when it is received. The following sections describe the different Transport types and their properties.  Note that the properties of the types are the ones that exist locally (aka on the Connector/in the App). The Backbone does not necessarily know about them. The properties that only exist locally are marked accordingly in the tables below. Further there are properties that are confidential and are therefore encrypted before sent to the Backbone, in order to enable end-to-end encryption. Both kinds of these properties are marked accordingly in the “Remarks” column of the property tables below.  Token  Tokens can be used to save arbitrary structured data on the Backbone, which is encrypted with a random symmetric key. You can then pass the ID of the Token, together with the random key, to another Identity, which can then retrieve the token and decrypt it, e.g. inside of a QR Code, which you send to the recipient via letter. Tokens can be handy in a lot of scenarios, for example:     You want to share secret information with someone you don’t have a Relationship with.   The enmeshed App currently uses a Token to save a Backup of the Identity. ID and secret key are then encoded in a QR Code, which the user can print out and scan later in order to restore the Identity on a new device.   A Token has the following properties:                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Token starts with the letters “TOK”. This way you can tell apart a Token ID from any other ID just by looking at the prefix.                         createdBy       string       The Address of the Identity that created the Token.                         createdByDevice       string       The ID of the Device that created the Token. You can use this information to track back who exactly did what.                         content       unknown       The content of the Token. You can add whatever you want here.       will be encrypted before sent to the Backbone                 createdAt       string       A timestamp that describes when the Token was created                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.                         secretKey       string       The key with which the Token was encrypted.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the Token. You can use it to share the Token with someone else.       saved only locally                 isEphemeral       boolean       If set to true the Token will not be cached in the database and only displayed once. You will not be able to fetch this Token unless you remember its id and secretKey.                   RelationshipTemplate  A Relationship Template serves two purposes:     It represents the permission to establish a Relationship. When sending a Relationship request, the sender has to attach the ID of a valid Relationship Template created by the recipient. Otherwise the Backbone blocks the Relationship request. And since the IDs are randomly generated, you can only obtain such an ID from the recipient.   It can contain data which is of interest for the one who uses the Relationship Template. The enmeshed App for example expects a Relationship Template content which contains a Request which contains e.g. Attributes about the creator of the Template as well as queries for Attributes that the Template creator wants to receive together with the Relationship request.                  Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Template starts with the letters “RLT”. This way you can tell apart a Relationship Template ID from any other ID just by looking at the prefix.                         isOwn       boolean       true if the Relationship Template was created by yourself, false if it was created by someone else.       saved only locally                 createdBy       string       The Address of the Identity that created the Relationship Template.                         createdByDevice       string       The ID of the Device that created the Relationship Template. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Token was created                         content       RelationshipTemplateContent | unknown       The content of the Relationship Template. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, RelationshipTemplateContent has to be used. Otherwise feel free to insert whatever you want or need.                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.       will be encrypted before sent to the Backbone                 maxNumberOfAllocations       number | undefined       Can be set to limit the number of allocations of this template. A Relationship Template is allocated by another Identity when it is first retrieved by it from the Backbone. After this value is reached, the Backbone rejects each request of any new Identity that wants to retrieve it. Identities that already allocated it will still be able to retrieve it.                         truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the RelationshipTemplate. You can use it to share the RelationshipTemplate with someone else.                   Relationship  A Relationship between two Identities is the prerequisite for them to exchange Messages. If there is no Relationship, the Backbone blocks all Messages that are tried to be sent. This ensures that you only receive Messages from Identities you know, so you are protected from any harmful Messages like spam or phishing mails.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship starts with the letters “REL”. This way you can tell apart a Relationship ID from any other ID just by looking at the prefix.                         template       RelationshipTemplate       The Relationship Template that was used to establish this Relationship.                         status       &quot;Pending&quot; | &quot;Active&quot; | &quot;Rejected&quot; | &quot;Revoked&quot;       The status of this Relationship. Pending: the Relationship was created, but not yet accepted the recipient. In this state you cannot send Messages yet.Active: this means that the Relationship is active. As long as it is active, both participants can exchange Messages.Rejected: the Relationship was rejected by the recipient.Revoked: the Relationship was revoked by the sender.                         changes       RelationshipChange[]       The history of changes made to this Relationship. You can find the definition of a Relationship Change below.                         peer       string       The Address of the Identity with which you have this Relationship.       saved only locally           RelationshipChange  Since a Relationship “belongs” to two Identities, each change on such a Relationship demands for the agreement of both parties. That’s where Relationship Changes come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a Relationship Change to the other party, which has to accept it in order for the change to take effect. If the other party doesn’t want to accept it, it can also reject it. And if the party that created the Relationship Change changes its mind, it can revoke the Relationship Change. The Backbone makes sure that a Relationship Change can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a Relationship Change that is already revoked, you will receive an error.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Change starts with the letters “RCH”. This way you can tell apart a Relationship Change ID from any other ID just by looking at the prefix.                         status       &quot;Pending&quot; |&quot;Accepted&quot; |&quot;Rejected&quot; |&quot;Revoked&quot;       The current status of the Relationship Change.                         type       &quot;Creation&quot;       The type of the Relationship Change. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second Relationship Change type.                         request       RelationshipChangeRequest       Information about the request of the Relationship Change.                         response       RelationshipChangeResponse | undefined       Information about the response of the Relationship Change.                   Note that RelationshipChangeRequest and RelationshipChangeResponse have nothing to do with Requests and Responses, which we will discuss later.  RelationshipChangeRequest                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Request.                         createdByDevice       string       The ID of the Device that created the Relationship Change Request. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Request was created                         content       RelationshipCreationChangeRequestContent | unknown       The content of the Relationship Change Request. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the Relationship Change is Creation, RelationshipCreationChangeRequestContent has to be used. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone           RelationshipChangeResponse                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Response.                         createdByDevice       string       The ID of the Device that created the Relationship Change Response. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Response was created                         content       unknown       The content of the Relationship Change Response. You can add whatever you want here. Since the enmeshed App doesn’t expect any special content here, there is no need to watch out.       will be encrypted before sent to the Backbone           Message  A Message is a piece of data that can be sent to one or more recipients. The sender is completely free in what the content of the Message looks like. Though in order to enable a normalized communication, enmeshed defines some content structures for Messages, and in the future there will be more of those. Consider that the enmeshed App only supports those normalized Message contents. Currently there are:     Mail   Request   ResponseWrapper   Notification   You can read more details about each of these in the corresponding sections of the “Content Types” chapter.  But if you are communicating with another Connector, feel free to settle on any content structure that fits your needs.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Message starts with the letters “MSG”. This way you can tell apart a Message ID from any other ID just by looking at the prefix.                         content       unknown       The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either Mail, Request, Response or Notification. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone                 createdBy       string       The Address of the Identity that created the Message.                         createdByDevice       string       The ID of the Device that created the Message. You can use this information to track back who exactly did what.                         recipients       Recipient[]       An array of recipients of this Message.                         createdAt       string       A timestamp that describes when the Message was created                         attachments       string[]       An array of File IDs you want to attach to your Message. You receive the File ID after you uploaded a file to the Backbone. By attaching a File to a Message, you share the secret key used to encrypt/decrypt the File, which cannot be undone.                   Recipient                 Name       Type       Description       Remarks                       address       string       The Address of the recipient of the Message.                         relationshipId       string       The ID of the Relationship between the recipient and the sender of the Message.       saved only locally                 receivedAt       string | undefined       A timestamp that describes when the recipient retrieved the Message from the Backbone. undefined when the Message wasn’t received yet. Caution: “received” does not mean that it was read, so don’t mix this up with a read receipt.                         receivedByDevice       string | undefined       The ID of the Device that first retrieved the Message. undefined when the Message wasn’t received yet. This is of no interest for the sender of the Message, but rather for the recipient itself, since they can use it for audit purposes. sender                   File  The Backbone allows you to upload files, which are saved as - you guessed it - Files.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each File starts with the letters “FIL”. This way you can tell apart a File ID from any other ID just by looking at the prefix.                         createdAt       string       A timestamp that describes when the File was created                         createdBy       string       The Address of the Identity that created the File.                         createdByDevice       string       The ID of the Device that created the File. You can use this information to track back who exactly did what.                         expiresAt       string       A timestamp that describes when the File expires on the Backbone. An expired File cannot be fetched from the Backbone anymore. However, the cached version of the File on Connector and App will still be accesible.                         filename       string       The name of the file as it was on the device that uploaded it.       will be encrypted before sent to the Backbone                 filesize       number       The size of the plaintext file in bytes.       will be encrypted before sent to the Backbone                 mimetype       string       The mimetype of the file.       will be encrypted before sent to the Backbone                 title       string       A human readable title of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 description       string | undefined       A human readable description of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 secretKey       string       The key that was used to encrypt the File.       saved only locally                 isOwn       boolean       true if the File was created by yourself, false if it was created by someone else.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the File. You can use it to share the File with someone else.       saved only locally           A File further has its content, of course. But since this is not a JSON property, it is not included in this table. You can download the content of the File separately.  Local Types  In addition to the types that are shared between Identities via the Backbone, there are certain types that only exist within one Identity. These types usually contain metadata about Content types that should not be transferred to other Identities. They are created and updated by the Consumption Layer.  Currently there are three main Local types:     LocalRequest   LocalNotification   LocalAttribute   Each of them further describes some sub types.  This chapter explains all of those types, together with their properties.  LocalRequest  A LocalRequest contains the local metadata for a Request.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalRequest starts with the letters “REQ”. This way you can tell apart a LocalRequest ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Request, false if you received it.                 peer       string       The Identity that sent you the corresponding Request/that you sent the Request to.                 createdAt       string       A timestamp that describes when the LocalRequest was created                 status       LocalRequestStatus       The current status of the Request. See below for a list of all possible values.                 content       Request       The actual Content object this LocalRequest defines the metadata for.                 source       LocalRequestSource | undefined       Information about the Transport object with which the Request came in/was sent. This property is undefined if the Request is not sent yet.                 response       LocalResponse | undefined       Metadata + Content object of the response. If there is no response yet, this property is undefined.           LocalRequestStatus  Depending on whether it is an incoming or an outgoing Request, there can be different statuses. The following state diagram shows which status exists in both cases and when there are transitions from one state to another:       Draft   This status only exists for outgoing Requests. It means that the LocalRequest was created, but not yet sent.   Open   In case of an outgoing Request, Open means that the Request was sent. The transition to Open happens automatically when you send the Request with a Message.   In case of an incoming Request, Open means that the LocalRequest was received.   DecisionRequired   After the prerequisites of the Request and all of its RequestItems were checked, a decision can be made. At first, the Decider Module tries to make an automatic decision. It therefore checks all LocalRequests in status DecisionRequired.   ManualDecisionRequired   If the Decider Module cannot make a decision, it moves the LocalRequest to ManualDecisionRequired. When the LocalRequest is in this status, it’s the User’s turn to decide whether they want to accept or reject the Request.   Decided   When the User or the Decider Module accepts or rejects the Request, the Response and ResponseItems are generated based on the passed parameters. This Response is saved in the response property of the LocalRequest, but not yet sent.   Completed   In case of an incoming Request, the Runtime Module listens to an Event saying that a Request moved to status Decided. It then checks on which way the Request was received (Message/RelationshipTemplate) and sends the Response on the corresponding way (by sending a message or creating a Relationship). After the Response was successfully sent, it moves the LocalRequest to Completed.   In case of an outgoing Request, the Runtime Module listens to the MessageReceivedEvent and checks the content of the sent Message for a Response. If there is one, it moves the corresponding LocalRequest to Completed.   Expired   When the timestamp in expiresAt of a Request is reached, the Request automatically moves to the status Expired.   LocalRequestSource  With the information in this type you can clearly identify the Transport object the Request was sent/received in. Currently there are only two possibilities: Message and Relationship Template.                 Name       Type       Description                       type       “Message” | “RelationshipTemplate”       The type of Transport object the Request was sent/received in.                 reference       string       The ID of the Transport object the Request was sent/received in.           LocalResponse  When a LocalRequest is decided/received, a Local Response is generated, which contains the Response, together with some metadata.                 Name       Type       Description                       createdAt       string       A timestamp that describes when the LocalResponse was created                 content       Response       The actual Content object this Local Response defines the metadata for.                 source       LocalResponseSource | undefined       Information about the Transport object with which the Response came in/was sent. This property is undefined if the Response is not sent/received yet.           LocalResponseSource  With the information in this type you can clearly identify the Transport object the Response was sent/received in. Currently there are only two possibilities: Message and Relationship Change.                 Name       Type       Description                       type       “Message” | “RelationshipChange”       The type of Transport object the Response was sent/received in.                 reference       string       The ID of the Transport object the Response was sent/received in.           LocalNotification  A LocalNotification contains the local metadata for a Notification.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalNotification starts with the letters “NOT”. This way you can tell apart a LocalNotification ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Notification, false if you received it.                 peer       string       The Identity that sent you the corresponding Notification/that you sent the Notification to.                 createdAt       string       A timestamp that describes when the LocalNotification was created                 status       LocalNotificationStatus       The current status of the Notification. See below for a list of all possible values.                 content       Notification       The actual Content object this LocalNotification defines the metadata for.                 source       LocalNotificationSource       Information about the Transport object with which the Notification came in/was sent.                 receivedByDevice       string | undefined       The ID of the device that received the Notification. For reasons of consistence, the Notification can only be processed by this device.           LocalNotificationStatus  Depending on whether it is an incoming or an outgoing Notification, there can be different statuses.     Sent   This is the only valid status on sender side. If a Notification is sent and, therefore, a LocalNotification is created, its status will be set to Sent.   Open   Receiving a Notification, a LocalNotification is created with status Open.   Completed   After receiving a Notification, its items will be processed internally. If all processes finish successfully, the status of the LocalNotification will be set to Completed.   Error   If an error occurs while processing the items of a received Notification, the status of the LocalNotification will be set to Error.   LocalNotificationSource  With the information in this type you can clearly identify the Transport object the Notification was sent/received in. Currently, the only possibility for transmitting Notifications are Messages.                 Name       Type       Description                       type       “Message”       The type of Transport object the Notification was sent/received in. So far, Notifications can only be transmitted via Messages.                 reference       string       The id of the Transport object the Notification was sent/received in.           LocalAttribute  A LocalAttribute contains the local metadata for an Attribute. There are three situations a LocalAttribute is created in the database:     The Identity maintains an Attribute about itself (e.g. sets its first name). We call such a LocalAttribute “RepositoryAttribute”.   The Identity shares an Attribute of itself with another Identity (e.g. sends it in a Request). In that case, a copy of the original LocalAttribute is created, where the shareInfo property is set.   The Identity receives an Attribute from another Identity (e.g. receives it in a Request). In that case a new LocalAttribute is created, where the shareInfo is set.                  Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttribute starts with the letters “ATT”. This way you can tell apart a LocalAttribute ID from any other ID just by looking at the prefix.                 parentId       string | undefined       If the Attribute referenced by this LocalAttribute is a component of a composite Attribute, the parentId property is set to the id of the composite Attribute. Example: if a LocalAttribute is created with the content StreetAddress, for each property of the StreetAddress an additional LocalAttribute is created. And each of these will have parentId set to the id of the LocalAttribute for the StreetAddress.                 createdAt       string       A timestamp that describes when the LocalAttribute was created                 content       IdentityAttribute | RelationshipAttribute       The actual Content object this LocalAttribute defines the metadata for.                 succeeds       string | undefined       The ID of the LocalAttribute that succeeds the current one.                 succeededBy       string | undefined       The ID of the LocalAttribute that is succeeded by the current one.                 shareInfo       LocalAttributeShareInfo | undefined       Information about the peer this LocalAttribute was received from/shared with, as well as via which LocalRequest it was received/sent. If the LocalAttribute refers to a RepositoryAttribute, this property is undefined.           LocalAttributeShareInfo  The LocalAttributeShareInfo helps to keep track of how the LocalAttribute was received/sent, from whom it was received/who sent it, as well as which LocalAttribute it was copied from (in case of a shared IdentityAttribute). For example, this enables us to track back who we shared a certain IdentityAttribute with, so we are able to notify each of them when changing it. The Attribute can be either transmitted via Request or Notification. Hence, only one of requestReference and notificationReference can be set.                 Name       Type       Description                       peer       string       The Address of the Identity the LocalAttribute was received from/shared with.                 requestReference       string | undefined       The id of the LocalRequest the LocalAttribute was received in/sent with. If this is set, notificationReference must be undefined.                 notificationReference       string | undefined       The id of the LocalNotification the LocalAttribute was received in/sent with. If this is set, requestReference must be undefined.                 sourceAttribute       string | undefined       If the LocalAttribute is a copy of a RepositoryAttribute, then this property contains the id of the RepositoryAttribute.           LocalAttributeListener  A LocalAttributeListener is created when you accept an incoming Request with a RegisterAttributeListenerRequestItem. It is used to keep track of which Attribute Listeners currently exist and what they are listening for.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttributeListener starts with the letters “ATL”. This way you can tell apart a LocalAttributeListener ID from any other ID just by looking at the prefix.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The query the Attribute that is listened to must match. Note that you cannot send a RelationshipAttributeQuery here, because it doesn’t make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it.                 peer       string       The Address of the peer that requested the Attribute Listener.           Content Types  Content Types can be seen as a data contract between Identities. The medium through which this data is exchanged are the Transport types (e.g. Messages, Tokens, …). This chapter shows all the Content types and describes their intended usage.  Request  A Request allows you to ask another Identity to do something. What this “something” is depends on which of the so called RequestItems were added to the Request (e.g. CreateAttributeRequestItem, ReadAttributeRequestItem, …). The Request is then sent to the peer via Message or Relationship Template. The peer can then review the Request and decide whether they want to accept or reject it. And if they accept it, they can even choose which of the Items they want to accept. You can also put multiple Items into a group in order to ensure that they can only be accepted/rejected as a unit.                 Name       Type       Description                       @type       “Request”                         id       string | undefined       Unique identifier of this object. This property is undefined if the Request is inside of a Relationship Template. Remark: the ID of each Request starts with the letters “REQ”. This way you can tell apart a Request ID from any other ID just by looking at the prefix.                 title       string | undefined       An optional, human readable title for the Request.                 description       string | undefined       An optional, human readable description for the Request.                 expiresAt       string | undefined       A timestamp that describes when the Request expires on the Backbone. An expired Request cannot be fetched from the Backbone anymore. However, the cached version of the Request on Connector and App will still be accesible.                 items       (RequestItemGroup | \*RequestItem)[]       An array of RequestItems and Groups that are part of the Request. There must be at least one Item or Group per Request.                 metadata       string | undefined       Optional custom metadata that can be sent together with the Request. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Request.           RequestItems  RequestItems can be sent inside of a Request and specify what should be done when the Request is accepted.  AuthenticationRequestItem                 Name       Type       Description                       @type       &quot;AuthenticationRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ConsentRequestItem                 Name       Type       Description                       @type       &quot;ConsentRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 consent       string       The textual consent the user needs to give. This is different to the title and description of the RequestItem, as the consent would be the actual statement the user agrees to.                 link       string | undefined       A valid URL linking to a website which contains more information, like the EULA or privacy terms.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           CreateAttributeRequestItem                 Name       Type       Description                       @type       &quot;CreateAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to create for the peer within the Identity of the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           FreeTextRequestItem                 Name       Type       Description                       @type       &quot;FreeTextRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 freeText       string       The free text you want to send to the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ProposeAttributeRequestItem                 Name       Type       Description                       @type       &quot;ProposeAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ReadAttributeRequestItem                 Name       Type       Description                       @type       &quot;ReadAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | ThirdPartyRelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RegisterAttributeListenerRequestItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The structured query of the Attribute the sender would like to query.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ShareAttributeRequestItem                 Name       Type       Description                       @type       &quot;ShareAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to share. This is not the LocalAttribute but the content data structure of the Attribute. The owner of the Attribute which should be shared can only be the sender Identity.                 sourceAttributeId       string       The id of the LocalAttribute which is the source of the shared Attribute. This will be used later to reference the sourceAttribute from its shared copy.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RequestItemGroup                 Name       Type       Description                       @type       &quot;RequestItemGroup&quot;                         title       string | undefined       An optional, human readable title for the RequestItem Group.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       Optional metadata that can be sent together with this RequestItem. The intended usage is the same as of the metadata property of the Request.                 mustBeAccepted       boolean       If set to true, then this RequestItem Group has to be accepted when the Request is accepted.                 items       *RequestItem[]       The items inside of this Group. There has to be at least one RequestItem per Group. Note that we do not support nested Groups at the moment. If you need this feature, you can raise a feature request.           Response                 Name       Type       Description                       @type       &quot;Response&quot;                         result       &quot;Accepted&quot; | &quot;Rejected&quot;       Whether the Response was accepted or rejected by the recipient of the Request.                 requestId       string       The id of the Request this Response belongs to. The Sender of the Request needs this information to map the Response to the corresponding Request.                 items       (ResponseItemGroup\|ResponseItem)[]       An array of Response Items and Groups that are part of the Response. For each RequestItem (Group) of the Request, there must be one Response Item (Group) in the Response. Note that the indices have to be the same for matching Request and Response Items.           ResponseItems  Response Items are sent inside of a Response. They contain the response data that is sent by the recipient of the Request. There are three different kinds of Response Items: AcceptResponseItem, RejectResponseItem and ErrorResponseItem. Depending on the actual RequestItem, there can be different derivations of these three items. For example, in case of a CreateAttributeRequestItem, there is a special CreateAttributeAcceptResponseItem, while for an AuthenticationRequestItem, the AcceptResponseItem can be used, because there is no additional information necessary next to whether it was accepted or rejected.  AcceptResponseItem                 Name       Type       Description                       @type       &quot;AcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.           CreateAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;CreateAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.           FreeTextAcceptResponseItem                 Name       Type       Description                       @type       &quot;FreeTextAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 freeText       string       The free text that is used to answer the RequestItem.           ProposeAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ProposeAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.The owner of the Attribute which is proposed can only be the recipient Identity.           ReadAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ReadAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the returned LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute that will be shared to the peer.           RegisterAttributeListenerAcceptResponseItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 listenerId       string       The id of the created AttributeListener.           ShareAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ShareAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the shared LocalAttribute.           RejectResponseItem                 Name       Type       Description                       @type       &quot;RejectResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Rejected&quot;       The only possible value here is the string &quot;Rejected&quot;.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           ErrorResponseItem  The ErrorResponseItem is only created by the enmeshed Runtime, in case something happens which hinders you from further processing of the RequestItem. It will never be created manually. The properties are:                 Name       Type       Description                       @type       &quot;ErrorResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Error&quot;       The only possible value here is the string &quot;Error&quot;.                 code       string       An error code telling the sender about the kind of error that occurred.                 message       string       A human readable error message with details about the error.           ResponseItemGroup                 Name       Type       Description                       @type       &quot;ResponseItemGroup&quot;                         items       ResponseItem[]       The items inside of this Group. For each RequestItem of the RequestItem Group, there must be one Response Item in the Response Item Group. Note that the indices have to be the same for matching Request and Response Items.           ResponseWrapper  The ResponseWrapper is a wrapper around the Response that is sent by the recipient of the Request. It contains the Response itself, but also some additional information that is required for the Request to be processed correctly.                 Name       Type       Description                       @type       &quot;ResponseWrapper&quot;                         requestId       string       The id of the Request this Response belongs to.                 requestSourceReference       string       The reference to the Message or RelationshipTemplate the Request was received with.                 requestSourceType       &quot;Message&quot; | &quot;RelationshipTemplate&quot;       Specifies if the Request was transferred via Message or RelationshipTemplate.                 response       Response       The Response that is sent by the recipient of the Request.           Notification  Notifications provide you with the possibility to notify a peer about something, e.g. the succession of one of your Attributes. However, unlike Requests they don’t offer the option to make a decision whether or not they want to accept this change. In the example of Attribute succession, the peer can not decide to accept or reject the updated value, but is simply informed about it.                 Name       Type       Description                       @type       &quot;Notification&quot;                         id       string       Unique identifier of this object. Remark: the ID of each Notification starts with the letters “NOT”. This way you can tell apart a Notification ID from any other ID just by looking at the prefix.                 items       NotificationItem[]       An array of NotificationItems that are part of the Notification. There must be at least one Item per Notification.           NotificationItems  NotificationItems are sent inside a Notification and specify which processes should be triggered when receiving the Notification.  PeerSharedAttributeSucceededNotificationItem  A PeerSharedAttributeSucceededNotificationItem will be sent, if an Attribute, a peer shared with you, was succeeded by them and they choose to notify you about it. Internally, the succeeded version will then be created at your side as successor for your previously received Attribute.                 Name       Type       Description                       @type       &quot;PeerSharedAttributeSucceededNotificationItem&quot;                         predecessorId       string       The id of the LocalAttribute that was succeeded                 successorId       string       The id of the LocalAttribute it was succeeded by                 successorContent       IdentityAttribute | RelationshipAttribute       The updated content of the LocalAttribute           Attributes  An Attribute is some piece of information about an Identity itself (e.g. its name, address, birth date, etc.) or about an Identity in the context of a Relationship (e.g. the customer id the of the user the Relationship). Since the two scenarios differ quite a lot, there are two different types for them: IdentityAttribute and RelationshipAttribute.  IdentityAttribute  IdentityAttributes describe an Identity itself. Their values are strongly normalized. There is a list of available values here.                 Name       Type       Description                       @type       &quot;IdentityAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 value       IdentityAttributeValue       The Attribute’s value.                 tags       string[] | undefined       To specify additional information.           RelationshipAttribute  RelationshipAttributes describe an Identity in the context of a Relationship. While there are some types that can be used as a value for a RelationshipAttribute, these types are rather generic (e.g. ProprietaryString, ProprietaryInteger, …).                 Name       Type       Description                       @type       &quot;RelationshipAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 key       string       An arbitrary key that is set by the creator of this Attribute. It is used to identify the Attribute in a query, especially by a third party. Example: you could set something like customerId in case of a customer id.                 isTechnical       boolean | undefined       Defines whether the RelationshipAttribute contains data that is actually relevant for the user (isTechnical=false) or whether it should be hidden in the UI (isTechnical=true).                 value       RelationshipAttributeValue       The Attribute’s value.                 confidentiality       &quot;public&quot; | &quot;protected&quot; | &quot;private&quot; | When this property is set to &quot;private&quot;, it means that third parties are not able to query this RelationshipAttribute. It therefore only exists in the Relationship it was created in. If the confidentiality is &quot;protected&quot;, third parties can query the RelationshipAttribute, but the App shows a warning saying that you should only share it with someone you trust. If the confidentiality is &quot;public&quot;, everybody can query the Attribute, without anything special to happen.                   AttributeQueries  One of the main features of enmeshed is sharing Attributes. For this, an Identity either proactively sends its Attributes to a peer. Or, if let’s say a company wants to know the birth date of its customer, it can ask for it. Depending on the exact use case, the latter can be achieved with one of a bunch of RequestItems, like for example a ReadAttributeRequestItem, or a CreateAttributeListenerRequestItem. All of them have in common that they define a query property, which contains either an IdentityAttributeQuery or a RelationshipAttributeQuery.  IdentityAttributeQuery  An IdentityAttributeQuery is used to query for IdentityAttributes. For that, it defines the following properties:                 Name       Type       Description                       @type       &quot;IdentityAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 valueType       string       The type of value that should be queried, e.g. &quot;StreetAddress&quot;, &quot;BirthDate&quot; or &quot;Nationality&quot;.                 tags       string[] | undefined       To specify additional information.           You can only query IdentityAttributes owned by the recipient of the query.  RelationshipAttributeQuery  There are cases in which you want to query some data from your peer that is not an IdentityAttribute. An example for this is when an electricity provider asks for the electric meter number of a new customer. Since this information is only relevant in the context of the Relationship, an IdentityAttribute wouldn’t make any sense here. That’s why you would send a RelationshipAttributeQuery. Its properties are:                 Name       Type       Description                       @type       &quot;RelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute.                 attributeCreationHints       RelationshipAttributeCreationHints       Contains information about the value that will be created, like the value type or its confidentiality.           RelationshipAttributeCreationHints                 Name       Type       Description                       title       string       A short text describing the purpose of the Attribute that is about to be created.                 description       string | undefined       A long text describing the purpose of the Attribute that is about to be created.                 valueType       string       The value type of the Attribute to be created (e.g. &quot;ProprietaryInteger&quot;, &quot;ProprietaryString&quot;, …)                 confidentiality       &quot;public&quot; |&quot;protected&quot; |&quot;private&quot;       The confidentiality of the Attribute to be created. See RelationshipAttribute for a more detailed description of confidentialities.                 valueHints       ValueHints | undefined       Hints for validating the value, e.g. a regular expression or a min/max length.           ValueHints                 Name       Type       Description                       @type       &quot;ValueHints&quot;                         editHelp       string | undefined       A help text you can use to describe the purpose of the Attribute.                 min       number | undefined       In case of a string: the minimum length of the string. In case of an integer: the minimum value.                 max       number | undefined       In case of a string: the maximum length of the string. In case of an integer: the maximum value.                 pattern       string | undefined       A regular expression that is used to validate the value. Only applicable if the value is a string.                 values       ValueHintsValue[] | undefined       An array of allowed values.                 defaultValue       string | number | boolean | undefined       The default value that is used if no value is provided.                 propertyHints       Record&lt;string, ValueHints&gt; | undefined       A set of Value Hints of all properties. The key is the name of the property and the value a ValueHints object. Only applicable if the value is complex.           ValueHintsOverride  ValueHintsOverride has the same properties as ValueHints, except that all of them are optional. This type is used for some RelationshipAttribute values  ValueHintsValue                 Name       Type       Description                       key       string | number | boolean       The actual value.                 displayName       string       How the value should be displayed on the UI.           ThirdPartyRelationshipAttributeQuery  If you want to query Attributes the user has in the context of a Relationship with a third party, you can use the ThirdPartyRelationshipAttributeQuery. An example would be the query for the number of a bonus card managed by another company (like Payback). A ThirdPartyRelationshipAttributeQuery has the following properties:                 Name       Type       Description                       @type       &quot;ThirdPartyRelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute. Can be an empty string (&quot;&quot;), if the owner is unknown or you are querying from multiple thirdParties that could own the attribute.                 thirdParty       string[]       The Address of the third parties the RelationshipAttribute should be queried from.           IQLQuery  If you want to query Attributes by their content, you can use the IQLQuery. It allows you to specify conditions the Attribute must match and which may be chained using binary operations. Every property of the Attribute’s content may be queried, independend of whether it is nested or not, by formulating it as a lowercase key. Furthermore, using an uppercase term is a shortcut for comparing the term to the value.@type property and using # refers to the tag property. For example, if you want to query a StreetAddress in Germany which is tagged as [Primary Address] the queryString would be StreetAddress &amp;&amp; value.country.value == Germany &amp;&amp; #&quot;Primary Address&quot;. If no corresponding Attribute exists at the peer’s side, you are given the possibility to add attributeCreationHints, suggesting to create an Attribute which matches a specific valueType and optionally tags.                 Name       Type       Description                       @type       &quot;IQLQuery&quot;                         queryString       string       The condition the attribute must fulfill. It is made up of terms of the form &lt;key&gt; &lt;operator&gt; &lt;value&gt;, which may be chained using binary operations. Uppercase expressions refer to the property value@type and # to tags.                 attributeCreationHints       IQLQueryCreationHints | undefined       Suggestions for creating a new Attribute, if the query returns empty.           IQLQueryCreationHints                 Name       Type       Description                       valueType       AttributeValues.Identity.TypeName       The value.@type of the Attribute, which should be created.                 tags       string[] | undefined       The tags for the Attribute, which should be created.           RelationshipTemplateContent  Theoretically you can send any kind of data in a Relationship Template. However, if your peer uses the enmeshed App, it will only be able to process Relationship Templates that contain a RelationshipTemplateContent, which looks like this:                 Name       Type       Description                       @type       &quot;RelationshipTemplateContent&quot;                         title       string | undefined       An optional, human readable title that should be rendered in the UI.                 metadata       object | undefined       Optional custom metadata that can be sent together with the Relationship Template. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Template.                 onNewRelationship       Request       The Request that should pop up to the user in case there is no Relationship yet. In this Request you can send Attributes of yourself the user needs to in order to know who’s Template it is (e.g. company name, address, …), as ask for Attributes of the user you need to know in the Relationship, or send some information you already know about the user, so it can be saved in its wallet (e.g. the customer id).                 onExistingRelationship       Request | undefined       The Request that should pop up to the user in case a Relationship already exists. An example usage is a Request with an AuthenticationRequestItem for the sake of two-factor authentication.           RelationshipCreationChangeRequestContent  The naming on this one in combination with its response property is a bit confusing. Even though the RelationshipCreationChangeRequestContent contains the word “Request”, it has a response property. This is because in the context of Relationships, there are Relationship Changes, which have a request and a response property. But caution: these have nothing to do with the Content-types Request and Response.                 Name       Type       Description                       @type       &quot;RelationshipCreationChangeRequestContent&quot;                         response       Response       The Response to the Request that was contained in the RelationshipTemplateContent (either in the onExistingRelationship property or in the onNewRelationship property).           Mail  A Mail can be sent as the content of a Message. It is comparable with the classic email, so its properties should not contain any surprise.                 Name       Type       Description                       @type       &quot;Mail&quot;                         to       string[]       The enmeshed Addresses of the main recipients of this Mail.                 cc       string[] | undefined       The enmeshed Addresses that should receive a copy of this Mail, additionally to the ones specified in to.                 subject       string       The subject of the Mail.                 body       string       The body of the Mail.           Consumption  DecideRequestItemParameters  In order to answer a Request, the Response must be formulated appropriately. As an easier interface to do so various DecideRequestItemParameters are provided. If you want to reject any RequestItem, you must use the RejectRequestItemParameters. If you want to accept a RequestItem, however, depending on its kind you might need different parameters. For example, an AuthenticationRequestItem can be accepted using the AcceptRequestItemParameters, but for a FreeTextRequestItem AcceptFreeTextRequestItemParameters are required.  RejectRequestItemParameters                 Name       Type       Description                       accept       &quot;false&quot;       The only possible value here is the string “false”.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           AcceptRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.           AcceptFreeTextRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 freeText       string       The free text that is used to answer the RequestItem.           AcceptProposeAttributeRequestItemParameters  The parameters to accept a ProposeAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ProposeAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.           AcceptReadAttributeRequestItemParameters  The parameters to accept a ReadAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 existingAttributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ReadAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 newAttribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.">
 
 
   <meta name="author" content="Enmeshed Team">
@@ -26,7 +26,7 @@
 <meta property="og:url" content="/integrate/data-model-overview">
 
 
-  <meta property="og:description" content="The enmeshed data model can be divided into three parts:     Transport types   Local types   Content types   The following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.   (note that you can click on each type in order to navigate to the paragraph with the corresponding description)  At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.  Transport Types  Transport types like RelationshipTemplate, Token or File are types that are “exchanged” between Identities via the Backbone. They are created and updated by the Transport Layer. In most cases they have a content property, which contains the actual payload that should be transferred between the Identities. This payload is being encrypted when it is sent to the Backbone, and decrypted by the other Identity when it is received. The following sections describe the different Transport types and their properties.  Note that the properties of the types are the ones that exist locally (aka on the Connector/in the App). The Backbone does not necessarily know about them. The properties that only exist locally are marked accordingly in the tables below. Further there are properties that are confidential and are therefore encrypted before sent to the Backbone, in order to enable end-to-end encryption. Both kinds of these properties are marked accordingly in the “Remarks” column of the property tables below.  Token  Tokens can be used to save arbitrary structured data on the Backbone, which is encrypted with a random symmetric key. You can then pass the ID of the Token, together with the random key, to another Identity, which can then retrieve the token and decrypt it, e.g. inside of a QR Code, which you send to the recipient via letter. Tokens can be handy in a lot of scenarios, for example:     You want to share secret information with someone you don’t have a Relationship with.   The enmeshed App currently uses a Token to save a Backup of the Identity. ID and secret key are then encoded in a QR Code, which the user can print out and scan later in order to restore the Identity on a new device.   A Token has the following properties:                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Token starts with the letters “TOK”. This way you can tell apart a Token ID from any other ID just by looking at the prefix.                         createdBy       string       The Address of the Identity that created the Token.                         createdByDevice       string       The ID of the Device that created the Token. You can use this information to track back who exactly did what.                         content       unknown       The content of the Token. You can add whatever you want here.       will be encrypted before sent to the Backbone                 createdAt       string       A timestamp that describes when the Token was created                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.                         secretKey       string       The key with which the Token was encrypted.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the Token. You can use it to share the Token with someone else.       saved only locally                 isEphemeral       boolean       If set to true the Token will not be cached in the database and only displayed once. You will not be able to fetch this Token unless you remember its id and secretKey.                   RelationshipTemplate  A Relationship Template serves two purposes:     It represents the permission to establish a Relationship. When sending a Relationship request, the sender has to attach the ID of a valid Relationship Template created by the recipient. Otherwise the Backbone blocks the Relationship request. And since the IDs are randomly generated, you can only obtain such an ID from the recipient.   It can contain data which is of interest for the one who uses the Relationship Template. The enmeshed App for example expects a Relationship Template content which contains a Request which contains e.g. Attributes about the creator of the Template as well as queries for Attributes that the Template creator wants to receive together with the Relationship request.                  Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Template starts with the letters “RLT”. This way you can tell apart a Relationship Template ID from any other ID just by looking at the prefix.                         isOwn       boolean       true if the Relationship Template was created by yourself, false if it was created by someone else.       saved only locally                 createdBy       string       The Address of the Identity that created the Relationship Template.                         createdByDevice       string       The ID of the Device that created the Relationship Template. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Token was created                         content       RelationshipTemplateContent | unknown       The content of the Relationship Template. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, RelationshipTemplateContent has to be used. Otherwise feel free to insert whatever you want or need.                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.       will be encrypted before sent to the Backbone                 maxNumberOfAllocations       number | undefined       Can be set to limit the number of allocations of this template. A Relationship Template is allocated by another Identity when it is first retrieved by it from the Backbone. After this value is reached, the Backbone rejects each request of any new Identity that wants to retrieve it. Identities that already allocated it will still be able to retrieve it.                         truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the RelationshipTemplate. You can use it to share the RelationshipTemplate with someone else.                   Relationship  A Relationship between two Identities is the prerequisite for them to exchange Messages. If there is no Relationship, the Backbone blocks all Messages that are tried to be sent. This ensures that you only receive Messages from Identities you know, so you are protected from any harmful Messages like spam or phishing mails.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship starts with the letters “REL”. This way you can tell apart a Relationship ID from any other ID just by looking at the prefix.                         template       RelationshipTemplate       The Relationship Template that was used to establish this Relationship.                         status       &quot;Pending&quot; | &quot;Active&quot; | &quot;Rejected&quot; | &quot;Revoked&quot;       The status of this Relationship. Pending: the Relationship was created, but not yet accepted the recipient. In this state you cannot send Messages yet.Active: this means that the Relationship is active. As long as it is active, both participants can exchange Messages.Rejected: the Relationship was rejected by the recipient.Revoked: the Relationship was revoked by the sender.                         changes       RelationshipChange[]       The history of changes made to this Relationship. You can find the definition of a Relationship Change below.                         peer       string       The Address of the Identity with which you have this Relationship.       saved only locally           RelationshipChange  Since a Relationship “belongs” to two Identities, each change on such a Relationship demands for the agreement of both parties. That’s where Relationship Changes come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a Relationship Change to the other party, which has to accept it in order for the change to take effect. If the other party doesn’t want to accept it, it can also reject it. And if the party that created the Relationship Change changes its mind, it can revoke the Relationship Change. The Backbone makes sure that a Relationship Change can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a Relationship Change that is already revoked, you will receive an error.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Change starts with the letters “RCH”. This way you can tell apart a Relationship Change ID from any other ID just by looking at the prefix.                         status       &quot;Pending&quot; |&quot;Accepted&quot; |&quot;Rejected&quot; |&quot;Revoked&quot;       The current status of the Relationship Change.                         type       &quot;Creation&quot;       The type of the Relationship Change. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second Relationship Change type.                         request       RelationshipChangeRequest       Information about the request of the Relationship Change.                         response       RelationshipChangeResponse | undefined       Information about the response of the Relationship Change.                   Note that RelationshipChangeRequest and RelationshipChangeResponse have nothing to do with Requests and Responses, which we will discuss later.  RelationshipChangeRequest                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Request.                         createdByDevice       string       The ID of the Device that created the Relationship Change Request. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Request was created                         content       RelationshipCreationChangeRequestContent | unknown       The content of the Relationship Change Request. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the Relationship Change is Creation, RelationshipCreationChangeRequestContent has to be used. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone           RelationshipChangeResponse                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Response.                         createdByDevice       string       The ID of the Device that created the Relationship Change Response. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Response was created                         content       unknown       The content of the Relationship Change Response. You can add whatever you want here. Since the enmeshed App doesn’t expect any special content here, there is no need to watch out.       will be encrypted before sent to the Backbone           Message  A Message is a piece of data that can be sent to one or more recipients. The sender is completely free in what the content of the Message looks like. Though in order to enable a normalized communication, enmeshed defines some content structures for Messages, and in the future there will be more of those. Consider that the enmeshed App only supports those normalized Message contents. Currently there are:     Mail   Request   ResponseWrapper   You can read more details about each of these in the corresponding sections of the “Content Types” chapter.  But if you are communicating with another Connector, feel free to settle on any content structure that fits your needs.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Message starts with the letters “MSG”. This way you can tell apart a Message ID from any other ID just by looking at the prefix.                         content       unknown       The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either Mail, Request or Response. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone                 createdBy       string       The Address of the Identity that created the Message.                         createdByDevice       string       The ID of the Device that created the Message. You can use this information to track back who exactly did what.                         recipients       Recipient[]       An array of recipients of this Message.                         createdAt       string       A timestamp that describes when the Message was created                         attachments       string[]       An array of File IDs you want to attach to your Message. You receive the File ID after you uploaded a file to the Backbone. By attaching a File to a Message, you share the secret key used to encrypt/decrypt the File, which cannot be undone.                   Recipient                 Name       Type       Description       Remarks                       address       string       The Address of the recipient of the Message.                         relationshipId       string       The ID of the Relationship between the recipient and the sender of the Message.       saved only locally                 receivedAt       string | undefined       A timestamp that describes when the recipient retrieved the Message from the Backbone. undefined when the Message wasn’t received yet. Caution: “received” does not mean that it was read, so don’t mix this up with a read receipt.                         receivedByDevice       string | undefined       The ID of the Device that first retrieved the Message. undefined when the Message wasn’t received yet. This is of no interest for the sender of the Message, but rather for the recipient itself, since they can use it for audit purposes. sender                   File  The Backbone allows you to upload files, which are saved as - you guessed it - Files.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each File starts with the letters “FIL”. This way you can tell apart a File ID from any other ID just by looking at the prefix.                         createdAt       string       A timestamp that describes when the File was created                         createdBy       string       The Address of the Identity that created the File.                         createdByDevice       string       The ID of the Device that created the File. You can use this information to track back who exactly did what.                         expiresAt       string       A timestamp that describes when the File expires on the Backbone. An expired File cannot be fetched from the Backbone anymore. However, the cached version of the File on Connector and App will still be accesible.                         filename       string       The name of the file as it was on the device that uploaded it.       will be encrypted before sent to the Backbone                 filesize       number       The size of the plaintext file in bytes.       will be encrypted before sent to the Backbone                 mimetype       string       The mimetype of the file.       will be encrypted before sent to the Backbone                 title       string       A human readable title of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 description       string | undefined       A human readable description of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 secretKey       string       The key that was used to encrypt the File.       saved only locally                 isOwn       boolean       true if the File was created by yourself, false if it was created by someone else.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the File. You can use it to share the File with someone else.       saved only locally           A File further has its content, of course. But since this is not a JSON property, it is not included in this table. You can download the content of the File separately.  Local Types  In addition to the types that are shared between Identities via the Backbone, there are certain types that only exist within one Identity. These types usually contain metadata about Content types that should not be transferred to other Identities. They are created and updated by the Consumption Layer.  Currently there are three main Local types:     LocalRequest   LocalNotification   LocalAttribute   Each of them further describes some sub types.  This chapter explains all of those types, together with their properties.  LocalRequest  A LocalRequest contains the local metadata for a Request.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalRequest starts with the letters “REQ”. This way you can tell apart a LocalRequest ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Request, false if you received it.                 peer       string       The Identity that sent you the corresponding Request/that you sent the Request to.                 createdAt       string       A timestamp that describes when the LocalRequest was created                 status       LocalRequestStatus       The current status of the Request. See below for a list of all possible values.                 content       Request       The actual Content object this LocalRequest defines the metadata for.                 source       LocalRequestSource | undefined       Information about the Transport object with which the Request came in/was sent. This property is undefined if the Request is not sent yet.                 response       LocalResponse | undefined       Metadata + Content object of the response. If there is no response yet, this property is undefined.           LocalRequestStatus  Depending on whether it is an incoming or an outgoing Request, there can be different statuses. The following state diagram shows which status exists in both cases and when there are transitions from one state to another:       Draft   This status only exists for outgoing Requests. It means that the LocalRequest was created, but not yet sent.   Open   In case of an outgoing Request, Open means that the Request was sent. The transition to Open happens automatically when you send the Request with a Message.   In case of an incoming Request, Open means that the LocalRequest was received.   DecisionRequired   After the prerequisites of the Request and all of its RequestItems were checked, a decision can be made. At first, the Decider Module tries to make an automatic decision. It therefore checks all LocalRequests in status DecisionRequired.   ManualDecisionRequired   If the Decider Module cannot make a decision, it moves the LocalRequest to ManualDecisionRequired. When the LocalRequest is in this status, it’s the User’s turn to decide whether they want to accept or reject the Request.   Decided   When the User or the Decider Module accepts or rejects the Request, the Response and ResponseItems are generated based on the passed parameters. This Response is saved in the response property of the LocalRequest, but not yet sent.   Completed   In case of an incoming Request, the Runtime Module listens to an Event saying that a Request moved to status Decided. It then checks on which way the Request was received (Message/RelationshipTemplate) and sends the Response on the corresponding way (by sending a message or creating a Relationship). After the Response was successfully sent, it moves the LocalRequest to Completed.   In case of an outgoing Request, the Runtime Module listens to the MessageReceivedEvent and checks the content of the sent Message for a Response. If there is one, it moves the corresponding LocalRequest to Completed.   Expired   When the timestamp in expiresAt of a Request is reached, the Request automatically moves to the status Expired.   LocalRequestSource  With the information in this type you can clearly identify the Transport object the Request was sent/received in. Currently there are only two possibilities: Message and Relationship Template.                 Name       Type       Description                       type       “Message” | “RelationshipTemplate”       The type of Transport object the Request was sent/received in.                 reference       string       The ID of the Transport object the Request was sent/received in.           LocalResponse  When a LocalRequest is decided/received, a Local Response is generated, which contains the Response, together with some metadata.                 Name       Type       Description                       createdAt       string       A timestamp that describes when the LocalResponse was created                 content       Response       The actual Content object this Local Response defines the metadata for.                 source       LocalResponseSource | undefined       Information about the Transport object with which the Response came in/was sent. This property is undefined if the Response is not sent/received yet.           LocalResponseSource  With the information in this type you can clearly identify the Transport object the Response was sent/received in. Currently there are only two possibilities: Message and Relationship Change.                 Name       Type       Description                       type       “Message” | “RelationshipChange”       The type of Transport object the Response was sent/received in.                 reference       string       The ID of the Transport object the Response was sent/received in.           LocalNotification  A LocalNotification contains the local metadata for a Notification.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalNotification starts with the letters “NOT”. This way you can tell apart a LocalNotification ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Notification, false if you received it.                 peer       string       The Identity that sent you the corresponding Notification/that you sent the Notification to.                 createdAt       string       A timestamp that describes when the LocalNotification was created                 status       LocalNotificationStatus       The current status of the Notification. See below for a list of all possible values.                 content       Notification       The actual Content object this LocalNotification defines the metadata for.                 source       LocalNotificationSource       Information about the Transport object with which the Notification came in/was sent.                 receivedByDevice       string | undefined       The ID of the device that received the Notification. For reasons of consistence, the Notification can only be processed by this device.           LocalNotificationStatus  Depending on whether it is an incoming or an outgoing Notification, there can be different statuses.     Sent   This is the only valid status on sender side. If a Notification is sent and, therefore, a LocalNotification is created, its status will be set to Sent.   Open   Receiving a Notification, a LocalNotification is created with status Open.   Completed   After receiving a Notification, its items will be processed internally. If all processes finish successfully, the status of the LocalNotification will be set to Completed.   Error   If an error occurs while processing the items of a received Notification, the status of the LocalNotification will be set to Error.   LocalNotificationSource  With the information in this type you can clearly identify the Transport object the Notification was sent/received in. Currently, the only possibility for transmitting Notifications are Messages.                 Name       Type       Description                       type       “Message”       The type of Transport object the Notification was sent/received in. So far, Notifications can only be transmitted via Messages.                 reference       string       The id of the Transport object the Notification was sent/received in.           LocalAttribute  A LocalAttribute contains the local metadata for an Attribute. There are three situations a LocalAttribute is created in the database:     The Identity maintains an Attribute about itself (e.g. sets its first name). We call such a LocalAttribute “RepositoryAttribute”.   The Identity shares an Attribute of itself with another Identity (e.g. sends it in a Request). In that case, a copy of the original LocalAttribute is created, where the shareInfo property is set.   The Identity receives an Attribute from another Identity (e.g. receives it in a Request). In that case a new LocalAttribute is created, where the shareInfo is set.                  Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttribute starts with the letters “ATT”. This way you can tell apart a LocalAttribute ID from any other ID just by looking at the prefix.                 parentId       string | undefined       If the Attribute referenced by this LocalAttribute is a component of a composite Attribute, the parentId property is set to the id of the composite Attribute. Example: if a LocalAttribute is created with the content StreetAddress, for each property of the StreetAddress an additional LocalAttribute is created. And each of these will have parentId set to the id of the LocalAttribute for the StreetAddress.                 createdAt       string       A timestamp that describes when the LocalAttribute was created                 content       IdentityAttribute | RelationshipAttribute       The actual Content object this LocalAttribute defines the metadata for.                 succeeds       string | undefined       The ID of the LocalAttribute that succeeds the current one.                 succeededBy       string | undefined       The ID of the LocalAttribute that is succeeded by the current one.                 shareInfo       LocalAttributeShareInfo | undefined       Information about the peer this LocalAttribute was received from/shared with, as well as via which LocalRequest it was received/sent. If the LocalAttribute refers to a RepositoryAttribute, this property is undefined.           LocalAttributeShareInfo  The LocalAttributeShareInfo helps to keep track of how the LocalAttribute was received/sent, from whom it was received/who sent it, as well as which LocalAttribute it was copied from (in case of a shared IdentityAttribute). For example, this enables us to track back who we shared a certain IdentityAttribute with, so we are able to notify each of them when changing it. The Attribute can be either transmitted via Request or Notification. Hence, only one of requestReference and notificationReference can be set.                 Name       Type       Description                       peer       string       The Address of the Identity the LocalAttribute was received from/shared with.                 requestReference       string | undefined       The id of the LocalRequest the LocalAttribute was received in/sent with. If this is set, notificationReference must be undefined.                 notificationReference       string | undefined       The id of the LocalNotification the LocalAttribute was received in/sent with. If this is set, requestReference must be undefined.                 sourceAttribute       string | undefined       If the LocalAttribute is a copy of a RepositoryAttribute, then this property contains the id of the RepositoryAttribute.           LocalAttributeListener  A LocalAttributeListener is created when you accept an incoming Request with a RegisterAttributeListenerRequestItem. It is used to keep track of which Attribute Listeners currently exist and what they are listening for.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttributeListener starts with the letters “ATL”. This way you can tell apart a LocalAttributeListener ID from any other ID just by looking at the prefix.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The query the Attribute that is listened to must match. Note that you cannot send a RelationshipAttributeQuery here, because it doesn’t make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it.                 peer       string       The Address of the peer that requested the Attribute Listener.           Content Types  Content Types can be seen as a data contract between Identities. The medium through which this data is exchanged are the Transport types (e.g. Messages, Tokens, …). This chapter shows all the Content types and describes their intended usage.  Request  A Request allows you to ask another Identity to do something. What this “something” is depends on which of the so called RequestItems were added to the Request (e.g. CreateAttributeRequestItem, ReadAttributeRequestItem, …). The Request is then sent to the peer via Message or Relationship Template. The peer can then review the Request and decide whether they want to accept or reject it. And if they accept it, they can even choose which of the Items they want to accept. You can also put multiple Items into a group in order to ensure that they can only be accepted/rejected as a unit.                 Name       Type       Description                       @type       “Request”                         id       string | undefined       Unique identifier of this object. This property is undefined if the Request is inside of a Relationship Template. Remark: the ID of each Request starts with the letters “REQ”. This way you can tell apart a Request ID from any other ID just by looking at the prefix.                 title       string | undefined       An optional, human readable title for the Request.                 description       string | undefined       An optional, human readable description for the Request.                 expiresAt       string | undefined       A timestamp that describes when the Request expires on the Backbone. An expired Request cannot be fetched from the Backbone anymore. However, the cached version of the Request on Connector and App will still be accesible.                 items       (RequestItemGroup | \*RequestItem)[]       An array of RequestItems and Groups that are part of the Request. There must be at least one Item or Group per Request.                 metadata       string | undefined       Optional custom metadata that can be sent together with the Request. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Request.           RequestItems  RequestItems can be sent inside of a Request and specify what should be done when the Request is accepted.  AuthenticationRequestItem                 Name       Type       Description                       @type       &quot;AuthenticationRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ConsentRequestItem                 Name       Type       Description                       @type       &quot;ConsentRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 consent       string       The textual consent the user needs to give. This is different to the title and description of the RequestItem, as the consent would be the actual statement the user agrees to.                 link       string | undefined       A valid URL linking to a website which contains more information, like the EULA or privacy terms.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           CreateAttributeRequestItem                 Name       Type       Description                       @type       &quot;CreateAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to create for the peer within the Identity of the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           FreeTextRequestItem                 Name       Type       Description                       @type       &quot;FreeTextRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 freeText       string       The free text you want to send to the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ProposeAttributeRequestItem                 Name       Type       Description                       @type       &quot;ProposeAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ReadAttributeRequestItem                 Name       Type       Description                       @type       &quot;ReadAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | ThirdPartyRelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RegisterAttributeListenerRequestItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The structured query of the Attribute the sender would like to query.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ShareAttributeRequestItem                 Name       Type       Description                       @type       &quot;ShareAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to share. This is not the LocalAttribute but the content data structure of the Attribute. The owner of the Attribute which should be shared can only be the sender Identity.                 sourceAttributeId       string       The id of the LocalAttribute which is the source of the shared Attribute. This will be used later to reference the sourceAttribute from its shared copy.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RequestItemGroup                 Name       Type       Description                       @type       &quot;RequestItemGroup&quot;                         title       string | undefined       An optional, human readable title for the RequestItem Group.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       Optional metadata that can be sent together with this RequestItem. The intended usage is the same as of the metadata property of the Request.                 mustBeAccepted       boolean       If set to true, then this RequestItem Group has to be accepted when the Request is accepted.                 items       *RequestItem[]       The items inside of this Group. There has to be at least one RequestItem per Group. Note that we do not support nested Groups at the moment. If you need this feature, you can raise a feature request.           Response                 Name       Type       Description                       @type       &quot;Response&quot;                         result       &quot;Accepted&quot; | &quot;Rejected&quot;       Whether the Response was accepted or rejected by the recipient of the Request.                 requestId       string       The id of the Request this Response belongs to. The Sender of the Request needs this information to map the Response to the corresponding Request.                 items       (ResponseItemGroup\|ResponseItem)[]       An array of Response Items and Groups that are part of the Response. For each RequestItem (Group) of the Request, there must be one Response Item (Group) in the Response. Note that the indices have to be the same for matching Request and Response Items.           ResponseItems  Response Items are sent inside of a Response. They contain the response data that is sent by the recipient of the Request. There are three different kinds of Response Items: AcceptResponseItem, RejectResponseItem and ErrorResponseItem. Depending on the actual RequestItem, there can be different derivations of these three items. For example, in case of a CreateAttributeRequestItem, there is a special CreateAttributeAcceptResponseItem, while for an AuthenticationRequestItem, the AcceptResponseItem can be used, because there is no additional information necessary next to whether it was accepted or rejected.  AcceptResponseItem                 Name       Type       Description                       @type       &quot;AcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.           CreateAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;CreateAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.           FreeTextAcceptResponseItem                 Name       Type       Description                       @type       &quot;FreeTextAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 freeText       string       The free text that is used to answer the RequestItem.           ProposeAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ProposeAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.The owner of the Attribute which is proposed can only be the recipient Identity.           ReadAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ReadAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the returned LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute that will be shared to the peer.           RegisterAttributeListenerAcceptResponseItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 listenerId       string       The id of the created AttributeListener.           ShareAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ShareAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the shared LocalAttribute.           RejectResponseItem                 Name       Type       Description                       @type       &quot;RejectResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Rejected&quot;       The only possible value here is the string &quot;Rejected&quot;.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           ErrorResponseItem  The ErrorResponseItem is only created by the enmeshed Runtime, in case something happens which hinders you from further processing of the RequestItem. It will never be created manually. The properties are:                 Name       Type       Description                       @type       &quot;ErrorResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Error&quot;       The only possible value here is the string &quot;Error&quot;.                 code       string       An error code telling the sender about the kind of error that occurred.                 message       string       A human readable error message with details about the error.           ResponseItemGroup                 Name       Type       Description                       @type       &quot;ResponseItemGroup&quot;                         items       ResponseItem[]       The items inside of this Group. For each RequestItem of the RequestItem Group, there must be one Response Item in the Response Item Group. Note that the indices have to be the same for matching Request and Response Items.           ResponseWrapper  The ResponseWrapper is a wrapper around the Response that is sent by the recipient of the Request. It contains the Response itself, but also some additional information that is required for the Request to be processed correctly.                 Name       Type       Description                       @type       &quot;ResponseWrapper&quot;                         requestId       string       The id of the Request this Response belongs to.                 requestSourceReference       string       The reference to the Message or RelationshipTemplate the Request was received with.                 requestSourceType       &quot;Message&quot; | &quot;RelationshipTemplate&quot;       Specifies if the Request was transferred via Message or RelationshipTemplate.                 response       Response       The Response that is sent by the recipient of the Request.           Notification  Notifications provide you with the possibility to notify a peer about something, e.g. the succession of one of your Attributes. However, unlike Requests they don’t offer the option to make a decision whether or not they want to accept this change. In the example of Attribute succession, the peer can not decide to accept or reject the updated value, but is simply informed about it.                 Name       Type       Description                       @type       &quot;Notification&quot;                         id       string       Unique identifier of this object. Remark: the ID of each Notification starts with the letters “NOT”. This way you can tell apart a Notification ID from any other ID just by looking at the prefix.                 items       NotificationItem[]       An array of NotificationItems that are part of the Notification. There must be at least one Item per Notification.           NotificationItems  NotificationItems are sent inside a Notification and specify which processes should be triggered when receiving the Notification.  PeerSharedAttributeSucceededNotificationItem  A PeerSharedAttributeSucceededNotificationItem will be sent, if an Attribute, a peer shared with you, was succeeded by them and they choose to notify you about it. Internally, the succeeded version will then be created at your side as successor for your previously received Attribute.                 Name       Type       Description                       @type       &quot;PeerSharedAttributeSucceededNotificationItem&quot;                         predecessorId       string       The id of the LocalAttribute that was succeeded                 successorId       string       The id of the LocalAttribute it was succeeded by                 successorContent       IdentityAttribute | RelationshipAttribute       The updated content of the LocalAttribute           Attributes  An Attribute is some piece of information about an Identity itself (e.g. its name, address, birth date, etc.) or about an Identity in the context of a Relationship (e.g. the customer id the of the user the Relationship). Since the two scenarios differ quite a lot, there are two different types for them: IdentityAttribute and RelationshipAttribute.  IdentityAttribute  IdentityAttributes describe an Identity itself. Their values are strongly normalized. There is a list of available values here.                 Name       Type       Description                       @type       &quot;IdentityAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 value       IdentityAttributeValue       The Attribute’s value.                 tags       string[] | undefined       To specify additional information.           RelationshipAttribute  RelationshipAttributes describe an Identity in the context of a Relationship. While there are some types that can be used as a value for a RelationshipAttribute, these types are rather generic (e.g. ProprietaryString, ProprietaryInteger, …).                 Name       Type       Description                       @type       &quot;RelationshipAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 key       string       An arbitrary key that is set by the creator of this Attribute. It is used to identify the Attribute in a query, especially by a third party. Example: you could set something like customerId in case of a customer id.                 isTechnical       boolean | undefined       Defines whether the RelationshipAttribute contains data that is actually relevant for the user (isTechnical=false) or whether it should be hidden in the UI (isTechnical=true).                 value       RelationshipAttributeValue       The Attribute’s value.                 confidentiality       &quot;public&quot; | &quot;protected&quot; | &quot;private&quot; | When this property is set to &quot;private&quot;, it means that third parties are not able to query this RelationshipAttribute. It therefore only exists in the Relationship it was created in. If the confidentiality is &quot;protected&quot;, third parties can query the RelationshipAttribute, but the App shows a warning saying that you should only share it with someone you trust. If the confidentiality is &quot;public&quot;, everybody can query the Attribute, without anything special to happen.                   AttributeQueries  One of the main features of enmeshed is sharing Attributes. For this, an Identity either proactively sends its Attributes to a peer. Or, if let’s say a company wants to know the birth date of its customer, it can ask for it. Depending on the exact use case, the latter can be achieved with one of a bunch of RequestItems, like for example a ReadAttributeRequestItem, or a CreateAttributeListenerRequestItem. All of them have in common that they define a query property, which contains either an IdentityAttributeQuery or a RelationshipAttributeQuery.  IdentityAttributeQuery  An IdentityAttributeQuery is used to query for IdentityAttributes. For that, it defines the following properties:                 Name       Type       Description                       @type       &quot;IdentityAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 valueType       string       The type of value that should be queried, e.g. &quot;StreetAddress&quot;, &quot;BirthDate&quot; or &quot;Nationality&quot;.                 tags       string[] | undefined       To specify additional information.           You can only query IdentityAttributes owned by the recipient of the query.  RelationshipAttributeQuery  There are cases in which you want to query some data from your peer that is not an IdentityAttribute. An example for this is when an electricity provider asks for the electric meter number of a new customer. Since this information is only relevant in the context of the Relationship, an IdentityAttribute wouldn’t make any sense here. That’s why you would send a RelationshipAttributeQuery. Its properties are:                 Name       Type       Description                       @type       &quot;RelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute.                 attributeCreationHints       RelationshipAttributeCreationHints       Contains information about the value that will be created, like the value type or its confidentiality.           RelationshipAttributeCreationHints                 Name       Type       Description                       title       string       A short text describing the purpose of the Attribute that is about to be created.                 description       string | undefined       A long text describing the purpose of the Attribute that is about to be created.                 valueType       string       The value type of the Attribute to be created (e.g. &quot;ProprietaryInteger&quot;, &quot;ProprietaryString&quot;, …)                 confidentiality       &quot;public&quot; |&quot;protected&quot; |&quot;private&quot;       The confidentiality of the Attribute to be created. See RelationshipAttribute for a more detailed description of confidentialities.                 valueHints       ValueHints | undefined       Hints for validating the value, e.g. a regular expression or a min/max length.           ValueHints                 Name       Type       Description                       @type       &quot;ValueHints&quot;                         editHelp       string | undefined       A help text you can use to describe the purpose of the Attribute.                 min       number | undefined       In case of a string: the minimum length of the string. In case of an integer: the minimum value.                 max       number | undefined       In case of a string: the maximum length of the string. In case of an integer: the maximum value.                 pattern       string | undefined       A regular expression that is used to validate the value. Only applicable if the value is a string.                 values       ValueHintsValue[] | undefined       An array of allowed values.                 defaultValue       string | number | boolean | undefined       The default value that is used if no value is provided.                 propertyHints       Record&lt;string, ValueHints&gt; | undefined       A set of Value Hints of all properties. The key is the name of the property and the value a ValueHints object. Only applicable if the value is complex.           ValueHintsOverride  ValueHintsOverride has the same properties as ValueHints, except that all of them are optional. This type is used for some RelationshipAttribute values  ValueHintsValue                 Name       Type       Description                       key       string | number | boolean       The actual value.                 displayName       string       How the value should be displayed on the UI.           ThirdPartyRelationshipAttributeQuery  If you want to query Attributes the user has in the context of a Relationship with a third party, you can use the ThirdPartyRelationshipAttributeQuery. An example would be the query for the number of a bonus card managed by another company (like Payback). A ThirdPartyRelationshipAttributeQuery has the following properties:                 Name       Type       Description                       @type       &quot;ThirdPartyRelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute. Can be an empty string (&quot;&quot;), if the owner is unknown or you are querying from multiple thirdParties that could own the attribute.                 thirdParty       string[]       The Address of the third parties the RelationshipAttribute should be queried from.           IQLQuery  If you want to query Attributes by their content, you can use the IQLQuery. It allows you to specify conditions the Attribute must match and which may be chained using binary operations. Every property of the Attribute’s content may be queried, independend of whether it is nested or not, by formulating it as a lowercase key. Furthermore, using an uppercase term is a shortcut for comparing the term to the value.@type property and using # refers to the tag property. For example, if you want to query a StreetAddress in Germany which is tagged as [Primary Address] the queryString would be StreetAddress &amp;&amp; value.country.value == Germany &amp;&amp; #&quot;Primary Address&quot;. If no corresponding Attribute exists at the peer’s side, you are given the possibility to add attributeCreationHints, suggesting to create an Attribute which matches a specific valueType and optionally tags.                 Name       Type       Description                       @type       &quot;IQLQuery&quot;                         queryString       string       The condition the attribute must fulfill. It is made up of terms of the form &lt;key&gt; &lt;operator&gt; &lt;value&gt;, which may be chained using binary operations. Uppercase expressions refer to the property value@type and # to tags.                 attributeCreationHints       IQLQueryCreationHints | undefined       Suggestions for creating a new Attribute, if the query returns empty.           IQLQueryCreationHints                 Name       Type       Description                       valueType       AttributeValues.Identity.TypeName       The value.@type of the Attribute, which should be created.                 tags       string[] | undefined       The tags for the Attribute, which should be created.           RelationshipTemplateContent  Theoretically you can send any kind of data in a Relationship Template. However, if your peer uses the enmeshed App, it will only be able to process Relationship Templates that contain a RelationshipTemplateContent, which looks like this:                 Name       Type       Description                       @type       &quot;RelationshipTemplateContent&quot;                         title       string | undefined       An optional, human readable title that should be rendered in the UI.                 metadata       object | undefined       Optional custom metadata that can be sent together with the Relationship Template. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Template.                 onNewRelationship       Request       The Request that should pop up to the user in case there is no Relationship yet. In this Request you can send Attributes of yourself the user needs to in order to know who’s Template it is (e.g. company name, address, …), as ask for Attributes of the user you need to know in the Relationship, or send some information you already know about the user, so it can be saved in its wallet (e.g. the customer id).                 onExistingRelationship       Request | undefined       The Request that should pop up to the user in case a Relationship already exists. An example usage is a Request with an AuthenticationRequestItem for the sake of two-factor authentication.           RelationshipCreationChangeRequestContent  The naming on this one in combination with its response property is a bit confusing. Even though the RelationshipCreationChangeRequestContent contains the word “Request”, it has a response property. This is because in the context of Relationships, there are Relationship Changes, which have a request and a response property. But caution: these have nothing to do with the Content-types Request and Response.                 Name       Type       Description                       @type       &quot;RelationshipCreationChangeRequestContent&quot;                         response       Response       The Response to the Request that was contained in the RelationshipTemplateContent (either in the onExistingRelationship property or in the onNewRelationship property).           Mail  A Mail can be sent as the content of a Message. It is comparable with the classic email, so its properties should not contain any surprise.                 Name       Type       Description                       @type       &quot;Mail&quot;                         to       string[]       The enmeshed Addresses of the main recipients of this Mail.                 cc       string[] | undefined       The enmeshed Addresses that should receive a copy of this Mail, additionally to the ones specified in to.                 subject       string       The subject of the Mail.                 body       string       The body of the Mail.           Consumption  DecideRequestItemParameters  In order to answer a Request, the Response must be formulated appropriately. As an easier interface to do so various DecideRequestItemParameters are provided. If you want to reject any RequestItem, you must use the RejectRequestItemParameters. If you want to accept a RequestItem, however, depending on its kind you might need different parameters. For example, an AuthenticationRequestItem can be accepted using the AcceptRequestItemParameters, but for a FreeTextRequestItem AcceptFreeTextRequestItemParameters are required.  RejectRequestItemParameters                 Name       Type       Description                       accept       &quot;false&quot;       The only possible value here is the string “false”.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           AcceptRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.           AcceptFreeTextRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 freeText       string       The free text that is used to answer the RequestItem.           AcceptProposeAttributeRequestItemParameters  The parameters to accept a ProposeAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ProposeAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.           AcceptReadAttributeRequestItemParameters  The parameters to accept a ReadAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 existingAttributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ReadAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 newAttribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.">
+  <meta property="og:description" content="The enmeshed data model can be divided into three parts:     Transport types   Local types   Content types   The following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.   (note that you can click on each type in order to navigate to the paragraph with the corresponding description)  At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.  Transport Types  Transport types like RelationshipTemplate, Token or File are types that are “exchanged” between Identities via the Backbone. They are created and updated by the Transport Layer. In most cases they have a content property, which contains the actual payload that should be transferred between the Identities. This payload is being encrypted when it is sent to the Backbone, and decrypted by the other Identity when it is received. The following sections describe the different Transport types and their properties.  Note that the properties of the types are the ones that exist locally (aka on the Connector/in the App). The Backbone does not necessarily know about them. The properties that only exist locally are marked accordingly in the tables below. Further there are properties that are confidential and are therefore encrypted before sent to the Backbone, in order to enable end-to-end encryption. Both kinds of these properties are marked accordingly in the “Remarks” column of the property tables below.  Token  Tokens can be used to save arbitrary structured data on the Backbone, which is encrypted with a random symmetric key. You can then pass the ID of the Token, together with the random key, to another Identity, which can then retrieve the token and decrypt it, e.g. inside of a QR Code, which you send to the recipient via letter. Tokens can be handy in a lot of scenarios, for example:     You want to share secret information with someone you don’t have a Relationship with.   The enmeshed App currently uses a Token to save a Backup of the Identity. ID and secret key are then encoded in a QR Code, which the user can print out and scan later in order to restore the Identity on a new device.   A Token has the following properties:                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Token starts with the letters “TOK”. This way you can tell apart a Token ID from any other ID just by looking at the prefix.                         createdBy       string       The Address of the Identity that created the Token.                         createdByDevice       string       The ID of the Device that created the Token. You can use this information to track back who exactly did what.                         content       unknown       The content of the Token. You can add whatever you want here.       will be encrypted before sent to the Backbone                 createdAt       string       A timestamp that describes when the Token was created                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.                         secretKey       string       The key with which the Token was encrypted.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the Token. You can use it to share the Token with someone else.       saved only locally                 isEphemeral       boolean       If set to true the Token will not be cached in the database and only displayed once. You will not be able to fetch this Token unless you remember its id and secretKey.                   RelationshipTemplate  A Relationship Template serves two purposes:     It represents the permission to establish a Relationship. When sending a Relationship request, the sender has to attach the ID of a valid Relationship Template created by the recipient. Otherwise the Backbone blocks the Relationship request. And since the IDs are randomly generated, you can only obtain such an ID from the recipient.   It can contain data which is of interest for the one who uses the Relationship Template. The enmeshed App for example expects a Relationship Template content which contains a Request which contains e.g. Attributes about the creator of the Template as well as queries for Attributes that the Template creator wants to receive together with the Relationship request.                  Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Template starts with the letters “RLT”. This way you can tell apart a Relationship Template ID from any other ID just by looking at the prefix.                         isOwn       boolean       true if the Relationship Template was created by yourself, false if it was created by someone else.       saved only locally                 createdBy       string       The Address of the Identity that created the Relationship Template.                         createdByDevice       string       The ID of the Device that created the Relationship Template. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Token was created                         content       RelationshipTemplateContent | unknown       The content of the Relationship Template. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, RelationshipTemplateContent has to be used. Otherwise feel free to insert whatever you want or need.                         expiresAt       string       A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.       will be encrypted before sent to the Backbone                 maxNumberOfAllocations       number | undefined       Can be set to limit the number of allocations of this template. A Relationship Template is allocated by another Identity when it is first retrieved by it from the Backbone. After this value is reached, the Backbone rejects each request of any new Identity that wants to retrieve it. Identities that already allocated it will still be able to retrieve it.                         truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the RelationshipTemplate. You can use it to share the RelationshipTemplate with someone else.                   Relationship  A Relationship between two Identities is the prerequisite for them to exchange Messages. If there is no Relationship, the Backbone blocks all Messages that are tried to be sent. This ensures that you only receive Messages from Identities you know, so you are protected from any harmful Messages like spam or phishing mails.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship starts with the letters “REL”. This way you can tell apart a Relationship ID from any other ID just by looking at the prefix.                         template       RelationshipTemplate       The Relationship Template that was used to establish this Relationship.                         status       &quot;Pending&quot; | &quot;Active&quot; | &quot;Rejected&quot; | &quot;Revoked&quot;       The status of this Relationship. Pending: the Relationship was created, but not yet accepted the recipient. In this state you cannot send Messages yet.Active: this means that the Relationship is active. As long as it is active, both participants can exchange Messages.Rejected: the Relationship was rejected by the recipient.Revoked: the Relationship was revoked by the sender.                         changes       RelationshipChange[]       The history of changes made to this Relationship. You can find the definition of a Relationship Change below.                         peer       string       The Address of the Identity with which you have this Relationship.       saved only locally           RelationshipChange  Since a Relationship “belongs” to two Identities, each change on such a Relationship demands for the agreement of both parties. That’s where Relationship Changes come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a Relationship Change to the other party, which has to accept it in order for the change to take effect. If the other party doesn’t want to accept it, it can also reject it. And if the party that created the Relationship Change changes its mind, it can revoke the Relationship Change. The Backbone makes sure that a Relationship Change can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a Relationship Change that is already revoked, you will receive an error.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Relationship Change starts with the letters “RCH”. This way you can tell apart a Relationship Change ID from any other ID just by looking at the prefix.                         status       &quot;Pending&quot; |&quot;Accepted&quot; |&quot;Rejected&quot; |&quot;Revoked&quot;       The current status of the Relationship Change.                         type       &quot;Creation&quot;       The type of the Relationship Change. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second Relationship Change type.                         request       RelationshipChangeRequest       Information about the request of the Relationship Change.                         response       RelationshipChangeResponse | undefined       Information about the response of the Relationship Change.                   Note that RelationshipChangeRequest and RelationshipChangeResponse have nothing to do with Requests and Responses, which we will discuss later.  RelationshipChangeRequest                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Request.                         createdByDevice       string       The ID of the Device that created the Relationship Change Request. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Request was created                         content       RelationshipCreationChangeRequestContent | unknown       The content of the Relationship Change Request. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the Relationship Change is Creation, RelationshipCreationChangeRequestContent has to be used. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone           RelationshipChangeResponse                 Name       Type       Description       Remarks                       createdBy       string       The Address of the Identity that created the Relationship Change Response.                         createdByDevice       string       The ID of the Device that created the Relationship Change Response. You can use this information to track back who exactly did what.                         createdAt       string       A timestamp that describes when the Relationship Change Response was created                         content       unknown       The content of the Relationship Change Response. You can add whatever you want here. Since the enmeshed App doesn’t expect any special content here, there is no need to watch out.       will be encrypted before sent to the Backbone           Message  A Message is a piece of data that can be sent to one or more recipients. The sender is completely free in what the content of the Message looks like. Though in order to enable a normalized communication, enmeshed defines some content structures for Messages, and in the future there will be more of those. Consider that the enmeshed App only supports those normalized Message contents. Currently there are:     Mail   Request   ResponseWrapper   Notification   You can read more details about each of these in the corresponding sections of the “Content Types” chapter.  But if you are communicating with another Connector, feel free to settle on any content structure that fits your needs.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each Message starts with the letters “MSG”. This way you can tell apart a Message ID from any other ID just by looking at the prefix.                         content       unknown       The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either Mail, Request, Response or Notification. Otherwise feel free to insert whatever you want or need.       will be encrypted before sent to the Backbone                 createdBy       string       The Address of the Identity that created the Message.                         createdByDevice       string       The ID of the Device that created the Message. You can use this information to track back who exactly did what.                         recipients       Recipient[]       An array of recipients of this Message.                         createdAt       string       A timestamp that describes when the Message was created                         attachments       string[]       An array of File IDs you want to attach to your Message. You receive the File ID after you uploaded a file to the Backbone. By attaching a File to a Message, you share the secret key used to encrypt/decrypt the File, which cannot be undone.                   Recipient                 Name       Type       Description       Remarks                       address       string       The Address of the recipient of the Message.                         relationshipId       string       The ID of the Relationship between the recipient and the sender of the Message.       saved only locally                 receivedAt       string | undefined       A timestamp that describes when the recipient retrieved the Message from the Backbone. undefined when the Message wasn’t received yet. Caution: “received” does not mean that it was read, so don’t mix this up with a read receipt.                         receivedByDevice       string | undefined       The ID of the Device that first retrieved the Message. undefined when the Message wasn’t received yet. This is of no interest for the sender of the Message, but rather for the recipient itself, since they can use it for audit purposes. sender                   File  The Backbone allows you to upload files, which are saved as - you guessed it - Files.                 Name       Type       Description       Remarks                       id       string       Unique identifier of this object. Remark: the ID of each File starts with the letters “FIL”. This way you can tell apart a File ID from any other ID just by looking at the prefix.                         createdAt       string       A timestamp that describes when the File was created                         createdBy       string       The Address of the Identity that created the File.                         createdByDevice       string       The ID of the Device that created the File. You can use this information to track back who exactly did what.                         expiresAt       string       A timestamp that describes when the File expires on the Backbone. An expired File cannot be fetched from the Backbone anymore. However, the cached version of the File on Connector and App will still be accesible.                         filename       string       The name of the file as it was on the device that uploaded it.       will be encrypted before sent to the Backbone                 filesize       number       The size of the plaintext file in bytes.       will be encrypted before sent to the Backbone                 mimetype       string       The mimetype of the file.       will be encrypted before sent to the Backbone                 title       string       A human readable title of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 description       string | undefined       A human readable description of the file, which can be defined when uploading the File.       will be encrypted before sent to the Backbone                 secretKey       string       The key that was used to encrypt the File.       saved only locally                 isOwn       boolean       true if the File was created by yourself, false if it was created by someone else.       saved only locally                 truncatedReference       string       A base64 encoded string containing all information necessary for another Identity to load the File. You can use it to share the File with someone else.       saved only locally           A File further has its content, of course. But since this is not a JSON property, it is not included in this table. You can download the content of the File separately.  Local Types  In addition to the types that are shared between Identities via the Backbone, there are certain types that only exist within one Identity. These types usually contain metadata about Content types that should not be transferred to other Identities. They are created and updated by the Consumption Layer.  Currently there are three main Local types:     LocalRequest   LocalNotification   LocalAttribute   Each of them further describes some sub types.  This chapter explains all of those types, together with their properties.  LocalRequest  A LocalRequest contains the local metadata for a Request.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalRequest starts with the letters “REQ”. This way you can tell apart a LocalRequest ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Request, false if you received it.                 peer       string       The Identity that sent you the corresponding Request/that you sent the Request to.                 createdAt       string       A timestamp that describes when the LocalRequest was created                 status       LocalRequestStatus       The current status of the Request. See below for a list of all possible values.                 content       Request       The actual Content object this LocalRequest defines the metadata for.                 source       LocalRequestSource | undefined       Information about the Transport object with which the Request came in/was sent. This property is undefined if the Request is not sent yet.                 response       LocalResponse | undefined       Metadata + Content object of the response. If there is no response yet, this property is undefined.           LocalRequestStatus  Depending on whether it is an incoming or an outgoing Request, there can be different statuses. The following state diagram shows which status exists in both cases and when there are transitions from one state to another:       Draft   This status only exists for outgoing Requests. It means that the LocalRequest was created, but not yet sent.   Open   In case of an outgoing Request, Open means that the Request was sent. The transition to Open happens automatically when you send the Request with a Message.   In case of an incoming Request, Open means that the LocalRequest was received.   DecisionRequired   After the prerequisites of the Request and all of its RequestItems were checked, a decision can be made. At first, the Decider Module tries to make an automatic decision. It therefore checks all LocalRequests in status DecisionRequired.   ManualDecisionRequired   If the Decider Module cannot make a decision, it moves the LocalRequest to ManualDecisionRequired. When the LocalRequest is in this status, it’s the User’s turn to decide whether they want to accept or reject the Request.   Decided   When the User or the Decider Module accepts or rejects the Request, the Response and ResponseItems are generated based on the passed parameters. This Response is saved in the response property of the LocalRequest, but not yet sent.   Completed   In case of an incoming Request, the Runtime Module listens to an Event saying that a Request moved to status Decided. It then checks on which way the Request was received (Message/RelationshipTemplate) and sends the Response on the corresponding way (by sending a message or creating a Relationship). After the Response was successfully sent, it moves the LocalRequest to Completed.   In case of an outgoing Request, the Runtime Module listens to the MessageReceivedEvent and checks the content of the sent Message for a Response. If there is one, it moves the corresponding LocalRequest to Completed.   Expired   When the timestamp in expiresAt of a Request is reached, the Request automatically moves to the status Expired.   LocalRequestSource  With the information in this type you can clearly identify the Transport object the Request was sent/received in. Currently there are only two possibilities: Message and Relationship Template.                 Name       Type       Description                       type       “Message” | “RelationshipTemplate”       The type of Transport object the Request was sent/received in.                 reference       string       The ID of the Transport object the Request was sent/received in.           LocalResponse  When a LocalRequest is decided/received, a Local Response is generated, which contains the Response, together with some metadata.                 Name       Type       Description                       createdAt       string       A timestamp that describes when the LocalResponse was created                 content       Response       The actual Content object this Local Response defines the metadata for.                 source       LocalResponseSource | undefined       Information about the Transport object with which the Response came in/was sent. This property is undefined if the Response is not sent/received yet.           LocalResponseSource  With the information in this type you can clearly identify the Transport object the Response was sent/received in. Currently there are only two possibilities: Message and Relationship Change.                 Name       Type       Description                       type       “Message” | “RelationshipChange”       The type of Transport object the Response was sent/received in.                 reference       string       The ID of the Transport object the Response was sent/received in.           LocalNotification  A LocalNotification contains the local metadata for a Notification.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalNotification starts with the letters “NOT”. This way you can tell apart a LocalNotification ID from any other ID just by looking at the prefix.                 isOwn       boolean       true if you sent the Notification, false if you received it.                 peer       string       The Identity that sent you the corresponding Notification/that you sent the Notification to.                 createdAt       string       A timestamp that describes when the LocalNotification was created                 status       LocalNotificationStatus       The current status of the Notification. See below for a list of all possible values.                 content       Notification       The actual Content object this LocalNotification defines the metadata for.                 source       LocalNotificationSource       Information about the Transport object with which the Notification came in/was sent.                 receivedByDevice       string | undefined       The ID of the device that received the Notification. For reasons of consistence, the Notification can only be processed by this device.           LocalNotificationStatus  Depending on whether it is an incoming or an outgoing Notification, there can be different statuses.     Sent   This is the only valid status on sender side. If a Notification is sent and, therefore, a LocalNotification is created, its status will be set to Sent.   Open   Receiving a Notification, a LocalNotification is created with status Open.   Completed   After receiving a Notification, its items will be processed internally. If all processes finish successfully, the status of the LocalNotification will be set to Completed.   Error   If an error occurs while processing the items of a received Notification, the status of the LocalNotification will be set to Error.   LocalNotificationSource  With the information in this type you can clearly identify the Transport object the Notification was sent/received in. Currently, the only possibility for transmitting Notifications are Messages.                 Name       Type       Description                       type       “Message”       The type of Transport object the Notification was sent/received in. So far, Notifications can only be transmitted via Messages.                 reference       string       The id of the Transport object the Notification was sent/received in.           LocalAttribute  A LocalAttribute contains the local metadata for an Attribute. There are three situations a LocalAttribute is created in the database:     The Identity maintains an Attribute about itself (e.g. sets its first name). We call such a LocalAttribute “RepositoryAttribute”.   The Identity shares an Attribute of itself with another Identity (e.g. sends it in a Request). In that case, a copy of the original LocalAttribute is created, where the shareInfo property is set.   The Identity receives an Attribute from another Identity (e.g. receives it in a Request). In that case a new LocalAttribute is created, where the shareInfo is set.                  Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttribute starts with the letters “ATT”. This way you can tell apart a LocalAttribute ID from any other ID just by looking at the prefix.                 parentId       string | undefined       If the Attribute referenced by this LocalAttribute is a component of a composite Attribute, the parentId property is set to the id of the composite Attribute. Example: if a LocalAttribute is created with the content StreetAddress, for each property of the StreetAddress an additional LocalAttribute is created. And each of these will have parentId set to the id of the LocalAttribute for the StreetAddress.                 createdAt       string       A timestamp that describes when the LocalAttribute was created                 content       IdentityAttribute | RelationshipAttribute       The actual Content object this LocalAttribute defines the metadata for.                 succeeds       string | undefined       The ID of the LocalAttribute that succeeds the current one.                 succeededBy       string | undefined       The ID of the LocalAttribute that is succeeded by the current one.                 shareInfo       LocalAttributeShareInfo | undefined       Information about the peer this LocalAttribute was received from/shared with, as well as via which LocalRequest it was received/sent. If the LocalAttribute refers to a RepositoryAttribute, this property is undefined.           LocalAttributeShareInfo  The LocalAttributeShareInfo helps to keep track of how the LocalAttribute was received/sent, from whom it was received/who sent it, as well as which LocalAttribute it was copied from (in case of a shared IdentityAttribute). For example, this enables us to track back who we shared a certain IdentityAttribute with, so we are able to notify each of them when changing it. The Attribute can be either transmitted via Request or Notification. Hence, only one of requestReference and notificationReference can be set.                 Name       Type       Description                       peer       string       The Address of the Identity the LocalAttribute was received from/shared with.                 requestReference       string | undefined       The id of the LocalRequest the LocalAttribute was received in/sent with. If this is set, notificationReference must be undefined.                 notificationReference       string | undefined       The id of the LocalNotification the LocalAttribute was received in/sent with. If this is set, requestReference must be undefined.                 sourceAttribute       string | undefined       If the LocalAttribute is a copy of a RepositoryAttribute, then this property contains the id of the RepositoryAttribute.           LocalAttributeListener  A LocalAttributeListener is created when you accept an incoming Request with a RegisterAttributeListenerRequestItem. It is used to keep track of which Attribute Listeners currently exist and what they are listening for.                 Name       Type       Description                       id       string       Unique identifier of this object. Remark: the ID of each LocalAttributeListener starts with the letters “ATL”. This way you can tell apart a LocalAttributeListener ID from any other ID just by looking at the prefix.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The query the Attribute that is listened to must match. Note that you cannot send a RelationshipAttributeQuery here, because it doesn’t make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it.                 peer       string       The Address of the peer that requested the Attribute Listener.           Content Types  Content Types can be seen as a data contract between Identities. The medium through which this data is exchanged are the Transport types (e.g. Messages, Tokens, …). This chapter shows all the Content types and describes their intended usage.  Request  A Request allows you to ask another Identity to do something. What this “something” is depends on which of the so called RequestItems were added to the Request (e.g. CreateAttributeRequestItem, ReadAttributeRequestItem, …). The Request is then sent to the peer via Message or Relationship Template. The peer can then review the Request and decide whether they want to accept or reject it. And if they accept it, they can even choose which of the Items they want to accept. You can also put multiple Items into a group in order to ensure that they can only be accepted/rejected as a unit.                 Name       Type       Description                       @type       “Request”                         id       string | undefined       Unique identifier of this object. This property is undefined if the Request is inside of a Relationship Template. Remark: the ID of each Request starts with the letters “REQ”. This way you can tell apart a Request ID from any other ID just by looking at the prefix.                 title       string | undefined       An optional, human readable title for the Request.                 description       string | undefined       An optional, human readable description for the Request.                 expiresAt       string | undefined       A timestamp that describes when the Request expires on the Backbone. An expired Request cannot be fetched from the Backbone anymore. However, the cached version of the Request on Connector and App will still be accesible.                 items       (RequestItemGroup | \*RequestItem)[]       An array of RequestItems and Groups that are part of the Request. There must be at least one Item or Group per Request.                 metadata       string | undefined       Optional custom metadata that can be sent together with the Request. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Request.           RequestItems  RequestItems can be sent inside of a Request and specify what should be done when the Request is accepted.  AuthenticationRequestItem                 Name       Type       Description                       @type       &quot;AuthenticationRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ConsentRequestItem                 Name       Type       Description                       @type       &quot;ConsentRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 consent       string       The textual consent the user needs to give. This is different to the title and description of the RequestItem, as the consent would be the actual statement the user agrees to.                 link       string | undefined       A valid URL linking to a website which contains more information, like the EULA or privacy terms.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           CreateAttributeRequestItem                 Name       Type       Description                       @type       &quot;CreateAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to create for the peer within the Identity of the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           FreeTextRequestItem                 Name       Type       Description                       @type       &quot;FreeTextRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 freeText       string       The free text you want to send to the peer.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ProposeAttributeRequestItem                 Name       Type       Description                       @type       &quot;ProposeAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ReadAttributeRequestItem                 Name       Type       Description                       @type       &quot;ReadAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | RelationshipAttributeQuery | ThirdPartyRelationshipAttributeQuery | IQLQuery       The structured query of the Attribute the sender would like to receive.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RegisterAttributeListenerRequestItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 query       IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery       The structured query of the Attribute the sender would like to query.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           ShareAttributeRequestItem                 Name       Type       Description                       @type       &quot;ShareAttributeRequestItem&quot;       Specifies the type of the RequestItem for internal processing.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to share. This is not the LocalAttribute but the content data structure of the Attribute. The owner of the Attribute which should be shared can only be the sender Identity.                 sourceAttributeId       string       The id of the LocalAttribute which is the source of the shared Attribute. This will be used later to reference the sourceAttribute from its shared copy.                 title       string | undefined       An optional, human readable title for the RequestItem.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.                 mustBeAccepted       boolean       The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.                 requireManualDecision       boolean | undefined       To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.           RequestItemGroup                 Name       Type       Description                       @type       &quot;RequestItemGroup&quot;                         title       string | undefined       An optional, human readable title for the RequestItem Group.                 description       string | undefined       An optional, human readable description for the RequestItem.                 metadata       object | undefined       Optional metadata that can be sent together with this RequestItem. The intended usage is the same as of the metadata property of the Request.                 mustBeAccepted       boolean       If set to true, then this RequestItem Group has to be accepted when the Request is accepted.                 items       *RequestItem[]       The items inside of this Group. There has to be at least one RequestItem per Group. Note that we do not support nested Groups at the moment. If you need this feature, you can raise a feature request.           Response                 Name       Type       Description                       @type       &quot;Response&quot;                         result       &quot;Accepted&quot; | &quot;Rejected&quot;       Whether the Response was accepted or rejected by the recipient of the Request.                 requestId       string       The id of the Request this Response belongs to. The Sender of the Request needs this information to map the Response to the corresponding Request.                 items       (ResponseItemGroup\|ResponseItem)[]       An array of Response Items and Groups that are part of the Response. For each RequestItem (Group) of the Request, there must be one Response Item (Group) in the Response. Note that the indices have to be the same for matching Request and Response Items.           ResponseItems  Response Items are sent inside of a Response. They contain the response data that is sent by the recipient of the Request. There are three different kinds of Response Items: AcceptResponseItem, RejectResponseItem and ErrorResponseItem. Depending on the actual RequestItem, there can be different derivations of these three items. For example, in case of a CreateAttributeRequestItem, there is a special CreateAttributeAcceptResponseItem, while for an AuthenticationRequestItem, the AcceptResponseItem can be used, because there is no additional information necessary next to whether it was accepted or rejected.  AcceptResponseItem                 Name       Type       Description                       @type       &quot;AcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.           CreateAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;CreateAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.           FreeTextAcceptResponseItem                 Name       Type       Description                       @type       &quot;FreeTextAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 freeText       string       The free text that is used to answer the RequestItem.           ProposeAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ProposeAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the created LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.The owner of the Attribute which is proposed can only be the recipient Identity.           ReadAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ReadAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the returned LocalAttribute.                 attribute       IdentityAttribute | RelationshipAttribute       The IdentityAttribute or RelationshipAttribute that will be shared to the peer.           RegisterAttributeListenerAcceptResponseItem                 Name       Type       Description                       @type       &quot;RegisterAttributeListenerAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 listenerId       string       The id of the created AttributeListener.           ShareAttributeAcceptResponseItem                 Name       Type       Description                       @type       &quot;ShareAttributeAcceptResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Accepted&quot;       The only possible value here is the string &quot;Accepted&quot;.                 attributeId       string       The id of the shared LocalAttribute.           RejectResponseItem                 Name       Type       Description                       @type       &quot;RejectResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Rejected&quot;       The only possible value here is the string &quot;Rejected&quot;.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           ErrorResponseItem  The ErrorResponseItem is only created by the enmeshed Runtime, in case something happens which hinders you from further processing of the RequestItem. It will never be created manually. The properties are:                 Name       Type       Description                       @type       &quot;ErrorResponseItem&quot;       The type of the ResponseItem.                 result       &quot;Error&quot;       The only possible value here is the string &quot;Error&quot;.                 code       string       An error code telling the sender about the kind of error that occurred.                 message       string       A human readable error message with details about the error.           ResponseItemGroup                 Name       Type       Description                       @type       &quot;ResponseItemGroup&quot;                         items       ResponseItem[]       The items inside of this Group. For each RequestItem of the RequestItem Group, there must be one Response Item in the Response Item Group. Note that the indices have to be the same for matching Request and Response Items.           ResponseWrapper  The ResponseWrapper is a wrapper around the Response that is sent by the recipient of the Request. It contains the Response itself, but also some additional information that is required for the Request to be processed correctly.                 Name       Type       Description                       @type       &quot;ResponseWrapper&quot;                         requestId       string       The id of the Request this Response belongs to.                 requestSourceReference       string       The reference to the Message or RelationshipTemplate the Request was received with.                 requestSourceType       &quot;Message&quot; | &quot;RelationshipTemplate&quot;       Specifies if the Request was transferred via Message or RelationshipTemplate.                 response       Response       The Response that is sent by the recipient of the Request.           Notification  Notifications provide you with the possibility to notify a peer about something, e.g. the succession of one of your Attributes. However, unlike Requests they don’t offer the option to make a decision whether or not they want to accept this change. In the example of Attribute succession, the peer can not decide to accept or reject the updated value, but is simply informed about it.                 Name       Type       Description                       @type       &quot;Notification&quot;                         id       string       Unique identifier of this object. Remark: the ID of each Notification starts with the letters “NOT”. This way you can tell apart a Notification ID from any other ID just by looking at the prefix.                 items       NotificationItem[]       An array of NotificationItems that are part of the Notification. There must be at least one Item per Notification.           NotificationItems  NotificationItems are sent inside a Notification and specify which processes should be triggered when receiving the Notification.  PeerSharedAttributeSucceededNotificationItem  A PeerSharedAttributeSucceededNotificationItem will be sent, if an Attribute, a peer shared with you, was succeeded by them and they choose to notify you about it. Internally, the succeeded version will then be created at your side as successor for your previously received Attribute.                 Name       Type       Description                       @type       &quot;PeerSharedAttributeSucceededNotificationItem&quot;                         predecessorId       string       The id of the LocalAttribute that was succeeded                 successorId       string       The id of the LocalAttribute it was succeeded by                 successorContent       IdentityAttribute | RelationshipAttribute       The updated content of the LocalAttribute           Attributes  An Attribute is some piece of information about an Identity itself (e.g. its name, address, birth date, etc.) or about an Identity in the context of a Relationship (e.g. the customer id the of the user the Relationship). Since the two scenarios differ quite a lot, there are two different types for them: IdentityAttribute and RelationshipAttribute.  IdentityAttribute  IdentityAttributes describe an Identity itself. Their values are strongly normalized. There is a list of available values here.                 Name       Type       Description                       @type       &quot;IdentityAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 value       IdentityAttributeValue       The Attribute’s value.                 tags       string[] | undefined       To specify additional information.           RelationshipAttribute  RelationshipAttributes describe an Identity in the context of a Relationship. While there are some types that can be used as a value for a RelationshipAttribute, these types are rather generic (e.g. ProprietaryString, ProprietaryInteger, …).                 Name       Type       Description                       @type       &quot;RelationshipAttribute&quot;                         owner       string       The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.                 validFrom       string | undefined       The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.                 validTo       string | undefined       The date until this Attribute is valid. Could be in the past if the Attribute is already expired.                 key       string       An arbitrary key that is set by the creator of this Attribute. It is used to identify the Attribute in a query, especially by a third party. Example: you could set something like customerId in case of a customer id.                 isTechnical       boolean | undefined       Defines whether the RelationshipAttribute contains data that is actually relevant for the user (isTechnical=false) or whether it should be hidden in the UI (isTechnical=true).                 value       RelationshipAttributeValue       The Attribute’s value.                 confidentiality       &quot;public&quot; | &quot;protected&quot; | &quot;private&quot; | When this property is set to &quot;private&quot;, it means that third parties are not able to query this RelationshipAttribute. It therefore only exists in the Relationship it was created in. If the confidentiality is &quot;protected&quot;, third parties can query the RelationshipAttribute, but the App shows a warning saying that you should only share it with someone you trust. If the confidentiality is &quot;public&quot;, everybody can query the Attribute, without anything special to happen.                   AttributeQueries  One of the main features of enmeshed is sharing Attributes. For this, an Identity either proactively sends its Attributes to a peer. Or, if let’s say a company wants to know the birth date of its customer, it can ask for it. Depending on the exact use case, the latter can be achieved with one of a bunch of RequestItems, like for example a ReadAttributeRequestItem, or a CreateAttributeListenerRequestItem. All of them have in common that they define a query property, which contains either an IdentityAttributeQuery or a RelationshipAttributeQuery.  IdentityAttributeQuery  An IdentityAttributeQuery is used to query for IdentityAttributes. For that, it defines the following properties:                 Name       Type       Description                       @type       &quot;IdentityAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 valueType       string       The type of value that should be queried, e.g. &quot;StreetAddress&quot;, &quot;BirthDate&quot; or &quot;Nationality&quot;.                 tags       string[] | undefined       To specify additional information.           You can only query IdentityAttributes owned by the recipient of the query.  RelationshipAttributeQuery  There are cases in which you want to query some data from your peer that is not an IdentityAttribute. An example for this is when an electricity provider asks for the electric meter number of a new customer. Since this information is only relevant in the context of the Relationship, an IdentityAttribute wouldn’t make any sense here. That’s why you would send a RelationshipAttributeQuery. Its properties are:                 Name       Type       Description                       @type       &quot;RelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute.                 attributeCreationHints       RelationshipAttributeCreationHints       Contains information about the value that will be created, like the value type or its confidentiality.           RelationshipAttributeCreationHints                 Name       Type       Description                       title       string       A short text describing the purpose of the Attribute that is about to be created.                 description       string | undefined       A long text describing the purpose of the Attribute that is about to be created.                 valueType       string       The value type of the Attribute to be created (e.g. &quot;ProprietaryInteger&quot;, &quot;ProprietaryString&quot;, …)                 confidentiality       &quot;public&quot; |&quot;protected&quot; |&quot;private&quot;       The confidentiality of the Attribute to be created. See RelationshipAttribute for a more detailed description of confidentialities.                 valueHints       ValueHints | undefined       Hints for validating the value, e.g. a regular expression or a min/max length.           ValueHints                 Name       Type       Description                       @type       &quot;ValueHints&quot;                         editHelp       string | undefined       A help text you can use to describe the purpose of the Attribute.                 min       number | undefined       In case of a string: the minimum length of the string. In case of an integer: the minimum value.                 max       number | undefined       In case of a string: the maximum length of the string. In case of an integer: the maximum value.                 pattern       string | undefined       A regular expression that is used to validate the value. Only applicable if the value is a string.                 values       ValueHintsValue[] | undefined       An array of allowed values.                 defaultValue       string | number | boolean | undefined       The default value that is used if no value is provided.                 propertyHints       Record&lt;string, ValueHints&gt; | undefined       A set of Value Hints of all properties. The key is the name of the property and the value a ValueHints object. Only applicable if the value is complex.           ValueHintsOverride  ValueHintsOverride has the same properties as ValueHints, except that all of them are optional. This type is used for some RelationshipAttribute values  ValueHintsValue                 Name       Type       Description                       key       string | number | boolean       The actual value.                 displayName       string       How the value should be displayed on the UI.           ThirdPartyRelationshipAttributeQuery  If you want to query Attributes the user has in the context of a Relationship with a third party, you can use the ThirdPartyRelationshipAttributeQuery. An example would be the query for the number of a bonus card managed by another company (like Payback). A ThirdPartyRelationshipAttributeQuery has the following properties:                 Name       Type       Description                       @type       &quot;ThirdPartyRelationshipAttributeQuery&quot;                         validFrom       string | undefined       The start date of the time frame the returned Attribute should be valid in.                 validTo       string | undefined       The end date of the time frame the returned Attribute should be valid in.                 key       string       The key of the RelationshipAttribute that should be queried.                 owner       string       The owner of the queried RelationshipAttribute. Can be an empty string (&quot;&quot;), if the owner is unknown or you are querying from multiple thirdParties that could own the attribute.                 thirdParty       string[]       The Address of the third parties the RelationshipAttribute should be queried from.           IQLQuery  If you want to query Attributes by their content, you can use the IQLQuery. It allows you to specify conditions the Attribute must match and which may be chained using binary operations. Every property of the Attribute’s content may be queried, independend of whether it is nested or not, by formulating it as a lowercase key. Furthermore, using an uppercase term is a shortcut for comparing the term to the value.@type property and using # refers to the tag property. For example, if you want to query a StreetAddress in Germany which is tagged as [Primary Address] the queryString would be StreetAddress &amp;&amp; value.country.value == Germany &amp;&amp; #&quot;Primary Address&quot;. If no corresponding Attribute exists at the peer’s side, you are given the possibility to add attributeCreationHints, suggesting to create an Attribute which matches a specific valueType and optionally tags.                 Name       Type       Description                       @type       &quot;IQLQuery&quot;                         queryString       string       The condition the attribute must fulfill. It is made up of terms of the form &lt;key&gt; &lt;operator&gt; &lt;value&gt;, which may be chained using binary operations. Uppercase expressions refer to the property value@type and # to tags.                 attributeCreationHints       IQLQueryCreationHints | undefined       Suggestions for creating a new Attribute, if the query returns empty.           IQLQueryCreationHints                 Name       Type       Description                       valueType       AttributeValues.Identity.TypeName       The value.@type of the Attribute, which should be created.                 tags       string[] | undefined       The tags for the Attribute, which should be created.           RelationshipTemplateContent  Theoretically you can send any kind of data in a Relationship Template. However, if your peer uses the enmeshed App, it will only be able to process Relationship Templates that contain a RelationshipTemplateContent, which looks like this:                 Name       Type       Description                       @type       &quot;RelationshipTemplateContent&quot;                         title       string | undefined       An optional, human readable title that should be rendered in the UI.                 metadata       object | undefined       Optional custom metadata that can be sent together with the Relationship Template. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Template.                 onNewRelationship       Request       The Request that should pop up to the user in case there is no Relationship yet. In this Request you can send Attributes of yourself the user needs to in order to know who’s Template it is (e.g. company name, address, …), as ask for Attributes of the user you need to know in the Relationship, or send some information you already know about the user, so it can be saved in its wallet (e.g. the customer id).                 onExistingRelationship       Request | undefined       The Request that should pop up to the user in case a Relationship already exists. An example usage is a Request with an AuthenticationRequestItem for the sake of two-factor authentication.           RelationshipCreationChangeRequestContent  The naming on this one in combination with its response property is a bit confusing. Even though the RelationshipCreationChangeRequestContent contains the word “Request”, it has a response property. This is because in the context of Relationships, there are Relationship Changes, which have a request and a response property. But caution: these have nothing to do with the Content-types Request and Response.                 Name       Type       Description                       @type       &quot;RelationshipCreationChangeRequestContent&quot;                         response       Response       The Response to the Request that was contained in the RelationshipTemplateContent (either in the onExistingRelationship property or in the onNewRelationship property).           Mail  A Mail can be sent as the content of a Message. It is comparable with the classic email, so its properties should not contain any surprise.                 Name       Type       Description                       @type       &quot;Mail&quot;                         to       string[]       The enmeshed Addresses of the main recipients of this Mail.                 cc       string[] | undefined       The enmeshed Addresses that should receive a copy of this Mail, additionally to the ones specified in to.                 subject       string       The subject of the Mail.                 body       string       The body of the Mail.           Consumption  DecideRequestItemParameters  In order to answer a Request, the Response must be formulated appropriately. As an easier interface to do so various DecideRequestItemParameters are provided. If you want to reject any RequestItem, you must use the RejectRequestItemParameters. If you want to accept a RequestItem, however, depending on its kind you might need different parameters. For example, an AuthenticationRequestItem can be accepted using the AcceptRequestItemParameters, but for a FreeTextRequestItem AcceptFreeTextRequestItemParameters are required.  RejectRequestItemParameters                 Name       Type       Description                       accept       &quot;false&quot;       The only possible value here is the string “false”.                 code       string | undefined       A code telling the sender about the reason for the rejection.                 message       string | undefined       A human readable message with details about the rejection.           AcceptRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.           AcceptFreeTextRequestItemParameters                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 freeText       string       The free text that is used to answer the RequestItem.           AcceptProposeAttributeRequestItemParameters  The parameters to accept a ProposeAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ProposeAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 attribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.           AcceptReadAttributeRequestItemParameters  The parameters to accept a ReadAttributeRequestItem with an existing Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 existingAttributeId       string       The id of the existing LocalAttribute.           The parameters to accept a ReadAttributeRequestItem with a new Attribute.                 Name       Type       Description                       accept       &quot;true&quot;       The only possible value here is the string “true”.                 newAttribute       IdentityAttribute | RelationshipAttribute       The new LocalAttribute.">
 
 
 
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -333,8 +333,8 @@ <h3>Integrate enmeshed</h3>
 
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Data Model Overview">
-    <meta itemprop="description" content="The enmeshed data model can be divided into three parts:  Transport types  Local types  Content typesThe following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.(note that you can click on each type in order to navigate to the paragraph with the corresponding description)At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.Transport TypesTransport types like RelationshipTemplate, Token or File are types that are “exchanged” between Identities via the Backbone. They are created and updated by the Transport Layer. In most cases they have a content property, which contains the actual payload that should be transferred between the Identities. This payload is being encrypted when it is sent to the Backbone, and decrypted by the other Identity when it is received. The following sections describe the different Transport types and their properties.Note that the properties of the types are the ones that exist locally (aka on the Connector/in the App). The Backbone does not necessarily know about them. The properties that only exist locally are marked accordingly in the tables below. Further there are properties that are confidential and are therefore encrypted before sent to the Backbone, in order to enable end-to-end encryption. Both kinds of these properties are marked accordingly in the “Remarks” column of the property tables below.TokenTokens can be used to save arbitrary structured data on the Backbone, which is encrypted with a random symmetric key. You can then pass the ID of the Token, together with the random key, to another Identity, which can then retrieve the token and decrypt it, e.g. inside of a QR Code, which you send to the recipient via letter. Tokens can be handy in a lot of scenarios, for example:  You want to share secret information with someone you don’t have a Relationship with.  The enmeshed App currently uses a Token to save a Backup of the Identity. ID and secret key are then encoded in a QR Code, which the user can print out and scan later in order to restore the Identity on a new device.A Token has the following properties:            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Token starts with the letters “TOK”. This way you can tell apart a Token ID from any other ID just by looking at the prefix.                     createdBy      string      The Address of the Identity that created the Token.                     createdByDevice      string      The ID of the Device that created the Token. You can use this information to track back who exactly did what.                     content      unknown      The content of the Token. You can add whatever you want here.      will be encrypted before sent to the Backbone              createdAt      string      A timestamp that describes when the Token was created                     expiresAt      string      A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.                     secretKey      string      The key with which the Token was encrypted.      saved only locally              truncatedReference      string      A base64 encoded string containing all information necessary for another Identity to load the Token. You can use it to share the Token with someone else.      saved only locally              isEphemeral      boolean      If set to true the Token will not be cached in the database and only displayed once. You will not be able to fetch this Token unless you remember its id and secretKey.             RelationshipTemplateA Relationship Template serves two purposes:  It represents the permission to establish a Relationship. When sending a Relationship request, the sender has to attach the ID of a valid Relationship Template created by the recipient. Otherwise the Backbone blocks the Relationship request. And since the IDs are randomly generated, you can only obtain such an ID from the recipient.  It can contain data which is of interest for the one who uses the Relationship Template. The enmeshed App for example expects a Relationship Template content which contains a Request which contains e.g. Attributes about the creator of the Template as well as queries for Attributes that the Template creator wants to receive together with the Relationship request.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Relationship Template starts with the letters “RLT”. This way you can tell apart a Relationship Template ID from any other ID just by looking at the prefix.                     isOwn      boolean      true if the Relationship Template was created by yourself, false if it was created by someone else.      saved only locally              createdBy      string      The Address of the Identity that created the Relationship Template.                     createdByDevice      string      The ID of the Device that created the Relationship Template. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the Token was created                     content      RelationshipTemplateContent | unknown      The content of the Relationship Template. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, RelationshipTemplateContent has to be used. Otherwise feel free to insert whatever you want or need.                     expiresAt      string      A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.      will be encrypted before sent to the Backbone              maxNumberOfAllocations      number | undefined      Can be set to limit the number of allocations of this template. A Relationship Template is allocated by another Identity when it is first retrieved by it from the Backbone. After this value is reached, the Backbone rejects each request of any new Identity that wants to retrieve it. Identities that already allocated it will still be able to retrieve it.                     truncatedReference      string      A base64 encoded string containing all information necessary for another Identity to load the RelationshipTemplate. You can use it to share the RelationshipTemplate with someone else.             RelationshipA Relationship between two Identities is the prerequisite for them to exchange Messages. If there is no Relationship, the Backbone blocks all Messages that are tried to be sent. This ensures that you only receive Messages from Identities you know, so you are protected from any harmful Messages like spam or phishing mails.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Relationship starts with the letters “REL”. This way you can tell apart a Relationship ID from any other ID just by looking at the prefix.                     template      RelationshipTemplate      The Relationship Template that was used to establish this Relationship.                     status      &quot;Pending&quot; | &quot;Active&quot; | &quot;Rejected&quot; | &quot;Revoked&quot;      The status of this Relationship. Pending: the Relationship was created, but not yet accepted the recipient. In this state you cannot send Messages yet.Active: this means that the Relationship is active. As long as it is active, both participants can exchange Messages.Rejected: the Relationship was rejected by the recipient.Revoked: the Relationship was revoked by the sender.                     changes      RelationshipChange[]      The history of changes made to this Relationship. You can find the definition of a Relationship Change below.                     peer      string      The Address of the Identity with which you have this Relationship.      saved only locally      RelationshipChangeSince a Relationship “belongs” to two Identities, each change on such a Relationship demands for the agreement of both parties. That’s where Relationship Changes come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a Relationship Change to the other party, which has to accept it in order for the change to take effect. If the other party doesn’t want to accept it, it can also reject it. And if the party that created the Relationship Change changes its mind, it can revoke the Relationship Change. The Backbone makes sure that a Relationship Change can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a Relationship Change that is already revoked, you will receive an error.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Relationship Change starts with the letters “RCH”. This way you can tell apart a Relationship Change ID from any other ID just by looking at the prefix.                     status      &quot;Pending&quot; |&quot;Accepted&quot; |&quot;Rejected&quot; |&quot;Revoked&quot;      The current status of the Relationship Change.                     type      &quot;Creation&quot;      The type of the Relationship Change. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second Relationship Change type.                     request      RelationshipChangeRequest      Information about the request of the Relationship Change.                     response      RelationshipChangeResponse | undefined      Information about the response of the Relationship Change.             Note that RelationshipChangeRequest and RelationshipChangeResponse have nothing to do with Requests and Responses, which we will discuss later.RelationshipChangeRequest            Name      Type      Description      Remarks                  createdBy      string      The Address of the Identity that created the Relationship Change Request.                     createdByDevice      string      The ID of the Device that created the Relationship Change Request. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the Relationship Change Request was created                     content      RelationshipCreationChangeRequestContent | unknown      The content of the Relationship Change Request. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the Relationship Change is Creation, RelationshipCreationChangeRequestContent has to be used. Otherwise feel free to insert whatever you want or need.      will be encrypted before sent to the Backbone      RelationshipChangeResponse            Name      Type      Description      Remarks                  createdBy      string      The Address of the Identity that created the Relationship Change Response.                     createdByDevice      string      The ID of the Device that created the Relationship Change Response. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the Relationship Change Response was created                     content      unknown      The content of the Relationship Change Response. You can add whatever you want here. Since the enmeshed App doesn’t expect any special content here, there is no need to watch out.      will be encrypted before sent to the Backbone      MessageA Message is a piece of data that can be sent to one or more recipients. The sender is completely free in what the content of the Message looks like. Though in order to enable a normalized communication, enmeshed defines some content structures for Messages, and in the future there will be more of those. Consider that the enmeshed App only supports those normalized Message contents. Currently there are:  Mail  Request  ResponseWrapperYou can read more details about each of these in the corresponding sections of the “Content Types” chapter.But if you are communicating with another Connector, feel free to settle on any content structure that fits your needs.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Message starts with the letters “MSG”. This way you can tell apart a Message ID from any other ID just by looking at the prefix.                     content      unknown      The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either Mail, Request or Response. Otherwise feel free to insert whatever you want or need.      will be encrypted before sent to the Backbone              createdBy      string      The Address of the Identity that created the Message.                     createdByDevice      string      The ID of the Device that created the Message. You can use this information to track back who exactly did what.                     recipients      Recipient[]      An array of recipients of this Message.                     createdAt      string      A timestamp that describes when the Message was created                     attachments      string[]      An array of File IDs you want to attach to your Message. You receive the File ID after you uploaded a file to the Backbone. By attaching a File to a Message, you share the secret key used to encrypt/decrypt the File, which cannot be undone.             Recipient            Name      Type      Description      Remarks                  address      string      The Address of the recipient of the Message.                     relationshipId      string      The ID of the Relationship between the recipient and the sender of the Message.      saved only locally              receivedAt      string | undefined      A timestamp that describes when the recipient retrieved the Message from the Backbone. undefined when the Message wasn’t received yet. Caution: “received” does not mean that it was read, so don’t mix this up with a read receipt.                     receivedByDevice      string | undefined      The ID of the Device that first retrieved the Message. undefined when the Message wasn’t received yet. This is of no interest for the sender of the Message, but rather for the recipient itself, since they can use it for audit purposes. sender             FileThe Backbone allows you to upload files, which are saved as - you guessed it - Files.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each File starts with the letters “FIL”. This way you can tell apart a File ID from any other ID just by looking at the prefix.                     createdAt      string      A timestamp that describes when the File was created                     createdBy      string      The Address of the Identity that created the File.                     createdByDevice      string      The ID of the Device that created the File. You can use this information to track back who exactly did what.                     expiresAt      string      A timestamp that describes when the File expires on the Backbone. An expired File cannot be fetched from the Backbone anymore. However, the cached version of the File on Connector and App will still be accesible.                     filename      string      The name of the file as it was on the device that uploaded it.      will be encrypted before sent to the Backbone              filesize      number      The size of the plaintext file in bytes.      will be encrypted before sent to the Backbone              mimetype      string      The mimetype of the file.      will be encrypted before sent to the Backbone              title      string      A human readable title of the file, which can be defined when uploading the File.      will be encrypted before sent to the Backbone              description      string | undefined      A human readable description of the file, which can be defined when uploading the File.      will be encrypted before sent to the Backbone              secretKey      string      The key that was used to encrypt the File.      saved only locally              isOwn      boolean      true if the File was created by yourself, false if it was created by someone else.      saved only locally              truncatedReference      string      A base64 encoded string containing all information necessary for another Identity to load the File. You can use it to share the File with someone else.      saved only locally      A File further has its content, of course. But since this is not a JSON property, it is not included in this table. You can download the content of the File separately.Local TypesIn addition to the types that are shared between Identities via the Backbone, there are certain types that only exist within one Identity. These types usually contain metadata about Content types that should not be transferred to other Identities. They are created and updated by the Consumption Layer.Currently there are three main Local types:  LocalRequest  LocalNotification  LocalAttributeEach of them further describes some sub types.This chapter explains all of those types, together with their properties.LocalRequestA LocalRequest contains the local metadata for a Request.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalRequest starts with the letters “REQ”. This way you can tell apart a LocalRequest ID from any other ID just by looking at the prefix.              isOwn      boolean      true if you sent the Request, false if you received it.              peer      string      The Identity that sent you the corresponding Request/that you sent the Request to.              createdAt      string      A timestamp that describes when the LocalRequest was created              status      LocalRequestStatus      The current status of the Request. See below for a list of all possible values.              content      Request      The actual Content object this LocalRequest defines the metadata for.              source      LocalRequestSource | undefined      Information about the Transport object with which the Request came in/was sent. This property is undefined if the Request is not sent yet.              response      LocalResponse | undefined      Metadata + Content object of the response. If there is no response yet, this property is undefined.      LocalRequestStatusDepending on whether it is an incoming or an outgoing Request, there can be different statuses. The following state diagram shows which status exists in both cases and when there are transitions from one state to another:  Draft  This status only exists for outgoing Requests. It means that the LocalRequest was created, but not yet sent.  Open  In case of an outgoing Request, Open means that the Request was sent. The transition to Open happens automatically when you send the Request with a Message.  In case of an incoming Request, Open means that the LocalRequest was received.  DecisionRequired  After the prerequisites of the Request and all of its RequestItems were checked, a decision can be made. At first, the Decider Module tries to make an automatic decision. It therefore checks all LocalRequests in status DecisionRequired.  ManualDecisionRequired  If the Decider Module cannot make a decision, it moves the LocalRequest to ManualDecisionRequired. When the LocalRequest is in this status, it’s the User’s turn to decide whether they want to accept or reject the Request.  Decided  When the User or the Decider Module accepts or rejects the Request, the Response and ResponseItems are generated based on the passed parameters. This Response is saved in the response property of the LocalRequest, but not yet sent.  Completed  In case of an incoming Request, the Runtime Module listens to an Event saying that a Request moved to status Decided. It then checks on which way the Request was received (Message/RelationshipTemplate) and sends the Response on the corresponding way (by sending a message or creating a Relationship). After the Response was successfully sent, it moves the LocalRequest to Completed.  In case of an outgoing Request, the Runtime Module listens to the MessageReceivedEvent and checks the content of the sent Message for a Response. If there is one, it moves the corresponding LocalRequest to Completed.  Expired  When the timestamp in expiresAt of a Request is reached, the Request automatically moves to the status Expired.LocalRequestSourceWith the information in this type you can clearly identify the Transport object the Request was sent/received in. Currently there are only two possibilities: Message and Relationship Template.            Name      Type      Description                  type      “Message” | “RelationshipTemplate”      The type of Transport object the Request was sent/received in.              reference      string      The ID of the Transport object the Request was sent/received in.      LocalResponseWhen a LocalRequest is decided/received, a Local Response is generated, which contains the Response, together with some metadata.            Name      Type      Description                  createdAt      string      A timestamp that describes when the LocalResponse was created              content      Response      The actual Content object this Local Response defines the metadata for.              source      LocalResponseSource | undefined      Information about the Transport object with which the Response came in/was sent. This property is undefined if the Response is not sent/received yet.      LocalResponseSourceWith the information in this type you can clearly identify the Transport object the Response was sent/received in. Currently there are only two possibilities: Message and Relationship Change.            Name      Type      Description                  type      “Message” | “RelationshipChange”      The type of Transport object the Response was sent/received in.              reference      string      The ID of the Transport object the Response was sent/received in.      LocalNotificationA LocalNotification contains the local metadata for a Notification.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalNotification starts with the letters “NOT”. This way you can tell apart a LocalNotification ID from any other ID just by looking at the prefix.              isOwn      boolean      true if you sent the Notification, false if you received it.              peer      string      The Identity that sent you the corresponding Notification/that you sent the Notification to.              createdAt      string      A timestamp that describes when the LocalNotification was created              status      LocalNotificationStatus      The current status of the Notification. See below for a list of all possible values.              content      Notification      The actual Content object this LocalNotification defines the metadata for.              source      LocalNotificationSource      Information about the Transport object with which the Notification came in/was sent.              receivedByDevice      string | undefined      The ID of the device that received the Notification. For reasons of consistence, the Notification can only be processed by this device.      LocalNotificationStatusDepending on whether it is an incoming or an outgoing Notification, there can be different statuses.  Sent  This is the only valid status on sender side. If a Notification is sent and, therefore, a LocalNotification is created, its status will be set to Sent.  Open  Receiving a Notification, a LocalNotification is created with status Open.  Completed  After receiving a Notification, its items will be processed internally. If all processes finish successfully, the status of the LocalNotification will be set to Completed.  Error  If an error occurs while processing the items of a received Notification, the status of the LocalNotification will be set to Error.LocalNotificationSourceWith the information in this type you can clearly identify the Transport object the Notification was sent/received in. Currently, the only possibility for transmitting Notifications are Messages.            Name      Type      Description                  type      “Message”      The type of Transport object the Notification was sent/received in. So far, Notifications can only be transmitted via Messages.              reference      string      The id of the Transport object the Notification was sent/received in.      LocalAttributeA LocalAttribute contains the local metadata for an Attribute. There are three situations a LocalAttribute is created in the database:  The Identity maintains an Attribute about itself (e.g. sets its first name). We call such a LocalAttribute “RepositoryAttribute”.  The Identity shares an Attribute of itself with another Identity (e.g. sends it in a Request). In that case, a copy of the original LocalAttribute is created, where the shareInfo property is set.  The Identity receives an Attribute from another Identity (e.g. receives it in a Request). In that case a new LocalAttribute is created, where the shareInfo is set.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalAttribute starts with the letters “ATT”. This way you can tell apart a LocalAttribute ID from any other ID just by looking at the prefix.              parentId      string | undefined      If the Attribute referenced by this LocalAttribute is a component of a composite Attribute, the parentId property is set to the id of the composite Attribute. Example: if a LocalAttribute is created with the content StreetAddress, for each property of the StreetAddress an additional LocalAttribute is created. And each of these will have parentId set to the id of the LocalAttribute for the StreetAddress.              createdAt      string      A timestamp that describes when the LocalAttribute was created              content      IdentityAttribute | RelationshipAttribute      The actual Content object this LocalAttribute defines the metadata for.              succeeds      string | undefined      The ID of the LocalAttribute that succeeds the current one.              succeededBy      string | undefined      The ID of the LocalAttribute that is succeeded by the current one.              shareInfo      LocalAttributeShareInfo | undefined      Information about the peer this LocalAttribute was received from/shared with, as well as via which LocalRequest it was received/sent. If the LocalAttribute refers to a RepositoryAttribute, this property is undefined.      LocalAttributeShareInfoThe LocalAttributeShareInfo helps to keep track of how the LocalAttribute was received/sent, from whom it was received/who sent it, as well as which LocalAttribute it was copied from (in case of a shared IdentityAttribute). For example, this enables us to track back who we shared a certain IdentityAttribute with, so we are able to notify each of them when changing it. The Attribute can be either transmitted via Request or Notification. Hence, only one of requestReference and notificationReference can be set.            Name      Type      Description                  peer      string      The Address of the Identity the LocalAttribute was received from/shared with.              requestReference      string | undefined      The id of the LocalRequest the LocalAttribute was received in/sent with. If this is set, notificationReference must be undefined.              notificationReference      string | undefined      The id of the LocalNotification the LocalAttribute was received in/sent with. If this is set, requestReference must be undefined.              sourceAttribute      string | undefined      If the LocalAttribute is a copy of a RepositoryAttribute, then this property contains the id of the RepositoryAttribute.      LocalAttributeListenerA LocalAttributeListener is created when you accept an incoming Request with a RegisterAttributeListenerRequestItem. It is used to keep track of which Attribute Listeners currently exist and what they are listening for.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalAttributeListener starts with the letters “ATL”. This way you can tell apart a LocalAttributeListener ID from any other ID just by looking at the prefix.              query      IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery      The query the Attribute that is listened to must match. Note that you cannot send a RelationshipAttributeQuery here, because it doesn’t make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it.              peer      string      The Address of the peer that requested the Attribute Listener.      Content TypesContent Types can be seen as a data contract between Identities. The medium through which this data is exchanged are the Transport types (e.g. Messages, Tokens, …). This chapter shows all the Content types and describes their intended usage.RequestA Request allows you to ask another Identity to do something. What this “something” is depends on which of the so called RequestItems were added to the Request (e.g. CreateAttributeRequestItem, ReadAttributeRequestItem, …). The Request is then sent to the peer via Message or Relationship Template. The peer can then review the Request and decide whether they want to accept or reject it. And if they accept it, they can even choose which of the Items they want to accept. You can also put multiple Items into a group in order to ensure that they can only be accepted/rejected as a unit.            Name      Type      Description                  @type      “Request”                     id      string | undefined      Unique identifier of this object. This property is undefined if the Request is inside of a Relationship Template. Remark: the ID of each Request starts with the letters “REQ”. This way you can tell apart a Request ID from any other ID just by looking at the prefix.              title      string | undefined      An optional, human readable title for the Request.              description      string | undefined      An optional, human readable description for the Request.              expiresAt      string | undefined      A timestamp that describes when the Request expires on the Backbone. An expired Request cannot be fetched from the Backbone anymore. However, the cached version of the Request on Connector and App will still be accesible.              items      (RequestItemGroup | \*RequestItem)[]      An array of RequestItems and Groups that are part of the Request. There must be at least one Item or Group per Request.              metadata      string | undefined      Optional custom metadata that can be sent together with the Request. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Request.      RequestItemsRequestItems can be sent inside of a Request and specify what should be done when the Request is accepted.AuthenticationRequestItem            Name      Type      Description                  @type      &quot;AuthenticationRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ConsentRequestItem            Name      Type      Description                  @type      &quot;ConsentRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              consent      string      The textual consent the user needs to give. This is different to the title and description of the RequestItem, as the consent would be the actual statement the user agrees to.              link      string | undefined      A valid URL linking to a website which contains more information, like the EULA or privacy terms.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      CreateAttributeRequestItem            Name      Type      Description                  @type      &quot;CreateAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to create for the peer within the Identity of the peer.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      FreeTextRequestItem            Name      Type      Description                  @type      &quot;FreeTextRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              freeText      string      The free text you want to send to the peer.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ProposeAttributeRequestItem            Name      Type      Description                  @type      &quot;ProposeAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.              query      IdentityAttributeQuery | RelationshipAttributeQuery | IQLQuery      The structured query of the Attribute the sender would like to receive.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ReadAttributeRequestItem            Name      Type      Description                  @type      &quot;ReadAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              query      IdentityAttributeQuery | RelationshipAttributeQuery | ThirdPartyRelationshipAttributeQuery | IQLQuery      The structured query of the Attribute the sender would like to receive.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      RegisterAttributeListenerRequestItem            Name      Type      Description                  @type      &quot;RegisterAttributeListenerRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              query      IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery      The structured query of the Attribute the sender would like to query.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ShareAttributeRequestItem            Name      Type      Description                  @type      &quot;ShareAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to share. This is not the LocalAttribute but the content data structure of the Attribute. The owner of the Attribute which should be shared can only be the sender Identity.              sourceAttributeId      string      The id of the LocalAttribute which is the source of the shared Attribute. This will be used later to reference the sourceAttribute from its shared copy.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      RequestItemGroup            Name      Type      Description                  @type      &quot;RequestItemGroup&quot;                     title      string | undefined      An optional, human readable title for the RequestItem Group.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      Optional metadata that can be sent together with this RequestItem. The intended usage is the same as of the metadata property of the Request.              mustBeAccepted      boolean      If set to true, then this RequestItem Group has to be accepted when the Request is accepted.              items      *RequestItem[]      The items inside of this Group. There has to be at least one RequestItem per Group. Note that we do not support nested Groups at the moment. If you need this feature, you can raise a feature request.      Response            Name      Type      Description                  @type      &quot;Response&quot;                     result      &quot;Accepted&quot; | &quot;Rejected&quot;      Whether the Response was accepted or rejected by the recipient of the Request.              requestId      string      The id of the Request this Response belongs to. The Sender of the Request needs this information to map the Response to the corresponding Request.              items      (ResponseItemGroup\|ResponseItem)[]      An array of Response Items and Groups that are part of the Response. For each RequestItem (Group) of the Request, there must be one Response Item (Group) in the Response. Note that the indices have to be the same for matching Request and Response Items.      ResponseItemsResponse Items are sent inside of a Response. They contain the response data that is sent by the recipient of the Request. There are three different kinds of Response Items: AcceptResponseItem, RejectResponseItem and ErrorResponseItem. Depending on the actual RequestItem, there can be different derivations of these three items. For example, in case of a CreateAttributeRequestItem, there is a special CreateAttributeAcceptResponseItem, while for an AuthenticationRequestItem, the AcceptResponseItem can be used, because there is no additional information necessary next to whether it was accepted or rejected.AcceptResponseItem            Name      Type      Description                  @type      &quot;AcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.      CreateAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;CreateAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the created LocalAttribute.      FreeTextAcceptResponseItem            Name      Type      Description                  @type      &quot;FreeTextAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              freeText      string      The free text that is used to answer the RequestItem.      ProposeAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;ProposeAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the created LocalAttribute.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.The owner of the Attribute which is proposed can only be the recipient Identity.      ReadAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;ReadAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the returned LocalAttribute.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute that will be shared to the peer.      RegisterAttributeListenerAcceptResponseItem            Name      Type      Description                  @type      &quot;RegisterAttributeListenerAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              listenerId      string      The id of the created AttributeListener.      ShareAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;ShareAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the shared LocalAttribute.      RejectResponseItem            Name      Type      Description                  @type      &quot;RejectResponseItem&quot;      The type of the ResponseItem.              result      &quot;Rejected&quot;      The only possible value here is the string &quot;Rejected&quot;.              code      string | undefined      A code telling the sender about the reason for the rejection.              message      string | undefined      A human readable message with details about the rejection.      ErrorResponseItemThe ErrorResponseItem is only created by the enmeshed Runtime, in case something happens which hinders you from further processing of the RequestItem. It will never be created manually. The properties are:            Name      Type      Description                  @type      &quot;ErrorResponseItem&quot;      The type of the ResponseItem.              result      &quot;Error&quot;      The only possible value here is the string &quot;Error&quot;.              code      string      An error code telling the sender about the kind of error that occurred.              message      string      A human readable error message with details about the error.      ResponseItemGroup            Name      Type      Description                  @type      &quot;ResponseItemGroup&quot;                     items      ResponseItem[]      The items inside of this Group. For each RequestItem of the RequestItem Group, there must be one Response Item in the Response Item Group. Note that the indices have to be the same for matching Request and Response Items.      ResponseWrapperThe ResponseWrapper is a wrapper around the Response that is sent by the recipient of the Request. It contains the Response itself, but also some additional information that is required for the Request to be processed correctly.            Name      Type      Description                  @type      &quot;ResponseWrapper&quot;                     requestId      string      The id of the Request this Response belongs to.              requestSourceReference      string      The reference to the Message or RelationshipTemplate the Request was received with.              requestSourceType      &quot;Message&quot; | &quot;RelationshipTemplate&quot;      Specifies if the Request was transferred via Message or RelationshipTemplate.              response      Response      The Response that is sent by the recipient of the Request.      NotificationNotifications provide you with the possibility to notify a peer about something, e.g. the succession of one of your Attributes.However, unlike Requests they don’t offer the option to make a decision whether or not they want to accept this change.In the example of Attribute succession, the peer can not decide to accept or reject the updated value, but is simply informed about it.            Name      Type      Description                  @type      &quot;Notification&quot;                     id      string      Unique identifier of this object. Remark: the ID of each Notification starts with the letters “NOT”. This way you can tell apart a Notification ID from any other ID just by looking at the prefix.              items      NotificationItem[]      An array of NotificationItems that are part of the Notification. There must be at least one Item per Notification.      NotificationItemsNotificationItems are sent inside a Notification and specify which processes should be triggered when receiving the Notification.PeerSharedAttributeSucceededNotificationItemA PeerSharedAttributeSucceededNotificationItem will be sent, if an Attribute, a peer shared with you, was succeeded by them and they choose to notify you about it.Internally, the succeeded version will then be created at your side as successor for your previously received Attribute.            Name      Type      Description                  @type      &quot;PeerSharedAttributeSucceededNotificationItem&quot;                     predecessorId      string      The id of the LocalAttribute that was succeeded              successorId      string      The id of the LocalAttribute it was succeeded by              successorContent      IdentityAttribute | RelationshipAttribute      The updated content of the LocalAttribute      AttributesAn Attribute is some piece of information about an Identity itself (e.g. its name, address, birth date, etc.) or about an Identity in the context of a Relationship (e.g. the customer id the of the user the Relationship). Since the two scenarios differ quite a lot, there are two different types for them: IdentityAttribute and RelationshipAttribute.IdentityAttributeIdentityAttributes describe an Identity itself. Their values are strongly normalized. There is a list of available values here.            Name      Type      Description                  @type      &quot;IdentityAttribute&quot;                     owner      string      The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.              validFrom      string | undefined      The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.              validTo      string | undefined      The date until this Attribute is valid. Could be in the past if the Attribute is already expired.              value      IdentityAttributeValue      The Attribute’s value.              tags      string[] | undefined      To specify additional information.      RelationshipAttributeRelationshipAttributes describe an Identity in the context of a Relationship. While there are some types that can be used as a value for a RelationshipAttribute, these types are rather generic (e.g. ProprietaryString, ProprietaryInteger, …).            Name      Type      Description                  @type      &quot;RelationshipAttribute&quot;                     owner      string      The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.              validFrom      string | undefined      The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.              validTo      string | undefined      The date until this Attribute is valid. Could be in the past if the Attribute is already expired.              key      string      An arbitrary key that is set by the creator of this Attribute. It is used to identify the Attribute in a query, especially by a third party. Example: you could set something like customerId in case of a customer id.              isTechnical      boolean | undefined      Defines whether the RelationshipAttribute contains data that is actually relevant for the user (isTechnical=false) or whether it should be hidden in the UI (isTechnical=true).              value      RelationshipAttributeValue      The Attribute’s value.              confidentiality      &quot;public&quot; | &quot;protected&quot; | &quot;private&quot; | When this property is set to &quot;private&quot;, it means that third parties are not able to query this RelationshipAttribute. It therefore only exists in the Relationship it was created in. If the confidentiality is &quot;protected&quot;, third parties can query the RelationshipAttribute, but the App shows a warning saying that you should only share it with someone you trust. If the confidentiality is &quot;public&quot;, everybody can query the Attribute, without anything special to happen.             AttributeQueriesOne of the main features of enmeshed is sharing Attributes. For this, an Identity either proactively sends its Attributes to a peer. Or, if let’s say a company wants to know the birth date of its customer, it can ask for it. Depending on the exact use case, the latter can be achieved with one of a bunch of RequestItems, like for example a ReadAttributeRequestItem, or a CreateAttributeListenerRequestItem. All of them have in common that they define a query property, which contains either an IdentityAttributeQuery or a RelationshipAttributeQuery.IdentityAttributeQueryAn IdentityAttributeQuery is used to query for IdentityAttributes. For that, it defines the following properties:            Name      Type      Description                  @type      &quot;IdentityAttributeQuery&quot;                     validFrom      string | undefined      The start date of the time frame the returned Attribute should be valid in.              validTo      string | undefined      The end date of the time frame the returned Attribute should be valid in.              valueType      string      The type of value that should be queried, e.g. &quot;StreetAddress&quot;, &quot;BirthDate&quot; or &quot;Nationality&quot;.              tags      string[] | undefined      To specify additional information.      You can only query IdentityAttributes owned by the recipient of the query.RelationshipAttributeQueryThere are cases in which you want to query some data from your peer that is not an IdentityAttribute. An example for this is when an electricity provider asks for the electric meter number of a new customer. Since this information is only relevant in the context of the Relationship, an IdentityAttribute wouldn’t make any sense here. That’s why you would send a RelationshipAttributeQuery. Its properties are:            Name      Type      Description                  @type      &quot;RelationshipAttributeQuery&quot;                     validFrom      string | undefined      The start date of the time frame the returned Attribute should be valid in.              validTo      string | undefined      The end date of the time frame the returned Attribute should be valid in.              key      string      The key of the RelationshipAttribute that should be queried.              owner      string      The owner of the queried RelationshipAttribute.              attributeCreationHints      RelationshipAttributeCreationHints      Contains information about the value that will be created, like the value type or its confidentiality.      RelationshipAttributeCreationHints            Name      Type      Description                  title      string      A short text describing the purpose of the Attribute that is about to be created.              description      string | undefined      A long text describing the purpose of the Attribute that is about to be created.              valueType      string      The value type of the Attribute to be created (e.g. &quot;ProprietaryInteger&quot;, &quot;ProprietaryString&quot;, …)              confidentiality      &quot;public&quot; |&quot;protected&quot; |&quot;private&quot;      The confidentiality of the Attribute to be created. See RelationshipAttribute for a more detailed description of confidentialities.              valueHints      ValueHints | undefined      Hints for validating the value, e.g. a regular expression or a min/max length.      ValueHints            Name      Type      Description                  @type      &quot;ValueHints&quot;                     editHelp      string | undefined      A help text you can use to describe the purpose of the Attribute.              min      number | undefined      In case of a string: the minimum length of the string. In case of an integer: the minimum value.              max      number | undefined      In case of a string: the maximum length of the string. In case of an integer: the maximum value.              pattern      string | undefined      A regular expression that is used to validate the value. Only applicable if the value is a string.              values      ValueHintsValue[] | undefined      An array of allowed values.              defaultValue      string | number | boolean | undefined      The default value that is used if no value is provided.              propertyHints      Record&lt;string, ValueHints&gt; | undefined      A set of Value Hints of all properties. The key is the name of the property and the value a ValueHints object. Only applicable if the value is complex.      ValueHintsOverrideValueHintsOverride has the same properties as ValueHints, except that all of them are optional. This type is used for some RelationshipAttribute valuesValueHintsValue            Name      Type      Description                  key      string | number | boolean      The actual value.              displayName      string      How the value should be displayed on the UI.      ThirdPartyRelationshipAttributeQueryIf you want to query Attributes the user has in the context of a Relationship with a third party, you can use the ThirdPartyRelationshipAttributeQuery. An example would be the query for the number of a bonus card managed by another company (like Payback). A ThirdPartyRelationshipAttributeQuery has the following properties:            Name      Type      Description                  @type      &quot;ThirdPartyRelationshipAttributeQuery&quot;                     validFrom      string | undefined      The start date of the time frame the returned Attribute should be valid in.              validTo      string | undefined      The end date of the time frame the returned Attribute should be valid in.              key      string      The key of the RelationshipAttribute that should be queried.              owner      string      The owner of the queried RelationshipAttribute. Can be an empty string (&quot;&quot;), if the owner is unknown or you are querying from multiple thirdParties that could own the attribute.              thirdParty      string[]      The Address of the third parties the RelationshipAttribute should be queried from.      IQLQueryIf you want to query Attributes by their content, you can use the IQLQuery.It allows you to specify conditions the Attribute must match and which may be chained using binary operations.Every property of the Attribute’s content may be queried, independend of whether it is nested or not, by formulating it as a lowercase key.Furthermore, using an uppercase term is a shortcut for comparing the term to the value.@type property and using # refers to the tag property.For example, if you want to query a StreetAddress in Germany which is tagged as [Primary Address] the queryString would be StreetAddress &amp;&amp; value.country.value == Germany &amp;&amp; #&quot;Primary Address&quot;.If no corresponding Attribute exists at the peer’s side, you are given the possibility to add attributeCreationHints, suggesting to create an Attribute which matches a specific valueType and optionally tags.            Name      Type      Description                  @type      &quot;IQLQuery&quot;                     queryString      string      The condition the attribute must fulfill. It is made up of terms of the form &lt;key&gt; &lt;operator&gt; &lt;value&gt;, which may be chained using binary operations. Uppercase expressions refer to the property value@type and # to tags.              attributeCreationHints      IQLQueryCreationHints | undefined      Suggestions for creating a new Attribute, if the query returns empty.      IQLQueryCreationHints            Name      Type      Description                  valueType      AttributeValues.Identity.TypeName      The value.@type of the Attribute, which should be created.              tags      string[] | undefined      The tags for the Attribute, which should be created.      RelationshipTemplateContentTheoretically you can send any kind of data in a Relationship Template. However, if your peer uses the enmeshed App, it will only be able to process Relationship Templates that contain a RelationshipTemplateContent, which looks like this:            Name      Type      Description                  @type      &quot;RelationshipTemplateContent&quot;                     title      string | undefined      An optional, human readable title that should be rendered in the UI.              metadata      object | undefined      Optional custom metadata that can be sent together with the Relationship Template. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Template.              onNewRelationship      Request      The Request that should pop up to the user in case there is no Relationship yet. In this Request you can send Attributes of yourself the user needs to in order to know who’s Template it is (e.g. company name, address, …), as ask for Attributes of the user you need to know in the Relationship, or send some information you already know about the user, so it can be saved in its wallet (e.g. the customer id).              onExistingRelationship      Request | undefined      The Request that should pop up to the user in case a Relationship already exists. An example usage is a Request with an AuthenticationRequestItem for the sake of two-factor authentication.      RelationshipCreationChangeRequestContentThe naming on this one in combination with its response property is a bit confusing. Even though the RelationshipCreationChangeRequestContent contains the word “Request”, it has a response property.This is because in the context of Relationships, there are Relationship Changes, which have a request and a response property. But caution: these have nothing to do with the Content-types Request and Response.            Name      Type      Description                  @type      &quot;RelationshipCreationChangeRequestContent&quot;                     response      Response      The Response to the Request that was contained in the RelationshipTemplateContent (either in the onExistingRelationship property or in the onNewRelationship property).      MailA Mail can be sent as the content of a Message. It is comparable with the classic email, so its properties should not contain any surprise.            Name      Type      Description                  @type      &quot;Mail&quot;                     to      string[]      The enmeshed Addresses of the main recipients of this Mail.              cc      string[] | undefined      The enmeshed Addresses that should receive a copy of this Mail, additionally to the ones specified in to.              subject      string      The subject of the Mail.              body      string      The body of the Mail.      ConsumptionDecideRequestItemParametersIn order to answer a Request, the Response must be formulated appropriately.As an easier interface to do so various DecideRequestItemParameters are provided.If you want to reject any RequestItem, you must use the RejectRequestItemParameters.If you want to accept a RequestItem, however, depending on its kind you might need different parameters.For example, an AuthenticationRequestItem can be accepted using the AcceptRequestItemParameters, but for a FreeTextRequestItem AcceptFreeTextRequestItemParameters are required.RejectRequestItemParameters            Name      Type      Description                  accept      &quot;false&quot;      The only possible value here is the string “false”.              code      string | undefined      A code telling the sender about the reason for the rejection.              message      string | undefined      A human readable message with details about the rejection.      AcceptRequestItemParameters            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.      AcceptFreeTextRequestItemParameters            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              freeText      string      The free text that is used to answer the RequestItem.      AcceptProposeAttributeRequestItemParametersThe parameters to accept a ProposeAttributeRequestItem with an existing Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              attributeId      string      The id of the existing LocalAttribute.      The parameters to accept a ProposeAttributeRequestItem with a new Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              attribute      IdentityAttribute | RelationshipAttribute      The new LocalAttribute.      AcceptReadAttributeRequestItemParametersThe parameters to accept a ReadAttributeRequestItem with an existing Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              existingAttributeId      string      The id of the existing LocalAttribute.      The parameters to accept a ReadAttributeRequestItem with a new Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              newAttribute      IdentityAttribute | RelationshipAttribute      The new LocalAttribute.      ">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="description" content="The enmeshed data model can be divided into three parts:  Transport types  Local types  Content typesThe following diagram gives you an overview of all the existing types and how they are connected to each other. The subsequent chapters describe these types in more detail.(note that you can click on each type in order to navigate to the paragraph with the corresponding description)At a first glance the amount of types is overwhelming. But in the following chapters all of them are explained in detail.Transport TypesTransport types like RelationshipTemplate, Token or File are types that are “exchanged” between Identities via the Backbone. They are created and updated by the Transport Layer. In most cases they have a content property, which contains the actual payload that should be transferred between the Identities. This payload is being encrypted when it is sent to the Backbone, and decrypted by the other Identity when it is received. The following sections describe the different Transport types and their properties.Note that the properties of the types are the ones that exist locally (aka on the Connector/in the App). The Backbone does not necessarily know about them. The properties that only exist locally are marked accordingly in the tables below. Further there are properties that are confidential and are therefore encrypted before sent to the Backbone, in order to enable end-to-end encryption. Both kinds of these properties are marked accordingly in the “Remarks” column of the property tables below.TokenTokens can be used to save arbitrary structured data on the Backbone, which is encrypted with a random symmetric key. You can then pass the ID of the Token, together with the random key, to another Identity, which can then retrieve the token and decrypt it, e.g. inside of a QR Code, which you send to the recipient via letter. Tokens can be handy in a lot of scenarios, for example:  You want to share secret information with someone you don’t have a Relationship with.  The enmeshed App currently uses a Token to save a Backup of the Identity. ID and secret key are then encoded in a QR Code, which the user can print out and scan later in order to restore the Identity on a new device.A Token has the following properties:            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Token starts with the letters “TOK”. This way you can tell apart a Token ID from any other ID just by looking at the prefix.                     createdBy      string      The Address of the Identity that created the Token.                     createdByDevice      string      The ID of the Device that created the Token. You can use this information to track back who exactly did what.                     content      unknown      The content of the Token. You can add whatever you want here.      will be encrypted before sent to the Backbone              createdAt      string      A timestamp that describes when the Token was created                     expiresAt      string      A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.                     secretKey      string      The key with which the Token was encrypted.      saved only locally              truncatedReference      string      A base64 encoded string containing all information necessary for another Identity to load the Token. You can use it to share the Token with someone else.      saved only locally              isEphemeral      boolean      If set to true the Token will not be cached in the database and only displayed once. You will not be able to fetch this Token unless you remember its id and secretKey.             RelationshipTemplateA Relationship Template serves two purposes:  It represents the permission to establish a Relationship. When sending a Relationship request, the sender has to attach the ID of a valid Relationship Template created by the recipient. Otherwise the Backbone blocks the Relationship request. And since the IDs are randomly generated, you can only obtain such an ID from the recipient.  It can contain data which is of interest for the one who uses the Relationship Template. The enmeshed App for example expects a Relationship Template content which contains a Request which contains e.g. Attributes about the creator of the Template as well as queries for Attributes that the Template creator wants to receive together with the Relationship request.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Relationship Template starts with the letters “RLT”. This way you can tell apart a Relationship Template ID from any other ID just by looking at the prefix.                     isOwn      boolean      true if the Relationship Template was created by yourself, false if it was created by someone else.      saved only locally              createdBy      string      The Address of the Identity that created the Relationship Template.                     createdByDevice      string      The ID of the Device that created the Relationship Template. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the Token was created                     content      RelationshipTemplateContent | unknown      The content of the Relationship Template. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, RelationshipTemplateContent has to be used. Otherwise feel free to insert whatever you want or need.                     expiresAt      string      A timestamp that describes when the Token expires on the Backbone. An expired Token cannot be fetched from the Backbone anymore. However, the cached version of the Token on Connector and App will still be accesible.      will be encrypted before sent to the Backbone              maxNumberOfAllocations      number | undefined      Can be set to limit the number of allocations of this template. A Relationship Template is allocated by another Identity when it is first retrieved by it from the Backbone. After this value is reached, the Backbone rejects each request of any new Identity that wants to retrieve it. Identities that already allocated it will still be able to retrieve it.                     truncatedReference      string      A base64 encoded string containing all information necessary for another Identity to load the RelationshipTemplate. You can use it to share the RelationshipTemplate with someone else.             RelationshipA Relationship between two Identities is the prerequisite for them to exchange Messages. If there is no Relationship, the Backbone blocks all Messages that are tried to be sent. This ensures that you only receive Messages from Identities you know, so you are protected from any harmful Messages like spam or phishing mails.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Relationship starts with the letters “REL”. This way you can tell apart a Relationship ID from any other ID just by looking at the prefix.                     template      RelationshipTemplate      The Relationship Template that was used to establish this Relationship.                     status      &quot;Pending&quot; | &quot;Active&quot; | &quot;Rejected&quot; | &quot;Revoked&quot;      The status of this Relationship. Pending: the Relationship was created, but not yet accepted the recipient. In this state you cannot send Messages yet.Active: this means that the Relationship is active. As long as it is active, both participants can exchange Messages.Rejected: the Relationship was rejected by the recipient.Revoked: the Relationship was revoked by the sender.                     changes      RelationshipChange[]      The history of changes made to this Relationship. You can find the definition of a Relationship Change below.                     peer      string      The Address of the Identity with which you have this Relationship.      saved only locally      RelationshipChangeSince a Relationship “belongs” to two Identities, each change on such a Relationship demands for the agreement of both parties. That’s where Relationship Changes come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a Relationship Change to the other party, which has to accept it in order for the change to take effect. If the other party doesn’t want to accept it, it can also reject it. And if the party that created the Relationship Change changes its mind, it can revoke the Relationship Change. The Backbone makes sure that a Relationship Change can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a Relationship Change that is already revoked, you will receive an error.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Relationship Change starts with the letters “RCH”. This way you can tell apart a Relationship Change ID from any other ID just by looking at the prefix.                     status      &quot;Pending&quot; |&quot;Accepted&quot; |&quot;Rejected&quot; |&quot;Revoked&quot;      The current status of the Relationship Change.                     type      &quot;Creation&quot;      The type of the Relationship Change. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second Relationship Change type.                     request      RelationshipChangeRequest      Information about the request of the Relationship Change.                     response      RelationshipChangeResponse | undefined      Information about the response of the Relationship Change.             Note that RelationshipChangeRequest and RelationshipChangeResponse have nothing to do with Requests and Responses, which we will discuss later.RelationshipChangeRequest            Name      Type      Description      Remarks                  createdBy      string      The Address of the Identity that created the Relationship Change Request.                     createdByDevice      string      The ID of the Device that created the Relationship Change Request. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the Relationship Change Request was created                     content      RelationshipCreationChangeRequestContent | unknown      The content of the Relationship Change Request. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the Relationship Change is Creation, RelationshipCreationChangeRequestContent has to be used. Otherwise feel free to insert whatever you want or need.      will be encrypted before sent to the Backbone      RelationshipChangeResponse            Name      Type      Description      Remarks                  createdBy      string      The Address of the Identity that created the Relationship Change Response.                     createdByDevice      string      The ID of the Device that created the Relationship Change Response. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the Relationship Change Response was created                     content      unknown      The content of the Relationship Change Response. You can add whatever you want here. Since the enmeshed App doesn’t expect any special content here, there is no need to watch out.      will be encrypted before sent to the Backbone      MessageA Message is a piece of data that can be sent to one or more recipients. The sender is completely free in what the content of the Message looks like. Though in order to enable a normalized communication, enmeshed defines some content structures for Messages, and in the future there will be more of those. Consider that the enmeshed App only supports those normalized Message contents. Currently there are:  Mail  Request  ResponseWrapper  NotificationYou can read more details about each of these in the corresponding sections of the “Content Types” chapter.But if you are communicating with another Connector, feel free to settle on any content structure that fits your needs.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each Message starts with the letters “MSG”. This way you can tell apart a Message ID from any other ID just by looking at the prefix.                     content      unknown      The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either Mail, Request, Response or Notification. Otherwise feel free to insert whatever you want or need.      will be encrypted before sent to the Backbone              createdBy      string      The Address of the Identity that created the Message.                     createdByDevice      string      The ID of the Device that created the Message. You can use this information to track back who exactly did what.                     recipients      Recipient[]      An array of recipients of this Message.                     createdAt      string      A timestamp that describes when the Message was created                     attachments      string[]      An array of File IDs you want to attach to your Message. You receive the File ID after you uploaded a file to the Backbone. By attaching a File to a Message, you share the secret key used to encrypt/decrypt the File, which cannot be undone.             Recipient            Name      Type      Description      Remarks                  address      string      The Address of the recipient of the Message.                     relationshipId      string      The ID of the Relationship between the recipient and the sender of the Message.      saved only locally              receivedAt      string | undefined      A timestamp that describes when the recipient retrieved the Message from the Backbone. undefined when the Message wasn’t received yet. Caution: “received” does not mean that it was read, so don’t mix this up with a read receipt.                     receivedByDevice      string | undefined      The ID of the Device that first retrieved the Message. undefined when the Message wasn’t received yet. This is of no interest for the sender of the Message, but rather for the recipient itself, since they can use it for audit purposes. sender             FileThe Backbone allows you to upload files, which are saved as - you guessed it - Files.            Name      Type      Description      Remarks                  id      string      Unique identifier of this object. Remark: the ID of each File starts with the letters “FIL”. This way you can tell apart a File ID from any other ID just by looking at the prefix.                     createdAt      string      A timestamp that describes when the File was created                     createdBy      string      The Address of the Identity that created the File.                     createdByDevice      string      The ID of the Device that created the File. You can use this information to track back who exactly did what.                     expiresAt      string      A timestamp that describes when the File expires on the Backbone. An expired File cannot be fetched from the Backbone anymore. However, the cached version of the File on Connector and App will still be accesible.                     filename      string      The name of the file as it was on the device that uploaded it.      will be encrypted before sent to the Backbone              filesize      number      The size of the plaintext file in bytes.      will be encrypted before sent to the Backbone              mimetype      string      The mimetype of the file.      will be encrypted before sent to the Backbone              title      string      A human readable title of the file, which can be defined when uploading the File.      will be encrypted before sent to the Backbone              description      string | undefined      A human readable description of the file, which can be defined when uploading the File.      will be encrypted before sent to the Backbone              secretKey      string      The key that was used to encrypt the File.      saved only locally              isOwn      boolean      true if the File was created by yourself, false if it was created by someone else.      saved only locally              truncatedReference      string      A base64 encoded string containing all information necessary for another Identity to load the File. You can use it to share the File with someone else.      saved only locally      A File further has its content, of course. But since this is not a JSON property, it is not included in this table. You can download the content of the File separately.Local TypesIn addition to the types that are shared between Identities via the Backbone, there are certain types that only exist within one Identity. These types usually contain metadata about Content types that should not be transferred to other Identities. They are created and updated by the Consumption Layer.Currently there are three main Local types:  LocalRequest  LocalNotification  LocalAttributeEach of them further describes some sub types.This chapter explains all of those types, together with their properties.LocalRequestA LocalRequest contains the local metadata for a Request.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalRequest starts with the letters “REQ”. This way you can tell apart a LocalRequest ID from any other ID just by looking at the prefix.              isOwn      boolean      true if you sent the Request, false if you received it.              peer      string      The Identity that sent you the corresponding Request/that you sent the Request to.              createdAt      string      A timestamp that describes when the LocalRequest was created              status      LocalRequestStatus      The current status of the Request. See below for a list of all possible values.              content      Request      The actual Content object this LocalRequest defines the metadata for.              source      LocalRequestSource | undefined      Information about the Transport object with which the Request came in/was sent. This property is undefined if the Request is not sent yet.              response      LocalResponse | undefined      Metadata + Content object of the response. If there is no response yet, this property is undefined.      LocalRequestStatusDepending on whether it is an incoming or an outgoing Request, there can be different statuses. The following state diagram shows which status exists in both cases and when there are transitions from one state to another:  Draft  This status only exists for outgoing Requests. It means that the LocalRequest was created, but not yet sent.  Open  In case of an outgoing Request, Open means that the Request was sent. The transition to Open happens automatically when you send the Request with a Message.  In case of an incoming Request, Open means that the LocalRequest was received.  DecisionRequired  After the prerequisites of the Request and all of its RequestItems were checked, a decision can be made. At first, the Decider Module tries to make an automatic decision. It therefore checks all LocalRequests in status DecisionRequired.  ManualDecisionRequired  If the Decider Module cannot make a decision, it moves the LocalRequest to ManualDecisionRequired. When the LocalRequest is in this status, it’s the User’s turn to decide whether they want to accept or reject the Request.  Decided  When the User or the Decider Module accepts or rejects the Request, the Response and ResponseItems are generated based on the passed parameters. This Response is saved in the response property of the LocalRequest, but not yet sent.  Completed  In case of an incoming Request, the Runtime Module listens to an Event saying that a Request moved to status Decided. It then checks on which way the Request was received (Message/RelationshipTemplate) and sends the Response on the corresponding way (by sending a message or creating a Relationship). After the Response was successfully sent, it moves the LocalRequest to Completed.  In case of an outgoing Request, the Runtime Module listens to the MessageReceivedEvent and checks the content of the sent Message for a Response. If there is one, it moves the corresponding LocalRequest to Completed.  Expired  When the timestamp in expiresAt of a Request is reached, the Request automatically moves to the status Expired.LocalRequestSourceWith the information in this type you can clearly identify the Transport object the Request was sent/received in. Currently there are only two possibilities: Message and Relationship Template.            Name      Type      Description                  type      “Message” | “RelationshipTemplate”      The type of Transport object the Request was sent/received in.              reference      string      The ID of the Transport object the Request was sent/received in.      LocalResponseWhen a LocalRequest is decided/received, a Local Response is generated, which contains the Response, together with some metadata.            Name      Type      Description                  createdAt      string      A timestamp that describes when the LocalResponse was created              content      Response      The actual Content object this Local Response defines the metadata for.              source      LocalResponseSource | undefined      Information about the Transport object with which the Response came in/was sent. This property is undefined if the Response is not sent/received yet.      LocalResponseSourceWith the information in this type you can clearly identify the Transport object the Response was sent/received in. Currently there are only two possibilities: Message and Relationship Change.            Name      Type      Description                  type      “Message” | “RelationshipChange”      The type of Transport object the Response was sent/received in.              reference      string      The ID of the Transport object the Response was sent/received in.      LocalNotificationA LocalNotification contains the local metadata for a Notification.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalNotification starts with the letters “NOT”. This way you can tell apart a LocalNotification ID from any other ID just by looking at the prefix.              isOwn      boolean      true if you sent the Notification, false if you received it.              peer      string      The Identity that sent you the corresponding Notification/that you sent the Notification to.              createdAt      string      A timestamp that describes when the LocalNotification was created              status      LocalNotificationStatus      The current status of the Notification. See below for a list of all possible values.              content      Notification      The actual Content object this LocalNotification defines the metadata for.              source      LocalNotificationSource      Information about the Transport object with which the Notification came in/was sent.              receivedByDevice      string | undefined      The ID of the device that received the Notification. For reasons of consistence, the Notification can only be processed by this device.      LocalNotificationStatusDepending on whether it is an incoming or an outgoing Notification, there can be different statuses.  Sent  This is the only valid status on sender side. If a Notification is sent and, therefore, a LocalNotification is created, its status will be set to Sent.  Open  Receiving a Notification, a LocalNotification is created with status Open.  Completed  After receiving a Notification, its items will be processed internally. If all processes finish successfully, the status of the LocalNotification will be set to Completed.  Error  If an error occurs while processing the items of a received Notification, the status of the LocalNotification will be set to Error.LocalNotificationSourceWith the information in this type you can clearly identify the Transport object the Notification was sent/received in. Currently, the only possibility for transmitting Notifications are Messages.            Name      Type      Description                  type      “Message”      The type of Transport object the Notification was sent/received in. So far, Notifications can only be transmitted via Messages.              reference      string      The id of the Transport object the Notification was sent/received in.      LocalAttributeA LocalAttribute contains the local metadata for an Attribute. There are three situations a LocalAttribute is created in the database:  The Identity maintains an Attribute about itself (e.g. sets its first name). We call such a LocalAttribute “RepositoryAttribute”.  The Identity shares an Attribute of itself with another Identity (e.g. sends it in a Request). In that case, a copy of the original LocalAttribute is created, where the shareInfo property is set.  The Identity receives an Attribute from another Identity (e.g. receives it in a Request). In that case a new LocalAttribute is created, where the shareInfo is set.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalAttribute starts with the letters “ATT”. This way you can tell apart a LocalAttribute ID from any other ID just by looking at the prefix.              parentId      string | undefined      If the Attribute referenced by this LocalAttribute is a component of a composite Attribute, the parentId property is set to the id of the composite Attribute. Example: if a LocalAttribute is created with the content StreetAddress, for each property of the StreetAddress an additional LocalAttribute is created. And each of these will have parentId set to the id of the LocalAttribute for the StreetAddress.              createdAt      string      A timestamp that describes when the LocalAttribute was created              content      IdentityAttribute | RelationshipAttribute      The actual Content object this LocalAttribute defines the metadata for.              succeeds      string | undefined      The ID of the LocalAttribute that succeeds the current one.              succeededBy      string | undefined      The ID of the LocalAttribute that is succeeded by the current one.              shareInfo      LocalAttributeShareInfo | undefined      Information about the peer this LocalAttribute was received from/shared with, as well as via which LocalRequest it was received/sent. If the LocalAttribute refers to a RepositoryAttribute, this property is undefined.      LocalAttributeShareInfoThe LocalAttributeShareInfo helps to keep track of how the LocalAttribute was received/sent, from whom it was received/who sent it, as well as which LocalAttribute it was copied from (in case of a shared IdentityAttribute). For example, this enables us to track back who we shared a certain IdentityAttribute with, so we are able to notify each of them when changing it. The Attribute can be either transmitted via Request or Notification. Hence, only one of requestReference and notificationReference can be set.            Name      Type      Description                  peer      string      The Address of the Identity the LocalAttribute was received from/shared with.              requestReference      string | undefined      The id of the LocalRequest the LocalAttribute was received in/sent with. If this is set, notificationReference must be undefined.              notificationReference      string | undefined      The id of the LocalNotification the LocalAttribute was received in/sent with. If this is set, requestReference must be undefined.              sourceAttribute      string | undefined      If the LocalAttribute is a copy of a RepositoryAttribute, then this property contains the id of the RepositoryAttribute.      LocalAttributeListenerA LocalAttributeListener is created when you accept an incoming Request with a RegisterAttributeListenerRequestItem. It is used to keep track of which Attribute Listeners currently exist and what they are listening for.            Name      Type      Description                  id      string      Unique identifier of this object. Remark: the ID of each LocalAttributeListener starts with the letters “ATL”. This way you can tell apart a LocalAttributeListener ID from any other ID just by looking at the prefix.              query      IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery      The query the Attribute that is listened to must match. Note that you cannot send a RelationshipAttributeQuery here, because it doesn’t make sense: by definition, both parties know about a RelationshipAttribute right from the beginning, because one party requests its creation, and the other one accepts it.              peer      string      The Address of the peer that requested the Attribute Listener.      Content TypesContent Types can be seen as a data contract between Identities. The medium through which this data is exchanged are the Transport types (e.g. Messages, Tokens, …). This chapter shows all the Content types and describes their intended usage.RequestA Request allows you to ask another Identity to do something. What this “something” is depends on which of the so called RequestItems were added to the Request (e.g. CreateAttributeRequestItem, ReadAttributeRequestItem, …). The Request is then sent to the peer via Message or Relationship Template. The peer can then review the Request and decide whether they want to accept or reject it. And if they accept it, they can even choose which of the Items they want to accept. You can also put multiple Items into a group in order to ensure that they can only be accepted/rejected as a unit.            Name      Type      Description                  @type      “Request”                     id      string | undefined      Unique identifier of this object. This property is undefined if the Request is inside of a Relationship Template. Remark: the ID of each Request starts with the letters “REQ”. This way you can tell apart a Request ID from any other ID just by looking at the prefix.              title      string | undefined      An optional, human readable title for the Request.              description      string | undefined      An optional, human readable description for the Request.              expiresAt      string | undefined      A timestamp that describes when the Request expires on the Backbone. An expired Request cannot be fetched from the Backbone anymore. However, the cached version of the Request on Connector and App will still be accesible.              items      (RequestItemGroup | \*RequestItem)[]      An array of RequestItems and Groups that are part of the Request. There must be at least one Item or Group per Request.              metadata      string | undefined      Optional custom metadata that can be sent together with the Request. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Request.      RequestItemsRequestItems can be sent inside of a Request and specify what should be done when the Request is accepted.AuthenticationRequestItem            Name      Type      Description                  @type      &quot;AuthenticationRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ConsentRequestItem            Name      Type      Description                  @type      &quot;ConsentRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              consent      string      The textual consent the user needs to give. This is different to the title and description of the RequestItem, as the consent would be the actual statement the user agrees to.              link      string | undefined      A valid URL linking to a website which contains more information, like the EULA or privacy terms.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      CreateAttributeRequestItem            Name      Type      Description                  @type      &quot;CreateAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to create for the peer within the Identity of the peer.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      FreeTextRequestItem            Name      Type      Description                  @type      &quot;FreeTextRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              freeText      string      The free text you want to send to the peer.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ProposeAttributeRequestItem            Name      Type      Description                  @type      &quot;ProposeAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.              query      IdentityAttributeQuery | RelationshipAttributeQuery | IQLQuery      The structured query of the Attribute the sender would like to receive.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ReadAttributeRequestItem            Name      Type      Description                  @type      &quot;ReadAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              query      IdentityAttributeQuery | RelationshipAttributeQuery | ThirdPartyRelationshipAttributeQuery | IQLQuery      The structured query of the Attribute the sender would like to receive.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      RegisterAttributeListenerRequestItem            Name      Type      Description                  @type      &quot;RegisterAttributeListenerRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              query      IdentityAttributeQuery | ThirdPartyRelationshipAttributeQuery      The structured query of the Attribute the sender would like to query.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      ShareAttributeRequestItem            Name      Type      Description                  @type      &quot;ShareAttributeRequestItem&quot;      Specifies the type of the RequestItem for internal processing.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to share. This is not the LocalAttribute but the content data structure of the Attribute. The owner of the Attribute which should be shared can only be the sender Identity.              sourceAttributeId      string      The id of the LocalAttribute which is the source of the shared Attribute. This will be used later to reference the sourceAttribute from its shared copy.              title      string | undefined      An optional, human readable title for the RequestItem.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      The metadata property can be used to provide arbitrary JSON content by the sender of the request. The metadata is not processed by enmeshed. It is a great way to use your own process descriptors at the time of sending the request which helps you identify the correct internal process at the time of receiving the response.              mustBeAccepted      boolean      The mandatory mustBeAccepted property is used to differentiate between required and optional RequestItems within the Request. In other words, if the peer Identity may or may not decide to ignore this specific RequestItem. If set to true, the peer cannot accept the Request without accepting this item. For example, some Attributes are mandatory for the business process and thus the respective RequestItems must be accepted (mustBeAccepted = true). A consent to a newsletter is optional and thus only can be accepted (mustBeAccepted = false). Keep in mind that if the RequestItem is inside of a RequestItem Group, then this flag takes effect only when the Group is accepted. So as long as the Group is not accepted, the Item does not have to be accepted either.              requireManualDecision      boolean | undefined      To block the automated acceptance of Requests, the requireManualDecision property can be set to true. The default is, that each RequestItem may be automatically processed on the peer side. If the sender would like to have an enforced manual acceptance step the requireManualDecision property can be set to true.      RequestItemGroup            Name      Type      Description                  @type      &quot;RequestItemGroup&quot;                     title      string | undefined      An optional, human readable title for the RequestItem Group.              description      string | undefined      An optional, human readable description for the RequestItem.              metadata      object | undefined      Optional metadata that can be sent together with this RequestItem. The intended usage is the same as of the metadata property of the Request.              mustBeAccepted      boolean      If set to true, then this RequestItem Group has to be accepted when the Request is accepted.              items      *RequestItem[]      The items inside of this Group. There has to be at least one RequestItem per Group. Note that we do not support nested Groups at the moment. If you need this feature, you can raise a feature request.      Response            Name      Type      Description                  @type      &quot;Response&quot;                     result      &quot;Accepted&quot; | &quot;Rejected&quot;      Whether the Response was accepted or rejected by the recipient of the Request.              requestId      string      The id of the Request this Response belongs to. The Sender of the Request needs this information to map the Response to the corresponding Request.              items      (ResponseItemGroup\|ResponseItem)[]      An array of Response Items and Groups that are part of the Response. For each RequestItem (Group) of the Request, there must be one Response Item (Group) in the Response. Note that the indices have to be the same for matching Request and Response Items.      ResponseItemsResponse Items are sent inside of a Response. They contain the response data that is sent by the recipient of the Request. There are three different kinds of Response Items: AcceptResponseItem, RejectResponseItem and ErrorResponseItem. Depending on the actual RequestItem, there can be different derivations of these three items. For example, in case of a CreateAttributeRequestItem, there is a special CreateAttributeAcceptResponseItem, while for an AuthenticationRequestItem, the AcceptResponseItem can be used, because there is no additional information necessary next to whether it was accepted or rejected.AcceptResponseItem            Name      Type      Description                  @type      &quot;AcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.      CreateAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;CreateAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the created LocalAttribute.      FreeTextAcceptResponseItem            Name      Type      Description                  @type      &quot;FreeTextAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              freeText      string      The free text that is used to answer the RequestItem.      ProposeAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;ProposeAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the created LocalAttribute.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute to propose for the peer as the queried Attribute.The owner of the Attribute which is proposed can only be the recipient Identity.      ReadAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;ReadAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the returned LocalAttribute.              attribute      IdentityAttribute | RelationshipAttribute      The IdentityAttribute or RelationshipAttribute that will be shared to the peer.      RegisterAttributeListenerAcceptResponseItem            Name      Type      Description                  @type      &quot;RegisterAttributeListenerAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              listenerId      string      The id of the created AttributeListener.      ShareAttributeAcceptResponseItem            Name      Type      Description                  @type      &quot;ShareAttributeAcceptResponseItem&quot;      The type of the ResponseItem.              result      &quot;Accepted&quot;      The only possible value here is the string &quot;Accepted&quot;.              attributeId      string      The id of the shared LocalAttribute.      RejectResponseItem            Name      Type      Description                  @type      &quot;RejectResponseItem&quot;      The type of the ResponseItem.              result      &quot;Rejected&quot;      The only possible value here is the string &quot;Rejected&quot;.              code      string | undefined      A code telling the sender about the reason for the rejection.              message      string | undefined      A human readable message with details about the rejection.      ErrorResponseItemThe ErrorResponseItem is only created by the enmeshed Runtime, in case something happens which hinders you from further processing of the RequestItem. It will never be created manually. The properties are:            Name      Type      Description                  @type      &quot;ErrorResponseItem&quot;      The type of the ResponseItem.              result      &quot;Error&quot;      The only possible value here is the string &quot;Error&quot;.              code      string      An error code telling the sender about the kind of error that occurred.              message      string      A human readable error message with details about the error.      ResponseItemGroup            Name      Type      Description                  @type      &quot;ResponseItemGroup&quot;                     items      ResponseItem[]      The items inside of this Group. For each RequestItem of the RequestItem Group, there must be one Response Item in the Response Item Group. Note that the indices have to be the same for matching Request and Response Items.      ResponseWrapperThe ResponseWrapper is a wrapper around the Response that is sent by the recipient of the Request. It contains the Response itself, but also some additional information that is required for the Request to be processed correctly.            Name      Type      Description                  @type      &quot;ResponseWrapper&quot;                     requestId      string      The id of the Request this Response belongs to.              requestSourceReference      string      The reference to the Message or RelationshipTemplate the Request was received with.              requestSourceType      &quot;Message&quot; | &quot;RelationshipTemplate&quot;      Specifies if the Request was transferred via Message or RelationshipTemplate.              response      Response      The Response that is sent by the recipient of the Request.      NotificationNotifications provide you with the possibility to notify a peer about something, e.g. the succession of one of your Attributes.However, unlike Requests they don’t offer the option to make a decision whether or not they want to accept this change.In the example of Attribute succession, the peer can not decide to accept or reject the updated value, but is simply informed about it.            Name      Type      Description                  @type      &quot;Notification&quot;                     id      string      Unique identifier of this object. Remark: the ID of each Notification starts with the letters “NOT”. This way you can tell apart a Notification ID from any other ID just by looking at the prefix.              items      NotificationItem[]      An array of NotificationItems that are part of the Notification. There must be at least one Item per Notification.      NotificationItemsNotificationItems are sent inside a Notification and specify which processes should be triggered when receiving the Notification.PeerSharedAttributeSucceededNotificationItemA PeerSharedAttributeSucceededNotificationItem will be sent, if an Attribute, a peer shared with you, was succeeded by them and they choose to notify you about it.Internally, the succeeded version will then be created at your side as successor for your previously received Attribute.            Name      Type      Description                  @type      &quot;PeerSharedAttributeSucceededNotificationItem&quot;                     predecessorId      string      The id of the LocalAttribute that was succeeded              successorId      string      The id of the LocalAttribute it was succeeded by              successorContent      IdentityAttribute | RelationshipAttribute      The updated content of the LocalAttribute      AttributesAn Attribute is some piece of information about an Identity itself (e.g. its name, address, birth date, etc.) or about an Identity in the context of a Relationship (e.g. the customer id the of the user the Relationship). Since the two scenarios differ quite a lot, there are two different types for them: IdentityAttribute and RelationshipAttribute.IdentityAttributeIdentityAttributes describe an Identity itself. Their values are strongly normalized. There is a list of available values here.            Name      Type      Description                  @type      &quot;IdentityAttribute&quot;                     owner      string      The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.              validFrom      string | undefined      The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.              validTo      string | undefined      The date until this Attribute is valid. Could be in the past if the Attribute is already expired.              value      IdentityAttributeValue      The Attribute’s value.              tags      string[] | undefined      To specify additional information.      RelationshipAttributeRelationshipAttributes describe an Identity in the context of a Relationship. While there are some types that can be used as a value for a RelationshipAttribute, these types are rather generic (e.g. ProprietaryString, ProprietaryInteger, …).            Name      Type      Description                  @type      &quot;RelationshipAttribute&quot;                     owner      string      The Identity that owns this Attribute. Only the owner of an Attribute is allowed to change it after its creation.              validFrom      string | undefined      The date from which on the Attribute is valid. Could be in the future if the Attribute is not yet valid.              validTo      string | undefined      The date until this Attribute is valid. Could be in the past if the Attribute is already expired.              key      string      An arbitrary key that is set by the creator of this Attribute. It is used to identify the Attribute in a query, especially by a third party. Example: you could set something like customerId in case of a customer id.              isTechnical      boolean | undefined      Defines whether the RelationshipAttribute contains data that is actually relevant for the user (isTechnical=false) or whether it should be hidden in the UI (isTechnical=true).              value      RelationshipAttributeValue      The Attribute’s value.              confidentiality      &quot;public&quot; | &quot;protected&quot; | &quot;private&quot; | When this property is set to &quot;private&quot;, it means that third parties are not able to query this RelationshipAttribute. It therefore only exists in the Relationship it was created in. If the confidentiality is &quot;protected&quot;, third parties can query the RelationshipAttribute, but the App shows a warning saying that you should only share it with someone you trust. If the confidentiality is &quot;public&quot;, everybody can query the Attribute, without anything special to happen.             AttributeQueriesOne of the main features of enmeshed is sharing Attributes. For this, an Identity either proactively sends its Attributes to a peer. Or, if let’s say a company wants to know the birth date of its customer, it can ask for it. Depending on the exact use case, the latter can be achieved with one of a bunch of RequestItems, like for example a ReadAttributeRequestItem, or a CreateAttributeListenerRequestItem. All of them have in common that they define a query property, which contains either an IdentityAttributeQuery or a RelationshipAttributeQuery.IdentityAttributeQueryAn IdentityAttributeQuery is used to query for IdentityAttributes. For that, it defines the following properties:            Name      Type      Description                  @type      &quot;IdentityAttributeQuery&quot;                     validFrom      string | undefined      The start date of the time frame the returned Attribute should be valid in.              validTo      string | undefined      The end date of the time frame the returned Attribute should be valid in.              valueType      string      The type of value that should be queried, e.g. &quot;StreetAddress&quot;, &quot;BirthDate&quot; or &quot;Nationality&quot;.              tags      string[] | undefined      To specify additional information.      You can only query IdentityAttributes owned by the recipient of the query.RelationshipAttributeQueryThere are cases in which you want to query some data from your peer that is not an IdentityAttribute. An example for this is when an electricity provider asks for the electric meter number of a new customer. Since this information is only relevant in the context of the Relationship, an IdentityAttribute wouldn’t make any sense here. That’s why you would send a RelationshipAttributeQuery. Its properties are:            Name      Type      Description                  @type      &quot;RelationshipAttributeQuery&quot;                     validFrom      string | undefined      The start date of the time frame the returned Attribute should be valid in.              validTo      string | undefined      The end date of the time frame the returned Attribute should be valid in.              key      string      The key of the RelationshipAttribute that should be queried.              owner      string      The owner of the queried RelationshipAttribute.              attributeCreationHints      RelationshipAttributeCreationHints      Contains information about the value that will be created, like the value type or its confidentiality.      RelationshipAttributeCreationHints            Name      Type      Description                  title      string      A short text describing the purpose of the Attribute that is about to be created.              description      string | undefined      A long text describing the purpose of the Attribute that is about to be created.              valueType      string      The value type of the Attribute to be created (e.g. &quot;ProprietaryInteger&quot;, &quot;ProprietaryString&quot;, …)              confidentiality      &quot;public&quot; |&quot;protected&quot; |&quot;private&quot;      The confidentiality of the Attribute to be created. See RelationshipAttribute for a more detailed description of confidentialities.              valueHints      ValueHints | undefined      Hints for validating the value, e.g. a regular expression or a min/max length.      ValueHints            Name      Type      Description                  @type      &quot;ValueHints&quot;                     editHelp      string | undefined      A help text you can use to describe the purpose of the Attribute.              min      number | undefined      In case of a string: the minimum length of the string. In case of an integer: the minimum value.              max      number | undefined      In case of a string: the maximum length of the string. In case of an integer: the maximum value.              pattern      string | undefined      A regular expression that is used to validate the value. Only applicable if the value is a string.              values      ValueHintsValue[] | undefined      An array of allowed values.              defaultValue      string | number | boolean | undefined      The default value that is used if no value is provided.              propertyHints      Record&lt;string, ValueHints&gt; | undefined      A set of Value Hints of all properties. The key is the name of the property and the value a ValueHints object. Only applicable if the value is complex.      ValueHintsOverrideValueHintsOverride has the same properties as ValueHints, except that all of them are optional. This type is used for some RelationshipAttribute valuesValueHintsValue            Name      Type      Description                  key      string | number | boolean      The actual value.              displayName      string      How the value should be displayed on the UI.      ThirdPartyRelationshipAttributeQueryIf you want to query Attributes the user has in the context of a Relationship with a third party, you can use the ThirdPartyRelationshipAttributeQuery. An example would be the query for the number of a bonus card managed by another company (like Payback). A ThirdPartyRelationshipAttributeQuery has the following properties:            Name      Type      Description                  @type      &quot;ThirdPartyRelationshipAttributeQuery&quot;                     validFrom      string | undefined      The start date of the time frame the returned Attribute should be valid in.              validTo      string | undefined      The end date of the time frame the returned Attribute should be valid in.              key      string      The key of the RelationshipAttribute that should be queried.              owner      string      The owner of the queried RelationshipAttribute. Can be an empty string (&quot;&quot;), if the owner is unknown or you are querying from multiple thirdParties that could own the attribute.              thirdParty      string[]      The Address of the third parties the RelationshipAttribute should be queried from.      IQLQueryIf you want to query Attributes by their content, you can use the IQLQuery.It allows you to specify conditions the Attribute must match and which may be chained using binary operations.Every property of the Attribute’s content may be queried, independend of whether it is nested or not, by formulating it as a lowercase key.Furthermore, using an uppercase term is a shortcut for comparing the term to the value.@type property and using # refers to the tag property.For example, if you want to query a StreetAddress in Germany which is tagged as [Primary Address] the queryString would be StreetAddress &amp;&amp; value.country.value == Germany &amp;&amp; #&quot;Primary Address&quot;.If no corresponding Attribute exists at the peer’s side, you are given the possibility to add attributeCreationHints, suggesting to create an Attribute which matches a specific valueType and optionally tags.            Name      Type      Description                  @type      &quot;IQLQuery&quot;                     queryString      string      The condition the attribute must fulfill. It is made up of terms of the form &lt;key&gt; &lt;operator&gt; &lt;value&gt;, which may be chained using binary operations. Uppercase expressions refer to the property value@type and # to tags.              attributeCreationHints      IQLQueryCreationHints | undefined      Suggestions for creating a new Attribute, if the query returns empty.      IQLQueryCreationHints            Name      Type      Description                  valueType      AttributeValues.Identity.TypeName      The value.@type of the Attribute, which should be created.              tags      string[] | undefined      The tags for the Attribute, which should be created.      RelationshipTemplateContentTheoretically you can send any kind of data in a Relationship Template. However, if your peer uses the enmeshed App, it will only be able to process Relationship Templates that contain a RelationshipTemplateContent, which looks like this:            Name      Type      Description                  @type      &quot;RelationshipTemplateContent&quot;                     title      string | undefined      An optional, human readable title that should be rendered in the UI.              metadata      object | undefined      Optional custom metadata that can be sent together with the Relationship Template. This property is meant purely for developers who integrate with enmeshed. They can write for example some kind of key into this property, which can be used later to identify the content of this Template.              onNewRelationship      Request      The Request that should pop up to the user in case there is no Relationship yet. In this Request you can send Attributes of yourself the user needs to in order to know who’s Template it is (e.g. company name, address, …), as ask for Attributes of the user you need to know in the Relationship, or send some information you already know about the user, so it can be saved in its wallet (e.g. the customer id).              onExistingRelationship      Request | undefined      The Request that should pop up to the user in case a Relationship already exists. An example usage is a Request with an AuthenticationRequestItem for the sake of two-factor authentication.      RelationshipCreationChangeRequestContentThe naming on this one in combination with its response property is a bit confusing. Even though the RelationshipCreationChangeRequestContent contains the word “Request”, it has a response property.This is because in the context of Relationships, there are Relationship Changes, which have a request and a response property. But caution: these have nothing to do with the Content-types Request and Response.            Name      Type      Description                  @type      &quot;RelationshipCreationChangeRequestContent&quot;                     response      Response      The Response to the Request that was contained in the RelationshipTemplateContent (either in the onExistingRelationship property or in the onNewRelationship property).      MailA Mail can be sent as the content of a Message. It is comparable with the classic email, so its properties should not contain any surprise.            Name      Type      Description                  @type      &quot;Mail&quot;                     to      string[]      The enmeshed Addresses of the main recipients of this Mail.              cc      string[] | undefined      The enmeshed Addresses that should receive a copy of this Mail, additionally to the ones specified in to.              subject      string      The subject of the Mail.              body      string      The body of the Mail.      ConsumptionDecideRequestItemParametersIn order to answer a Request, the Response must be formulated appropriately.As an easier interface to do so various DecideRequestItemParameters are provided.If you want to reject any RequestItem, you must use the RejectRequestItemParameters.If you want to accept a RequestItem, however, depending on its kind you might need different parameters.For example, an AuthenticationRequestItem can be accepted using the AcceptRequestItemParameters, but for a FreeTextRequestItem AcceptFreeTextRequestItemParameters are required.RejectRequestItemParameters            Name      Type      Description                  accept      &quot;false&quot;      The only possible value here is the string “false”.              code      string | undefined      A code telling the sender about the reason for the rejection.              message      string | undefined      A human readable message with details about the rejection.      AcceptRequestItemParameters            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.      AcceptFreeTextRequestItemParameters            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              freeText      string      The free text that is used to answer the RequestItem.      AcceptProposeAttributeRequestItemParametersThe parameters to accept a ProposeAttributeRequestItem with an existing Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              attributeId      string      The id of the existing LocalAttribute.      The parameters to accept a ProposeAttributeRequestItem with a new Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              attribute      IdentityAttribute | RelationshipAttribute      The new LocalAttribute.      AcceptReadAttributeRequestItemParametersThe parameters to accept a ReadAttributeRequestItem with an existing Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              existingAttributeId      string      The id of the existing LocalAttribute.      The parameters to accept a ReadAttributeRequestItem with a new Attribute.            Name      Type      Description                  accept      &quot;true&quot;      The only possible value here is the string “true”.              newAttribute      IdentityAttribute | RelationshipAttribute      The new LocalAttribute.      ">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -717,6 +717,7 @@ <h2 id="message">Message</h2>
   <li><a href="#mail"><code class="language-plaintext highlighter-rouge">Mail</code></a></li>
   <li><a href="#request"><code class="language-plaintext highlighter-rouge">Request</code></a></li>
   <li><a href="#responsewrapper"><code class="language-plaintext highlighter-rouge">ResponseWrapper</code></a></li>
+  <li><a href="#notification"><code class="language-plaintext highlighter-rouge">Notification</code></a></li>
 </ul>
 
 <p>You can read more details about each of these in the corresponding sections of the “Content Types” chapter.</p>
@@ -742,7 +743,7 @@ <h2 id="message">Message</h2>
     <tr>
       <td>content</td>
       <td><code class="language-plaintext highlighter-rouge">unknown</code></td>
-      <td>The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either <code class="language-plaintext highlighter-rouge">Mail</code>, <code class="language-plaintext highlighter-rouge">Request</code> or <code class="language-plaintext highlighter-rouge">Response</code>. Otherwise feel free to insert whatever you want or need.</td>
+      <td>The content of the Message. You can add whatever you want here. However, if it is intended for a User of the enmeshed App, use either <code class="language-plaintext highlighter-rouge">Mail</code>, <code class="language-plaintext highlighter-rouge">Request</code>, <code class="language-plaintext highlighter-rouge">Response</code> or <code class="language-plaintext highlighter-rouge">Notification</code>. Otherwise feel free to insert whatever you want or need.</td>
       <td>will be encrypted before sent to the Backbone</td>
     </tr>
     <tr>
@@ -3003,7 +3004,7 @@ <h4 id="acceptreadattributerequestitemparameters">AcceptReadAttributeRequestItem
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/delete-identity-from-enmeshed.html b/integrate/delete-identity-from-enmeshed.html
index 01ea62e1d..e17eb8104 100644
--- a/integrate/delete-identity-from-enmeshed.html
+++ b/integrate/delete-identity-from-enmeshed.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Delete Identity from enmeshed">
     <meta itemprop="description" content="This feature (or parts of it) and its documentation are still in developmentPlease note that this section describes features which are currently in development, and we are actively working on enhancing your experience.Thus you could encounter unfinished APIs, incompatible changes, mistakes or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this feature, e.g. by filing an issue in our feedback repository.FlowEvery Identity has the option of deleting itself from the Backbone. There are three options to delete the Identity:  Actively trigger the deletion process by use of the App or the Connector. There is no further approval of the Identity required with this option.  Actively trigger the deletion process by use of support tickets/e-mails to the Backbone operator (as required by GDPR). An active approval of the Identity is required with this option, as the Backbone must ensure, that the support ticket creator is the owner of the Identity. As there is the need of a push notification channel for this, the Connector does not have the ability to trigger the Identity deletion over the Backbone.  Be inactive for a long period of time: Depending on the Backbone environment, deleting inactive Identities is possible.All peers of the to-be-deleted Identity are informed about this deletion, otherwise they will end up getting Backbone errors that the Identity is no longer available.Usually Identity deletion takes place with a grace period in which the owner of the Identity can revoke the decision to be deleted. The identity deletion can be triggered by the runtime.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -391,7 +391,7 @@ <h1 id="flow">Flow</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/error-codes.html b/integrate/error-codes.html
index 0fcf6c509..35a166be9 100644
--- a/integrate/error-codes.html
+++ b/integrate/error-codes.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Error Codes">
     <meta itemprop="description" content="Please find a list of enmeshed error codes below. Most often the errors occur on invalid input or actions. If you happen to find unexpected errors while using enmeshed or cannot deduce the reason for your error, please report it in the enmeshed Issue Tracker.            ErrorCode      Description                  error.connector.http.methodNotAllowed       This method is not supported for the requested resource.              error.connector.http.notAcceptable       The requested resource is capable of generating only content not acceptable according to the Accept headers sent in the request.              error.connector.http.routeDoesNotExist       The requested route does not exist.              error.connector.unauthorized       Unauthorized.              error.connector.validation.invalidJsonInPayload       The given payload is not a valid json object.              error.consumption.attributes.cannotSucceedAttributesWithAParent       The Attribute you want to succeed has a parent. You cannot succeed Attributes with a parent. Instead, succeed the parent, which will implicitly succeed all its children. For example, if you want to change a HouseNumber, you should succeed the Address it is part of.              error.consumption.requests.decide.validation.invalidNumberOfItems       The Request and the Response item count is different.              error.consumption.requests.decide.validation.itemAcceptedButParentNotAccepted       You accepted an item of a Request or RequestItemGroup, but you rejected the parent. If you accept a RequestItem, you need to accept all parents up to the root.              error.consumption.requests.decide.validation.mustBeAcceptedItemNotAccepted       The Request was accepted but an item that was flagged as ‘mustBeAccepted’ was not accepted.              error.consumption.requests.decide.validation.requestItemAnsweredAsRequestItemGroup       You answered a RequestItem as a RequestItemGroup.              error.consumption.requests.decide.validation.requestItemGroupAnsweredAsRequestItem       You answered a RequestItemGroup as a RequestItem.              error.consumption.requests.invalidRequestItem       The given RequestItem is invalid.              error.consumption.requests.servalErrorDuringRequestItemProcessing       A serialization / validation error occurred during the RequestItem processing. Check the type definitions of your used types.              error.consumption.requests.unexpectedErrorDuringRequestItemProcessing       An unknown error occurred during the RequestItem processing.              error.runtime.alreadyInitialized       The runtime is already initialized. The init method can only be executed once.              error.runtime.alreadyStarted       The runtime is already started. You should stop it first for a restart.              error.runtime.cacheEmpty       The cache of the requested entity is empty.              error.runtime.challenges.invalidChallenge       The challengeString is invalid.              error.runtime.challenges.invalidSignature       The signature is invalid.              error.runtime.files.invalidReference       The given reference is not valid. The reference for a file must start with ‘VE9L’ or ‘RklM’.              error.runtime.invalidTokenContent       The given token has an invalid content for this route.              error.runtime.messages.fileNotFoundInMessage       The requested file was not found in the given message.              error.runtime.notInitialized       The runtime is not initialized. You must run init before you can start or stop the runtime.              error.runtime.notStarted       The runtime is not started. You can only stop the runtime if you executed start before.              error.runtime.notSupported       The requested feature is not supported.              error.runtime.recordNotFound       The requested Record was not found. Make sure the ID exists and the record is not expired.              error.runtime.relationshipTemplates.cannotCreateQRCodeForPeerTemplate       You cannot create a QRCode for a peer template.              error.runtime.relationshipTemplates.cannotCreateTokenForPeerTemplate       You cannot create a token for a peer template.              error.runtime.relationshipTemplates.invalidReference       The given reference is not valid. The reference for a relationship template must start with ‘VE9L’ or ‘VE9L’.              error.runtime.requestDeserialization       There was an error during the request deserialization.              error.runtime.servalError       A serialization / validation error occurred.              error.runtime.startup.noActiveAccount       No AccountController could be found. You might have to login first.              error.runtime.startup.noActiveConsumptionController       No ConsumptionController could be found. You might have to login first.              error.runtime.startup.noActiveExpander       No DataViewExpander could be found. You might have to login first.              error.runtime.unknown       An unknown error occurred. Check the error message or the stack trace to learn more.              error.runtime.unknownType       The given ‘@type’ could not be found during the deserialization.              error.runtime.validation.invalidPayload       The given combination of properties in the payload is not supported.              error.runtime.validation.invalidPropertyValue       A property of the given payload is invalid.              error.transport.challenges.challengeTypeRequiresRelationship       The challenge type ‘Relationship’ requires a relationship for the challenge creation.              error.transport.datawallet.currentBiggerThanTarget       The current datawallet version is bigger than the target version.              error.transport.datawallet.encryptedPayloadIsNoCipher       The given encrypted payload is no cipher.              error.transport.datawallet.insufficientSupportedDatawalletVersion       The current SupportedDatawalletVersion is too low to perform the requested operation.              error.transport.datawallet.unsupportedModification       A collection was recieved in a CacheChanged datawallet modification but is not supported in the current version of the library.              error.transport.devices.alreadyOnboarded       The device that you try to create an onboarding code for has already been onboarded.              error.transport.files.cipherMismatch       The actual hash of the cipher does not match the given cipherHash. Something went wrong while storing/transmitting the file.              error.transport.files.fileContentUndefined       The given files content is undefined.              error.transport.files.invalidMetadata       The metadata of the file is invalid.              error.transport.files.invalidTruncatedReference       The given truncated reference is invalid.              error.transport.files.maxFileSizeExceeded       The given file content size exceeds the max file size the backbone accepts.              error.transport.files.plaintextHashMismatch       The actual hash of the plaintext does not match the given plaintextHash. Something went wrong while encrypting/decrypting the file.              error.transport.general.baseUrlNotSet       The baseUrl was not set.              error.transport.general.platformClientIdNotSet       The platform clientId was not set.              error.transport.general.platformClientInvalid       The combination of platform clientId and clientSecret is invalid.              error.transport.general.platformClientSecretNotSet       The platform clientSecret was not set.              error.transport.identity.realmLength       The given realm is not 3 characters long.              error.transport.messages.noMatchingRelationship       A Relationship with the given address does not exist.              error.transport.messages.ownAddressNotInList       The recipients list of a message didn’t contain an entry for the own address. This message should not have been received.              error.transport.messages.plaintextMismatch       The own address was not named as a recipient within the signed MessagePlaintext. For example this can be caused by a replay attack.              error.transport.messages.signatureListMismatch       The signature list didn’t contain an entry for a given address.              error.transport.messages.signatureNotValid       The digital signature on a message for a peer key is invalid. An impersonination attack might be the cause of this.              error.transport.notSupported       The requested method is not yet supported.              error.transport.recordNotFound       The requested record was not found.              error.transport.relationships.wrongChangeStatus       The relationship change has the wrong status to run the requested operation.              error.transport.secrets.secretNotFound       No secret was found for a specific type.              error.transport.secrets.wrongBaseKeyType       The given secret type is not supported!              error.transport.signatureNotValid       A signature is invalid.              error.transport.tokens.invalidTokenContent       The given token content is invalid.      ">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -652,7 +652,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/event-introduction.html b/integrate/event-introduction.html
index 8357c8148..409f61a20 100644
--- a/integrate/event-introduction.html
+++ b/integrate/event-introduction.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Event introduction">
     <meta itemprop="description" content="Connecting an external system with the enmeshed Connector, the main communication is performed by addressing the Connector’s REST API.This way, processes can be initiated by the organization’s backend service or data can be requested from the Connector.In addition, events offer the possibility for the Connector to actively give feedback to the external system.Thus, a bidirectional communication is established.What is an event?Events are predefined datastructures used within enmeshed to communicate a significant change of an entity’s state.They are heavily used internally by the enmeshed Runtime, but can also be propagated by the Connector to external systems.Thus, these systems don’t have to perform long polling, in order to receive changes, but are actively informed once they occur.This is not only more efficient, also, its is safer, since it keeps you updated about all changes of interest.Working with events allows to determine routines, that are executed whenever a specific event arises, called handlers.An overview of the Connector events that may occur is given in the corresponding section.Motivation for using eventsAs an exemplary process of how working with events can benefit your mode of operation, we look at the procedure of exchanging Messages.Procedure without eventsFirstly, we consider the case without using events.To send a Message, the external system posts the corresponding request to the REST API of the Connector.Then, it regularly fetches its state, until a response is received.This might take many cycles, depending on the refresh rate, and implies a delay between the time the response is received by the Connector and the external system.Procedure with eventsIn contrast, if you work with events, as soon as the Connector successfully sent your Message, a transport.messageSent event will be transmitted to your system as a confirmation.Awaiting the response, no long polling is necessary, since the Connector actively sends a transport.messageReceived event, containing the answer, once it is received.Modules to receive eventsIn order to receive events, the Connector needs to be synchronized with the Backbone.This can be automated using the Sync Module.Fetching changes from the Backbone regularly, it forwards the received events to Modules that are configured to process them, e.g. AMQP Publisher, PubSub Publisher or Webhooks.Working with message brokers has the advantage that events are conserved, even in case of a downtime of the recipient.Thus, we recommend to work with a message broker module like AMQP or PubSub instead of Webhooks.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -417,7 +417,7 @@ <h2 id="modules-to-receive-events">Modules to receive events</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/faq.html b/integrate/faq.html
index 128be447a..ec8bdc896 100644
--- a/integrate/faq.html
+++ b/integrate/faq.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="FAQ">
     <meta itemprop="description" content="Welcome to our FAQ page! Here, you’ll find answers to the most common questions about enmeshed. If you’re looking for quick and straightforward information, you’ve come to the right place.Common questionsWhat is enmeshed?A description of enmeshed can be found on the main pageTechnical QuestionsWhen I scan the QR I get the error: “error.relationshipTemplateProcessedModule.raltionshipTemplateNotSupported”It seems the wrapper RelationshipTemplateContent around the RequestItems in the RelationshipTemplate is missing. If the Template is intended for a User of the enmeshed App (which is the primary use-case), the wrapper RelationshipTemplateContent has to be used.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -385,7 +385,7 @@ <h2 id="when-i-scan-the-qr-i-get-the-error-errorrelationshiptemplateprocessedmod
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/integration-example.html b/integrate/integration-example.html
index 2c6b34d72..7a08b0e07 100644
--- a/integrate/integration-example.html
+++ b/integrate/integration-example.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Integration example">
     <meta itemprop="description" content="In this tutorial we go through the basic steps necessary to establish a Relationship to another Identity and send Messages between two Identities with an existing Relationship.This will create a better understanding of these processes, which will help you automating them for your organization.It is not mandatory to have an own Connector installed.The following steps include small interactive pieces of the Connector’s API documentation that, when executed, fire Requests on a Connector we provide for testing purposes.If you would like to use it, start by checking the health of the Connector:Nevertheless, you are welcome to use your own Connector, either with a REST client (e.g. Insomnia or Postman) or by using the RapiDoc documentation (/docs/rapidoc) hosted on your Connector.The payloads for the Requests that are sent during this tutorial contain placeholders marked with &lt;...&gt;.You need to replace them with values before you send the Requests.Prerequisites  If you want to use your own Connector for executing the examples:          Install the Connector      Make sure the Sync Module is disabled (because in this tutorial we will synchronize manually via the HTTP endpoint)      Make sure the docs are enabled for the documentation route to work      Get the API key that was configured during installation of the Connector (it needs to be sent in the X-API-KEY header of every HTTP Request)        You need the enmeshed App installed on your mobile device.Establishing RelationshipsIn order to communicate with another Identity, a Relationship to that Identity is required.Thus, in this first part of the tutorial you will learn how to establish a Relationship between your Connector and another Identity.In this example the other Identity will be an App.However, it could be another Connector, as well, e.g. if two companies want to exchange data securily without opening a port or network.The way we will establish the Relationship is via a RelationshipTemplate.This is created by the Connector and contains its display name, as well as the data it would like to receive from the other Identity.Then, the App user fills out all required information of the template and sends the Relationship Request to the Connector.It in turn accepts the Request, which results in the creation of a new Relationship.Connector: Create an AttributeFirstly, let’s create a display name for our Connector.While communicating with the other Identity in the subsequent steps, we will choose to share this display name.Technically, for this we need to create an IdentityAttribute with a value of type DisplayName for our Connector.To do so, execute POST /api/v2/Attributes with the following payload:{  &quot;content&quot;: {    &quot;@type&quot;: &quot;IdentityAttribute&quot;,    &quot;owner&quot;: &quot;&lt;your Connector&#39;s address&gt;&quot;,    &quot;value&quot;: {      &quot;@type&quot;: &quot;DisplayName&quot;,      &quot;value&quot;: &quot;Demo Connector of integration example&quot;    }  }}You can query the Connector’s address via the route /api/v2/Account/IdentityInfo. If you are using the Demo Connector of this Tutorial, the address is id134nJmN7E4Carb6KyRJyePVnXxVHEYQgWD.Corresponding interactive API docs excerpt:                    Save the id of the Attribute that you can find in the Response. You will need it in the next step.    Connector: Test your Request’s ValidityNext, we want to create a RelationshipTemplate, that can be used by the App to send a Relationship Request to our Connector.The content of the template can be widely configured, but for simplicity we will use a Request with just two RequestItemGroups in our example.On the one hand, we want to share an Attribute with the App, namely the display name of our Connector we created in the previous step.For this, we use a ShareAttributeRequestItem.On the other hand, we use ReadAttributeRequestItems to receive Attributes from the App.Let’s assume the Connector needs to know the given name and surname of its contact to create a Relationship and, additionally, offers the option to specify an e-mail address for communication.{  &quot;content&quot;: {    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;RequestItemGroup&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;Shared Attributes&quot;,        &quot;items&quot;: [          {            &quot;@type&quot;: &quot;ShareAttributeRequestItem&quot;,            &quot;mustBeAccepted&quot;: true,            &quot;attribute&quot;: {              &quot;@type&quot;: &quot;IdentityAttribute&quot;,              &quot;owner&quot;: &quot;&quot;,              &quot;value&quot;: {                &quot;@type&quot;: &quot;DisplayName&quot;,                &quot;value&quot;: &quot;Demo Connector of integration example&quot;              }            },            &quot;sourceAttributeId&quot;: &quot;&lt;the id of the attribute created above&gt;&quot;          }        ]      },      {        &quot;@type&quot;: &quot;RequestItemGroup&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;Requested Attributes&quot;,        &quot;items&quot;: [          {            &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,            &quot;mustBeAccepted&quot;: true,            &quot;query&quot;: {              &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,              &quot;valueType&quot;: &quot;GivenName&quot;            }          },          {            &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,            &quot;mustBeAccepted&quot;: true,            &quot;query&quot;: {              &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,              &quot;valueType&quot;: &quot;Surname&quot;            }          },          {            &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,            &quot;mustBeAccepted&quot;: false,            &quot;query&quot;: {              &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,              &quot;valueType&quot;: &quot;EMailAddress&quot;            }          }        ]      }    ]  }}Before we actually create the template, we want to ensure the validity of the Request and its items.Corresponding interactive API docs excerpt:Even though the Requests are validated during the RelationshipTemplate creation, you should not skip this step, as it gives you additional information in case of validation errors.Connector: Create a RelationshipTemplateIf the Response is successful, we can create the RelationshipTemplate.To do so, we use the content we just validated.Furthermore, we specify an expiration date, which is located in the future, and restrict the access to a single allocation.{  &quot;maxNumberOfAllocations&quot;: 1,  &quot;expiresAt&quot;: &quot;2024-12-31T00:00:00.000Z&quot;,  &quot;content&quot;: {    &quot;@type&quot;: &quot;RelationshipTemplateContent&quot;,    &quot;title&quot;: &quot;Connector Demo Contact&quot;,    &quot;onNewRelationship&quot;: {      // &lt;the value of the &#39;content&#39; property validated in the previous step&gt;    }  }}Corresponding interactive API docs excerpt:                    Save the id of the RelationshipTemplate that you can find in the Response. You will need it in the next step.    Connector: Create a QR Code for the RelationshipTemplateNow, to allow the App to retrieve the RelationshipTemplate, we create a QR Code, that can be scanned by the App.For this, execute the GET /api/v2/RelationshipTemplates/{id} route (Accept Header: image/png) and use the id of the RelationshipTemplate from the previous step as the value for id.Corresponding interactive API docs excerpt:App: Send a Relationship RequestOpen the created QR Code and start the enmeshed App. Depending on what you already did with the App, choose one of the following paths:  If this is the first time you use the App:          click on “Scan code”      hold the camera in front of the QR code        If you want to use a new profile:          click on the “+ New profile” button      click on “Scan code”      hold the camera in front of the QR code        If you want to use an existing profile:          select the existing profile      navigate to “Contacts”      click on “Add contact”      hold the camera in front of the QR code      All three paths should result in a screen similar to the one below, where you can see the information that you added as content to the RelationshipTemplate.Finally, fill out the required fields and click on “Add contact” to send the Relationship Request. This will create a new Relationship between the App and the Connector. This Relationship has the status Pending for now.Connector: Accept the Relationship RequestIn order to move the Relationship into the Active state, we now need to accept the Relationship Request with the Connector.To do so, we synchronize updates of the Backbone, which will fetch all changes that occurred since the last time this endpoint was executed.Corresponding interactive API docs excerpt:In the Response we will receive the created Relationship, which contains the corresponding RelationshipCreationChange.Example:{  &quot;result&quot;: {    &quot;messages&quot;: [],    &quot;relationships&quot;: [      {        &quot;id&quot;: &quot;RELmJj25x2bZW0VXzAiQ&quot;,        ...        &quot;status&quot;: &quot;Pending&quot;,        &quot;peer&quot;: &quot;id19Sy75wjCWhQSxsbMiGLn6iSBfWvQmot5b&quot;,        &quot;changes&quot;: [          {            &quot;id&quot;: &quot;RCHUwBw7BWlROPlEjb51&quot;,            ...            &quot;status&quot;: &quot;Pending&quot;,            &quot;type&quot;: &quot;Creation&quot;          }        ]      }    ]  }}                    Save the id of the Relationship (REL_________________), as well as the id of the first RelationshipChange (RCH_________________) in the changes array and use them as input to the PUT /api/v2/Relationships/{id}/Changes/{changeId}/Accept route. You can leave that Request body as it is.    Corresponding interactive API docs excerpt:Now the Relationship is in the Active state, so we can start to communicate with the opposite Identity, which we will do in the next part of this tutorial.For this, we will need the address of that Identity.It can be found in the Response, when accepting the Relationship.                    Save the peer property of the Response (id1_________________). You will need it in the next step.    Sending and Receiving MessagesAfter having established a Relationship with an Identity, we can start to exchange Messages.Enmeshed defines different types of Messages.In this tutorial we will focus on Messages of type Mail, which can be compared to a classic e-mail: it is possible to specify one or more recipients, a subject and a body, as well as to add attachments.Sending a Message with a ConnectorFirstly, we will send a Message from the Connector to the App.For this, we need the address of our peer, that we copied in the previous step, and insert it in the fields recipient and to.Further, the subject and body properties can be modified with some custom content.{  &quot;recipients&quot;: [&quot;id_________________________________&quot;],  &quot;content&quot;: {    &quot;@type&quot;: &quot;Mail&quot;,    &quot;to&quot;: [&quot;id_________________________________&quot;],    &quot;subject&quot;: &quot;Welcome&quot;,    &quot;body&quot;: &quot;Hello. We are pleased to welcome you as our customer.&quot;  }}Corresponding interactive API docs excerpt:After having sent the Message, you should receive a push notification on your phone.Open the enmeshed App, navigate to “Contacts” and select the Relationship.You should see the Message in the list.Tapping on it reveals more details.Receiving a Message with a ConnectorNext, we are going to send a Message from the App to the Connector.So, open the enmeshed App, navigate to “Contacts” and select your Relationship.Then, tap on “New Message”, enter a subject and body and tap on “Send”.In order to fetch the Message, we need to synchronize the Connector with the Backbone again.Corresponding interactive API docs excerpt:The Response should contain a Message with the content you entered in the App.What’s next?Now that you have successfully established a Relationship and exchanged Messages, you can further explore the enmeshed API. You can for example:  explore the enmeshed data model and learn more about the objects you used during this tutorial and the objects you will encounter in the future  learn how to send Requests over Messages with your established Relationship  dive deeper into creating and sending Requests over RelationshipTemplates">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -722,7 +722,7 @@ <h2 id="whats-next">What’s next?</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/process-received-enmeshed-onboarding-package-and-create-relationship.html b/integrate/process-received-enmeshed-onboarding-package-and-create-relationship.html
index 67f1ccf28..9804cc72c 100644
--- a/integrate/process-received-enmeshed-onboarding-package-and-create-relationship.html
+++ b/integrate/process-received-enmeshed-onboarding-package-and-create-relationship.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Process received enmeshed onboarding package and create relationship">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.FlowThis scenario describes the steps to go through after an onboarding package was created by an IdentityA and has been processed and accepted by another IdentityB. Thus, IdentityA received all required information by IdentityB over enmeshed with a RelationshipCreationChange. For IdentityB, this means the (possibly so far unknown) peer accepted the Request within the RelationshipTemplate and thus responded with the requested data.If the RelationshipTemplate was personalized or session-based, IdentityA needs to map the information within the created RelationshipTemplate for IdentityB and the received RelationshipCreationChange from IdentityB with the known data of external system of the user or session. IdentityA should be able to reflect the status for IdentityB in an existing web-session, e.g. update the screen which was formerly the enmeshed onboarding QR-Code.Now the received data needs to be manually checked for completeness, if the data is semantically correct and possibly could even be trusted. Even long-running real-world identity and credit rating checks could be performed now. Throughout this period, IdentityA can decide to accept or reject the Relationship. On the other hand, IdentityB could also decide to revoke the sent RelationshipCreationChange and thus revoke the whole onboarding process.We propose to have a very low entry barrier in order to create the secure Relationship and have secure means to communicate bidirectionally with the peer. Status, roles or flags could be used for the authorization and verification of the corresponding natural person or specific attributes afterwards. In fact, our favored scenario is to directly accept every incoming onboarding package and afterwards check the respective data. Therefore, we’ve created the AutoAcceptRelationshipCreationChanges Module.Examples  Received: Once an onboarding package is accepted by the recipient, the web-session could refresh the screen and state that the communication over enmeshed was successful and the content is being processed.  Acceptance: Net new users onboard themselves via enmeshed and profiles are generated for them  Acceptance: Existing users onboard themselves via enmeshed and their existing profiles get updated  Rejection: Users who entered wrong data in order to fulfill a business need (e.g. obvious fake data)">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -396,7 +396,7 @@ <h1 id="examples">Examples</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/process-responses-to-outgoing-requests.html b/integrate/process-responses-to-outgoing-requests.html
index 435c5b7d1..54df106d9 100644
--- a/integrate/process-responses-to-outgoing-requests.html
+++ b/integrate/process-responses-to-outgoing-requests.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Process responses to outgoing requests">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.FlowIf one sents out structured Requests, one usually wants to process the respective Responses to those Requests.Responses to Requests are received by standard enmeshed Messages that are automatically processed internally: The Response within the Message is extracted, converted to a LocalResponse and stored to the already existing LocalRequest. The LocalRequest is then set to status Completed. While processing the Response, external systems can listen to certain technical and semantic events propagated by the Connector.Depending on the semantic of the Request and its containing RequestItems, some changes are automatically processed by enmeshed. If IdentityA requests an Attribute of IdentityB, and IdentityB accepts the Request by responding with the respective Attribute, IdentityA automatically processes the Response and thus stores the additional Attribute for IdentityB. On the other hand, external systems usually needs to listen to the respective changes based on the sent out enmeshed events.Examples  Organization receives a single user consent to an updated privacy consent  Organization receives the birthdate of a single user because it has been missing">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -392,7 +392,7 @@ <h1 id="examples">Examples</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/propose-attribute-to-peer.html b/integrate/propose-attribute-to-peer.html
index af51e6fbe..8216327ae 100644
--- a/integrate/propose-attribute-to-peer.html
+++ b/integrate/propose-attribute-to-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Propose Attribute to peer">
     <meta itemprop="description" content="An Identity may have received information about a peer in the past that it needs to process a transaction at a later time. To ensure the accuracy of the available information, the Identity can propose Attributes to the peer for creation. Depending on whether the peer confirms the fittingness of a proposed Attribute, it can agree to its creation or correct the Attribute Value beforehand. Proposing Attributes to a peer can be useful in these and many other situations, such as:  An organization supports an Identity in setting up an enmeshed account by proposing Attributes to it that was derived from the organization’s knowledge about the Identity.  A company wants to make sure that the currently stored street address of a customer is valid before using it to ship an item to the customer.  A company proposes subscribing to its newsletter to one of its customers.We will now explain how a Connector, hereinafter referred to as the Sender, can propose an Attribute to another Connector, the so-called Recipient. Since understanding this proposing process requires knowledge about Requests and how to use them in general, you should take a look at our Request and Response introduction before continuing reading this guide.Please note that the general procedure is the same if the Connector wants to propose an Attribute to an App user instead of another Connector. For reasons of clarity, this guide focuses on the proposing process with two Connectors.Request for proposing AttributesThe Sender wants to propose an Attribute to the Recipient. To do this, the Sender must first create a suitable Request, which it can then send to the Recipient. In the following subsections, we describe the general appearance of a Request for proposing Attributes.Role of ProposeAttributeRequestItemTo propose a single Attribute to the Recipient, a single RequestItem of type ProposeAttributeRequestItem must be inserted into the items property of the Request. It is possible to propose an IdentityAttribute or a RelationshipAttribute, which must be inserted into the attribute property of the ProposeAttributeRequestItem. As it only makes sense for the Sender to propose an Attribute to the Recipient which is owned by the Recipient, the Sender must specify an empty string as the value for the owner property of the Attribute. The Recipient automatically becomes the owner of the Attribute later on. As the Recipient may want to change the Attribute Value of the proposed Attribute, the Sender must formulate a query matching the attribute. If the Sender specifies an attribute and a query that are incompatible, an error with the code error.runtime.requestDeserialization is to be expected.Combinations and usage scenarios of ProposeAttributeRequestItemThe following table provides an overview of the possible kinds of Attributes that the Sender can propose to the Recipient using the ProposeAttributeRequestItem. It must be taken into account whether the Attribute is an IdentityAttribute or a RelationshipAttribute and that its owner must be the Recipient, which is why the Sender must always specify an empty string as the value for the owner property of the Attribute contained within the attribute property of the ProposeAttributeRequestItem.            Attribute Type      Attribute Owner      Possible?      Automation      Examples/Reason                  Identity      Sender      ✗      N/A      It makes no sense to propose own Attributes, use ShareAttributeRequestItem instead.              Identity      Recipient      ✓      USER_DECISION      Company sends name and address to new customer during its onboarding process.              Relationship      Sender      ✗      N/A      It makes no sense to propose own Attributes, use CreateAttributeRequestItem or ReadAttributeRequestItem instead.              Relationship      Recipient      ✓      USER_DECISION      With this combination the Sender asks the Recipient for the one-time permission to write a RelationshipAttribute, which is owned by the Recipient, once and the Sender proposes a value which might make sense as a default.Example: Company asks new customer to subscribe to the newsletter and proposes the subscription as default once.      Example of proposing an IdentityAttributeIn the case in which the Sender wants to propose an IdentityAttribute to the Recipient, it must use a ProposeAttributeRequestItem which contains the IdentityAttribute in its attribute property and a matching IdentityAttributeQuery in its query property. This means that the specified value for the valueType property of the IdentityAttributeQuery must correspond to the Attribute Value type of the IdentityAttribute. The ProposeAttributeRequestItem must then be inserted into the items property of the Request for proposing Attributes. For example, the Sender wants to propose an IdentityAttribute of type EMailAddress to the Recipient. The value of the mustBeAccepted property of the ProposeAttributeRequestItem is set to true in our example and the &lt;...&gt; notation is used as a placeholder for the actual data as usual.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;EMailAddress&quot;,          &quot;value&quot;: &quot;&lt;email address that the Sender proposes to the Recipient&gt;&quot;        }      },      &quot;query&quot;: {        &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,        &quot;valueType&quot;: &quot;EMailAddress&quot;      }    }  ]}It is also possible to use an appropriate IQLQuery instead of an IdentityAttributeQuery as the query when proposing an IdentityAttribute with a ProposeAttributeRequestItem.Example of proposing a RelationshipAttributeLet’s consider the case in which the Sender has established an active Relationship with the Recipient and the Sender wants to propose a RelationshipAttribute for this Relationship to the Recipient. Then the Sender needs to insert a corresponding ProposeAttributeRequestItem, which contains the RelationshipAttribute in its attribute property and a matching RelationshipAttributeQuery in its query property, into the items property of the Request for proposing Attributes. In particular, it is necessary that the specified value for the attributeCreationHints.valueType property of the RelationshipAttributeQuery corresponds to the Attribute Value type of the RelationshipAttribute. For example, the Sender wants to propose a RelationshipAttribute of type ProprietaryString to the Recipient whose confidentiality is &quot;public&quot;, whereby the value of the mustBeAccepted property of the associated ProposeAttributeRequestItem is set to true.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;RelationshipAttribute&quot;,        &quot;owner&quot;: &quot;&quot;,        &quot;key&quot;: &quot;&lt;key of RelationshipAttribute&gt;&quot;,        &quot;confidentiality&quot;: &quot;public&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;ProprietaryString&quot;,          &quot;title&quot;: &quot;&lt;title of RelationshipAttribute&gt;&quot;,          &quot;value&quot;: &quot;&lt;actual value of RelationshipAttribute that the Sender proposes to the Recipient&gt;&quot;        }      },      &quot;query&quot;: {        &quot;@type&quot;: &quot;RelationshipAttributeQuery&quot;,        &quot;key&quot;: &quot;&lt;key of RelationshipAttribute&gt;&quot;,        &quot;owner&quot;: &quot;&quot;,        &quot;attributeCreationHints&quot;: {          &quot;title&quot;: &quot;&lt;title of RelationshipAttribute&gt;&quot;,          &quot;valueType&quot;: &quot;ProprietaryString&quot;,          &quot;confidentiality&quot;: &quot;public&quot;        }      }    }  ]}Propose multiple AttributesProposing Attributes to a peer is not limited to just a single Attribute, but it is possible to propose multiple Attributes to a peer at the same time. For this purpose, several ProposeAttributeRequestItems or suitable RequestItemGroups can be inserted into the items property of the Request for proposing Attributes. If you want to use a RequestItemGroup in order to propose multiple Attributes to the Recipient at the same time, you must insert corresponding ProposeAttributeRequestItems into the items property of it.Send and receive the RequestThe Sender that wants to propose an Attribute to the Recipient may or may not already have a Relationship with the Recipient. Depending on which is the case, a different method can be used to send the Request for proposing Attributes. There are two ways to send the Request for proposing Attributes created by the Sender to the Recipient.Request over TemplateIf there is currently no Relationship between the Sender and the Recipient, this approach must be used. However, it is also possible for the Sender to use a RelationshipTemplate to send a Request to the Recipient if there is already an active Relationship between them. All details on how to send and receive a Request via a RelationshipTemplate in general can be found in the Requests over Templates guide.Request over MessageThe Sender only has the option of sending a Request to the Recipient via a Message if there is already an active Relationship between them. All information on how to send and receive a Request via a Message can be found in the Requests over Messages guide.Accept the Request and deal with the proposed AttributesAfter the Recipient has received the Request for proposing Attributes, it can accept it to create all or some of the Attributes that were proposed for creation by the Sender. The Recipient also has the option of overwriting the Attribute Values beforehand or sending existing Attributes back to the Sender instead of creating new ones. To accept the Request, proceed as described in the Accept incoming Request use case documentation and specify the id of the received Request. Also, you need to decide and specify for each ProposeAttributeRequestItem and RequestItemGroup contained in the Request for proposing Attributes whether you want to accept or reject it.If the Recipient does not want to deal with any of the Attributes proposed by the Sender and, therefore, does not want to accept the Request for proposing Attributes of the Sender, it can reject it as a whole as well. For that, follow the instructions of the Reject incoming Request use case.Accept a ProposeAttributeRequestItemThe Recipient can accept a ProposeAttributeRequestItem contained in the Request for proposing Attributes using an appropriate AcceptProposeAttributeRequestItemParameter. Depending on whether the Recipient confirms the fittingness of the associated proposed Attribute, it can agree to its creation and send it back to the Sender unchanged or correct the Attribute Value beforehand. To do this, the Recipient needs to specify the proposed Attribute or an Attribute that differs from the proposed Attribute only by the Attribute Value as the value for the attribute parameter of the AcceptProposeAttributeRequestItemParameters. If the Recipient does not want to create a new Attribute, it can alternatively send an existing Attribute back to the Sender. The attributeId parameter of the AcceptProposeAttributeRequestItemParameters must be used for that. The existing Attribute may only differ from the proposed Attribute by the Attribute Value. The acceptance of a ProposeAttributeRequestItem leads to the creation of a corresponding LocalAttribute with a LocalAttributeShareInfo contained within its shareInfo property. The content of the LocalAttribute is the Attribute that the Recipient wants to send back to the Sender. Depending on whether the Recipient confirms the fittingness of the proposed Attribute, it is therefore the proposed Attribute itself or a corrected version of it. Based on this LocalAttribute, an appropriate AcceptResponseItem of type ProposeAttributeAcceptResponseItem is generated, which incorporates the id of the LocalAttribute with the LocalAttributeShareInfo in its attributeId property and the Attribute that the Recipient wants to send back to the Sender in its attribute property. This ProposeAttributeAcceptResponseItem will be contained within the items property of the Response to the Request for proposing Attributes that will be transferred to the Sender. If a new IdentityAttribute is to be created and sent back to the Sender, a corresponding LocalAttribute without a LocalAttributeShareInfo is additionally created for the Recipient beforehand.It is noticeable that accepting a ProposeAttributeRequestItem essentially works in the same way as accepting a ReadAttributeRequestItem. Both types of RequestItems are used when an Identity needs information from a peer. The difference between the two RequestItems is that when using the ProposeAttributeRequestItem, the Identity not only asks for an Attribute of a certain Attribute Value Type, but also proposes a specific Attribute to the peer for creation that might be suitable. The ProposeAttributeRequestItem can therefore also be understood as a combination of the ReadAttributeRequestItem and the CreateAttributeRequestItem. To gain a deeper understanding of these connections, take a look at the Read Attribute from peer guide and the Create Attribute for peer guide.Reject a ProposeAttributeRequestItemEven if the Recipient accepts the Request for proposing Attributes as a whole, it may decide not to accept all of the ProposeAttributeRequestItems it contains. To be more precise, the Recipient has the option of rejecting ProposeAttributeRequestItems that have the value false specified in their mustBeAccepted property. To reject a ProposeAttributeRequestItem, use the RejectRequestItemParameters. The rejection of a ProposeAttributeRequestItem leads to the creation of a corresponding ResponseItem of type RejectResponseItem. This will be contained within the items property of the Response to the Request for proposing Attributes.Example of accepting a RequestItemGroupLet’s look at an example where the Sender proposes the Recipient’s PersonName and contact information in the form of an EMailAddress and a PhoneNumber to the Recipient during its onboarding process. For this purpose, the Sender creates a Request for proposing Attributes, which contains a ProposeAttributeRequestItem belonging to the PersonName and a RequestItemGroup belonging to the contact information in its items property. The RequestItemGroup itself includes two ProposeAttributeRequestItems in its items property, namely one for the EMailAddress and one for the PhoneNumber.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;PersonName&quot;,          &quot;givenName&quot;: &quot;&lt;given name that the Sender proposes to the Recipient&gt;&quot;,          &quot;surname&quot;: &quot;&lt;surname that the Sender proposes to the Recipient&gt;&quot;        }      },      &quot;query&quot;: {        &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,        &quot;valueType&quot;: &quot;PersonName&quot;      }    },    {      &quot;@type&quot;: &quot;RequestItemGroup&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;items&quot;: [        {          &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: true,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;EMailAddress&quot;,              &quot;value&quot;: &quot;&lt;email address that the Sender proposes to the Recipient&gt;&quot;            }          },          &quot;query&quot;: {            &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,            &quot;valueType&quot;: &quot;EMailAddress&quot;          }        },        {          &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: false,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;PhoneNumber&quot;,              &quot;value&quot;: &quot;&lt;phone number that the Sender proposes to the Recipient&gt;&quot;            }          },          &quot;query&quot;: {            &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,            &quot;valueType&quot;: &quot;PhoneNumber&quot;          }        }      ]    }  ]}In our example, the Sender only requires the Recipient to accept the ProposeAttributeRequestItems belonging to the PersonName and the EMailAddress, which is why the individual ProposeAttributeRequestItems and the RequestItemGroup within the Request have specified corresponding values in their mustBeAccepted property. We assume that the Recipient wants to accept the Request and all its ProposeAttributeRequestItems with the exception of the PhoneNumber.If the Recipient wants to accept the Request for proposing Attributes, it must accept all ProposeAttributeRequestItems for which the mustBeAccepted property is set to true. It is therefore not permitted for the Recipient to refuse to accept the ProposeAttributeRequestItem belonging to the PersonName or the EMailAddress.We assume that the Recipient confirms the fittingness of the PersonName proposed by the Sender and that the Sender has proposed an outdated EMailAddress to the Recipient for creation. The Recipient therefore wants to create a corrected version of the EMailAddress and send it back to the Sender. The Recipient accepts at least one ProposeAttributeRequestItem of the RequestItemGroup, rejects the PhoneNumber and accepts the ProposeAttributeRequestItems belonging to the PersonName and the EMailAddress. Consequently, it responds to the Request for proposing Attributes as follows:{  &quot;items&quot;: [    {      // Accept the creation of the proposed PersonName      &quot;accept&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;PersonName&quot;,          &quot;givenName&quot;: &quot;&lt;given name that the Sender proposes to the Recipient&gt;&quot;,          &quot;surname&quot;: &quot;&lt;surname that the Sender proposes to the Recipient&gt;&quot;        }      }    },    {      // Accept RequestItemGroup      &quot;accept&quot;: true,      &quot;items&quot;: [        {          // Create a corrected version of the proposed EMailAddress          &quot;accept&quot;: true,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;EMailAddress&quot;,              &quot;value&quot;: &quot;&lt;Recipient&#39;s corrected version of the email address&gt;&quot;            }          }        },        {          // Reject PhoneNumber          &quot;accept&quot;: false        }      ]    }  ]}Note that it is important to respond to RequestItems and RequestItemGroups in the same order in which they were received.Receive the Response to the RequestWe now assume that the Recipient has accepted the Request for proposing Attributes of the Sender. In order for the Sender to receive the Response of the Recipient, it needs to synchronize the updates of the Backbone. Please note that this synchronization can also be automated by using the Sync Module.To view the Response to the Request, search for it in the synchronization result or proceed as described in the Query outgoing Requests use case documentation and use the following query parameter:  If the Request was sent via a Template: Specify &lt;ID of RelationshipTemplate&gt; as the value for the source.reference query parameter.  If the Request was sent via a Message: Specify &lt;ID of Request&gt; as the value for the id query parameter.The Integrator of the Sender can now get the Response of the Recipient from the response.content property of the result. In the items property of the Response is a ProposeAttributeAcceptResponseItem for each accepted ProposeAttributeRequestItem and a RejectResponseItem for each rejected ProposeAttributeRequestItem included. Note that each accepted ProposeAttributeRequestItem leads to the creation of an appropriate LocalAttribute with a LocalAttributeShareInfo of the Sender. The content of the LocalAttribute is the Attribute that the Recipient has sent back to the Sender. Depending on whether the Recipient has confirmed the fittingness of the Attribute proposed by the Sender, it is therefore the proposed Attribute itself or a corrected version of it.In case of an error, ErrorResponseItems can also be included in the Response. If the Request for proposing Attributes contains a RequestItemGroup in its items property, the Response to this Request contains a corresponding ResponseItemGroup in its items property.What’s next?An Identity has several options for requesting an Attribute creation. This guide covers how an Identity can request the creation of an Attribute for a peer so that the Attribute Value is proposed by the Identity, but can be modified by the peer when accepting the Request. In some cases, it makes more sense if the peer cannot change the proposed Attribute Value. For that, take a look at the Create Attribute for peer guide.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -672,7 +672,7 @@ <h2 id="whats-next">What’s next?</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/read-attribute-from-peer.html b/integrate/read-attribute-from-peer.html
index 30ef37af8..b9680e893 100644
--- a/integrate/read-attribute-from-peer.html
+++ b/integrate/read-attribute-from-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Read Attribute from peer">
     <meta itemprop="description" content="There are many situations in which an Identity is interested in an IdentityAttribute or a RelationshipAttribute of another Identity, for example:  A company must know the age of a customer in order to carry out an age check if they want to purchase alcohol or other age-restricted goods.  A company needs the street address of a customer so that it can send them an invoice after the customer has made a purchase from the company.  An organization is interested in the birth date of a member so that it can wish them a happy birthday every year.  A university needs to know the email address of a student in order to be able to send them emails.In this guide, we explain how a Connector, hereinafter referred to as the Sender, can read an Attribute of another Connector, the so-called Recipient. Since understanding this reading process requires knowledge about Requests and how to use them in general, you should take a look at our Request and Response introduction before continuing reading this guide.Please note that the general procedure is the same if the Connector wants to read an Attribute of an App user instead of another Connector. For reasons of clarity, this guide focuses on the reading process with two Connectors.Request for reading AttributesThe Sender wants to read an Attribute of the Recipient. To do this, the Sender must first create a suitable Request, which it can then send to the Recipient. In the following subsections, we describe the general appearance of a Request for reading Attributes.Role of ReadAttributeRequestItemFor reading a single Attribute, the Sender needs to insert a single RequestItem of type ReadAttributeRequestItem into the items property of the Request. The input it has to provide for the query property of the ReadAttributeRequestItem depends on what type of Attribute it wants to get. If the Sender wants to read an IdentityAttribute, it can use an appropriate IdentityAttributeQuery. If it is interested in a RelationshipAttribute of the Recipient, it can insert a RelationshipAttributeQuery or a ThirdPartyRelationshipAttributeQuery at this point. This depends on whether the Sender wants to read a RelationshipAttribute that the Recipient has in the context of a Relationship with the Sender or with a third party. It is also permitted to specify an IQLQuery for the query property of the ReadAttributeRequestItem.Combinations and usage scenarios of ReadAttributeRequestItemThe following table provides an overview of the possible kinds of Attributes that the Sender can read from the Recipient using the ReadAttributeRequestItem. It must be taken into account whether the Attribute is an IdentityAttribute or a RelationshipAttribute and which Identity is its owner. If the Sender wants to read a RelationshipAttribute from the Recipient, a distinction must be made between which Identities the Relationship in question exists.            Attribute Type      Attribute Owner      Third Party      Possible?      Automation      Examples/Reason                  Identity      Sender             ✗      N/A      It makes no sense to read own IdentityAttributes.              Identity      Recipient             ✓      USER_DECISION      Company asks customer for its delivery address.              Relationship      Sender             ✓      USER_DECISION      With this combination the Sender gives the Recipient the one-time permission to write a RelationshipAttribute once.Example: Electricity provider asks new customers for electricity meter number.              Relationship      Recipient             ✓      USER_DECISION      With this combination the Sender asks the Recipient for the one-time permission to write a RelationshipAttribute.Example: Company asks new customer to subscribe to the newsletter.              Relationship      Recipient      Third Party      ✓      USER DECISION / NOT ALLOWED - depending on confidentiality      With this combination the Sender requests a RelationshipAttribute from a Relationship between the Recipient and a third party that is owned by the Recipient. Example: A social network asks for Facebook privacy settings of a user to get senseful defaults of its own privacy settings.              Relationship      Third Party      Third Party      ✓      USER DECISION / NOT ALLOWED - depending on confidentiality      With this combination the Sender requests a RelationshipAttribute from a Relationship between the Recipient and a third party that is owned by the third party. Example: An online shop asks for the Payback customer ID of a user to book the order on their account.      Example of reading an IdentityAttributeWe assume that the Sender wants to read an IdentityAttribute of type EMailAddress of the Recipient. To do this, it inserts the corresponding IdentityAttributeQuery into the query property of the ReadAttributeRequestItem, which is contained within the items property of the Request for reading Attributes. In our example, we have chosen to set the value of the mustBeAccepted property of the ReadAttributeRequestItem to true.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;query&quot;: {        &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,        &quot;valueType&quot;: &quot;EMailAddress&quot;      }    }  ]}Example of reading a RelationshipAttributeWe now consider the case that the Sender has an active Relationship established with the Recipient and that the Sender wants to request a RelationshipAttribute of this Relationship whose value is set by the Recipient. Then the associated ReadAttributeRequestItem, which is contained in the items property of the Request for reading Attributes created by the Sender, must contain an appropriate RelationshipAttributeQuery in its query property. For example, if the Sender wants to request a RelationshipAttribute of type ProprietaryString that is owned by the Recipient and whose confidentiality is &quot;public&quot;, the Request could look like this:{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;query&quot;: {        &quot;@type&quot;: &quot;RelationshipAttributeQuery&quot;,        &quot;key&quot;: &quot;&lt;key of RelationshipAttribute&gt;&quot;,        &quot;owner&quot;: &quot;&lt;Address of Recipient&gt;&quot;,        &quot;attributeCreationHints&quot;: {          &quot;title&quot;: &quot;&lt;title of RelationshipAttribute&gt;&quot;,          &quot;valueType&quot;: &quot;ProprietaryString&quot;,          &quot;confidentiality&quot;: &quot;public&quot;        }      }    }  ]}Note that the &lt;...&gt; notation is used as a placeholder for the actual data as usual. Further details on the purposes for which you can use a RelationshipAttributeQuery can be found in the table of the Combinations and usage scenarios of the ReadAttributeRequestItem. For information on using the ThirdPartyRelationshipAttributeQuery, you should also refer to this table.Read multiple AttributesRequesting read access is not limited to just a single Attribute, but it is possible to request read access to multiple Attributes at the same time. Several ReadAttributeRequestItems or suitable RequestItemGroups can be inserted into the items property of the Request for reading Attributes for this purpose. If you want to use a RequestItemGroup in order to request read access to multiple Attributes of the Recipient at the same time, you must insert corresponding ReadAttributeRequestItems into the items property of it.Send and receive the RequestThe Sender that wants to read an Attribute of the Recipient may or may not already have a Relationship with the Recipient. Depending on which is the case, a different method can be used to send the Request for reading Attributes. There are two ways to send the Request for reading Attributes created by the Sender to the Recipient.Request over TemplateIf there is currently no Relationship between the Sender and the Recipient, this approach must be used. But it is also possible for the Sender to use a RelationshipTemplate to send a Request to the Recipient if there is already an active Relationship between them. All details on how to send and receive a Request via a RelationshipTemplate in general can be found in the Requests over Templates guide.Request over MessageThe Sender only has the option of sending a Request to the Recipient via a Message if there is already an active Relationship between them. All information on how to send and receive a Request via a Message can be found in the Requests over Messages guide.Accept the RequestAfter the Recipient has received the Request for reading Attributes, it can accept it to give the Sender read access to all or some of the requested Attributes. To do this, proceed as described in the Accept incoming Request use case documentation and specify the id of the received Request. You must also decide and specify for each ReadAttributeRequestItem and RequestItemGroup contained in the Request for reading Attributes whether you want to accept or reject it.If the Recipient does not want the Sender to read any of its Attributes and, therefore, does not want to accept the Request for reading Attributes of the Sender, it can reject it as a whole as well. For this, follow the instructions of the Reject incoming Request use case.Accept a ReadAttributeRequestItemIf the Recipient agrees to share a requested Attribute with the Sender, it can accept the associated ReadAttributeRequestItem contained in the Request for reading Attributes. In particular, it must then provide the requested Attribute for its Response to the Request. Depending on whether the Recipient wants to share an Attribute that already exists as a LocalAttribute or that has to be created first, different parameters for this must be used. These AcceptReadAttributeRequestItemParameters are described in the corresponding section of the Data Model Overview. The acceptance of a ReadAttributeRequestItem always leads to the creation of a LocalAttribute with a LocalAttributeShareInfo contained within its shareInfo property, whose underlying content is given by the shared Attribute. An appropriate AcceptResponseItem of type ReadAttributeAcceptResponseItem is generated, which incorporates the id of the LocalAttribute with the LocalAttributeShareInfo in its attributeId property and the shared Attribute in its attribute property. This ReadAttributeAcceptResponseItem will be included in the items property of the Response to the Request for reading Attributes that will be transferred to the Sender. If a new IdentityAttribute is to be shared, a corresponding LocalAttribute without a LocalAttributeShareInfo is additionally created for the Recipient beforehand.Reject a ReadAttributeRequestItemEven if the Recipient accepts the Request for reading Attributes as a whole, it may decide not to share every requested Attribute with the Sender. To be more precise, the Recipient has the option of rejecting ReadAttributeRequestItems that have the value false specified in their mustBeAccepted property. To reject a ReadAttributeRequestItem, use the RejectRequestItemParameters. The rejection of a ReadAttributeRequestItem leads to the creation of a ResponseItem of type RejectResponseItem. This will be contained within the items property of the Response to the Request for reading Attributes.Example of accepting a RequestItemGroupLet’s look at an example where the Sender is interested in the Recipient’s BirthDate and contact information in the form of an EMailAddress or a PhoneNumber. To ask the Recipient for this data, the Sender creates a Request for reading Attributes, which contains a ReadAttributeRequestItem belonging to the BirthDate and a RequestItemGroup belonging to the contact information in its items property. The RequestItemGroup itself contains two ReadAttributeRequestItems in its items property, namely one for the EMailAddress and one for the PhoneNumber.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: false,      &quot;query&quot;: {        &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,        &quot;valueType&quot;: &quot;BirthDate&quot;      }    },    {      &quot;@type&quot;: &quot;RequestItemGroup&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;items&quot;: [        {          &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: true,          &quot;query&quot;: {            &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,            &quot;valueType&quot;: &quot;EMailAddress&quot;          }        },        {          &quot;@type&quot;: &quot;ReadAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: false,          &quot;query&quot;: {            &quot;@type&quot;: &quot;IdentityAttributeQuery&quot;,            &quot;valueType&quot;: &quot;PhoneNumber&quot;          }        }      ]    }  ]}In our example, the Sender only requires the Recipient to share its EMailAddress, which is why the individual ReadAttributeRequestItems and the RequestItemGroup within the Request have specified corresponding values in their mustBeAccepted property. We assume that the Recipient wants to accept the Request and only wants to share its EMailAddress, which is already saved as an appropriate LocalAttribute, with the Sender.If the Recipient wants to accept the Request for reading Attributes, it must accept all ReadAttributeRequestItems for which the mustBeAccepted property is set to true. It is therefore not permitted, for example, for the Recipient to refuse to share its EMailAddress and instead share its PhoneNumber.The Recipient refuses to share its BirthDate with the Sender and accepts at least one ReadAttributeRequestItem of the RequestItemGroup. Also, the Recipient accepts the sharing of its EMailAddress and rejects the sharing of its PhoneNumber. Thus, it responds to the Request for reading Attributes as follows:{  &quot;items&quot;: [    {      // Reject sharing of BirthDate      &quot;accept&quot;: false    },    {      // Accept RequestItemGroup      &quot;accept&quot;: true,      &quot;items&quot;: [        {          // Accept sharing of existing EMailAddress          &quot;accept&quot;: true,          &quot;existingAttributeId&quot;: &quot;&lt;ID of LocalAttribute of EMailAddress&gt;&quot;        },        {          // Reject sharing of PhoneNumber          &quot;accept&quot;: false        }      ]    }  ]}Note that it is important to respond to RequestItems and RequestItemGroups in the same order in which they were received.Get the AttributesWe now assume that the Recipient has accepted the Request for reading Attributes of the Sender. In order for the Sender to receive the Response of the Recipient, it needs to synchronize the updates of the Backbone. Please note that this synchronization can also be automated by using the Sync Module.To view the Response to the Request, search for it in the synchronization result or proceed as described in the Query outgoing Requests use case documentation and use the following query parameter:  If the Request was sent via a Template: Specify &lt;ID of RelationshipTemplate&gt; as the value for the source.reference query parameter.  If the Request was sent via a Message: Specify &lt;ID of Request&gt; as the value for the id query parameter.The Integrator of the Sender can now get the Response of the Recipient from the response.content property of the result. In particular, each requested and shared Attribute that belongs to an accepted ReadAttributeRequestItem can be read from a corresponding ReadAttributeAcceptResponseItem within the items property of the Response. Internally, the shared attribute that can be read from the ReadAttributeAcceptResponseItem is used to create an appropriate LocalAttribute with a LocalAttributeShareInfo of the Sender. On the other hand, there is a corresponding RejectResponseItem in the items property of the Response for each rejected ReadAttributeRequestItem.In case of an error, ErrorResponseItems can also be included in the Response. If the Request for reading Attributes contains a RequestItemGroup in its items property, the Response to this Request contains a corresponding ResponseItemGroup in its items property.What’s next?Take a look at our Integration example if you want to see how an Attribute of a peer is read by an Identity in the context of a larger process. Also note that it is not only possible to request the reading of an Attribute from a peer, but that you can share your own Attribute with a peer as well. Consult the Share own Attribute to peer guide for this.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -632,7 +632,7 @@ <h2 id="whats-next">What’s next?</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/request-and-process-attributes-by-messages.html b/integrate/request-and-process-attributes-by-messages.html
index cca32854d..e14dbc32e 100644
--- a/integrate/request-and-process-attributes-by-messages.html
+++ b/integrate/request-and-process-attributes-by-messages.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Request and process attributes by messages">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.The onExistingRelationship field can also be sent with a RelationshipTemplateContent. The request in this field is processed if this template is processed by an identity that already has a relationship with the connector.This can be used, for example, to be able to log in via qr code.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -381,7 +381,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/request-and-response-introduction.html b/integrate/request-and-response-introduction.html
index 2b4fab2c5..1e400e6c1 100644
--- a/integrate/request-and-response-introduction.html
+++ b/integrate/request-and-response-introduction.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Request and Response introduction">
     <meta itemprop="description" content="Requests are the main instrument in enmeshed to interact with other Identities.They enable various business processes, e.g. creating, sharing or receiving Attributes, asking a peer for authentication or consent, and much more.Also, parts of a vaster business process can be implemented with them, like querying all personal information of a user to fill out a tax form.Requests are unique between Identities and can only be processed once by a single Identity, even across multiple devices associated with them.Each Request can only have a single Response, which responds to the complete Request and contains all the information the requestor needs.The Request-Response flow allows to establish transactional behavior between Identities.Please note that there are some data structures used in the context of enmeshed, that also use the terms “Request” and “Response” in their name, but do not correspond to the objects described on this page, e.g. RelationshipChangeRequest and RelationshipChangeResponse.RequestsStructure of RequestsA Request can be created by an Identity and sent to a peer to exchange information with them.Specifying the exact demands to the peer, RequestItems are the core of the Request.In case multiple RequestItems should be answered jointly, e.g. to enhance the structure for the user, they can be combined to a RequestItemGroup.After creating the Request, it can be transmitted either via a Template (see Requests over Templates) or via a Message (see Requests over Messages).Types of RequestItemsTo extinguish different scenarios how to use Requests, there are various types of RequestItems tailored to them.AuthenticationRequestItemWith the AuthenticationRequestItem the sender can request the peer for an authentication in a business context for a certain purpose. The peer can then decide to authenticate or not. This authentication is mostly short-lived and limited in time.Examples:  Authentication for a login to a website  Authentication for opening a doorConsentRequestItemWith the ConsentRequestItem it is possible to request a consent of the peer to an arbitrary text and thus reach agreement on a certain non machine-processable context.To request an accept/reject decision from a peer to a free text, the ConsentRequestItem is used.Please do not use the ConsentRequestItem to submit tons of text to the peer Identity. It is meant to be a short consent or summary the user agrees to. Please move longer text to external websites.The ConsentRequestItem is also not meant for contractual agreements.Examples:  “I hereby confirm that I have read the privacy terms of this cloud service and agree to them.”  “The provided EULA has been read and agreed to.”  “Yes, I have backed up all of my data of this PC and you can wipe it.”  “I opt in to the newsletter.”CreateAttributeRequestItemIf you want to create Identity- or RelationshipAttributes for the peer, the CreateAttributeRequestItem can be used. Please have a look at the ProposeAttributeRequestItem if the peer should be able to overwrite the Attribute.To create an Attribute with a fixed value defined by the sender, an Identity uses the CreateAttributeRequestItem. A fixed value in this case means, that the recipient is not allowed to change the value when accepting the request.Examples of use cases for the CreateAttributeRequestItem can be found in the Create Attribute for peer guide.FreeTextRequestItemWith the FreeTextRequestItem it is possible to send a free text to the peer. The peer itself can accept this with a free text as well.ProposeAttributeRequestItemThe ProposeAttributeRequestItem is a combination of ReadAttributeRequestItem and CreateAttributeRequestItem. The sender would like to receive a correct Attribute from the peer, thinks it has a possible value but the peer might overrule this value with an existing or new one.To create an Attribute with a value proposed by the sender, an Identity uses the ProposeAttributeRequestItem. A proposed value in this case means, that the recipient is allowed to change the value if accepting the request.Examples of use cases for the ProposeAttributeRequestItem can be found in the Propose Attribute to peer guide.ReadAttributeRequestItemIf you want to query an Identity’s Attributes this is done with the ReadAttributeRequestItem.To query Attributes which are not known to the sender, an Identity uses the ReadAttributeRequestItem.Examples of use cases for the ReadAttributeRequestItem can be found in the Read Attribute from peer guide.RegisterAttributeListenerRequestItemThis item is used to register a Listener for a specific Attribute. The Listener will create a Request in status Draft if an Attribute was created that matches the given query and the user is able to send the Request to the creator of the RegisterAttributeListenerRequestItem.Examples:  Asking for a specific RelationshipAttribute of a partner organization.ShareAttributeRequestItemIf you want to share the own DisplayName and possibly other Attributes this is done with the ShareAttributeRequestItem.To share own IdentityAttributes (owner = self) an Identity uses the ShareAttributeRequestItem. The Identity needs to create the IdentityAttribute separately before the Attribute can be shared.Examples of use cases for the ShareAttributeRequestItem can be found in the Share own Attribute to peer guide.ResponsesStructure of ResponsesOnce the other Identity receives a Request, they can decide whether to accept or reject it.Then, a Response will be created, containing a ResponseItem or ResponseItemGroup for every RequestItem or RequestItemGroup, respectively.The kind of ResponseItem depends on the decision of the Recipient, as well as on the kind of RequestItem.Types of ResponseItemsThere are three different categories of ResponseItems.If a RequestItem is accepted, an AcceptResponseItem will be created.Depending on the kind of RequestItem, it might be a specific AcceptResponseItem, extending the base AcceptResponseItem to answer to RequestItems demanding additional information.For example, a ReadAttributeRequestItem is accepted using a ReadAttributeAcceptResponseItem, additionally transmitting information about the respective Attribute.If a RequestItem is rejected, however, a RejectResponseItem is created.Lastly, in case the enmeshed Runtime detects a problem, an ErrorResponseItem is generated.It will never be created manually.Request-Response flowLocalRequests and LocalResponsesRequests and Responses as discussed above refer to the data structures that are exchanged between Identities.Locally, each Identity stores them in LocalRequests and LocalResponses.Note that the LocalResponse is stored within the respective LocalRequest, besides properties that are common for both peers like the LocalRequestStatus and others that are distinct for each Identity, e.g. the address of the peer or whether the Request was sent by you or received from the peer.Sending Requests via MessagesRequests can only be send via Message, if you already have an active Relationship with the recipient.Otherwise, you need to utilize a RelationshipTemplate.If you want to send a Request via Message, firstly you need to create a LocalRequest.Its ID equals the one of the associated Request that is sent in a Message to your peer.If the peer accepts the Request and reponds to it, at their side a LocalRequest will be created, having the same ID, however, opposite values for the fields peer and isOwn.Also, a LocalResponse will be created and stored directly within the LocalRequest.Then, a Message will transfer the Response wrapped in a ResponseWrapper back to you, where it can be mapped to your initially created LocalRequest.You can find an example for the Request-Response flow via Message below.Sending Requests via RelationshipTemplatesIf you don’t have a Relationship with the Recipient yet, the Request needs to be formulated within the onNewRelationship property of the RelationshipTemplateContent.Otherwise, utilize the onExistingRelationship property.Alternatively, you can transfer Requests via RelationshipTemplates.To do so, you locally create the RelationshipTemplate and in the process the Request, however, no LocalRequest will be created, yet.Hence, the Request your peer receives also doesn’t have an ID, yet.Now, there are two possibilities: either you already have a Relationship with the peer or you wish to establish one, given the condition the peer accepts your Request.For this, you formulate the Request in the content.onExistingRelationship or the content.onNewRelationship property of the RelationshipTemplate, respectively.Note, however, that the content.onNewRelationship property is required and, therefore, must always be set, in order to avoid unstable behavior, if someone you don’t have a Relationship with opens the RelationshipTemplate.Firstly, let’s consider the case you already have a Relationship with the peer.Receiving your RelationshipTemplate, thus, at their side the content.onExistingRelationship property will be processed, containing your Request.If the peer decides to accept and to respond to the Request, a LocalRequest will be created, comprising the LocalResponse.Its content, i.e. the Response, is wrapped in a ResponseWrapper and sent via Message back to you.Only now, a LocalRequest at your side will be created, having the same ID like its counterpart at your peer’s side, since it was transmitted within the Response.Also, the LocalResponse is stored directly within the LocalRequest, so that the LocalRequest you just created already has the status accepted.In case you don’t have a Relationship with the peer yet, opening the RelationshipTemplate, its content.onNewRelationship property will be processed.If the peer decides to accept and to respond to your Request, again a LocalRequest and LocalResponse will be created at their side.However, the returned data differ.Instead of a ResponseWrapper inside a Message, a Relationship is returned which is in the status pending for now.It contains the RelationshipTemplate, as well as the changes the peer made to it, i.e. the created Request and Response.Only after you accept the RelationshipCreationChangeRequest (not the kind of Request discussed on this page), the LocalRequest with LocalResponse is created at your side and the peer will receive the information about the status change via a consumption.incomingRequestStatusChanged event.You can find an example for the Request-Response flow via RelationshipTemplate below.ExamplesWorking with required and optional RequestItemsAn organization has a Relationship with a customer and needs their consent to the privacy terms.Additionally, the organization would like to know, if the customer is interested in optionally receiving a newsletter.Thus, they send a Request via Message, containing two ConsentRequestItems.On the one hand, the RequestItem regarding consent to the Privacy Terms has the mustBeAccepted flag enabled, indicating that the Request can’t be accepted without accepting this item.On the other hand, the RequestItem regarding the Newsletter has the mustBeAccepted flag disabled.Hence, the customer can freely choose whether or not they would like to give their consent to it.Let’s consider the case the Request and, therefore, the privacy terms are accepted, but the consent to the newsletter is denied.The resulting Request-Response flow is depicted in the following graphic.For simplicity some properties are omitted.Working with RequestItemGroupsAt a job fair a company wants to offer a convenient way to get in touch with interested jobseekers.For this, they provide a QR-code, linking to a RelationshipTemplate.In its content.onNewRelationship property it holds a Request with two RequestItemGroups.One of them contains Attributes the company shares with the peer, e.g. the company name.The other contains Attributes it would like to query from the peer.In this example they are the given and surname and optionally an e-mail address, following the Integration example.Now, an interested person can scan the QR-code, provide their information and send their Response inside a RelationshipCreationChangeRequest.Once the company accepts the new Relationship, they can exchange messages or other data using enmeshed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -572,7 +572,7 @@ <h3 id="working-with-requestitemgroups">Working with RequestItemGroups</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/request-persistent-consent-of-peer.html b/integrate/request-persistent-consent-of-peer.html
index c22f4edb0..f1f05f4f3 100644
--- a/integrate/request-persistent-consent-of-peer.html
+++ b/integrate/request-persistent-consent-of-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Request persistent consent of peer">
     <meta itemprop="description" content="Here is an explanation of how to obtain a person’s persistent consent on a particular topicTo request an accept/reject decision from a peer to a free text, the ConsentRequestItem is used.Represents the consent of a person to a specific topic. If you want to obtain a consent, you can send a ProposeAttributeRequestItem RelationshipAttribute with a Consent value where the owner is the peer.Examples  “I hereby confirm that I have read the privacy terms of this cloud service and agree to them.”  “The provided EULA has been read and agreed to.”  “Yes, I have backed up all of my data of this PC and you can wipe it.”  “I opt in to the newsletter.”Please do not use the Consent to submit tons of text to the peer Identity. It is meant to be a short consent or summary the user agrees to. Please move longer text to external websites.The Consent is also not meant for contractual agreements.Check your Requests validityAt first you should check if your Request is valid. You can do this by calling the POST /api/v2/Requests/Outgoing/Validate route on the Sender Connector with the following body.For the persistent consent request we use the ProposeAttributeRequestItem.{  &quot;content&quot;: {    &quot;@type&quot;: &quot;Request&quot;,    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;attribute&quot;: {          &quot;@type&quot;: &quot;RelationshipAttribute&quot;,          &quot;key&quot;: &quot;MyConsent&quot;,          &quot;owner&quot;: &quot;&quot;,          &quot;confidentiality&quot;: &quot;private&quot;,          &quot;value&quot;: {            &quot;@type&quot;: &quot;Consent&quot;,            &quot;consent&quot;: &quot;I hereby confirm that I have read the privacy terms of this cloud service and agree to them.&quot;          }        },        &quot;query&quot;: {          &quot;@type&quot;: &quot;RelationshipAttributeQuery&quot;,          &quot;key&quot;: &quot;MyConsent&quot;,          &quot;owner&quot;: &quot;&quot;,          &quot;attributeCreationHints&quot;: {            &quot;title&quot;: &quot;consent to content&quot;,            &quot;valueType&quot;: &quot;Consent&quot;,            &quot;confidentiality&quot;: &quot;private&quot;          }        }      }    ]  }}Create the RequestTo create the Request you have to call the POST /api/v2/Messages route on the Sender Connector, with the content property of the payload in the step before. Use the following JSON in the body:{  &quot;recipients&quot;: [&quot;&lt;the address of the Recipient Connector&gt;&quot;],  &quot;content&quot;: {    &quot;@type&quot;: &quot;Request&quot;,    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;ProposeAttributeRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;attribute&quot;: {          &quot;@type&quot;: &quot;RelationshipAttribute&quot;,          &quot;key&quot;: &quot;MyConsent&quot;,          &quot;owner&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;,          &quot;confidentiality&quot;: &quot;private&quot;,          &quot;value&quot;: {            &quot;@type&quot;: &quot;Consent&quot;,            &quot;consent&quot;: &quot;I hereby confirm that I have read the privacy terms of this cloud service and agree to them.&quot;          }        },        &quot;query&quot;: {          &quot;@type&quot;: &quot;RelationshipAttributeQuery&quot;,          &quot;key&quot;: &quot;MyConsent&quot;,          &quot;owner&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;,          &quot;attributeCreationHints&quot;: {            &quot;title&quot;: &quot;consent to content&quot;,            &quot;valueType&quot;: &quot;Consent&quot;,            &quot;confidentiality&quot;: &quot;private&quot;          }        }      }    ]  }}Note that the Request is currently in status Draft.Example accepted response:&quot;items&quot;: [  {    &quot;@type&quot;: &quot;ProposeAttributeAcceptResponseItem&quot;,    &quot;attribute&quot;: {      &quot;@type&quot;: &quot;RelationshipAttribute&quot;,      &quot;confidentiality&quot;: &quot;private&quot;,      &quot;isTechnical&quot;: false,      &quot;key&quot;: &quot;MyConsent&quot;,      &quot;owner&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;,      &quot;value&quot;: {        &quot;@type&quot;: &quot;Consent&quot;,        &quot;consent&quot;: &quot;I hereby confirm that I have read the privacy terms of this cloud service and agree to them.&quot;      }    },    &quot;attributeId&quot;: &quot;ATT...&quot;,    &quot;result&quot;: &quot;Accepted&quot;  }],&quot;requestId&quot;: &quot;REQ...&quot;,&quot;result&quot;: &quot;Accepted&quot;">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -544,7 +544,7 @@ <h2 id="create-the-request">Create the Request</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requesting-authentication.html b/integrate/requesting-authentication.html
index c73c898c6..1833040c2 100644
--- a/integrate/requesting-authentication.html
+++ b/integrate/requesting-authentication.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Requesting authentication">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.FlowEnmeshed supports specific authentication requests for users, e.g. for multi-factor based logins. This is done by sending out Requests with AuthenticationRequestItems.Examples  Single-factor based logins, e.g. scanning in an enmeshed QR-Code from an unknown browser window  Multi-factor based logins, e.g. requesting the user’s authentication over enmeshed after a password-based login  Multi-factor based business processes, e.g. requesting the user’s authentication if the user want to read or change certain kind of administrative information">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -389,7 +389,7 @@ <h1 id="examples">Examples</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requesting-one-time-consents.html b/integrate/requesting-one-time-consents.html
index 5e291be19..4d1b90fe8 100644
--- a/integrate/requesting-one-time-consents.html
+++ b/integrate/requesting-one-time-consents.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Requesting one-time consents">
     <meta itemprop="description" content="With the ConsentRequest it is possible to request a consent of the peer to an arbitrary text and thus reach agreement on a certain non machine-processable context.To request an accept/reject decision from a peer to a free text, the ConsentRequestItem is used.Check your Requests validityAt first you should check if your Request is valid. You can do this by calling the POST /api/v2/Requests/Outgoing/Validate route on the Sender Connector with the following body.For the one-time consent request we use the ConsentRequestItem.Even though the peer property is optional, it is recommended to specify it whenever possible. This allows additional validation rules to execute. When you are sending a Request over Messages you always know your peer.{  &quot;content&quot;: {    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;ConsentRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;The Sender is asking for an one time consent&quot;,        &quot;consent&quot;: &quot;I hereby confirm that I have read the privacy terms of this cloud service and agree to them.&quot;,        &quot;link&quot;: &quot;privacy.demo&quot;      }    ]  },  &quot;peer&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;}Examples  “I hereby confirm the login to the website”  “I confirm my presence in the course”Please do not use the ConsentRequest to submit tons of text to the peer Identity. It is meant to be a short consent or summary the user agrees to. Please move longer text to external websites.The ConsentRequest is also not meant for contractual agreements.Create the RequestTo create the Request you have to call the POST /api/v2/Requests/Outgoing route on the Sender Connector. Use the following JSON in the Request body:{  &quot;content&quot;: {    // the content property of the payload in the step before  },  &quot;peer&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;}Note that the Request is currently in status Draft.                    Save the complete content of the response. You will need it in the sending Request step.    Example response:{  &quot;id&quot;: &quot;REQ...&quot;,  &quot;status&quot;: &quot;Draft&quot;,  // ...  &quot;content&quot;: {    &quot;@type&quot;: &quot;Request&quot;,    &quot;id&quot;: &quot;REQ...&quot;,    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;AuthenticationRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;The Sender is asking for an authentication&quot;      }    ]  }}Sending RequestThere are 2 ways to send the request to the user. Either when creating a RelationshipTemplate or with a contact who already has a relationship, via a message.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -506,7 +506,7 @@ <h2 id="sending-request">Sending Request</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requests-and-requestitems.html b/integrate/requests-and-requestitems.html
index ec0e7b839..258185ffc 100644
--- a/integrate/requests-and-requestitems.html
+++ b/integrate/requests-and-requestitems.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Requests and RequestItems">
     <meta itemprop="description" content="AuthenticationRequestItemWith the AuthenticationRequestItem the sender can request the peer for an authentication in a business context for a certain purpose. The peer can then decide to authenticate or not. This authentication is mostly short-lived and limited in time.Examples  Authentication for a login to a website  Authentication for opening a doorResponse ParametersItem Properties  To accept this RequestItem an AcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.ConsentRequestItemWith the ConsentRequestItem it is possible to request a consent of the peer to an arbitrary text and thus reach agreement on a certain non machine-processable context.To request an accept/reject decision from a peer to a free text, the ConsentRequestItem is used.Please do not use the ConsentRequestItem to submit tons of text to the peer Identity. It is meant to be a short consent or summary the user agrees to. Please move longer text to external websites.The ConsentRequestItem is also not meant for contractual agreements.Examples  “I hereby confirm that I have read the privacy terms of this cloud service and agree to them.”  “The provided EULA has been read and agreed to.”  “Yes, I have backed up all of my data of this PC and you can wipe it.”  “I opt in to the newsletter.”Response ParametersItem Properties  To accept this RequestItem an AcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.CreateAttributeRequestItemIf you want to create Identity- or RelationshipAttributes for the peer, the CreateAttributeRequestItem can be used. Please have a look at the ProposeAttributeRequestItem if the peer should be able to overwrite the Attribute.To create an Attribute with a fixed value defined by the sender, an Identity uses the CreateAttributeRequestItem. A fixed value in this case means, that the recipient is not allowed to change the value when accepting the request.ExamplesExamples of use cases for the CreateAttributeRequestItem can be found in the Create Attribute for peer guide.ResponseItem Properties  To accept this RequestItem a CreateAttributeAcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.Combinations and usage scenariosCombinations and usage scenarios of the CreateAttributeRequestItem can be found in the Create Attribute for peer guide.FreeTextRequestItemWith the FreeTextRequestItem it is possible to send a free text to the peer. The peer itself can accept this with a free text as well.Response ParametersItem Properties  To accept this RequestItem a FreeTextAcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptFreeTextRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.ProposeAttributeRequestItemThe ProposeAttributeRequestItem is a combination of ReadAttributeRequestItem and CreateAttributeRequestItem. The sender would like to receive a correct Attribute from the peer, thinks it has a possible value but the peer might overrule this value with an existing or new one.To create an Attribute with a value proposed by the sender, an Identity uses the ProposeAttributeRequestItem. A proposed value in this case means, that the recipient is allowed to change the value if accepting the request.ExamplesExamples of use cases for the ProposeAttributeRequestItem can be found in the Propose Attribute to peer guide.ResponseItem Properties  To accept this RequestItem a ProposeAttributeAcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptProposeAttributeRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.Combinations and usage scenariosCombinations and usage scenarios of the ProposeAttributeRequestItem can be found in the Propose Attribute to peer guide.ReadAttributeRequestItemIf you want to query an Identity’s Attributes this is done with the ReadAttributeRequestItem.To query Attributes which are not known to the sender, an Identity uses the ReadAttributeRequestItem.ExamplesExamples of use cases for the ReadAttributeRequestItem can be found in the Read Attribute from peer guide.ResponseItem Properties  To accept this RequestItem a ReadAttributeAcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptReadAttributeRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.Combinations and usage scenariosCombinations and usage scenarios of the ReadAttributeRequestItem can be found in the Read Attribute from peer guide.RegisterAttributeListenerRequestItemThis item is used to register a Listener for a specific Attribute. The Listener will create a Request in status Draft if an Attribute was created that matches the given query and the user is able to send the Request to the creator of the RegisterAttributeListenerRequestItem.Examples  Asking for a specific RelationshipAttribute of a partner organization.ResponseItem Properties  To accept this RequestItem a RegisterAttributeListenerAcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.ShareAttributeRequestItemIf you want to share the own DisplayName and possibly other Attributes this is done with the ShareAttributeRequestItem.To share own IdentityAttributes (owner = self) an Identity uses the ShareAttributeRequestItem. The Identity needs to create the IdentityAttribute separately before the Attribute can be shared.ExamplesExamples of use cases for the ShareAttributeRequestItem can be found in the Share own Attribute to peer guide.ResponseItem Properties  To accept this RequestItem a ShareAttributeAcceptResponseItem will be transferred.  To reject this RequestItem a RejectResponseItem will be transferred.  In case of an error an ErrorResponseItem will be transferred.Parameters  To accept this RequestItem you can utilize AcceptRequestItemParameters.  To reject this RequestItem you can utilize RejectRequestItemParameters.Combinations and usage scenariosCombinations and usage scenarios of the ShareAttributeRequestItem can be found in the Share own Attribute to peer guide.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -608,7 +608,7 @@ <h3 id="shareattributerequestitem-combinationsandusagescenarios">Combinations an
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requests-over-messages.html b/integrate/requests-over-messages.html
index 47d16df9f..59e8b82b7 100644
--- a/integrate/requests-over-messages.html
+++ b/integrate/requests-over-messages.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Requests over Messages">
     <meta itemprop="description" content="This guide explains how to send and receive a Request over enmeshed Messages using two Connectors, the first of which sends a Request to the second, and the second accepts or rejects the Request. It provides step-by-step instructions for validating the Request, creating and sending the Request, and accepting or rejecting the Request.This guide assumes that you already have an active Relationship between two Connectors. If you don’t, you should follow the Requests over Templates guide first. If you created a Relationship during the Connector Tutorial this will also work.In this guide, the first Connector will be called Sender and the second Connector will be called Recipient. The Sender will send a Request to the Recipient. For the next steps you will need the enmeshed Address of the Recipient. You can find it out by calling the GET /api/v2/Relationships route on the Sender Connector.[  // ...  {    &quot;id&quot;: &quot;REL..&quot;,    &quot;status&quot;: &quot;Active&quot;,    // ...    &quot;peer&quot;: &quot;id1...&quot;  }]                    Look for the correct Relationship and then take its peer property. Save it for later.    Check your Requests validityAt first you should check if your Request is valid. You can do this by calling the POST /api/v2/Requests/Outgoing/Validate route on the Sender Connector with the following body.For simplicity the Request inside the Template only contains an AuthenticationRequestItem, but you can use any RequestItems you want.Even though the peer property is optional, it is recommended to specify it whenever possible. This allows additional validation rules to execute. When you are sending a Request over Messages you always know your peer.{  &quot;content&quot;: {    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;AuthenticationRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;The Sender is asking for an authentication&quot;      }    ]  },  &quot;peer&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;}Create the RequestTo create the Request you have to call the POST /api/v2/Requests/Outgoing route on the Sender Connector. Use the following JSON in the Request body:{  &quot;content&quot;: {    // the content property of the payload in the step before  },  &quot;peer&quot;: &quot;&lt;the address of the Recipient Connector&gt;&quot;}Note that the Request is currently in status Draft.                    Save the complete content of the response. You will need it in the next step.    Example response:{  &quot;id&quot;: &quot;REQ...&quot;,  &quot;status&quot;: &quot;Draft&quot;,  // ...  &quot;content&quot;: {    &quot;@type&quot;: &quot;Request&quot;,    &quot;id&quot;: &quot;REQ...&quot;,    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;AuthenticationRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;The Sender is asking for an authentication&quot;      }    ]  }}Send the RequestNow you have to send the Request to the Recipient. You can do so by calling the POST /api/v2/Messages route on the Sender Connector. Use the following JSON in the Request body:{  &quot;recipients&quot;: [&quot;&lt;the address of the Recipient Connector&gt;&quot;],  &quot;content&quot;: {    // the content you copied in the step before  }}This is where the automation of the enmeshed Runtime steps in and moves the Request from status Draft to status Open. You can observe this behaviour by querying the Request via GET /api/v2/Requests/Outgoing/{id} on the Sender Connector.Fetch the RequestIn order to fetch the Message with the Request, you have to synchronize the Recipient Connector (GET /api/v2/Account/Sync).The enmeshed Runtime will read the Message and create a new incoming Request. You can observe this by long polling the incoming Requests or by waiting for the consumption.incomingRequestReceived event.The long polling is done by calling the GET /api/v2/Requests/Incoming route. You can use the query params source.reference=&lt;id-of-the-message&gt; and status=ManualDecisionRequired to filter for Requests that belong to the Message that contained the Request.For more information about the events you can head over to the Connector Modules site and read about the AMQP Publisher module and the WebhooksV2 module that are propagating events.                    After you received the Request, save its id for the next step.    Answer the RequestAcceptIf you want to accept the Request you can do so by calling the PUT /api/v2/Requests/Incoming/{id}/Accept route. You can use the id you saved in the previous step. In the payload you have to accept at least all RequestItems where the mustBeAccepted property is set to true. In case of the example Request the payload is the following:{  &quot;items&quot;: [    {      &quot;accept&quot;: true    }  ]}RejectIf you want to reject the Request you can do so by calling the PUT /api/v2/Requests/Incoming/{id}/Reject route. You can use the id you saved in the previous step. In the payload you have to reject all RequestItems. In case of the example Request the payload is the following:{  &quot;items&quot;: [    {      &quot;accept&quot;: false    }  ]}Runtime automationNo matter if you accepted or rejected the Request: the response is similar. You can see that the Request moved to status Decided. This is where the enmeshed Runtime steps in and handles the Request based on you decision. It will move the Request to status Completed and send the Response to the Sender via a Message. This behavior can be observed by querying the Request again after a few seconds (GET /api/v2/Requests/Incoming/{id}).Sync the ResponseThe Sender will receive the Response as a Message. Therefore you have to synchronize the Sender Connector (GET /api/v2/Account/Sync).After a few seconds the Request has moved to status Completed and the Response is available in the response property of the Request. You can observe this by querying the Request via GET /api/v2/Requests/Outgoing/{id} on the Sender Connector.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -589,7 +589,7 @@ <h2 id="sync-the-response">Sync the Response</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requests-over-templates.html b/integrate/requests-over-templates.html
index b19cbe024..dee1d3bab 100644
--- a/integrate/requests-over-templates.html
+++ b/integrate/requests-over-templates.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Requests over Templates">
     <meta itemprop="description" content="This guide will explain the end to end flow of sharing and answering a Request over a Template. This flow usually happens between the App and a Connector, but for simplicity and more transparency we will use two Connectors. Therefore you have to start two Connectors that don’t have a Relationship yet.You can use the Connector Installation Guide if you need help for the setup the Connectors.On the first Connector you will create a Template. This Connector will be called Templator in the following steps. The second Connector is called Requestor, because it will create the Relationship and therefore it creates the RelationshipCreationChangeRequest.Check your Request’s validityAt first you should check if your Request is valid. You can do this by calling the POST /api/v2/Requests/Outgoing/Validate route on the Templator Connector with the following body.For simplicity the Request inside the Template only contains an AuthenticationRequestItem, but you can use any RequestItems you want.{  &quot;content&quot;: {    &quot;items&quot;: [      {        &quot;@type&quot;: &quot;AuthenticationRequestItem&quot;,        &quot;mustBeAccepted&quot;: true,        &quot;title&quot;: &quot;The templator is asking for an authentication&quot;      }    ]  }}Even though the Requests are validated during the RelationshipTemplate creation you should not skip this step as it gives you additional information in case of validation errors.Create the TemplateCreate the Relationship Template on the Templator’s Connector. You can do so by calling the POST /api/v2/RelationshipTemplates/Own route. Use the following JSON in the Request body:{  &quot;maxNumberOfAllocations&quot;: 1,  &quot;expiresAt&quot;: &quot;2023-06-01T00:00:00.000Z&quot;,  &quot;content&quot;: {    &quot;@type&quot;: &quot;RelationshipTemplateContent&quot;,    &quot;title&quot;: &quot;Connector Demo Contact&quot;,    &quot;onNewRelationship&quot;: {      // the content property of the payload in the step before    }  }}You will receive a response with the complete RelationshipTemplate.                    Save the truncatedReference and the id of the RelationshipTemplate. You will need them in the next steps.    {  &quot;id&quot;: &quot;RLT..&quot;,  // ...  &quot;truncatedReference&quot;: &quot;UkxU...&quot;}Load the Template and get the RequestNow you have to load the Template on the Requestor Connector. You can do so by calling the POST /api/v2/RelationshipTemplates/Peer route with the following content. Use the truncatedReference you copied before:{  &quot;reference&quot;: &quot;UkxU...&quot;}If no Relationship exists, this will trigger a process in the enmeshed Runtime. It will create a new incoming Request on which we will work in the next step. You can observe this by long polling the incoming Requests or by waiting for the consumption.incomingRequestReceived event.The long polling is done by calling the GET /api/v2/Requests/Incoming route. You can use the query params source.reference=&lt;id-of-the-template&gt; and status=ManualDecisionRequired to filter for Requests that belong to the Template you are currently working on.For more information about the events you can head over to the Connector Modules site and read about the AMQP Publisher module and the WebhooksV2 module that are propagating events.                    After you received the Request, save its id for the next step.    Answer the RequestThe rejection is explained before the acceptance because you can re-do it as often if you want. If you accept the Request a RelationshipRequest will be sent and no new Request will be created until the RelationshipRequest is answered. If the RelationshipRequest is accepted the enmeshed Runtime will recognize the existing Relationship and will also not create a new Request.So if you want to test the full flow, you should first reject the Request. After that you can create a new one, which you can accept.If there is no open RelationshipRequest or existing Relationship, you can trigger the creation of a new Request by loading the Template again with the same truncated reference.RejectIf you want to reject the Request you can do so by calling the PUT /api/v2/Requests/Incoming/{id}/Reject route. You can use the id you saved in the previous step. In the payload you have to reject all RequestItems. In case of the example Request the payload is the following:{  &quot;items&quot;: [    {      &quot;accept&quot;: false    }  ]}In the response you can see the Request has moved to status Decided. This is where the enmeshed Runtime steps in and handles the Request based on you decision. Because you rejected the Request, the enmeshed Runtime will only move the Request to status completed. This behavior can be observed by querying the Request again after a few seconds (GET /api/v2/Requests/Incoming/{id}).AcceptIf you tried out the Rejection before this step make sure to create a Request by loading the Template again with the same truncated reference.If you want to accept the Request you can do so by calling the PUT /api/v2/Requests/Incoming/{id}/Accept route. You can use the id you saved in the template loading step. In the payload you have to accept at least all RequestItems where the mustBeAccepted property is set to true. In case of the example Request the payload is the following:{  &quot;items&quot;: [    {      &quot;accept&quot;: true    }  ]}In the response you can see the Request has moved to status Decided. This is where the enmeshed Runtime steps in and handles the Request based on you decision. Because you accepted the Request, the enmeshed Runtime will send your Response to the Templator by creating a Relationship. This behavior can be observed by querying the Request again after a few seconds (GET /api/v2/Requests/Incoming/{id}). When the Request is in status Completed you can query the created Relationship (GET /api/v2/Relationships, query parameter template.id=&lt;id-of-the-template&gt;).If you synchronize the Templator Connector (POST /api/v2/Account/Sync) you will see a new Relationship in the response. The Relationship looks as follows:{  &quot;id&quot;: &quot;REL...&quot;,  &quot;template&quot;: {    // ...  },  &quot;status&quot;: &quot;Active&quot;,  &quot;peer&quot;: &quot;id1...&quot;,  // ...  &quot;changes&quot;: [    {      &quot;id&quot;: &quot;RCH...&quot;,      &quot;request&quot;: {        &quot;createdBy&quot;: &quot;id1...&quot;,        &quot;createdByDevice&quot;: &quot;DVC...&quot;,        &quot;createdAt&quot;: &quot;2022-11-04T13:31:01.360Z&quot;,        &quot;content&quot;: {          &quot;@type&quot;: &quot;RelationshipCreationChangeRequestContent&quot;,          &quot;response&quot;: {            &quot;items&quot;: [              {                &quot;@type&quot;: &quot;AcceptResponseItem&quot;,                &quot;result&quot;: &quot;Accepted&quot;              }            ],            &quot;requestId&quot;: &quot;REQ...&quot;,            &quot;result&quot;: &quot;Accepted&quot;          }        }      },      &quot;status&quot;: &quot;Accepted&quot;,      &quot;type&quot;: &quot;Creation&quot;      // ...    }  ]}Pay particular attention to the changes.0.request.content property that contains the Response that was generated by the enmeshed Runtime.Now you can accept the Relationship on the Templator Connector by calling the PUT /api/v2/Relationships/{relationshipId}/Changes/{changeId}/Accept route.When you synchronize the Requestor Connector (POST /api/v2/Account/Sync) you can see that the Relationship is now in status Active on both Connectors.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -594,7 +594,7 @@ <h3 id="accept">Accept</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/respond-to-incoming-requests.html b/integrate/respond-to-incoming-requests.html
index 2daa9eedc..5aab4a4f7 100644
--- a/integrate/respond-to-incoming-requests.html
+++ b/integrate/respond-to-incoming-requests.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Respond to incoming requests">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.FlowIf one receives structured Requests, one usually needs to process the respective Request and respond to them.Requests are usually received by standard enmeshed Messages that are automatically processed internally: The Request within the Message is extracted, a LocalRequest is created and an automated decision of the LocalRequest is tried. If the Request cannot be decided automatically, it is set to status ManualDecisionRequired. While processing the Request, external systems can listen to certain technical and semantic events propagated by the Connector.The Request can then be manually accepted or rejected and before that, the respective canAccept or canReject APIs should be called.Depending on the semantic of the Request and its containing RequestItems, some changes are automatically processed by enmeshed. If IdentityA requests an Attribute of IdentityB, and IdentityB accepts the Request by responding with the respective Attribute, IdentityB automatically creates a shared copy of this specific LocalAttribute and completes the LocalRequest. On the other hand, external systems usually needs to listen to the respective changes based on the sent out enmeshed events.Examples  Organization receives a user request and needs to act manually on it  Organization receives a user request and it was automatically decided by the Connector">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -394,7 +394,7 @@ <h1 id="examples">Examples</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/sending-messages-with-attachments.html b/integrate/sending-messages-with-attachments.html
index af5d9d071..5e5fa4766 100644
--- a/integrate/sending-messages-with-attachments.html
+++ b/integrate/sending-messages-with-attachments.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Sending Messages with attachments">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.The Connector can send and receive Messages with attachments using enmeshed Files, which are first uploaded and encrypted on the Platform. Files send and received with this approach are primarily meant for single-purpose uses, as they cannot be easily shared by the sending/receiving Identity without further ado.Upload FilesIn order to submit Files via Message, they have to be first uploaded to the Connector. The Files are then encrypted and uploaded to the Platform, which results in a unique FileId for every File. These FileIds can then be used as attachments to send Messages with attachments.Download Attachments of MessagesThe metadata of attachments can be found within the respective Message, the actual content if the File must be downloaded separately.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -387,7 +387,7 @@ <h2 id="download-attachments-of-messages">Download Attachments of Messages</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/sending-messages.html b/integrate/sending-messages.html
index 7ecf9b000..69cdf39e4 100644
--- a/integrate/sending-messages.html
+++ b/integrate/sending-messages.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Sending Messages">
     <meta itemprop="description" content="The Connector can send and receive messages with attachments using REST requests and file IDs, which are first uploaded and encrypted on the Platform. Messages can be queried and downloaded, and the Connector pulls for new messages periodically.In order to send messages to recipients, a REST request can be sent with the given recipients and message content. Different message content structures are possible and defined in the chapter Data Structures. Additionally, an array of file ids can be added for property attachments in order to send attachments.Upload FilesIn order to submit attachments/files via message, they have to be first uploaded to the Connector. The files are then encrypted and uploaded to the Platform, which results in a FileId for every file.These FileIds can then be used as attachments to send messages with attachments.Get MessagesMessages can be directly queried from the Connector.Download Attachments of MessagesThe metadata of attachments can be found within the message, the actual files/binaries must be downloaded separately.Receive MessagesThe Connector pulls occasionally for new messages from the Platform and temporarily stores them in the database. They can then be fetched by the corresponding business systems by the REST API (pull) or by the defined HTTP endpoint (push).">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -445,7 +445,7 @@ <h2 id="receive-messages">Receive Messages</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/share-own-attribute-to-peer.html b/integrate/share-own-attribute-to-peer.html
index 49c5479e2..e027fb0a1 100644
--- a/integrate/share-own-attribute-to-peer.html
+++ b/integrate/share-own-attribute-to-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Share own Attribute to peer">
     <meta itemprop="description" content="There are many situations in which an Identity wants to share an own IdentityAttribute or a RelationshipAttribute with another Identity, for example:  A university wants to give a student the street address of its student administration so that they can send it documents by post.  An organization wants to share its email address with its members in order to be able to receive emails from them.  A company wants to share the customer number of one of its customers with another company.In this guide, we explain how a Connector, hereinafter referred to as the Sender, can share an own Attribute with another Connector, the so-called Recipient. Since understanding this sharing process requires knowledge about Requests and how to use them in general, you should take a look at our Request and Response introduction before continuing reading this guide.Please note that the general procedure is the same if the Connector wants to share an own Attribute with an App user instead of another Connector. For reasons of clarity, this guide focuses on the sharing process with two Connectors.Request for sharing AttributesThe Sender wants to share an own Attribute with the Recipient. To do this, the Sender must first create a suitable Request, which it can then send to the Recipient. In the following subsections, we describe the general appearance of a Request for sharing Attributes.Role of ShareAttributeRequestItemFor sharing a single Attribute, the Sender needs to insert a single RequestItem of type ShareAttributeRequestItem into the items property of the Request. The Sender can only share an Attribute that already exists as a LocalAttribute and, in the case of IdentityAttributes, is owned by it. The latter means that the Address of the Sender is contained in the content.owner property of the corresponding LocalAttribute. The id of the LocalAttribute must be inserted into the sourceAttributeId property and the content of the LocalAttribute into the attribute property of the ShareAttributeRequestItem.To get a list of all LocalAttributes that are owned by the Sender, proceed as described in the Query Attributes use case documentation and use &quot;content.owner=&lt;Address of Sender&gt;&quot; as query parameter. Please note that the &lt;...&gt; notation is used as a placeholder for the actual data as usual. If the id of a LocalAttribute is known, the underlying IdentityAttribute or RelationshipAttribute within its content property can be displayed by consulting the Get Attribute use case description and specifying the id of the LocalAttribute.Combinations and usage scenarios of ShareAttributeRequestItemThe following table provides an overview of the possible kinds of Attributes that the Sender can share with the Recipient using the ShareAttributeRequestItem. It must be taken into account whether the Attribute is an IdentityAttribute or a RelationshipAttribute and which Identity is its owner. If the Sender wants to share a RelationshipAttribute with the Recipient, a distinction must be made between which Identities the Relationship in question exists.            Attribute Type      Attribute Owner      Possible?      Automation      Examples/Reason                  Identity      Sender      ✓      AUTO ACCEPT      Company sends new customer the address of the company.              Identity      Recipient      ✗      N/A      It makes no sense to share the Attribute with the Recipient, because he already owns it.              Identity      Third Party      ✗      N/A      You cannot share an Attribute of which you are not the owner.              Identity      &lt;empty&gt;      ✓      AUTO ACCEPT      An empty owner defaults to an Attribute with owner=&lt;Sender&gt;.              Relationship      Sender      ✓      USER DECISION / NOT ALLOWED (depending on confidentiality)      A user can share own RelationshipAttributes of any Relationship with any other Relationship (if the confidentiality of the RelationshipAttribute is protected or public).Example: Share customer ID from company A with company B (User is owner of RelationshipAttribute).              Relationship      Recipient      ✗      N/A      It makes no sense to share the Attribute with the Recipient, because he already owns it.              Relationship      Third Party      ✓      USER DECISION / NOT ALLOWED (depending on confidentiality)      A user can share RelationshipAttributes of any Relationship with any other Relationship (if the confidentiality of the RelationshipAttribute is protected or public). Example: Share customer ID from company A with company B (Company A is owner of RelationshipAttribute), e.g. Payback number.              Relationship      &lt;empty&gt;      ✓      AUTO ACCEPT      An empty owner defaults to an Attribute with owner=&lt;Sender&gt;.      Example of sharing an own IdentityAttributeWe assume that the Integrator of the Sender has created an own IdentityAttribute of type BirthDate for the Sender by following the instructions of our Create own IdentityAttribute scenario documentation. This IdentityAttribute is stored locally within the content property of a corresponding LocalAttribute of the Sender.{  &quot;@type&quot;: &quot;LocalAttribute&quot;,  &quot;id&quot;: &quot;&lt;ID of LocalAttribute&gt;&quot;,  &quot;createdAt&quot;: &quot;&lt;creation date of LocalAttribute&gt;&quot;,  &quot;content&quot;: {    &quot;@type&quot;: &quot;IdentityAttribute&quot;,    &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,    &quot;value&quot;: {      &quot;@type&quot;: &quot;BirthDate&quot;,      &quot;day&quot;: &lt;day of birth date&gt;,      &quot;month&quot;: &lt;month of birth date&gt;,      &quot;year&quot;: &lt;year of birth date&gt;    }  }}In our example, the Sender wants to share the IdentityAttribute with the Recipient. To do so, it needs to insert the id of the corresponding LocalAttribute into the sourceAttributeId property and the IdentityAttribute itself into the attribute property of the ShareAttributeRequestItem contained within the items property of the Request for sharing Attributes. The value of the mustBeAccepted property of the ShareAttributeRequestItem is set to true in this example.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ShareAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;BirthDate&quot;,          &quot;day&quot;: &lt;day of birth date&gt;,          &quot;month&quot;: &lt;month of birth date&gt;,          &quot;year&quot;: &lt;year of birth date&gt;        }      },      &quot;sourceAttributeId&quot;: &quot;&lt;ID of LocalAttribute&gt;&quot;    }  ]}Example of sharing an own RelationshipAttributeWe now consider the case in which the Sender has an active Relationship with a third party and owns a RelationshipAttribute, which has already been created by using an appropriate Request, of type ProprietaryString of this Relationship. The Sender can request to share this RelationshipAttribute with the Recipient if its confidentiality is &quot;protected&quot; or &quot;public&quot;. In our example, we assume that the confidentiality of the RelationshipAttribute is &quot;public&quot; and that it is stored locally within the content property of a corresponding LocalAttribute with a LocalAttributeShareInfo of the Sender.{  &quot;@type&quot;: &quot;LocalAttribute&quot;,  &quot;id&quot;: &quot;&lt;ID of LocalAttribute&gt;&quot;,  &quot;createdAt&quot;: &quot;&lt;creation date of LocalAttribute&gt;&quot;,  &quot;content&quot;: {    &quot;@type&quot;: &quot;RelationshipAttribute&quot;,    &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,    &quot;key&quot;: &quot;&lt;key of RelationshipAttribute&gt;&quot;,    &quot;confidentiality&quot;: &quot;public&quot;,    &quot;value&quot;: {      &quot;@type&quot;: &quot;ProprietaryString&quot;,      &quot;title&quot;: &quot;&lt;title of RelationshipAttribute&gt;&quot;,      &quot;value&quot;: &quot;&lt;actual value of RelationshipAttribute&gt;&quot;    }  },  &quot;shareInfo&quot;: {    &quot;peer&quot;: &quot;&lt;Address of third party&gt;&quot;,    &quot;requestReference&quot;: &quot;&lt;ID of Request used for creating RelationshipAttribute&gt;&quot;  }}To share the RelationshipAttribute with the Recipient, the Sender needs to insert the id of the corresponding LocalAttribute into the sourceAttributeId property and the RelationshipAttribute itself into the attribute property of the ShareAttributeRequestItem contained within the items property of the Request for sharing Attributes. The value of the mustBeAccepted property of the ShareAttributeRequestItem is set to true in this example.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ShareAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;RelationshipAttribute&quot;,        &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,        &quot;key&quot;: &quot;&lt;key of RelationshipAttribute&gt;&quot;,        &quot;confidentiality&quot;: &quot;public&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;ProprietaryString&quot;,          &quot;title&quot;: &quot;&lt;title of RelationshipAttribute&gt;&quot;,          &quot;value&quot;: &quot;&lt;actual value of RelationshipAttribute&gt;&quot;        }      },      &quot;sourceAttributeId&quot;: &quot;&lt;ID of LocalAttribute&gt;&quot;    }  ]}The table of the Combinations and usage scenarios of the ShareAttributeRequestItem contains further information on sharing RelationshipAttributes in different application scenarios.Share multiple AttributesSharing is not limited to just a single Attribute, but it is possible to request the sharing of multiple Attributes at the same time. For this purpose, several ShareAttributeRequestItems or suitable RequestItemGroups can be inserted into the items property of the Request for sharing Attributes. If you want to use a RequestItemGroup in order to share multiple Attributes with the Recipient at the same time, you must insert corresponding ShareAttributeRequestItems into the items property of it.Send and receive the RequestThe Sender that wants to share an Attribute with the Recipient may or may not already have a Relationship with the Recipient. Depending on which is the case, a different method can be used to send the Request for sharing Attributes. There are two ways to send the Request for sharing Attributes created by the Sender to the Recipient.Request over TemplateIf there is currently no Relationship between the Sender and the Recipient, this approach must be used. However, it is also possible for the Sender to use a RelationshipTemplate to send a Request to the Recipient if there is already an active Relationship between them. All details on how to send and receive a Request via a RelationshipTemplate in general can be found in the Requests over Templates guide.Request over MessageThe Sender only has the option of sending a Request to the Recipient via a Message if there is already an active Relationship between them. All information on how to send and receive a Request via a Message can be found in the Requests over Messages guide.Accept the Request and get the AttributesAfter the Recipient has received the Request for sharing Attributes, it can accept it to get all or some of the Sender’s shared Attributes. To do this, proceed as described in the Accept incoming Request use case documentation and specify the id of the received Request. Also, you need to decide and specify for each ShareAttributeRequestItem and RequestItemGroup contained in the Request for sharing Attributes whether you want to accept or reject it.If the Recipient does not want to get any of the Sender’s shared Attributes and, therefore, does not want to accept the Request for sharing Attributes of the Sender, it can reject it as a whole too. For that, follow the instructions of the Reject incoming Request use case.Accept a ShareAttributeRequestItemIf the Recipient agrees to get one of the Sender’s shared Attributes, it can accept the associated ShareAttributeRequestItem contained in the Request for sharing Attributes. The AcceptRequestItemParameters must be used for this. The acceptance of a ShareAttributeRequestItem leads to the creation of a corresponding LocalAttribute with a LocalAttributeShareInfo contained within its shareInfo property. The content of the LocalAttribute is the underlying attribute of the ShareAttributeRequestItem. Based on this, an appropriate AcceptResponseItem of type ShareAttributeAcceptResponseItem is generated, which incorporates the id of the created LocalAttribute with the LocalAttributeShareInfo in its attributeId property. This will be contained within the items property of the Response to the Request for sharing Attributes that will be transferred to the Sender.Reject a ShareAttributeRequestItemEven if the Recipient accepts the Request for sharing Attributes as a whole, it may decide not to accept all of the Sender’s shared Attributes. To be more precise, the Recipient has the option of rejecting ShareAttributeRequestItems that have the value false specified in their mustBeAccepted property. To reject a ShareAttributeRequestItem, use the RejectRequestItemParameters. The rejection of a ShareAttributeRequestItem leads to the creation of a corresponding ResponseItem of type RejectResponseItem. This will be contained within the items property of the Response to the Request for sharing Attributes.Example of accepting a RequestItemGroupLet’s look at an example where the Sender wants to share its DisplayName and contact information in the form of an EMailAddress or a PhoneNumber with the Recipient. For this purpose, the Sender creates a Request for sharing Attributes, which contains a ShareAttributeRequestItem belonging to the DisplayName and a RequestItemGroup belonging to the contact information in its items property. The RequestItemGroup itself includes two ShareAttributeRequestItems in its items property, namely one for the EMailAddress and one for the PhoneNumber.{  &quot;@type&quot;: &quot;Request&quot;,  &quot;items&quot;: [    {      &quot;@type&quot;: &quot;ShareAttributeRequestItem&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;attribute&quot;: {        &quot;@type&quot;: &quot;IdentityAttribute&quot;,        &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,        &quot;value&quot;: {          &quot;@type&quot;: &quot;DisplayName&quot;,          &quot;value&quot;: &quot;&lt;display name that the Sender wants to share&gt;&quot;        }      },      &quot;sourceAttributeId&quot;: &quot;&lt;ID of LocalAttribute which is the source of the DisplayName&gt;&quot;    },    {      &quot;@type&quot;: &quot;RequestItemGroup&quot;,      &quot;mustBeAccepted&quot;: true,      &quot;items&quot;: [        {          &quot;@type&quot;: &quot;ShareAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: true,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;EMailAddress&quot;,              &quot;value&quot;: &quot;&lt;email address that the Sender wants to share&gt;&quot;            }          },          &quot;sourceAttributeId&quot;: &quot;&lt;ID of LocalAttribute which is the source of the EMailAddress&gt;&quot;        },        {          &quot;@type&quot;: &quot;ShareAttributeRequestItem&quot;,          &quot;mustBeAccepted&quot;: false,          &quot;attribute&quot;: {            &quot;@type&quot;: &quot;IdentityAttribute&quot;,            &quot;owner&quot;: &quot;&lt;Address of Sender&gt;&quot;,            &quot;value&quot;: {              &quot;@type&quot;: &quot;PhoneNumber&quot;,              &quot;value&quot;: &quot;&lt;phone number that the Sender wants to share&gt;&quot;            }          },          &quot;sourceAttributeId&quot;: &quot;&lt;ID of LocalAttribute which is the source of the PhoneNumber&gt;&quot;        }      ]    }  ]}In our example, the Sender only requires the Recipient to accept the DisplayName and the EMailAddress, which is why the individual ShareAttributeRequestItems and the RequestItemGroup within the Request have specified corresponding values in their mustBeAccepted property. We assume that the Recipient wants to accept the Request and all its ShareAttributeRequestItems with the exception of the PhoneNumber.If the Recipient wants to accept the Request for sharing Attributes, it must accept all ShareAttributeRequestItems for which the mustBeAccepted property is set to true. It is therefore not permitted for the Recipient to refuse to accept the DisplayName or the EMailAddress shared by the Sender.The Recipient accepts the DisplayName of the Sender and accepts at least one ShareAttributeRequestItem of the RequestItemGroup. Also, the Recipient accepts the EMailAddress and rejects the PhoneNumber of the Sender. It therefore responds to the Request for sharing Attributes as follows:{  &quot;items&quot;: [    {      // Accept DisplayName      &quot;accept&quot;: true    },    {      // Accept RequestItemGroup      &quot;accept&quot;: true,      &quot;items&quot;: [        {          // Accept EMailAddress          &quot;accept&quot;: true        },        {          // Reject PhoneNumber          &quot;accept&quot;: false        }      ]    }  ]}Note that it is important to respond to RequestItems and RequestItemGroups in the same order in which they were received.Receive the Response to the RequestWe now assume that the Recipient has accepted the Request for sharing Attributes of the Sender. In order for the Sender to receive the Response of the Recipient, it needs to synchronize the updates of the Backbone. Please note that this synchronization can also be automated by using the Sync Module.To view the Response to the Request, search for it in the synchronization result or proceed as described in the Query outgoing Requests use case documentation and use the following query parameter:  If the Request was sent via a Template: Specify &lt;ID of RelationshipTemplate&gt; as the value for the source.reference query parameter.  If the Request was sent via a Message: Specify &lt;ID of Request&gt; as the value for the id query parameter.The Integrator of the Sender can now get the Response of the Recipient from the response.content property of the result. In the items property of the Response is a ShareAttributeAcceptResponseItem for each accepted ShareAttributeRequestItem and a RejectResponseItem for each rejected ShareAttributeRequestItem included. Note that each accepted ShareAttributeRequestItem leads to the creation of an appropriate LocalAttribute with a LocalAttributeShareInfo of the Sender. The content of the LocalAttribute is the underlying attribute of the ShareAttributeRequestItem.In case of an error, ErrorResponseItems can also be included in the Response. If the Request for sharing Attributes contains a RequestItemGroup in its items property, the Response to this Request contains a corresponding ResponseItemGroup in its items property.What’s next?Take a look at our Integration example if you want to see how an Identity shares an own Attribute with a peer in the context of a larger process. Also note that it is not only possible to share your own Attribute with a peer, but you can also request to read an Attribute from a peer. Consult the Read Attribute from peer guide for this.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -708,7 +708,7 @@ <h2 id="whats-next">What’s next?</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/succeed-attribute-of-peer.html b/integrate/succeed-attribute-of-peer.html
index d3b252438..a4afe17e2 100644
--- a/integrate/succeed-attribute-of-peer.html
+++ b/integrate/succeed-attribute-of-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Succeed attribute of peer">
     <meta itemprop="description" content="This feature (or parts of it) and its documentation are still in developmentPlease note that this section describes features which are currently in development, and we are actively working on enhancing your experience.Thus you could encounter unfinished APIs, incompatible changes, mistakes or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this feature, e.g. by filing an issue in our feedback repository.FlowIf IdentityA has a more up-to-date value of an Attribute of IdentityB, a RequestSucceedAttributeRequestItem can actively request an Attribute succession of someone else.To ensure traceability, attributes cannot be overwritten directly, but only a new version can be saved, which is linked to the predecessors.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -383,7 +383,7 @@ <h1 id="flow">Flow</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/support.html b/integrate/support.html
index 0449753fd..5537524fd 100644
--- a/integrate/support.html
+++ b/integrate/support.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Support">
     <meta itemprop="description" content="For assisted support with the Connector or the Backbone provided by the j&amp;s-soft GmbH contact us via support[at]enmeshed.eu.Community support is a great way to get help and even contribute to the projects. Open bug reports and feature requests in the enmeshed issue tracker or share your feedback with the enmeshed team via the enmeshed discussions.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -375,7 +375,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/updating-identityattributes-of-yourself.html b/integrate/updating-identityattributes-of-yourself.html
index 8188237f0..e176b06f5 100644
--- a/integrate/updating-identityattributes-of-yourself.html
+++ b/integrate/updating-identityattributes-of-yourself.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Updating IdentityAttributes of yourself">
     <meta itemprop="description" content="This feature (or parts of it) and its documentation are still in developmentPlease note that this section describes features which are currently in development, and we are actively working on enhancing your experience.Thus you could encounter unfinished APIs, incompatible changes, mistakes or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this feature, e.g. by filing an issue in our feedback repository.FlowAttributes as such cannot be updated, but can be succeeded by a new Attribute. Thus, the value of an Attribute cannot be changed but overwritten by a new Attribute. We ensure that a coherent history of Attributes are available at all times on different parties.Consider an IdentityA which shared its DisplayName to IdentityB, IdentityC, and IdentityD. IdentityA now would like to change the DisplayName and has to execute the following steps:  Succeed the LocalAttribute of the current DisplayName with the new DisplayName  Notify each peer individually that the DisplayName changed (this is optional, for every peer it can be decided if the peer receives the new Attribute or not)Each peer would receive a Notification containing an AttributeSucceededNotificationItem which is automatically processed by each Identity. Thus, succeeding Attribute does not result into decidable Requests for the peer. They are only informed about the change.Examples  Changing IdentityAttributes because of name changes, a move to a new address or change of communication details  An Identity receiving a new telephone number but does not want to share this new telephone number to every peer">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -397,7 +397,7 @@ <h1 id="examples">Examples</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/use-cases.html b/integrate/use-cases.html
index 9192ffb92..a7e862653 100644
--- a/integrate/use-cases.html
+++ b/integrate/use-cases.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Use Cases">
     <meta itemprop="description" content="            Title                                    Layer ⌄                                                                        Actor ⌄                                                                                                            Category ⌄                                                                        Component ⌄                                                                             Load Token by id and key (without having an account)                 Anonymous        Identity        AnonymousTokens        Runtime                                         Load Token by truncated reference (without having an account)                 Anonymous        Identity        AnonymousTokens        Runtime                                         Accept incoming Request                 Consumption        Identity        Requests        Runtime                                         Check if incoming Request can be accepted                 Consumption        Identity        Requests        Runtime                                         Check if incoming Request can be rejected                 Consumption        Identity        Requests        Runtime                                         Check if outgoing Request can be created                 Consumption        Identity        Requests        Runtime                                         Create a shared Attribute copy                 Consumption        Identity        Attributes        Runtime                                         Create an Attribute                 Consumption        Identity        Attributes        Runtime                                         Create and complete outgoing Request from Relationship Template Response                 Consumption        Identity        Requests        Runtime                                         Create outgoing Request                 Consumption        Identity        Requests        Runtime                                         Discards outgoing Request                 Consumption        Identity        Requests        Runtime                                         Execute a RelationshipAttributeQuery                 Consumption        Identity        Attributes        Runtime                                         Execute a ThirdPartyAttributeQuery                 Consumption        Identity        Attributes        Runtime                                         Execute an IdentityAttributeQuery                 Consumption        Identity        Attributes        Runtime                                         Get Attribute                 Consumption        Identity        Attributes        Runtime                                         Get AttributeListener                 Consumption        Identity        AttributeListeners        Runtime                                         Get Attributes of peer                 Consumption        Identity        Attributes        Runtime                                         Get Attributes shared to peer                 Consumption        Identity        Attributes        Runtime                                         Get incoming Request                 Consumption        Identity        Requests        Runtime                                         Get outgoing Request                 Consumption        Identity        Requests        Runtime                                         Query AttributeListeners                 Consumption        Identity        AttributeListeners        Runtime                                         Query Attributes                 Consumption        Identity        Attributes        Runtime                                         Query incoming Requests                 Consumption        Identity        Requests        Runtime                                         Query outgoing Requests                 Consumption        Identity        Requests        Runtime                                         Reject incoming Request                 Consumption        Identity        Requests        Runtime                                         DELETE REST Endpoint                 Device        Integrator        Integration        Connector                                         Get Profile by Enmeshed Address                 Device        App        Profiles        AppRuntime                                         Get Profile                 Device        App        Profiles        AppRuntime                                         Get Profiles                 Device        App        Profiles        AppRuntime                                         Get support Information                 Device        Integrator        Monitoring        ConnectorRuntime                                         Get the Connector health status                 Device        Integrator        Monitoring        ConnectorRuntime                                         Get the Connector version information                 Device        Integrator        Monitoring        Connector                                         Get the number of requests and the status codes that were returned by the Connector                 Device        Integrator        Monitoring        Connector                                         GET REST Endpoint                 Device        Integrator        Integration        Connector                                         POST REST Endpoint                 Device        Integrator        Integration        Connector                                         PUT REST Endpoint                 Device        Integrator        Integration        Connector                                         Rename Profile                 Device        User        Profile        AppRuntime                                         Cancel Action                 Human        User        User Action        App                                         Device External UseCase                 Human        User        User Action        App                                         Enter Data (on screen)                 Human        User        User Action        App                                         Navigate to (screen) Screen                 Human        User        User Action        App                                         Negative Action                 Human        User        User Action        App                                         Positive Action                 Human        User        User Action        App                                         Scan QR-Code (on different device)                 Human        User        User Action        App                                         Select Item (on screen)                 Human        User        User Action        App                                         Accept Relationship Change                 Transport        Identity        Relationships        Runtime                                         Create own RelationshipTemplate                 Transport        Identity        RelationshipTemplates        Runtime                                         Create own Token                 Transport        Identity        Tokens        Runtime                                         Create Relationship with RelationshipTemplate                 Transport        Identity        Relationships        Runtime                                         Create Token for File                 Transport        Identity        Files        Runtime                                         Create Token for own Relationship Template                 Transport        Identity        RelationshipTemplates        Runtime                                         Download File of Attachment                 Transport        Identity        Messages        Runtime                                         Download File                 Transport        Identity        Files        Runtime                                         Get Attributes for Relationship                 Transport        Identity        Relationships        Runtime                                         Get currently used Device                 Transport        Identity        Account        Runtime                                         Get currently used Identity                 Transport        Identity        Account        Runtime                                         Get Device Onboarding Info                 Transport        Identity        Devices        Runtime                                         Get Device Onboarding Token                 Transport        Identity        Devices        Runtime                                         Get Device                 Transport        Identity        Devices        Runtime                                         Get File Metadata of Attachment                 Transport        Identity        Messages        Runtime                                         Get Message by MessageId                 Transport        Identity        Messages        Runtime                                         Get or load File                 Transport        Identity        Files        Runtime                                         Get own File                 Transport        Identity        Files        Runtime                                         Get Relationship by Address                 Transport        Identity        Relationships        Runtime                                         Get Relationship by RelationshipId                 Transport        Identity        Relationships        Runtime                                         Get Relationship Template                 Transport        Identity        RelationshipTemplates        Runtime                                         Get synchronization status with Backbone                 Transport        Identity        Account        Runtime                                         Get Token by TokenID                 Transport        Identity        Tokens        Runtime                                         Load item from truncated reference                 Transport        Identity        Account        Runtime                                         Load Relationship Template created by others                 Transport        Identity        RelationshipTemplates        Runtime                                         Load Token created by others                 Transport        Identity        Tokens        Runtime                                         Query Devices                 Transport        Identity        Devices        Runtime                                         Query Files                 Transport        Identity        Files        Runtime                                         Query Messages                 Transport        Identity        Messages        Runtime                                         Query Relationship Templates                 Transport        Identity        RelationshipTemplates        Runtime                                         Query Tokens by parameters                 Transport        Identity        Tokens        Runtime                                         Reject Relationship Change                 Transport        Identity        Relationships        Runtime                                         Send message to recipient(s)                 Transport        Identity        Messages        Runtime                                         Synchronize updates of Backbone                 Transport        Identity        Account        Runtime                                         Update Device                 Transport        Identity        Devices        Runtime                                         Upload own File                 Transport        Identity        Files        Runtime                ">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -1451,7 +1451,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate.html b/operate.html
index b40622ee0..99d92fe32 100644
--- a/operate.html
+++ b/operate.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Operate enmeshed">
     <meta itemprop="description" content="Looking to set up and maintain a connector in your own infrastructure? No worries, we’ve got you covered!">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -457,7 +457,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/configuration.html b/operate/configuration.html
index efe996971..c511cd716 100644
--- a/operate/configuration.html
+++ b/operate/configuration.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Configuration">
     <meta itemprop="description" content="Mounting a config file  Create a config file in JSON format in a folder of your choice.      Fill the config file with your desired configuration (it’s sufficient to add values you want to change; the Connector will merge your config file with the default configuration) Example:    {  &quot;infrastructure&quot;: {    &quot;httpServer&quot;: {      &quot;enabled&quot;: true,      &quot;apiKey&quot;: &quot;an-api-key&quot;    }  }}        Mount the created config file into the Docker container (e.g. to /config.json). See the official documentation for more information on how to mount files into a Docker container. This is also possible using docker compose.  Set the environment variable CUSTOM_CONFIG_LOCATION to the path you mounted your config file to (e.g. CUSTOM_CONFIG_LOCATION=&quot;/config.json&quot;).There is also an example config file available. It sets some default values, please only use the fields you requireEnvironment variablesThe configuration can also be done using environment variables. This feature is included in the Connector since version 2.2.1.Parsing rules      Nested fields can be represented using a colon (:) as a separator.    The : separator doesn’t work with environment variable hierarchical keys on all platforms. The double underscore (__) is supported on all platforms (e.g. bash does not support the : separator but it supports __ ). The Connector will therefore convert __ to : so you can use it on that systems.    The parameter casing must be the same as the config file casing.  The strings “true” and “false” are converted to the respective boolean values.  Number strings (&quot;1&quot; / &quot;1.1&quot;) will be converted to the respective number types.  Complex structures (arrays, objects) are not supported. (=&gt; modules:aModule:aKey=&#39;{&quot;a&quot;: &quot;x&quot;, &quot;b&quot;: &quot;y&quot;}&#39; or modules:aModule:aKey=&#39;[&quot;a&quot;, &quot;b&quot;]&#39; is not valid)ExampleYou want to configure the following values:{  &quot;infrastructure&quot;: {    &quot;httpServer&quot;: {      &quot;enabled&quot;: true,      &quot;port&quot;: 8080,      &quot;apiKey&quot;: &quot;an-api-key&quot;    }  }}  The first value can be configured using the variable infrastructure:httpServer:enabled=&quot;true&quot;. Note that the value is represented as a string in the environment variable and the Connector will rewrite it to its boolean representation.  The second value can be configured using the variable infrastructure:httpServer:port=&quot;8080&quot;. Note that the value is represented as a string in the environment variable and the Connector will rewrite it to its number representation.  The third value can be configured using the variable infrastructure:httpServer:apiKey=&quot;an-api-key&quot;.Configuration optionsThe Connector provides the following configuration parameters:{    &quot;debug&quot;: false,    &quot;transportLibrary&quot;: {        &quot;baseUrl&quot;: &quot;https://prod.enmeshed.eu&quot;,        &quot;platformClientId&quot;: &quot;CLIENT_ID&quot;,        &quot;platformClientSecret&quot;: &quot;CLIENT_SECRET&quot;    },    &quot;database&quot;: {        &quot;connectionString&quot;: &quot;mongodb://[username:password@]host1[:port1][,...hostN[:portN]][/[defaultauthdb][?options]]&quot;,        &quot;dbName&quot;: &quot;a-db-name&quot;    },    &quot;infrastructure&quot;: { ... },    &quot;modules&quot;: { ... }}You can validate the config using our schema file. This is possible for example with VSCode or online tools like jsonschemavalidator.net.debug availbable since version 3.3.0⚠️ Do not turn on debug mode in production environments.The debug flag configures if the Connector is set to production or debug mode. Defaults to false. Can also be configured using the environment variable DEBUG.transportLibrary      baseUrl default: &quot;https://prod.enmeshed.eu&quot;    The base url is used to communicate with the enmeshed platform. It can be changed to use a custom enmeshed Backbone.        platformClientId required    The client id is required to communicate with the enmeshed platform. It can be acquired from the enmeshed Support.        platformClientSecret required    The client secret is required to communicate with the enmeshed platform. It can be acquired from the enmeshed Support.  database      connectionString required    At this point the connection to the database can be configured. The connection string must follow the MongoDB Connection String URI Format.        dbName default: &quot;default&quot;    The dbName string is used as the name of the MongoDB database, prefixed with acc-. You can use any name you like, but keep in mind that changing it later will NOT rename the database. Instead a new database will be created, together with a new enmeshed identity. Even though the old database will still exist, the Connector will not be able to access the data until you change the dbName back to its original value.    If you would like to use multiple Connectors with distinct identities (one identity per Connector) running on the same database, you have to specify a unique dbName for each of them.    Note: If you are using the Connector in combintation with a FerretDB, you have to pay attention to the database name restrictions specified in the FerretDB documentation.  infrastructureEach infrastructure can be enabled or disabled by passing true / false to enabled.httpServerThe HTTP server is the base for the coreHttpApi Module. It opens an express HTTP server where Modules can register endpoints.Sample Configuration:{  // ...  &quot;infrastructure&quot;: {    &quot;httpServer&quot;: {      &quot;enabled&quot;: true,      &quot;cors&quot;: {        &quot;origin&quot;: false      },      &quot;apiKey&quot;: &quot;an-api-key&quot;    }  }}      enabled default: true    Enable or disable the HTTP server.        cors default: { &quot;origin&quot;: false }    configure the CORS middleware. Valid options can be found here.        apiKey required    Define the API-Key the Connector should use to authenticate requests.    The API-Key can be chosen arbitrarily and has to be sent with every request in the X-API-KEY HTTP-Header.    There are no limitations regarding the allowed characters. We recommend using an API-Key that is at least 20 characters long.    The API-Key protects your Connector from unauthorized access and should therefore be kept secret.        helmetOptions default: depending on the connector mode    Configure the helmet middleware.    Defaults to {} in production mode. In debug mode the following options are used:    {  &quot;contentSecurityPolicy&quot;: {    &quot;directives&quot;: {      &quot;defaultSrc&quot;: [],      &quot;scriptSrc&quot;: [&quot;&#39;self&#39;&quot;],      &quot;styleSrc&quot;: [&quot;&#39;self&#39;&quot;, &quot;&#39;unsafe-inline&#39;&quot;, &quot;https://fonts.googleapis.com&quot;],      &quot;imgSrc&quot;: [&quot;&#39;self&#39;&quot;, &quot;https://enmeshed.eu&quot;, &quot;data:&quot;],      &quot;connectSrc&quot;: [&quot;&#39;self&#39;&quot;],      &quot;upgradeInsecureRequests&quot;: null    }  }}      modulesEvery Module can be enabled or disabled by passing true / false to enabled. Read more about the Module by clicking on the  icon in each title.amqpPublisher Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;amqpPublisher&quot;: {      &quot;enabled&quot;: false,      &quot;url&quot;: &quot;amqp://example.com:5672&quot;,      &quot;exchange&quot;: &quot;myExchange&quot;    }  }}      enabled default: false    Enable or disable the AMQP Publisher Module.        url required    The URL of the AMQP server.        exchange default: &quot;&quot;    The name of the AMQP exchange to publish to.  autoAcceptRelationshipCreationChanges It is not recommended to use this Module for production scenarios.Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;autoAcceptRelationshipCreationChanges&quot;: {      &quot;enabled&quot;: false,      &quot;responseContent&quot;: {}    }  }}      enabled default: false    Enable or disable the autoAcceptRelationshipCreationChanges Module.        responseContent default: {}    The content that is used to accept the incoming Relationship Request.  coreHttpApi Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;coreHttpApi&quot;: {      &quot;enabled&quot;: true,      &quot;docs&quot;: {        &quot;enabled&quot;: false,        &quot;rapidoc&quot;: {          &quot;persistAuth&quot;: false        }      }    }  }}      enabled default: true    Enable or disable the coreHttpApi Module.        docs:enabled default: false    It is not possible to enable the docs in production mode.    Enable / disable the /docs/json and /docs/yaml routes and the rendered swagger / rapidoc documentations.        docs:rapidoc:persistAuth default: false    Authentication persistence can be a security risk. Use it with caution.    If set to true rapidoc persists the API Key in the local storage of the browser.  sync Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;sync&quot;: {      &quot;enabled&quot;: false,      &quot;interval&quot;: 60    }  }}      enabled default: false    Enable or disable the sync Module.        interval default: 60    The interval in seconds at which the sync Module will fetch changes from the Backbone.  PubSubPublisher Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;PubSubPublisher&quot;: {      &quot;enabled&quot;: false,      &quot;projectId&quot;: &quot;&quot;,      &quot;topic&quot;: &quot;&quot;,      &quot;keyFile&quot;: &quot;&quot;    }  }}      enabled default: false    Enable or disable the PubSub Publisher Module.        projectId required    The project id of the Google Cloud project.        topic required    The name of the PubSub topic to publish to.        keyFile required    The location of the key file to authenticate with the Google Cloud project.  webhooksV2 Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;webhooksV2&quot;: {      &quot;enabled&quot;: false,      &quot;targets&quot;: {},      &quot;webhooks&quot;: []    }  }}      enabled default: false    Enable or disable the webhooksV2 Module.        targets default: {}    Here you can predefine targets so you can reuse them for multiple webhooks.    A target consists of a URL as well as optional arbitrary headers, which the Connector should send as part of the request. Optionally, your URL can contain the placeholder {{trigger}}, which at runtime will be replaced with the event name that triggered the webhook (e.g. transport.messageReceived). This way, you can reuse the same target for multiple webhooks and still have different URLs for different events. See the code below for an example.    The server under the URL must respond to the request with a status code between 200 and 299. Otherwise the Connector will log a warning.        Example    {  // a target with headers  &quot;target1&quot;: {    &quot;url&quot;: &quot;https://example.com/enmeshed/webhook2&quot;,    // the following headers will be sent as part of the webhook    &quot;headers&quot;: {      &quot;a-header&quot;: &quot;a-value&quot;,      &quot;another-header&quot;: &quot;another-value&quot;    }  },  // a target without headers  &quot;target2&quot;: {    &quot;url&quot;: &quot;https://example.com/enmeshed/webhook&quot;  },  // a target with the {{trigger}} placeholder as part of the URL  &quot;target3&quot;: {    &quot;url&quot;: &quot;https://example.com/enmeshed/webhook/{{trigger}}&quot;  }}            webhooks default: []    The webhooks that will be called. A webhook consists of one or more Connector Events on which the webhook should be triggered, as well as a target to which the request should be sent. The target either is an inline definition of target as described above, or a name of a target defined in the targets object.        Example    [  {    &quot;triggers&quot;: [&quot;transport.messageReceived&quot;],    // inline declaration of a target    &quot;target&quot;: {      // see the targets section for a description of how to configure a target    }  },  {    &quot;triggers&quot;: [&quot;transport.messageReceived&quot;],    // a reference to a target defined in the &#39;targets&#39; object    &quot;target&quot;: &quot;target1&quot;  }]      Payload{  // the event name (e.g. transport.messageReceived) that triggered the webhook  &quot;trigger&quot;: &quot;transport.messageReceived&quot;,  // the data of the event  &quot;data&quot;: {}}You can find type definitions of the event data in the Connector Events section.TroubleshootingIf you encounter any problems while configuring the Connector, head over to the Troubleshooting site.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -779,7 +779,7 @@ <h2 id="troubleshooting">Troubleshooting</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/log-event-ids.html b/operate/log-event-ids.html
index b7b9b6377..5bc214f3c 100644
--- a/operate/log-event-ids.html
+++ b/operate/log-event-ids.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Log Event IDs">
     <meta itemprop="description" content="            EventId.Id      EventId.Name                  645028      AzureStorageAccount.ErrorDeletingBlob              516591      AzureStorageAccount.ErrorListingAllBlobs              599235      Challenges.DeleteExpiredChallenges.CancellationRequested              916630      Challenges.DeleteExpiredChallenges.DeletionSuccessful              715507      DefaultRabbitMqPersistentConnection.ConnectionError              454129      DefaultRabbitMqPersistentConnection.ConnectionIsBlocked              119836      DefaultRabbitMqPersistentConnection.ConnectionIsShutdown              143946      DefaultRabbitMqPersistentConnection.ConnectionThrewAnException              277894      Devices.ChangePassword.ChangedPasswordForDevice              436321      Devices.CreateIdentity.CreatedIdentity              383136      Devices.CreateTier.CreatedTier              950845      Devices.DirectPushService.DeletingDeviceRegistration              624412      Devices.DirectPushService.ErrorWhileTryingToSendNotification              628738      Devices.DirectPushService.UnregisteredDevice              776010      Devices.MarkDeviceAsDeleted.MarkedDeviceAsDeleted              219823      Devices.RegisterDevice.RegisteredDevice              949322      EventBusAzureServiceBus.ErrorHandlingMessage              726744      EventBusAzureServiceBus.ErrorWhileExecutingEventHandlerCausingRetry              146670      EventBusAzureServiceBus.ErrorWhileProcessingIntegrationEvent              630568      EventBusAzureServiceBus.EventWasNotProcessed              341537      EventBusAzureServiceBus.NoSubscriptionForEvent              302940      EventBusAzureServiceBus.SendingIntegrationEvent              712382      EventBusGoogleCloudPubSub.ErrorHandlingMessage              304842      EventBusGoogleCloudPubSub.ErrorWhileExecutingEventHandlerType              590747      EventBusGoogleCloudPubSub.NoSubscriptionForEvent              830408      EventBusGoogleCloudPubSub.SendingIntegrationEvent              411326      EventBusRabbitMQ.ErrorOnPublish              288394      EventBusRabbitMQ.ErrorWhileExecutingEventHandlerType              702822      EventBusRabbitMQ.ErrorWhileProcessingIntegrationEvent              980768      EventBusRabbitMQ.NoSubscriptionForEvent              585231      EventBusRabbitMQ.PublishedIntegrationEvent              259125      ExceptionFilter.ErrorWhileProcessingRequestToUri              799306      ExceptionFilter.InvalidUserInput              938218      ExceptionFilter.RequestBodyTooLarge              293800      ExecutionTime              293800      ExecutionTime              629592      Files.SanityCheck.NoBlobForFileId              487180      Files.SanityCheck.NoDatabaseEntryForBlobId              358892      GoogleCloudStorage.ErrorBlobWithNameExists              304533      GoogleCloudStorage.ErrorDeletingBlobWithName              997942      GoogleCloudStorage.ErrorDownloadingBlobWithName              998879      GoogleCloudStorage.ErrorListingAllBlobs              166344      GoogleCloudStorage.ErrorUploadingBlobWithName              724322      LoggingBehavior.HandledRequest              859729      Messages.SanityCheck.NoBlobForMessageId              809167      Messages.SanityCheck.NoDatabaseEntryForBlobId              868289      Quotas.CreateQuotaForIdentity.CreatedQuotaForIdentities              346835      Quotas.CreateQuotaForTier.CreatedQuotaForTier              247156      Quotas.DeleteQuotaForIdentity.DeletedQuota              519284      Quotas.DeleteTierQuotaDefinition.DeletedTierQuotaDefinition              811934      Quotas.IdentityCreatedIntegrationEventHandler.IdentityCreated              151788      Quotas.TierCreatedIntegrationEventHandler.TierCreated              582359      Quotas.TierDeletedIntegrationEventHandler.TierDeleted              664861      Relationships.RelationshipsRepository.ErrorTryingToSaveRelationshipChange              349287      Relationships.SanityCheck.NoBlobForRelationshipChangeId              231727      Relationships.SanityCheck.NoBlobForRelationshipTemplateId              429922      Relationships.SanityCheck.NoDatabaseEntryForBlobId              232800      Relationships.SanityCheck.NoDatabaseEntryForBlobId              525684      Synchronization.SanityCheck.NoBlobForDatawalletModificationId              560290      Synchronization.SanityCheck.NoDatabaseEntryForBlobId              826083      Tokens.SanityCheck.NoBlobForTokenId              271286      Tokens.SanityCheck.NoDatabaseEntryForBlobId      ">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -550,7 +550,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/modules.html b/operate/modules.html
index 5b03d2db4..3f249a746 100644
--- a/operate/modules.html
+++ b/operate/modules.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Modules">
     <meta itemprop="description" content="Since the Connector is based on the Runtime, all Modules of the Runtime are also available in the Connector.Additionally, the Connector defines its own Modules that only make sense in the context of a Connector and are therefore not defined in the Runtime.Read more about the Module configuration on the  icon in each title.AMQP Publisher This Module proxies all events of the internal event bus of the Connector to an exchange in a configurable AMQP server.Compared to webhooks, this gives you the full feature set of a message broker. There are multiple scenarios where this Module outweighs the Webhooks Module. For example:  You need persistence for the triggered events.  You want to integrate enmeshed into an already existing message broker.Auto Accept Relationship Creation Changes It is not recommended to use this Module for production scenarios.The autoAcceptRelationshipCreationChanges Module listens to the events about incoming Relationship Change Requests. It immediately accepts the Requests, using the configured responseContent.Keep in mind that you need to synchronize the state of the Connector with the Backbone in order to receive incoming Relationship Requests. The sync Module automates this, but you can also do this manually by calling the /api/v2/Account/Sync route.Core HTTP API This Module contains the HTTP API with all enmeshed base functionalities.Sync The sync Module regularly fetches changes from the Backbone (e.g. new Messages / new incoming Relationship Requests). This process automatically triggers the events used by other Modules like the webhooks Module.PubSub Publisher This Module proxies all events of the internal event bus of the Connector to a configurable PubSub instance.Compared to webhooks, this gives you the full feature set of a message broker. There are multiple scenarios where this Module outweighs the Webhooks Module. For example:  You need persistence for the triggered events.  You want to integrate enmeshed into an already existing message broker.WebhooksV2 With the REST API, pull mechanisms are supported. However, as there are many bidirectional scenarios within enmeshed, a push mechanism is favorable: the Connector is synchronizing its state with the Backbone and notifies the organization’s backend services about changes.For this, the Connector supports the configuration of webhooks which are called every time a specific Connector Event is triggered (e.g. a new Message has been received =&gt; transport.messageReceived).Keep in mind that you need to synchronize the state of the Connector with the Backbone in order to receive events. The sync Module automates this, but you can also do this manually by calling the /api/v2/Account/Sync route.Requesting ModulesIn case you need a further Module for your application, please state a feature request.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -347,7 +347,7 @@ <h3 id="requesting-modules">Requesting Modules</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/overview-of-connector-operations.html b/operate/overview-of-connector-operations.html
index 4b9eb9b86..dbf5abfeb 100644
--- a/operate/overview-of-connector-operations.html
+++ b/operate/overview-of-connector-operations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Overview of Connector operations">
     <meta itemprop="description" content="Basic TasksStopping the ConnectorStarting the Connector after a DowntimeBe advised that before starting the Connector after a downtime, you should ensure that the data within the database is on the most up-to-date time. Once the Connector starts its internal synchronization mechanism, it will update the database with the new information from the Backbone and if there are any automatismns set up (e.g. automatically accept relationships) the Connector updates the database with this new information. Thus, if the database is not on the very last point in time, there would be two inconsistent versions split across two databases.UpdateBackup &amp; RecoveryAll of the Connector data is stored in a MongoDB compatible database. Therefore we suggest you to use MongoDB replicas in a productive setup, to avoid having data loss.Additionally, offline backups of the replicas might make sense. For backup and recovery methods visit the official MongoDB docs. These backups might come in handy if the data within the database was compromised.In general, there is no need to backup the Connector itself. However, it makes sense to backup configuration and log files. Additionally, it might speed up the recovery process if a complete system image of the Connector is available.For a recovery, you should be able to just start the Connector again with the recovered database. For recovering the database itself, please also refer the MongoDB documentation.If you use FerretDB as your database engine make sure to backup the data of the underlying PostgreSQL database. Read more about this in the PostgreSQL documentation.Proposed System TasksCheck HealthThe Business Connector exposes a health route. You can check the health with a http request to &lt;connector-url&gt;/health.Check Available ResourcesCheck CPU WorkloadThe CPU workload can be checked using tools like htop or ctop on the host system.Check Memory ConsumptionThe Memory Consumption can be checked using tools like htop or ctop on the host system.Check Harddisk QuotaThe Harddisk Quota can be checked using linux tools like df. Please ensure, that sufficient free space is available.Check for Connector UpdatesNew Connector versions are regularly published to the given Docker registry. Depending on your installation method, the Docker image can be automatically updated by the provided Docker registry.Check for System and Docker UpdatesPlease consult the documentation of your operating system about system updates. Additionally, the Docker runtime should be regularly updated as well.We recommend to keep your operating system and Docker as up to date as possible.Check Error LogsYou can check the log using docker logs &lt;your-container-name&gt; or by checking the mounted log filesProposed Connector TasksAs some of the operative tasks should be done on a regular basis, please find a proposal for these tasks below.Check Access to Key MaterialCheck old MaterialCheck Connector Systems  Every Connector instance and host system should be regularly checked for available resources (CPU, RAM, HDD) and system updates.Check Third-Party Systems  Every third-party system (e.g. database, event buses, network components) and host system should be regularly checked for available resources (CPU, RAM, HDD) and system updates.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -366,7 +366,7 @@ <h3 id="check-third-party-systems">Check Third-Party Systems</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/performance-considerations.html b/operate/performance-considerations.html
index 96051fe36..b7c68092f 100644
--- a/operate/performance-considerations.html
+++ b/operate/performance-considerations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Performance Considerations">
     <meta itemprop="description" content="Scaling HorizontallyUsing multiple connectors with the same identity to scale horizontally and balance the workload across all available connectors is not supported at the moment.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -295,7 +295,7 @@ <h2 id="scaling-horizontally">Scaling Horizontally</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/privacy-considerations.html b/operate/privacy-considerations.html
index 8e4185e29..0cac87739 100644
--- a/operate/privacy-considerations.html
+++ b/operate/privacy-considerations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Privacy Considerations">
     <meta itemprop="description" content="Please be aware that personal or sensitive plaintext data is processed and stored in the Connector and the corresponding MongoDB database. The same applies to secret and private keys which should be treated as strictly confidential.Thus the access to the Connector and its database should be kept to a bare minimum of authorized users or systems. Please refer to the Security Considerations for details.As the Connector is running on the customer’s infrastructure in the complete authority of the customer, it is in the customer’s liability to ensure a secure and legal operation.Which data is processed by the Connector?Deleting Data">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -301,7 +301,7 @@ <h2 id="deleting-data">Deleting Data</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/security-considerations.html b/operate/security-considerations.html
index 5be36ff8f..d68feee3b 100644
--- a/operate/security-considerations.html
+++ b/operate/security-considerations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Security Considerations">
     <meta itemprop="description" content="The most important thing you have to keep in mind that the Connector is usually running on your landscape and in your authority. This is why you are also responsible for the security of the Connector and its data.And as the Connector is handling very sensitive data (please see chapter Privacy), it should be treated as any other business system - with the same requirements in terms of privacy, security, access or network setup.UpdatesAs with every software, it is important that you update the Connector regularly from the official Docker repositories. We do our best to keep the whole enmeshed project (of course including the Connector) as up-to-date as possible, having multiple checks with regards to security and the open-source-software lifecycle.Additionally, any software component the Connector or its data touches should be updated regularly.Examples are:  the Docker host system (operating system, virtual machine, …)  the Docker Runtime  the database (e.g. MongoDB or FerretDB)  the firewall  the virus scanner  the firmwares of any (network) component  possible integration platforms and modulesTrustAlthough enmeshed introduces a secure way of knowing who is sending messages to the Connector, and the corresponding Backbone is blocking messages from unknown parties, you shouldn’t trust others to not send you invalid, incorrect, illegal, or outright harmful data over the secure connection.Especially the encrypted data coming from the Backbone - which hasn’t been decrypted yet - might be harmful. We cannot check if the data is correctly encrypted. Only the Connector in your landscape does this automatically (in terms of decrypting the data and verifying its digital signature).This brings us to the next point: Virus Scans.Virus ScansYou should do Virus Scans regularly whenever sending or receiving data. However, the Connector has no integration capability for Virus Scanners (yet). This means, we cannot call for a virus scan while we are encrypting or decrypting enmeshed payload.Thus please consider scanning the host systems and the database for viruses regularly. Additionally, even encrypted data sent to and received from the Backbone should be scanned for viruses.NetworkingIt is best practice to block unnecessary access from and to software components between networks. In this chapter it is described which access the Connector actually requires and which requests could be blocked.Outbound External Connection: InternetThe Connector uses an TLS-secured Internet connection to the enmeshed Backbone which runs on the domain https://prod.enmeshed.eu. Your firewall must not block access to this domain, otherwise the Connector won’t work.To access the latest updates, other routes might need to be opened within the firewall settings.No Inbound External ConnectionsThe Connector synchronizes itself with the Backbone by a long-polling mechanism (it accesses the Internet). There is no data transfer triggered by the Backbone (or other users) and thus, there is no need for opening up special ports or reverse proxies for inbound connections from the Internet.Oubound Communication to Internal NetworksThe Connector does need to access its database. Access to other networks or systems from the Connector can be blocked unless there is a synchronization route (webhook) set up in the Connector configuration. Otherwise, the Connector needs to access the provided internal domains for submitting new data.Inbound Communication from Internal NetworksDepending on the integration setup, access to the Connector from the internal network could be blocked for the majority of requests. Usually, only requests from the integration systems, the developers or administrators need to be allowed.Authentication and User ManagementSo far, the Connector supports API-Key authentication to securely authenticate technical users. These API-Keys are random character strings with a high entropy and should be kept confidential at all times. Each internal system communicating with the Connector should receive its own API-Key.There is no authorization set up, thus every API-Key can call any API of the Connector API.End user authentication, e.g. business users accessing the system, should be done on the respective business system. Usually, there is no need for end users to access the Connector and thus they should not have access to the Connector (from a network and authentication perspective).Kernel DumpsKernel dumps can be a useful tool for diagnosing and troubleshooting system issues. However, they can also be a security risk if they contain sensitive information such as encryption keys. If an attacker gains access to a kernel dump file, they may be able to extract this information and use it to compromise the security of your system.As the Connector does not have access to the host system, it cannot directly control whether or not kernel dumps are enabled. Therefore, the administrator of the host system makes a decision on whether or not to disable kernel dumps based on their own security policies and risk tolerance.The recommended course of action is to disable kernel dumps on the host system, outside a development environment, where the Connector is running. This is in line with the recommendation of libsodium, the used encryption library.This can typically be done by modifying the kernel parameters or configuration settings.API key rotationIt is important to ensure that API keys are secure and cannot be easily compromised. One of the key aspects of API key security is regular rotation and expiration. If an API key is not rotated or expired, it can potentially be used by an attacker who has obtained the key through unauthorized means.Docker Compose File Security ConsiderationsDocker Compose is a tool to easily set up and host a complete landscape by running multiple Docker containers, configuring them and linking them together with a network. For development, testing and demonstration purposes, the enmeshed team provides Docker Compose files throughout this site or on GitHub. Please be aware, that those Docker Compose files should not be used in a public or productive environment, as they could contain insecure or otherwise unstable configurations, e.g. default passwords or the missing encryption at rest for MongoDB configuration. If you choose to use Docker Compose files in a public or production environment, it is important to educate yourself on how to create production-grade Docker Compose files to ensure the security of your system.Setup FirewallA firewall is a security system that monitors and controls incoming and outgoing network traffic based on predetermined security rules. By implementing a firewall, you can block unauthorized access to your network and prevent malicious traffic from entering your system.Allowing for potentially insecure protocols such as HTTP may expose sensitive information in transit to malicious parties, putting the system and its users at risk of data theft or other cyber attacks. Furthermore, the use of unsupported protocols may result in unintended side effects that could compromise system functionality or stability.To mitigate this risk, it is recommended that the connector restricts the supported protocols to HTTPS, which is a secure protocol that encrypts information in transit. This will help prevent sensitive information from being exposed to malicious parties. Additionally, any feature that allows developers to override the protocol check should be explicitly enabled and documented to ensure that it is used judiciously and with caution.Furthermore, an allowlist can be used to limit access to the system to only trusted sources, reducing the risk of unauthorized access and potential security vulnerabilities.When configuring the allowlist for the connector, it is important to include all necessary URLs while keeping the list as minimal as possible.One important consideration when configuring the allowlist is the baseUrl of the used Backbone. The baseUrl should be the minimum required for the allowlist to ensure that the connector is fully functional. Including unnecessary URLs in the allowlist can increase the attack surface and create potential security vulnerabilities.However, it is also important to consider other URLs that may need to be included in the allowlist, such as update URLs for Docker Hub, images, GitHub, Linux update environments, and other sources. These URLs may be necessary for the proper functioning of the system and should be carefully evaluated and included in the allowlist if deemed necessary.To ensure the security and integrity of the system, it is recommended to regularly review and update the allowlist as necessary. This includes removing any URLs that are no longer needed and adding new URLs that may be required.Database SecurityIt is crucial to secure databases, and in the case of MongoDB, it is essential to implement proper security measures to mitigate the risks associated with its default insecure configuration.On this page we have summarized some tips for the use of MongoDB and FerretDB. A good source for further information on these tips is the website of the respective database.With this page, we address what we consider to be the most important security tips. Even if you follow these tips, a security incident may occur.      Data encryption: Data stored in the database should be encrypted to ensure that even if an attacker gains access to the storage device, they cannot read the data. MongoDB provides built-in encryption at rest features, which can be enabled to secure data. For all databases it is possible to perform data encryption with storage encryption at the file system level or the block level. On Linux, file system encryption options include eCryptfs or EncFS and Block level options include dm-crypt + LUKS.        Network access restrictions: MongoDB should only be accessible through the connector and should not be directly accessible over the public network. This can be achieved through proper network configuration, such as setting up firewalls to restrict access.        Strong passwords and connection strings: All user credentials and connection strings should be strong and complex, to prevent unauthorized access to the database.        Regular updates and maintenance: Regular updates should be performed to keep the database up-to-date and to fix any known security vulnerabilities.  When you are using FerretDB as your database read more about security in the FerretDB documentation.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -418,7 +418,7 @@ <h2 id="database-security">Database Security</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/setup-with-docker-compose.html b/operate/setup-with-docker-compose.html
index 9f5eb5f6a..df89ee661 100644
--- a/operate/setup-with-docker-compose.html
+++ b/operate/setup-with-docker-compose.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Setup with Docker Compose">
     <meta itemprop="description" content="PrerequisitesMongoDBThe Connector requires a MongoDB compatible database as its data storage. MongoDB is a document-oriented database. For compatibility and security reasons, the most up-to-date version of MongoDB should be used.For more information, please see https://www.mongodb.com.If you want to use an open-source database you can use FerretDB instead.Container RuntimeThe Connector requires a Container Runtime like Docker or Kubernetes: Docker is a virtualization technology which introduces highly portable software containers. The Connector is shipped and updated as such a Docker container - the Docker Runtime is the runtime environment which can execute the Docker containers. For compatibility and security reasons, the most up-to-date version of the Docker Runtime should be used.For more information, please see https://www.docker.com.Visit the official docker docs for installation guides.Hardware RequirementsNo special hardware requirements have been identified so far and as always, hardware requirements strongly correlate with the envisoned usage scenario.A good starting point for hosting the Docker image of the Connector would be the following:  1 CPU  512MB RAM  1GB HDDDepending on the usage scenario, higher hardware requirements might be necessary.Internet ConnectivityA reliable and fast internet connection is mandatory for running the Connector. However, the Connector is only communicating with the Backbone so the corresponding domain (e.g. https://prod.enmeshed.eu) can be whitelisted and the associated certificate can be additionally pinned.List docker image tagsRead more about listing available docker image tags here.Familiarize with our policiesBefore setting up enmeshed, you should familiarize yourself with our Security Considerations and Privacy Considerations.Installation with DockerMake sure that you have installed docker compose. Visit the official installation guide for more information.ATTENTION: The Docker compose files we provide in this tutorial are not recommended to use in production scenarios. Please read Use Compose in production for more information on how to write a production-grade compose file and our Security Considerations.Option 1: docker compose including MongoDBGo through the following steps to start the Connector:  place the file examples/docker-compose-with-mongodb.yml as docker-compose.yml in a folder of your choice  create a config file that can be mounted inside the Connector. Fill the config file using the configuration docs and the example config file. If you used the yml-file from the first step, the connection string looks as follows:    mongodb://&lt;db-username&gt;:&lt;db-password&gt;@mongodb:27017        replace all &lt;placeholders&gt; in the compose file with the corresponding values  (optional) follow the steps under log file mounting if you want to persist and access the log files on the host system  execute docker compose up -d in the shellOption 2: docker compose with existing MongoDBVisit the official MongoDB website for installation without docker or cloud usage or the docker hub page for information about the installation with docker.Go through the following steps to start the Connector:  make your existing MongoDB available for the Connector  place the file examples/docker-compose-with-existing-mongodb.yml as docker-compose.yml in a folder of your choice  create a config file that can be mounted inside the Connector. Fill the config file using the configuration docs and the example config file  replace all &lt;placeholders&gt; in the compose file with the corresponding values  (optional) follow the steps under log file mounting if you want to persist and access the log files on the host system  execute docker compose up -d in the shellOption 3: docker compose with FerretDBGo through the following steps to start the Connector:  place the file examples/docker-compose-with-ferretdb.yml as docker-compose.yml in a folder of your choice  create a config file that can be mounted inside the Connector. Fill the config file using the configuration docs and the example config file. If you used the yml-file from the first step, the connection string looks as follows: mongodb://ferretdb:27017  replace all &lt;placeholders&gt; in the compose file with the corresponding values  (optional) follow the steps under log file mounting if you want to persist and access the log files on the host system  execute docker compose up -d in the shellInstallation with Kubernetes and HelmMake sure that you have a running Kubernetes cluster and that you have installed kubectl and Helm.You have to provide your own MongoDB instance. Visit the MongoDB website for installation without docker or cloud usage or the docker hub page for information about the installation with docker or install it in kubernetes via Helm.For the installation and configuration head over to the dedicated Connector Helm chart site.Validate the Connector installationYou can validate the Connector installation by checking its health route. Simply access &lt;connector-baseurl&gt;/health in your browser or using curl.If the swagger documentation is enabled you can also access it under &lt;connector-baseurl&gt;/docsLog file mounting  Uncomment the volume mapping in the created docker-compose.yml file  Create a folder where the log files shall be placed. Make sure that the process in the container has write access to the folder e.g. by executing chmod 777 &lt;folder&gt; on your created folder.  replace &lt;/folder/of/your/choice&gt; with the path to your created folderAPI platform hosted on the (development) ConnectorTo use the api platform hosted on the Connector you need to make the following config changes:      the http server must be enabled in the configuration of the Connector.    {  &quot;infrastructure&quot;: {    &quot;httpServer&quot;: {      &quot;enabled&quot;: true,      &quot;apiKey&quot;: &quot;an-api-key&quot;    }  }}            furthermore the API must be activated    {  &quot;modules&quot;: {    &quot;coreHttpApi&quot;: {      &quot;docs&quot;: {        &quot;enabled&quot;: true      }    }  }}            the API must not be used in production systems, therefore the tag “debug” must be activated    {  &quot;debug&quot;: true}      TroubleshootingIf you encounter any problems while setting up the Connector, head over to the Troubleshooting site.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -449,7 +449,7 @@ <h2 id="troubleshooting">Troubleshooting</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/setup-with-helm-charts.html b/operate/setup-with-helm-charts.html
index fa5c5c592..7d711578e 100644
--- a/operate/setup-with-helm-charts.html
+++ b/operate/setup-with-helm-charts.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Setup with Helm Charts">
     <meta itemprop="description" content="VersionsThe available Helm chart versions can be found on ArtifactHUB or in the GitHub Container Registry.We provide a new Helm chart version for each new Connector release and each Helm chart will deploy the Connector in the chart’s version. (Helm chart version 3.2.1 deploys Connector version 3.2.1)You can override the Connector version by setting the image.tag value in the Helm chart.ConfigurationThe Helm chart can be configured using a yaml file or the command line. The following table lists the configurable parameters of the Helm chart and their default values.You can also query the available options using the command line: helm show values oci://ghcr.io/nmshd/connector-helm-chart --version &lt;version&gt;            Parameter      Description      Default                  image.pullPolicy      The image’s PullPolicy      &quot;IfNotPresent&quot;              image.tag      The image’s tag. Available tags      The version of the Helm chart.              config      The configuration of the Connector in yaml or json format. Configuration options      {}                                           pod.securityContext      SecurityContext for the pod.      {}              pod.nodeSelector      NodeSelector for the pod.      {}              pod.tolerations      Tolerations for the pod.      []              pod.affinity      Affinity for the pod.      {}                                           pod.connector.environment      A list of environment variables for the Connector container. Can be used for configuring secrets.      []              pod.connector.securityContext      SecurityContext for the Connector container.      {}              pod.connector.resources      Resources for the Connector container.      {}              pod.connector.containerPort      The port the Connector is listening on. Must be the same as infrastructure.httpServer.port in the config.      80                                           pod.ferretdb.enabled      Enables / disables the FerretDB sidecar.      false              pod.ferretdb.image      The image used to deploy the FerretDB sidecar. Can be ferretdb ferretdb-dev or all-in-one      &quot;ferretdb&quot;              pod.ferretdb.tag      The tag used to deploy the FerretDB sidecar.      &quot;latest&quot;              pod.ferretdb.environment      A list of environment variables for the FerretDB container. Can be used for configuring secrets.      []              pod.ferretdb.securityContext      SecurityContext for the FerretDB container.      {}              pod.ferretdb.resources      Resources for the FerretDB container.      {}                                           service.type      The ServiceType of the service.      &quot;ClusterIP&quot;              service.port      The port of the service.      80      Example ConfigurationThe following example shows how to configure the Helm chart.config:  debug: true  modules:    coreHttpApi:      docs:        enabled: truepod:  connector:    environment:      - name: database__connectionString        valueFrom:          secretKeyRef:            name: db-connection-string            key: VALUE      - name: transportLibrary__platformClientId        value: test      - name: transportLibrary__platformClientSecret        valueFrom:          secretKeyRef:            name: platform-client-secret            key: VALUE      - name: infrastructure__httpServer__apiKey        valueFrom:          secretKeyRef:            name: api-key            key: VALUEIf you prefer json over yaml for the config section the following example is equivalent to the yaml example above.config: { &quot;modules&quot;: { &quot;coreHttpApi&quot;: { &quot;docs&quot;: { &quot;enabled&quot;: false } } } }# ...InstallationCreate a file named values.yaml with the desired configuration and run the following command to install the Helm chart.helm install &lt;installationName&gt; oci://ghcr.io/nmshd/connector-helm-chart --version &lt;version&gt; -f values.yamlInstallation with FerretDB all-in-oneThe Helm chart can be configured to deploy a FerretDB all-in-one instance as a sidecar. This image does not provide persistence, therefore this is useful e.g. for testing purposes or for a quick start.config:  debug: true  modules:    coreHttpApi:      docs:        enabled: true  database:    connectionString: &quot;mongodb://localhost:27017&quot;pod:  connector:    environment:      - name: transportLibrary__platformClientId        alueFrom:          secretKeyRef:            name: platform-client-id            key: VALUE      - name: transportLibrary__platformClientSecret        valueFrom:          secretKeyRef:            name: platform-client-secret            key: VALUE      - name: infrastructure__httpServer__apiKey        valueFrom:          secretKeyRef:            name: api-key            key: VALUE  ferretdb:    enabled: true    image: all-in-one">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -517,7 +517,7 @@ <h3 id="installation-with-ferretdb-all-in-one">Installation with FerretDB <code
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/support.html b/operate/support.html
index 0f3e2217b..66528f52b 100644
--- a/operate/support.html
+++ b/operate/support.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Support">
     <meta itemprop="description" content="SupportFor assisted support with the Connector or the Backbone provided by the j&amp;s-soft GmbH contact us via support[at]enmeshed.eu.Community support is a great way to get help and even contribute to the projects. Open bug reports and feature requests in the enmeshed issue tracker or share your feedback with the enmeshed team via the enmeshed discussions.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -297,7 +297,7 @@ <h2 id="support">Support</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/operate/troubleshooting-guide.html b/operate/troubleshooting-guide.html
index 68fb72bf7..754f4ee74 100644
--- a/operate/troubleshooting-guide.html
+++ b/operate/troubleshooting-guide.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -254,7 +254,7 @@ <h3>Operate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Troubleshooting Guide">
     <meta itemprop="description" content="Troubleshooting GuideFor any issues with the Connector make sure you checked the logs and the /Monitoring/* routes. The /Monitoring/Support route provides a lot of information about the current state of the Connector and you can for example detect misconfigurations.Common ErrorsConfig file mounting (EISDIR | invalid mode: RO)SymptomsOne of the following errors are logged during the startup of the Connector:  Error parsing your configuration file: [/config.json]: EISDIR: illegal operation on a directory, read  ERROR: for connector Cannot create container for service connector: invalid mode: ROHow to fix?Given the following filesystem structure:home/└── connector/    ├── config.json    └── docker-compose.ymlIf you mount /home/connector:/config.json:ro, the created /config.json in the container will be a directory. To fix this the mount has to be /home/connector/config.json:/config.json:ro or ./config.json:/config.json:ro (docker compose translates relative links to absolute links).Database Authorization ErrorSymptomsDuring the startup of the Connector, the following error is logged:[ERROR] ConnectorRuntime - Could not connect to the configured database. Try to check the connection string and the database status. Root error:  MongoServerError: Authentication failed.How to fix?This error can show up when you misuse the environment variables MONGO_INITDB_ROOT_USERNAME and/or MONGO_INITDB_ROOT_PASSWORD of the MongoDB Docker image. Even though their name is self-explanatory, you can easily read over the “INITDB” part in them. This means that the username and password you specify here are only used to initially create a database user. When you change them and then restart the container, the root username is not changed. If you want to change the root user’s name or password, look into the MongoDB documentation.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -338,7 +338,7 @@ <h3 id="database-authorization-error">Database Authorization Error</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/sitemap.xml b/sitemap.xml
index 6d009eb53..82b4ff062 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,631 +2,631 @@
 <urlset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd" xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
 <loc>/explore/how_does_enmeshed_work</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/example-scenarios</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/features</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/faq</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/integration</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/security</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/privacy</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/backbone</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/transport</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/consumption</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/integration</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/user-experience</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/app</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/backbone</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/connector</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/addresses</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/runtime</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/cryptography</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/blockchain</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/access-the-connector</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/attribute-values</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/connector-events</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/create-attribute-for-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/creating-complex-requests</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/data-model-overview</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/delete-identity-from-enmeshed</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/error-codes</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/event-introduction</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/faq</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/integration-example</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/process-received-enmeshed-onboarding-package-and-create-relationship</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/process-responses-to-outgoing-requests</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/propose-attribute-to-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/read-attribute-from-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/request-and-process-attributes-by-messages</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/request-and-response-introduction</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/request-persistent-consent-of-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requesting-authentication</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requesting-one-time-consents</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requests-and-requestitems</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requests-over-messages</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requests-over-templates</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/respond-to-incoming-requests</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/sending-messages-with-attachments</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/sending-messages</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/share-own-attribute-to-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/succeed-attribute-of-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/support</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/updating-identityattributes-of-yourself</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/use-cases</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/configuration</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/log-event-ids</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/modules</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/overview-of-connector-operations</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/performance-considerations</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/privacy-considerations</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/security-considerations</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/setup-with-docker-compose</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/setup-with-helm-charts</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/support</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/troubleshooting-guide</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/create-an-identity</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/delete-identity-from-enmeshed</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/delete-profile-from-the-app</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/get-overview-of-your-data</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/install-the-app</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/manually-fill-attributes-of-your-identity</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/process-received-enmeshed-onboarding-package-and-create-relationship</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/process-requests-of-contact</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/rename-profile-to-distinguish-multiple-profiles</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/secure-device-setup</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use/send-prefabricated-request-to-contact</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-anonymous-load-token-by-id-and-key-without-having-an-account</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-anonymous-load-token-by-truncated-reference-without-having-an-account</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-accept-incoming-request</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-check-if-incoming-request-can-be-accepted</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-check-if-incoming-request-can-be-rejected</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-check-if-outgoing-request-can-be-created</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-a-shared-attribute-copy</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-an-attribute</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-and-complete-outgoing-request-from-relationship-template-response</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-outgoing-request</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-discards-outgoing-request</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-execute-a-relationshipattributequery</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-execute-a-thirdpartyattributequery</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-execute-an-identityattributequery</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attribute</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attributelistener</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attributes-of-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attributes-shared-to-peer</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-incoming-request</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-outgoing-request</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-attributelisteners</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-attributes</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-incoming-requests</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-outgoing-requests</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-reject-incoming-request</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-delete_-rest-endpoint</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-profile-by-enmeshed-address</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-profile</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-profiles</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-support-information</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-the-connector-health-status</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-the-connector-version-information</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-the-number-of-requests-and-the-status-codes-that-were-returned-by-the-connector</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get_-rest-endpoint</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-post_-rest-endpoint</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-put_-rest-endpoint</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-rename-profile</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-cancel_-action</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-device_-external-usecase</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-enter_-data-on-screen</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-navigate-to-screen_-screen</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-negative_-action</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-positive_-action</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-scan_-qr-code-on-different-device</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-select_-item-on-screen</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-accept-relationship-change</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-own-relationshiptemplate</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-own-token</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-relationship-with-relationshiptemplate</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-token-for-file</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-token-for-own-relationship-template</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-download-file-of-attachment</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-download-file</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-attributes-for-relationship</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-currently-used-device</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-currently-used-identity</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-device-onboarding-info</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-device-onboarding-token</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-device</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-file-metadata-of-attachment</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-message-by-messageid</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-or-load-file</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-own-file</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-relationship-by-address</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-relationship-by-relationshipid</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-relationship-template</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-synchronization-status-with-backbone</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-token-by-tokenid</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-load-item-from-truncated-reference</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-load-relationship-template-created-by-others</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-load-token-created-by-others</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-devices</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-files</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-messages</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-relationship-templates</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-tokens-by-parameters</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-reject-relationship-change</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-send-message-to-recipients</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-synchronize-updates-of-backbone</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-update-device</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-upload-own-file</loc>
-<lastmod>2024-02-06T08:06:12+01:00</lastmod>
+<lastmod>2024-02-09T09:55:06+01:00</lastmod>
 </url>
 <url>
 <loc>/blog/introducing-enmeshed</loc>
diff --git a/use-case-anonymous-load-token-by-id-and-key-without-having-an-account.html b/use-case-anonymous-load-token-by-id-and-key-without-having-an-account.html
index 50389c9d4..946f37603 100644
--- a/use-case-anonymous-load-token-by-id-and-key-without-having-an-account.html
+++ b/use-case-anonymous-load-token-by-id-and-key-without-having-an-account.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Load Token by id and key (without having an account)">
     <meta itemprop="description" content="This use-case attempts to retrieve a Tokenby its id and secretKey without having an account on the Backbone, thus without an authentication.This can be used to fetch Tokens for Device Onboarding or Recovery.Parameters  The id of the Token.  The secretKey the Token was encrypted with, Base64URL encoded.On Success  Returns the corresponding Token.On Failure  There is no Token that matches the id.  The secretKey is not correct.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -468,7 +468,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-anonymous-load-token-by-truncated-reference-without-having-an-account.html b/use-case-anonymous-load-token-by-truncated-reference-without-having-an-account.html
index c6b503462..221817213 100644
--- a/use-case-anonymous-load-token-by-truncated-reference-without-having-an-account.html
+++ b/use-case-anonymous-load-token-by-truncated-reference-without-having-an-account.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Load Token by truncated reference (without having an account)">
     <meta itemprop="description" content="This use-case attempts to retrieve a Tokenby its truncatedReference without having an account on the Backbone, thus without an authentication.This can be used to fetch Tokens for Device Onboarding or Recovery.Parameters  The reference that contains all information to load a Token.On Success  Returns the corresponding Token.On Failure  There is no Token that matches the reference.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-accept-incoming-request.html b/use-case-consumption-accept-incoming-request.html
index 036f872f6..d3e05a515 100644
--- a/use-case-consumption-accept-incoming-request.html
+++ b/use-case-consumption-accept-incoming-request.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Accept incoming Request">
     <meta itemprop="description" content="This use-case attempts to accept an incoming LocalRequest with the corresponding parameters.It is advised to check if incoming Request can be acceptedin advance.Parameters  The id of the incoming Request.  The decision for each individual RequestItemexpressed as the appropriate Parameters defined in the Data Model.On Success  The Request is processed according to the decisions made.  A Message is sent to the requesting peer which contains the Response to the Request.  The LocalRequest is returnedOn Failure  The decisions do not match the RequestItems.  The decisions and values of respective RequestItems do not match the requested or required values, e.g. an E-Mail Address is wrong.  An item that has the mustBeAccepted field set was not accepted or left blank.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -500,7 +500,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-check-if-incoming-request-can-be-accepted.html b/use-case-consumption-check-if-incoming-request-can-be-accepted.html
index e7c77fc03..2fbcad850 100644
--- a/use-case-consumption-check-if-incoming-request-can-be-accepted.html
+++ b/use-case-consumption-check-if-incoming-request-can-be-accepted.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Check if incoming Request can be accepted">
     <meta itemprop="description" content="This use-case tests if an incoming LocalRequestcan be accepted with the given parameters without actually accepting it.This is great for checking if all required information of a Request was filled out in order to accept it, e.g. to update a user interface with the respective errors (and render an &#8220;Accept Button&#8221; as disabled) as long as there are errors.Parameters  The id of the incoming Request.  The decision for each individual RequestItemexpressed as the appropriate Parameters defined in the Data Model.On Success  Returns a RequestValidationResult that indicates if the Request can be accepted with the given parameters.On Failure  The decisions do not match the RequestItems.  The decisions and values of respective RequestItems do not match the requested or required values, e.g. an E-Mail Address is wrong.  An item that has the mustBeAccepted field set was not accepted or left blank.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -498,7 +498,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-check-if-incoming-request-can-be-rejected.html b/use-case-consumption-check-if-incoming-request-can-be-rejected.html
index 2298f5e9b..3e05d5dcc 100644
--- a/use-case-consumption-check-if-incoming-request-can-be-rejected.html
+++ b/use-case-consumption-check-if-incoming-request-can-be-rejected.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Check if incoming Request can be rejected">
     <meta itemprop="description" content="This use-case tests if an incoming Requestcan be rejected with the given parameters without actually rejecting it.It is advised to call canReject before actually rejecting a Request, however canReject will usually be successful, as there are only rare cases which block a rejection.Parameters  The id of the incoming request.  The decision for each individual RequestItemexpressed as the appropriate Parameters defined in the Data Model.On Success  Returns a RequestValidationResult that indicates if Request can be rejected with the given parameters.On Failure  The decisions do not match the RequestItems.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -496,7 +496,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-check-if-outgoing-request-can-be-created.html b/use-case-consumption-check-if-outgoing-request-can-be-created.html
index d149e6645..d92de1f77 100644
--- a/use-case-consumption-check-if-outgoing-request-can-be-created.html
+++ b/use-case-consumption-check-if-outgoing-request-can-be-created.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Check if outgoing Request can be created">
     <meta itemprop="description" content="This use-case is intended to check if a LocalRequest can be createdbased on a given Request for a given peer.Parameters  The content as a Request for the to be created LocalRequest  The peer is the address for which the LocalRequest should be created. There can only be one peer per LocalRequest.On Success  Returns a RequestValidationResult that indicates if the given Request is valid.On Failure  The LocalRequest cannot be created if the peer is unknown.  The LocalRequest cannot be created if the Request is malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-a-shared-attribute-copy.html b/use-case-consumption-create-a-shared-attribute-copy.html
index 179e9b955..6b6ac6cd5 100644
--- a/use-case-consumption-create-a-shared-attribute-copy.html
+++ b/use-case-consumption-create-a-shared-attribute-copy.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create a shared Attribute copy">
     <meta itemprop="description" content="Be advised that this is a Runtime-internal use-case which is automatically used by the module system. You should not call this use-case without having good reason.This use-case is intended to create a copy of a LocalAttribute with the intent to share it. The copy references the original LocalAttribute.Parameters  attributeId is the id of the attribute that the copy is made of.  peer is the address of the peer the copy will be sent to.  requestReference is a reference to the request the copy will be sent with.On Success  The copy is created and returned as a LocalAttribute.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-an-attribute.html b/use-case-consumption-create-an-attribute.html
index 4ee990c47..246d65aaa 100644
--- a/use-case-consumption-create-an-attribute.html
+++ b/use-case-consumption-create-an-attribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create an Attribute">
     <meta itemprop="description" content="This use-case is intended to create a LocalAttributebased on a given Attribute.Parameters  The content for the to be created LocalAttribute as AttributeOn Success  A LocalAttribute is created according to the parameters and returned.On Failure  The Attribute cannot be created if the parameter is malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -492,7 +492,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-and-complete-outgoing-request-from-relationship-template-response.html b/use-case-consumption-create-and-complete-outgoing-request-from-relationship-template-response.html
index 89702a48c..addfdb7d7 100644
--- a/use-case-consumption-create-and-complete-outgoing-request-from-relationship-template-response.html
+++ b/use-case-consumption-create-and-complete-outgoing-request-from-relationship-template-response.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create and complete outgoing Request from Relationship Template Response">
     <meta itemprop="description" content="Be advised that this is a Runtime-internal use-case which is automatically used by the module system. You should not call this use-case without having good reason.This use-case is intended to create and instantly complete an outgoing Request which was shared by a RelationshipTemplate and the Response has been received by an incoming RelationshipCreationChange.Parameters  templateId identifies the RelationshipTemplate the response originates from.  responseSourceId references the response either a messageor a RelationshipChange.  response is the content of the response.On Success  Creates and completes the outgoing request.  Returns the corresponding LocalRequest.On Failure  The template could not be found.  The response source could not be found.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -471,7 +471,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-outgoing-request.html b/use-case-consumption-create-outgoing-request.html
index a13e9b709..beb8b7637 100644
--- a/use-case-consumption-create-outgoing-request.html
+++ b/use-case-consumption-create-outgoing-request.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create outgoing Request">
     <meta itemprop="description" content="This use-case is intended to create an actionable LocalRequest based on a given Request for a given peer.One can (and should) check if the outgoing Request can be created before creating the LocalRequest with this use-case.The created LocalRequest needs to be manually submitted to the peer, e.g. by sending a message.Parameters  The content as a Request for the to be created LocalRequest  The peer is the address for which the LocalRequest should be created. There can only be one peer per LocalRequest.On Success  A new LocalRequest for the given parameters is created in status Draft and returned, but so far not sent to the given peer.On Failure  The request cannot be created if the peer is unknown.  The request cannot be created if the request content is malformed. Please check if the outgoing request can be created for more details.Please check if the outgoing request can be created for more details.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -497,7 +497,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-discards-outgoing-request.html b/use-case-consumption-discards-outgoing-request.html
index c516a50b6..cc7902ff3 100644
--- a/use-case-consumption-discards-outgoing-request.html
+++ b/use-case-consumption-discards-outgoing-request.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Discards outgoing Request">
     <meta itemprop="description" content="This use-case is intended to discard an outgoing LocalRequest that has not been sent to the peer yet and is thus still in status Draft.Parameters  id references the outgoing LocalRequest that is to be discarded.On Success  The LocalRequest is deleted and returned.On Failure  The LocalRequest could not be found.  The LocalRequest is not in status Draft.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -464,7 +464,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-execute-a-relationshipattributequery.html b/use-case-consumption-execute-a-relationshipattributequery.html
index 2a0923fa3..354dda3a8 100644
--- a/use-case-consumption-execute-a-relationshipattributequery.html
+++ b/use-case-consumption-execute-a-relationshipattributequery.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Execute a RelationshipAttributeQuery">
     <meta itemprop="description" content="{properties.description}This use-case is intended to execute an incoming RelationshipAttributeQuery (e.g. received by a ReadAttributeRequestItem) which returns a list of matching Relationship Attributes.Parameters  The query for the RelationshipAttributes as described in the RelationshipAttributeQuery.On Success  Returns the RelationshipAttributes as LocalAttributes that match the given query.On Failure  The query was malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-execute-a-thirdpartyattributequery.html b/use-case-consumption-execute-a-thirdpartyattributequery.html
index fee1069d4..1c1bd37aa 100644
--- a/use-case-consumption-execute-a-thirdpartyattributequery.html
+++ b/use-case-consumption-execute-a-thirdpartyattributequery.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Execute a ThirdPartyAttributeQuery">
     <meta itemprop="description" content="This use-case is intended to execute an incoming ThirdPartyRelationshipAttributeQuery(e.g. received by a ReadAttributeRequestItem) which returns a list of matchingRelationship Attributesof another peer.Parameters  The query for the RelationshipAttributes as described in the ThirdPartyRelationshipAttributeQuery.On Success  Returns the RelationshipAttributes as LocalAttributes that match the given query.On Failure  The query is malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-execute-an-identityattributequery.html b/use-case-consumption-execute-an-identityattributequery.html
index ea7801332..13bfbad98 100644
--- a/use-case-consumption-execute-an-identityattributequery.html
+++ b/use-case-consumption-execute-an-identityattributequery.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Execute an IdentityAttributeQuery">
     <meta itemprop="description" content="This use-case is intended to execute an incomingIdentityAttributeQuery (e.g. of a ReadAttributeRequestItem) which returns a list of matching Identity Attributes.Parameters  The query for the IdentityAttributes as described in the IdentityAttributeQuery.On Success  Returns the IdentityAttributes as LocalAttributes that match the given query.On Failure  The query was malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-attribute.html b/use-case-consumption-get-attribute.html
index 0fff939fb..47136ca11 100644
--- a/use-case-consumption-get-attribute.html
+++ b/use-case-consumption-get-attribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Attribute">
     <meta itemprop="description" content="This use-case is intended to retrieve a LocalAttribute by its id.Parameters  The id of the LocalAttribute.On Success  Returns the LocalAttribute corresponding to the id.On Failure  The LocalAttribute does not exist.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-attributelistener.html b/use-case-consumption-get-attributelistener.html
index c289ce325..330e63750 100644
--- a/use-case-consumption-get-attributelistener.html
+++ b/use-case-consumption-get-attributelistener.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get AttributeListener">
     <meta itemprop="description" content="This use-case is intended to retrieve an Attribute Listener by its id.Parameter  The unique id identifying the Attribute Listener.On Success  Returns the LocalAttributeListener that corresponds to the id.On Failure  There is no such Attribute Listener.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -463,7 +463,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-attributes-of-peer.html b/use-case-consumption-get-attributes-of-peer.html
index b53780562..c13167d37 100644
--- a/use-case-consumption-get-attributes-of-peer.html
+++ b/use-case-consumption-get-attributes-of-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Attributes of peer">
     <meta itemprop="description" content="This use-case is intended to retrieve Attributes that a peer has shared with the current Identity as LocalAttributes. The LocalAttributes can be specified using a complex query.Parameters  peer is the Address of the Identity that shared the LocalAttributes.  onlyValid filters the requested LocalAttributes to only consider currently valid LocalAttributes if set.  query describes the requested LocalAttributes in detail.  hideTechnical filters out technical LocalAttributes if set.On Success  Returns a list of LocalAttributes shared by the peer that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-attributes-shared-to-peer.html b/use-case-consumption-get-attributes-shared-to-peer.html
index f91579734..3b0fcfd98 100644
--- a/use-case-consumption-get-attributes-shared-to-peer.html
+++ b/use-case-consumption-get-attributes-shared-to-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Attributes shared to peer">
     <meta itemprop="description" content="This use-case is intended to retrieve Attributes that the current Idenity shared to a peer as LocalAttributes. The LocalAttributes can be specified using a complex query.Parameters  peer is the Address of the Identity that shared the LocalAttributes.  onlyValid filters the requested LocalAttributes to only consider currently valid LocalAttributes if set.  query describes the requested LocalAttributes in detail.  hideTechnical filters out technical LocalAttributes if set.On Success  Returns a list of LocalAttributes shared to the peer that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-incoming-request.html b/use-case-consumption-get-incoming-request.html
index d94f7afd7..66da25a6c 100644
--- a/use-case-consumption-get-incoming-request.html
+++ b/use-case-consumption-get-incoming-request.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get incoming Request">
     <meta itemprop="description" content="This use-case is intended to retrieve an incoming LocalRequest by its id. The differences of outgoing and incoming Requests are defined here.Parameters  The id of the incoming Request.On Success  Returns the incoming LocalRequest corresponding to the id.On Failure  There is no such incoming Request.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-outgoing-request.html b/use-case-consumption-get-outgoing-request.html
index 455c79ae2..fdfc954d7 100644
--- a/use-case-consumption-get-outgoing-request.html
+++ b/use-case-consumption-get-outgoing-request.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get outgoing Request">
     <meta itemprop="description" content="This use-case is intended to retrieve an outgoing LocalRequestby its id. The differences of outgoing and an incoming Requests are defined here.Parameters  The id of the outgoing Request.On Success  Returns the outgoing LocalRequest corresponding to the id.On Failure  There is no such outgoing Request.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-attributelisteners.html b/use-case-consumption-query-attributelisteners.html
index e66df7cf9..8a2dab352 100644
--- a/use-case-consumption-query-attributelisteners.html
+++ b/use-case-consumption-query-attributelisteners.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query AttributeListeners">
     <meta itemprop="description" content="This use-case is intended to query all Attribute Listenersbased on a query.Parameter  The query optionally describes the searched Attribute Listeners. If no query is given all Attribute Listeners are returned.On Success  Returns a list of LocalAttributeListeners that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -464,7 +464,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-attributes.html b/use-case-consumption-query-attributes.html
index 02209ecea..097479d29 100644
--- a/use-case-consumption-query-attributes.html
+++ b/use-case-consumption-query-attributes.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Attributes">
     <meta itemprop="description" content="This use-case is intended to query LocalAttributes. The LocalAttributes can be specified using a complex query.Parameters  The createdAt parameter describes the time when the LocalAttribute was created.  The content describes the searched Attribute (either a IdentityAttributeor a RelationshipAttribute.  succeeds and succeededBy give information about succession state of the LocalAttribute.  The shareInfo describes if the LocalAttribute was received or sent, to whom and when. Read more.On Success  Returns a list of LocalAttributes that match the parameters.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -494,7 +494,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-incoming-requests.html b/use-case-consumption-query-incoming-requests.html
index aaec26be0..245008361 100644
--- a/use-case-consumption-query-incoming-requests.html
+++ b/use-case-consumption-query-incoming-requests.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query incoming Requests">
     <meta itemprop="description" content="This use-case is intended to query incoming LocalRequests.Parameters  The id of the LocalRequest.  The peer is the Address of the Identity that sent the LocalRequest.  createdAt indicates the date of LocalRequest creation.  The status of the LocalRequest.  The content describes the Request wrapped by the LocalRequest.  The response describes the Response that might exist for the Request.On Success  Returns a list of incoming LocalRequests that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -496,7 +496,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-outgoing-requests.html b/use-case-consumption-query-outgoing-requests.html
index ab307c14f..061e98916 100644
--- a/use-case-consumption-query-outgoing-requests.html
+++ b/use-case-consumption-query-outgoing-requests.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query outgoing Requests">
     <meta itemprop="description" content="This use-case is intended to query outgoing LocalRequests.Parameters  The id of the LocalRequest.  The peer is the Address of the Identity that the LocalRequest was sent to.  createdAt indicates the date of LocalRequest creation.  The status of the LocalRequest.  The content describes the Request wrapped by the LocalRequest.  The response describes the Response that might exist for the Request.On Success  Returns a list of outgoing LocalRequests that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -495,7 +495,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-reject-incoming-request.html b/use-case-consumption-reject-incoming-request.html
index e4be7dbfe..f94da4db6 100644
--- a/use-case-consumption-reject-incoming-request.html
+++ b/use-case-consumption-reject-incoming-request.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Reject incoming Request">
     <meta itemprop="description" content="This use-case attempts to reject an incoming LocalRequest.It is advised to check if the incoming Request can be accepted in advance.Parameters  The id of the incoming LocalRequest.  The decision for each individual RequestItemexpressed as the appropriate Parameters defined in the Data Model.On Success  All RequestItems of the Request are rejected  A Message is sent to the requesting peer which contains the Response to the Request.  The LocalRequest is returnedOn Failure  The decisions do not match the request items.  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -498,7 +498,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-delete_-rest-endpoint.html b/use-case-device-delete_-rest-endpoint.html
index 35bbb9aca..b046bb44e 100644
--- a/use-case-device-delete_-rest-endpoint.html
+++ b/use-case-device-delete_-rest-endpoint.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="DELETE REST Endpoint">
     <meta itemprop="description" content="Be advised that this is a Connector-specific use-case which is triggered by an http-request. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case broadly describes the REST endpoints using the DELETE HTTP verb that are exposed by the Connector.Click here to learn more about HTTP request methods.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -447,7 +447,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-profile-by-enmeshed-address.html b/use-case-device-get-profile-by-enmeshed-address.html
index a8ba53cda..0239b4c64 100644
--- a/use-case-device-get-profile-by-enmeshed-address.html
+++ b/use-case-device-get-profile-by-enmeshed-address.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Profile by Enmeshed Address">
     <meta itemprop="description" content="This use-case retrieves the LocalAccount with the corresponding enmeshed Address.Parameters  The address of the corresponding Identity of the LocalAccount.On Success  Returns the LocalAccount of the Identity.On Failure  There is no such LocalAccount.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -463,7 +463,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-profile.html b/use-case-device-get-profile.html
index 978bae262..8ff05bdf2 100644
--- a/use-case-device-get-profile.html
+++ b/use-case-device-get-profile.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Profile">
     <meta itemprop="description" content="This use-case retrieves one LocalAccount by its id.Parameters  The id of the LocalAccount.On Success  The LocalAccount corresponding to the id.On Failure  There is no such account.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -463,7 +463,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-profiles.html b/use-case-device-get-profiles.html
index 1aa3b4a3c..f342fb820 100644
--- a/use-case-device-get-profiles.html
+++ b/use-case-device-get-profiles.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Profiles">
     <meta itemprop="description" content="This use-case retrieves all LocalAccounts available on this Device.ParametersOn Success  A list of LocalAccounts.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -457,7 +457,7 @@ <h2 id="on-success">On Success</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-support-information.html b/use-case-device-get-support-information.html
index 8513fb7f7..ed5667624 100644
--- a/use-case-device-get-support-information.html
+++ b/use-case-device-get-support-information.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get support Information">
     <meta itemprop="description" content="This use-case retrieves support information of the Connector, which can be used to receive support by the community / developers.It contains the Connector&#8217;s version information, its health, its configuration parameters and its Identity information (address and public key). Although, secrets out of the configuration are blanked out, you should take care to whom this information is shared.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -472,7 +472,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-the-connector-health-status.html b/use-case-device-get-the-connector-health-status.html
index d9833e077..c44e5220e 100644
--- a/use-case-device-get-the-connector-health-status.html
+++ b/use-case-device-get-the-connector-health-status.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get the Connector health status">
     <meta itemprop="description" content="This use-case retrieves the service health information of the Connector.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -470,7 +470,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-the-connector-version-information.html b/use-case-device-get-the-connector-version-information.html
index dd75bac39..dacc831a4 100644
--- a/use-case-device-get-the-connector-version-information.html
+++ b/use-case-device-get-the-connector-version-information.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get the Connector version information">
     <meta itemprop="description" content="This use-case retrieves the version information of the Connector, including the build number, underlying git commit, the Connector&#8217;s semantic version and its release date.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-the-number-of-requests-and-the-status-codes-that-were-returned-by-the-connector.html b/use-case-device-get-the-number-of-requests-and-the-status-codes-that-were-returned-by-the-connector.html
index 99389b95a..86de050cc 100644
--- a/use-case-device-get-the-number-of-requests-and-the-status-codes-that-were-returned-by-the-connector.html
+++ b/use-case-device-get-the-number-of-requests-and-the-status-codes-that-were-returned-by-the-connector.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get the number of requests and the status codes that were returned by the Connector">
     <meta itemprop="description" content="This use-case retrieves the overall count of http-requests as requestCount sent by the Connector to the Backbone. The returned requestCountByStatus is a more detailed view on how many requests succeeded or failed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get_-rest-endpoint.html b/use-case-device-get_-rest-endpoint.html
index f89f92727..f97acf7ef 100644
--- a/use-case-device-get_-rest-endpoint.html
+++ b/use-case-device-get_-rest-endpoint.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="GET REST Endpoint">
     <meta itemprop="description" content="Be advised that this is a Connector-specific use-case which is triggered by an http-request. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case broadly describes REST endpoints using the GET HTTP verb that are exposed by the Connector.Click here to learn more about HTTP request methods.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -447,7 +447,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-post_-rest-endpoint.html b/use-case-device-post_-rest-endpoint.html
index 85d8fba99..6325e63f3 100644
--- a/use-case-device-post_-rest-endpoint.html
+++ b/use-case-device-post_-rest-endpoint.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="POST REST Endpoint">
     <meta itemprop="description" content="Be advised that this is a Connector-specific use-case which is triggered by an http-request. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case broadly describes REST endpoints using the POST HTTP verbthat are exposed by the Connector.Click here to learnmore about HTTP request methods.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -449,7 +449,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-put_-rest-endpoint.html b/use-case-device-put_-rest-endpoint.html
index f8232132d..76eca552e 100644
--- a/use-case-device-put_-rest-endpoint.html
+++ b/use-case-device-put_-rest-endpoint.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="PUT REST Endpoint">
     <meta itemprop="description" content="Be advised that this is a Connector-specific use-case which is triggered by an http-request. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case broadly describes REST endpoints using the PUT HTTP verbthat are exposed by the Connector.Click here to learnmore about HTTP request methods.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -449,7 +449,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-rename-profile.html b/use-case-device-rename-profile.html
index e2aef422f..04013f5f5 100644
--- a/use-case-device-rename-profile.html
+++ b/use-case-device-rename-profile.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Rename Profile">
     <meta itemprop="description" content="This use-case intends to rename a LocalAccount (Profile) of the App that matches the given id.Parameters  The localAccountId is the id of the LocalAccount in question.  The newAccountName the LocalAccount name should use.On Success  The LocalAccount with the localAccountId is now named newAccountName.On Failure  There is no such LocalAccount.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-cancel_-action.html b/use-case-human-cancel_-action.html
index e94e11857..e1c7e2949 100644
--- a/use-case-human-cancel_-action.html
+++ b/use-case-human-cancel_-action.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Cancel Action">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.The cancel action use-case generally describes the action a user manually triggers on an App screen to stop a running process that has already been started, or to cancel the current user interface context by navigating back or close a popup.An example could be the user started to write a Mail to a contact and decides not to send it and returns to the home screen.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -448,7 +448,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-device_-external-usecase.html b/use-case-human-device_-external-usecase.html
index d42a5eac4..0beddb289 100644
--- a/use-case-human-device_-external-usecase.html
+++ b/use-case-human-device_-external-usecase.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Device External UseCase">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case describes any required manual user interaction on the Device, which might be required in order to to use the App.Examples:  Selecting a file with the native filesystem picker  Allow the App to use Camera, Push Notification, or equivalent  Copy and paste information across apps">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -454,7 +454,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-enter_-data-on-screen.html b/use-case-human-enter_-data-on-screen.html
index 0726bd7fb..92ec34552 100644
--- a/use-case-human-enter_-data-on-screen.html
+++ b/use-case-human-enter_-data-on-screen.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Enter Data (on screen)">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case describes entering data on the currently shown screen by the user. This is a manual task done by the user.An example could be the user entering the requested data in a incoming LocalRequest.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -448,7 +448,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-navigate-to-screen_-screen.html b/use-case-human-navigate-to-screen_-screen.html
index 54048a63d..7c5175cf9 100644
--- a/use-case-human-navigate-to-screen_-screen.html
+++ b/use-case-human-navigate-to-screen_-screen.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Navigate to (screen) Screen">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case describes the manual navigation of the App to a specific screen by the user. It includes all the actions the user needs to do in order to reach the specific screen.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -446,7 +446,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-negative_-action.html b/use-case-human-negative_-action.html
index 0f05b813b..a06da9e65 100644
--- a/use-case-human-negative_-action.html
+++ b/use-case-human-negative_-action.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Negative Action">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This App use-case broadly describes a dissent of the user with the information on a screen, and thus triggers a negative action on the screen.For example, the user manually rejects an incoming Request or RelationshipTemplate, because too much personal data is requested.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -448,7 +448,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-positive_-action.html b/use-case-human-positive_-action.html
index c05f3c47a..c18f30e1d 100644
--- a/use-case-human-positive_-action.html
+++ b/use-case-human-positive_-action.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Positive Action">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case broadly describes the manual action of a user that indicates consent with something shown on the screen and thus a positive action of the screen is triggered.For example, the user manually accepts an incoming Request or RelationshipTemplate in order to submit the requested data.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -448,7 +448,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-scan_-qr-code-on-different-device.html b/use-case-human-scan_-qr-code-on-different-device.html
index c44e0500e..12ae82836 100644
--- a/use-case-human-scan_-qr-code-on-different-device.html
+++ b/use-case-human-scan_-qr-code-on-different-device.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Scan QR-Code (on different device)">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case describes the process of using the Device&#8217;s camera to scan a qr-code.Typically, the qr-code encodes a link starting with nmshd://.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -447,7 +447,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-select_-item-on-screen.html b/use-case-human-select_-item-on-screen.html
index 632f24ad3..85d08c4ae 100644
--- a/use-case-human-select_-item-on-screen.html
+++ b/use-case-human-select_-item-on-screen.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Select Item (on screen)">
     <meta itemprop="description" content="Be advised that this is an App-specific use-case which is triggered by a manual user interaction. Although it is a very generic use-case which one would normally not describe, we introduced it because we require it in our overarching scenarios.This use-case broadly describes the manual action of a user that selects a specific item on the screen in order to receive more information about it or navigate to a specific page. Usually it triggers a navigation or a popup displaying this information.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -446,7 +446,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-accept-relationship-change.html b/use-case-transport-accept-relationship-change.html
index dd19536b7..597e03a15 100644
--- a/use-case-transport-accept-relationship-change.html
+++ b/use-case-transport-accept-relationship-change.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Accept Relationship Change">
     <meta itemprop="description" content="Accepts a RelationshipChange with the given changeId.Parameters  relationshipId the Relationship&#8217;s id which should be changed by the RelationshipChange  changeId the RelationshipChange&#8217;s id  content a possible answer to the respective RelationshipChange which the peer can fetchOn Success  The RelationshipChange is accepted and the given content made available for the peer.  Returns the changed RelationshipOn Failure  There is no such Relationship or RelationshipChange.  The changeId is not related to the relationshipId.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -494,7 +494,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-own-relationshiptemplate.html b/use-case-transport-create-own-relationshiptemplate.html
index d71595bc9..e23a36145 100644
--- a/use-case-transport-create-own-relationshiptemplate.html
+++ b/use-case-transport-create-own-relationshiptemplate.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create own RelationshipTemplate">
     <meta itemprop="description" content="Creates a RelationshipTemplate with the given parameters and submits it to the Backbone for other Identites to use.A RelationshipTemplate can be used by any party to either initiate a Relationship with the current Identity or retrieve a Request from an existing Relationship by a side-channel.Parameters  expiresAt is the ISODateTime the template expires at. This should be set as small as possible and cannot be in the past.  content describes the structure of the RelationshipTemplate. Whereas the enmeshed App requires a RelationshipTemplateContent as structure, the content of the RelationshipTemplate is arbitrary data.  maxNumberOfAllocations is the number of times the RelationshipTemplate can be accessed by different Identities to initiate a Relationship. The Backbone returns an error, if one accesses a RelationshipTemplate with no allocations left. Accessing the same RelationshipTemplate with the same Identity multiple times doesn&#8217;t affect the number of allocations. The allocation counts, even if the Identity does not accept the RelationshipTemplate by discarding it.On Success  Returns the created RelationshipTemplate on the Backbone.On Failure  The content is malformed.  expiresAt lies in the past">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -494,7 +494,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-own-token.html b/use-case-transport-create-own-token.html
index c405e5aa4..3b66862a0 100644
--- a/use-case-transport-create-own-token.html
+++ b/use-case-transport-create-own-token.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create own Token">
     <meta itemprop="description" content="Creates a Token that represents arbitrary encrypted data saved on the Backbone.Parameters  content an arbitrary JSON structure of the data to share via the Token.  expiresAt is the ISODateTime the Token expires at.  ephemeral indicates if the Token should be ephemeral and thus not be stored and cached on the local database. This is especially useful for Tokens which are created regularly, e.g. for RelationshipTemplates and doesn&#8217;t need to be stored.On Success  Returns the created Token.On Failure  The content is malformed.  expiresAt lies in the past">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-relationship-with-relationshiptemplate.html b/use-case-transport-create-relationship-with-relationshiptemplate.html
index d790d39f8..ec21b2543 100644
--- a/use-case-transport-create-relationship-with-relationshiptemplate.html
+++ b/use-case-transport-create-relationship-with-relationshiptemplate.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create Relationship with RelationshipTemplate">
     <meta itemprop="description" content="This use-case intends to create a Relationship based on a received RelationshipTemplate.Parameters  templateId references the RelationshipTemplate that was received from a party.  content can be used as a response with arbitrary data to the peer. This response is usually related to the data received by the RelationshipTemplate, e.g. the RelationshipTemplate contains Requests and the content here contains the respective Response to the Request.On Success  Creates and returns the Relationship.On Failure  The templateId does not resolve to a RelationshipTemplate.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-token-for-file.html b/use-case-transport-create-token-for-file.html
index bf90db5f6..6ffed3e03 100644
--- a/use-case-transport-create-token-for-file.html
+++ b/use-case-transport-create-token-for-file.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create Token for File">
     <meta itemprop="description" content="Creates a Token for a given file thatcorresponds to the given id.Parameters  fileId is the id of the File the Token should be created for.  expiresAt is the ISODateTime the Token expires at.  ephemeral indicates if the Token should be ephemeral and thus not be stored and cached on the local database. This is especially useful for Tokens which are created regularly, e.g. for RelationshipTemplates and doesn&#8217;t need to be stored.On Success  Returns the created Token.On Failure  fileId does not resolve to a file.  expiresAt lies in the past">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -495,7 +495,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-token-for-own-relationship-template.html b/use-case-transport-create-token-for-own-relationship-template.html
index 7de94b3fb..b2058cb6e 100644
--- a/use-case-transport-create-token-for-own-relationship-template.html
+++ b/use-case-transport-create-token-for-own-relationship-template.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create Token for own Relationship Template">
     <meta itemprop="description" content="Creates a Token for a given RelationshipTemplateParameters  fileId is the id of the File the Token should be created for.  expiresAt is the ISODateTime the Token expires at.  ephemeral indicates if the Token should be ephemeral and thus not be stored and cached on the local database. This is especially useful for Tokens which are created regularly, e.g. for RelationshipTemplates and doesn&#8217;t need to be stored.On Success  Returns the created Token.On Failure  templateId does not resolve to a RelationshipTemplate.  expiresAt lies in the past">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-download-file-of-attachment.html b/use-case-transport-download-file-of-attachment.html
index 89cc38d47..46c83a8f8 100644
--- a/use-case-transport-download-file-of-attachment.html
+++ b/use-case-transport-download-file-of-attachment.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Download File of Attachment">
     <meta itemprop="description" content="This use-case downloads a file that was sent by a Messageas an attachment.Internally uses the Download File Use-Case">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -449,7 +449,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-download-file.html b/use-case-transport-download-file.html
index c0b35dafc..1ac9637a2 100644
--- a/use-case-transport-download-file.html
+++ b/use-case-transport-download-file.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Download File">
     <meta itemprop="description" content="Download the File&#8217;s binary content that corresponds to the fileId. As the File is not stored/cached within the Connector, the encrypted File is downloaded from the Backbone, decrypted and returned every time this use-case is called.Parameters  id of the File.On Success  Downloads the binary content of the File that corresponds to the id.On Failure  There is no File with the given id.  The File is expired on the Backbone.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -492,7 +492,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-attributes-for-relationship.html b/use-case-transport-get-attributes-for-relationship.html
index 56a3dee4d..85c9e3939 100644
--- a/use-case-transport-get-attributes-for-relationship.html
+++ b/use-case-transport-get-attributes-for-relationship.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Attributes for Relationship">
     <meta itemprop="description" content="Retrieve all LocalAttributes that are related to the given Relationship id.Parameters  id of the Relationship.  hideTechnical indicates if RelationshipAttributesmarked as isTechnical should be filtered out.On Success  All LocalAttributes that are related to the Relationship.On Failure  The id did not resolve to a Relationship.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -492,7 +492,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-currently-used-device.html b/use-case-transport-get-currently-used-device.html
index 0e322698f..f8e5f18ec 100644
--- a/use-case-transport-get-currently-used-device.html
+++ b/use-case-transport-get-currently-used-device.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get currently used Device">
     <meta itemprop="description" content="This use-case retrieves information about the currently used Device.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -445,7 +445,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-currently-used-identity.html b/use-case-transport-get-currently-used-identity.html
index 7a2a208f2..4d2ba9b16 100644
--- a/use-case-transport-get-currently-used-identity.html
+++ b/use-case-transport-get-currently-used-identity.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get currently used Identity">
     <meta itemprop="description" content="This use-case retrieves information about the currently used Identity.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -445,7 +445,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-device-onboarding-info.html b/use-case-transport-get-device-onboarding-info.html
index ff82cb9e1..3beee140c 100644
--- a/use-case-transport-get-device-onboarding-info.html
+++ b/use-case-transport-get-device-onboarding-info.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Device Onboarding Info">
     <meta itemprop="description" content="This use-case retrieves the onboarding information a so far not-onboarded Device that corresponds to the given Device id in order to onboard the Device to the Identity.Parameters  id of the Device.On Success  Returns the onboarding information of the Device.On Failure  The Device was already onboarded.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -464,7 +464,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-device-onboarding-token.html b/use-case-transport-get-device-onboarding-token.html
index 9522de349..1425d497e 100644
--- a/use-case-transport-get-device-onboarding-token.html
+++ b/use-case-transport-get-device-onboarding-token.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Device Onboarding Token">
     <meta itemprop="description" content="This use-case retrieves the Tokenof a so far not-onboarded Device that corresponds to the given Device id in order to onboard the Device to the Identity.Parameters  id of the Device.  expiresAt is the ISODateTime the Token expires at.On Success  Returns the Token of the Device to onboard.On Failure  The Device was already onboarded.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-device.html b/use-case-transport-get-device.html
index 298ad189f..0d7f78b4c 100644
--- a/use-case-transport-get-device.html
+++ b/use-case-transport-get-device.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Device">
     <meta itemprop="description" content="This use-case retrieves the Device with the given id.Parameters  id of the Device.On Success  The Device that corresponds to the id.On Failure  No Device corresponds to the id.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -464,7 +464,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-file-metadata-of-attachment.html b/use-case-transport-get-file-metadata-of-attachment.html
index a321ac5b3..9e05aaf01 100644
--- a/use-case-transport-get-file-metadata-of-attachment.html
+++ b/use-case-transport-get-file-metadata-of-attachment.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get File Metadata of Attachment">
     <meta itemprop="description" content="This use-case retrieves the metadata of a File that was sent by a Messageas an attachment.Internally uses the get or load file use-case.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -449,7 +449,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-message-by-messageid.html b/use-case-transport-get-message-by-messageid.html
index 422b817a0..1e5ac9c73 100644
--- a/use-case-transport-get-message-by-messageid.html
+++ b/use-case-transport-get-message-by-messageid.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Message by MessageId">
     <meta itemprop="description" content="This use-case retrieves a Messageby its id.Parameters  id of the Message.On Success  Returns the Message that corresponds to the id.On Failure  id does not resolve to a Message.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-or-load-file.html b/use-case-transport-get-or-load-file.html
index 06c1e7d82..e78fd7327 100644
--- a/use-case-transport-get-or-load-file.html
+++ b/use-case-transport-get-or-load-file.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get or load File">
     <meta itemprop="description" content="This use-case retrieves a File by an id or the reference. This is usually the case, when a reference to a File was received by a peer (over a Message or by any side channel).Paramers  id or reference that identify the File.On Success  The File that corresponds to the id or the reference.On Failure  The given id or reference does not resolve to a File.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-own-file.html b/use-case-transport-get-own-file.html
index af164691a..9f043a540 100644
--- a/use-case-transport-get-own-file.html
+++ b/use-case-transport-get-own-file.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get own File">
     <meta itemprop="description" content="This use-case retrieves an own File.Parameters  id of the File which should be retrieved.On Success  The metadata of the File that match the id.On Failure  No File corresponds to the id.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-relationship-by-address.html b/use-case-transport-get-relationship-by-address.html
index 5f266396c..4ac4f05b5 100644
--- a/use-case-transport-get-relationship-by-address.html
+++ b/use-case-transport-get-relationship-by-address.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Relationship by Address">
     <meta itemprop="description" content="This use-case retrieves a Relationshipby the Address of a peer.Parameters  address of the peer.On Success  The Relationship that was inititated with the address.On Failure  There is no Relationship linked to the given address.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-relationship-by-relationshipid.html b/use-case-transport-get-relationship-by-relationshipid.html
index 0d4f9ce47..28095cb00 100644
--- a/use-case-transport-get-relationship-by-relationshipid.html
+++ b/use-case-transport-get-relationship-by-relationshipid.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Relationship by RelationshipId">
     <meta itemprop="description" content="This use-case retrieves a Relationshipby its id.Parameters  id of the Relationship.On Success  The Relationship that corresponds to the id.On Failure  The id does not resolve to a Relationship.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-relationship-template.html b/use-case-transport-get-relationship-template.html
index 65882b8d2..b83630053 100644
--- a/use-case-transport-get-relationship-template.html
+++ b/use-case-transport-get-relationship-template.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Relationship Template">
     <meta itemprop="description" content="This use-case retrieves a RelationshipTemplateby its id.Parameters  idof the RelationshipTemplate.On Success  The RelationshipTemplate that corresponds to the id.On Failure  The id doesn&#8217;t resolve to a RelationshipTemplate.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-synchronization-status-with-backbone.html b/use-case-transport-get-synchronization-status-with-backbone.html
index 28151d2fd..75338434d 100644
--- a/use-case-transport-get-synchronization-status-with-backbone.html
+++ b/use-case-transport-get-synchronization-status-with-backbone.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get synchronization status with Backbone">
     <meta itemprop="description" content="This use-case returns metadata about the synchronization status of the current Identity or Device with the Backbone. So far, it returns the timestamp of the last successful synchronization run which is triggered by /use-case-transport-synchronize-updates-of-backboneOn Success  Returns the metadata of the last sync run">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -477,7 +477,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-token-by-tokenid.html b/use-case-transport-get-token-by-tokenid.html
index c1157f9c3..3e9c45023 100644
--- a/use-case-transport-get-token-by-tokenid.html
+++ b/use-case-transport-get-token-by-tokenid.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get Token by TokenID">
     <meta itemprop="description" content="This use-case retieves a Tokenby its id.Parameters  id of the Token.On Success  The Token that corresponds to the id.On Failure  The id doesn&#8217;t resolve to a Token.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-load-item-from-truncated-reference.html b/use-case-transport-load-item-from-truncated-reference.html
index b909889d2..102b05f41 100644
--- a/use-case-transport-load-item-from-truncated-reference.html
+++ b/use-case-transport-load-item-from-truncated-reference.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Load item from truncated reference">
     <meta itemprop="description" content="This use-case intends to load an entity by its reference received by peer. It is internally using the specific use-cases of each entity:  If the reference references a Token, fetches the Token just like Load Token created by others.  If the reference references a RelationshipTemplate, fetches the RelationshipTemplate just like Load Relationship Template created by others.  If the reference references a File, fetches the File just like Get or load File.  If the reference references a DeviceOnboardingInformation, fetches the DeviceOnboardingInformation just like Get Device Onboarding Token.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -453,7 +453,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-load-relationship-template-created-by-others.html b/use-case-transport-load-relationship-template-created-by-others.html
index a7afe5562..b576c1a72 100644
--- a/use-case-transport-load-relationship-template-created-by-others.html
+++ b/use-case-transport-load-relationship-template-created-by-others.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Load Relationship Template created by others">
     <meta itemprop="description" content="This use-case loads a peer&#8217;s RelatonshipTemplate from the Backbone by a given reference to the RelationshipTemplate.ParametersThere are three different options to use this use-case, depending on the actual information received by the peer:  by knowing an id and the secretKey of the peer&#8217;s RelationshipTemplate (RelationshipTemplateReference)          id of the RelationshipTemplate      secretKey as Base64URL encoding for decrypting the RelationshipTemplate        by knowing a reference of the peer&#8217;s RelationshipTemplate (RelationshipTemplateReferenceTruncated)          reference as string        by knowing a reference of the peer&#8217;s Token, which references to the peer&#8217;s RelationshipTemplate TokenReferenceTruncated          reference as string      On Success  Returns the RelationshipTemplate.On Failure  The parameters are malformed.  The RelationshipTemplate does not exist.  The RelationshipTemplate is expired.  The maxNumberOfAllocations of the RelationshipTemplate are depleted.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -510,7 +510,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-load-token-created-by-others.html b/use-case-transport-load-token-created-by-others.html
index 6500ba085..0f7307d7d 100644
--- a/use-case-transport-load-token-created-by-others.html
+++ b/use-case-transport-load-token-created-by-others.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Load Token created by others">
     <meta itemprop="description" content="This use-case intends to load a peer&#8217;s Token from the Backbone by a given reference to the Token.ParametersThere are two possible options to load the Token:  by knowing the reference of the peer&#8217;s Token          reference that identifies the Token.      ephemeral to indicate that the Token should be stored locally.        by knowing the id and the secretKey of the peer&#8217;s Token          id of the Token.      secretKey that was used to encrypt the Token.      ephemeral to indicate if the Token should be stored locally.      On Success  Returns the corresponding Token.On Failure  The parameters are malformed.  The Token does not exist.  The Token is expired.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -506,7 +506,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-devices.html b/use-case-transport-query-devices.html
index 61ea6ba30..a8470b188 100644
--- a/use-case-transport-query-devices.html
+++ b/use-case-transport-query-devices.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Devices">
     <meta itemprop="description" content="This use-case queries all Devices of the Identity.On Success  Returns all Devices.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -452,7 +452,7 @@ <h2 id="on-success">On Success</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-files.html b/use-case-transport-query-files.html
index d443f47d5..c69968875 100644
--- a/use-case-transport-query-files.html
+++ b/use-case-transport-query-files.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Files">
     <meta itemprop="description" content="This use-case queries Files of the Identity.ParametersAll parameters are optional. If no parameter is given, all Files are returned.  createdAt is the ISODateTime the File was created at.  createdBy is the enmeshed Address of the Identity that created the File.  createdByDevice is the id of the Device that created the File.  description of the File.  expiresAt is the ISODateTime the File expires.  filename is the name of the actual file from the operating system.  filesize is the size of the respective file in bytes  mimetype of the respective file  title of the File  isOwn indicates if the File is owned by you.On Success  Returns all Files that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -501,7 +501,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-messages.html b/use-case-transport-query-messages.html
index 4670a498e..2d4e0310d 100644
--- a/use-case-transport-query-messages.html
+++ b/use-case-transport-query-messages.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Messages">
     <meta itemprop="description" content="This use-case queries Messages of the Identity.ParametersAll parameters are optional. If no parameter is given, all Messages are returned.  createdBy is the enmeshed Address of the Identity that created the Messsage.  createdByDevice is the id of the Device that created the File.  createdAt is the ISODateTime the Message was created at.  attachments are the File ids of the respective attachments.  recipients.address are the enmeshed Addresses of the Identities the Message was sent to.  recipients.relationshipId are the Relationship ids of the respective recipient.  participant is either the enmeshed Address of the sender or enmeshed Addresses of the Identities the Message was sent to.  content.@type the type of structure of the Message&#8217;s content  content.body the body of the Mail, if the Message is of type Mail  content.subject the subject of the Mail, if the Message is of type MailOn Success  Returns all Messages that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -500,7 +500,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-relationship-templates.html b/use-case-transport-query-relationship-templates.html
index 18d0a945e..3cf680b94 100644
--- a/use-case-transport-query-relationship-templates.html
+++ b/use-case-transport-query-relationship-templates.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Relationship Templates">
     <meta itemprop="description" content="This use-case queries RelationshipTemplatesof the Identity.ParametersAll parameters are optional. If no parameter is given, all RelationshipTemplates are returned.  isOwn indicates if the RelationshipTemplate was created by the current Identity.  createdAt is the ISODateTime the RelationshipTemplate was created at.  expiresAt is the ISODateTime the RelationshipTemplate expires.  createdBy is the enmeshed Address of the Identity that created the RelationshipTemplate.  createdByDevice is the id of the Device that created the RelationshipTemplate.  maxNumberOfAllocations is the number of times the RelationshipTemplate can be accessed by different Identities to initiate a Relationship. The Backbone returns an error, if one accesses a RelationshipTemplate with no allocations left. Accessing the same RelationshipTemplate with the same Identity multiple times doesn&#8217;t affect the number of allocations. The allocation counts, even if the Identity does not accept the RelationshipTemplate by discarding it.On Success  Returns all RelationshipTemplates that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -497,7 +497,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-tokens-by-parameters.html b/use-case-transport-query-tokens-by-parameters.html
index b56d4640b..86e9e12cb 100644
--- a/use-case-transport-query-tokens-by-parameters.html
+++ b/use-case-transport-query-tokens-by-parameters.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Tokens by parameters">
     <meta itemprop="description" content="This use-case queries Tokens of the Identity.Parameters  createdAt is the ISODateTime the Token was created at.  createdBy is the enmeshed Address of the Identity that created the Token.  createdByDevice is the id of the Device that created the Token.  expiresAt is the ISODateTime the Token expires.On Success  Returns all Tokens that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-reject-relationship-change.html b/use-case-transport-reject-relationship-change.html
index e7d637edb..ec876cd84 100644
--- a/use-case-transport-reject-relationship-change.html
+++ b/use-case-transport-reject-relationship-change.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Reject Relationship Change">
     <meta itemprop="description" content="Rejects a RelationshipChange with the given changeId.Parameters  relationshipId the Relationship&#8217;s id which should be changed by the RelationshipChange  changeId the RelationshipChange&#8217;s id  content a possible answer to the respective RelationshipChange which the peer can fetchOn Success  The RelationshipChange is rejected and the given content made available for the peer.  Returns the changed RelationshipOn Failure  There is no such Relationship or RelationshipChange.  The changeId is not related to the relationshipId.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -494,7 +494,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-send-message-to-recipients.html b/use-case-transport-send-message-to-recipients.html
index cba4db580..b4ccbadd4 100644
--- a/use-case-transport-send-message-to-recipients.html
+++ b/use-case-transport-send-message-to-recipients.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Send message to recipient(s)">
     <meta itemprop="description" content="This use-case sends a Message to the given recipient(s).Parameters  recipients is a list of the enmeshed Addresses which should receive the Message.  content the structured content of the Message. Usually a Mail when communicating with a user.  attachments is a list of File ids which should be attached to the Message.On Success  Sends the Message to all recipients  Returns the sent MessageOn Failure  One of the recipients is not an active Relationship  The attachments are not valid File ids.  The content is malformed.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -494,7 +494,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-synchronize-updates-of-backbone.html b/use-case-transport-synchronize-updates-of-backbone.html
index b7d105c93..7973d8107 100644
--- a/use-case-transport-synchronize-updates-of-backbone.html
+++ b/use-case-transport-synchronize-updates-of-backbone.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Synchronize updates of Backbone">
     <meta itemprop="description" content="Be advised that calling this use-case to sync the Identity/Device on a regular basis is discouraged, as it could lead to wrong return values if multiple endpoints trigger this use-case.Please configure the SyncModule and use eventing instead.This use-case retrieves all relevant data changes between the current Identity (and Device) and the Backbone since the last synchronization. The relevant data are so far new RelationshipChanges and Messages.On Success  A list of Relationships that have a new status.  A list of Messages that were retrieved since the last call.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -482,7 +482,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-update-device.html b/use-case-transport-update-device.html
index 5b8242984..f06683e54 100644
--- a/use-case-transport-update-device.html
+++ b/use-case-transport-update-device.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Update Device">
     <meta itemprop="description" content="This use-case updates the name or description of a Device using its id.Parameters  The id of the Device.  The new name of the Device  The new description of the DeviceOn Success  The corresponding Device is updated to the given name and description.On Failure  There is no such Device.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,7 @@ <h2 id="on-failure">On Failure</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-upload-own-file.html b/use-case-transport-upload-own-file.html
index 39b5b7d1e..52f810329 100644
--- a/use-case-transport-upload-own-file.html
+++ b/use-case-transport-upload-own-file.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -334,7 +334,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Upload own File">
     <meta itemprop="description" content="This use-case uses a given file outside of enmeshed, encrypts and uploads it to the Backbone and creates a File with the respective metadata information for the Identity to access it. The File can from now on be shared by references to other Identities.Parameters  content is the to-be-uploaded file content as byte array  filename is the name of the file from the operating system.  mimetype of the respective file  expiresAt is the ISODateTime the File expires.  title of the File  Optional description of the File.On Success  An encrypted File is stored on the Backbone and can be shared by its references  Only the metadata of the File is stored locally  Returns the created FileOn Failure  The parameters are malformed.  The file size is too big.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -499,7 +499,7 @@ <h6>Corresponding interactive API docs excerpt:</h6>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use.html b/use.html
index 37048218b..22bbafd39 100644
--- a/use.html
+++ b/use.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Use enmeshed">
     <meta itemprop="description" content="This page is intended for app users.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -407,7 +407,7 @@ <h2 id="getting-started">Getting Started</h2>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/create-an-identity.html b/use/create-an-identity.html
index e7f1c05f8..fa69ebae6 100644
--- a/use/create-an-identity.html
+++ b/use/create-an-identity.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create an Identity">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.IdentityA new digital Identity can be created in the App by the user. The Identity is the user’s primary entity and digital twin. All data and metadata in enmeshed is stored for Identities. Every Identity represents a certain natural or legal person. One can create separate Identities for personal and professional purposes.DevicesThe Device which created an Identity automatically is onboarded to the Identity. But a user can add more Devices, to have multiple devices accessing the very same digital Identity. An Identity which is used by a mobile phone, a tablet and a laptop has onboarded three Devices.ProfilesThe user can manage multiple Identities with one single App. Each Identity-to-App combination is called a Profile. Thus, each Profile within the App represents a separate digital Identity for which the App can be used.ExampleConsider a user who has three Devices (phone, tablet and business laptop) and three Identities (personal, work, child). A senseful combination would be the following:Multi-Device: Structured by Identities and their Devices:  Identity Personal          Device: Phone      Device: Tablet        Identity Child          Device: Phone      Device: Child        Identity Work          Device: Phone      Device: Business Laptop      Multi-Profile: Structured by Devices and their Profiles:  Device: Phone          Profile: Personal      Profile: Work      Profile: Child        Device: Tablet          Profile: Personal      Profile: Child        Device: Business Laptop          Profile: Work      ">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -305,7 +305,7 @@ <h1 id="example">Example</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/delete-identity-from-enmeshed.html b/use/delete-identity-from-enmeshed.html
index 3aedd071f..25ad85c0a 100644
--- a/use/delete-identity-from-enmeshed.html
+++ b/use/delete-identity-from-enmeshed.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Delete Identity from enmeshed">
     <meta itemprop="description" content="This feature (or parts of it) and its documentation are still in developmentPlease note that this section describes features which are currently in development, and we are actively working on enhancing your experience.Thus you could encounter unfinished APIs, incompatible changes, mistakes or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this feature, e.g. by filing an issue in our feedback repository.FlowEvery Identity has the option of deleting itself from the Backbone. There are three options to delete the Identity:  Actively trigger the deletion process by use of the App. There is no further approval of the Identity required with this option.  Actively trigger the deletion process by use of support tickets/e-mails to the Backbone operator (as required by GDPR). An active approval of the Identity is required with this option, as the Backbone must ensure, that the support ticket creator is the owner of the Identity. As there is the need of a push notification channel for this, the Connector does not have the ability to trigger the Identity deletion over the Backbone.  Be inactive for a long period of time: Depending on the Backbone environment, deleting inactive Identities is possible.All peers of the to-be-deleted Identity are informed about this deletion, otherwise they will end up getting Backbone errors that the Identity is no longer available.Usually Identity deletion takes place with a grace period in which the owner of the Identity can revoke the decision to be deleted. The identity deletion can be triggered by the runtime.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -257,7 +257,7 @@ <h1 id="flow">Flow</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/delete-profile-from-the-app.html b/use/delete-profile-from-the-app.html
index 26ed19de4..7454b4615 100644
--- a/use/delete-profile-from-the-app.html
+++ b/use/delete-profile-from-the-app.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Delete Profile from the App">
     <meta itemprop="description" content="This feature (or parts of it) and its documentation are still in developmentPlease note that this section describes features which are currently in development, and we are actively working on enhancing your experience.Thus you could encounter unfinished APIs, incompatible changes, mistakes or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this feature, e.g. by filing an issue in our feedback repository.The user has the option of deleting the Profile stored in the App. Thus all data of the associated Identity are deleted on this Device. If this is the last Device of an Identity, the user needs to delete the Identity from enmeshed, instead of only deleting the Profile.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -245,7 +245,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/get-overview-of-your-data.html b/use/get-overview-of-your-data.html
index bc5e01edc..c8ccc7839 100644
--- a/use/get-overview-of-your-data.html
+++ b/use/get-overview-of-your-data.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get overview of your data">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.The user can display all Attributes specific to the Identity within the profile area in the App.Attributes specific to a contact can be found in the details page of the respective contact.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -246,7 +246,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/install-the-app.html b/use/install-the-app.html
index 3fbafc6b6..baf8f156c 100644
--- a/use/install-the-app.html
+++ b/use/install-the-app.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Install the App">
     <meta itemprop="description" content="Caution: As enmeshed is open-source and the App is a white-label component, there are several flavors of the enmeshed App in the corresponding app stores.Enmeshed AppYou can get the enmeshed App over your favorite app stores. Please find the links below:  Enmeshed App on Apple AppStore  Enmeshed App on Google PlayStorePlease drop us some feedback if you would like to see the enmeshed App on different stores as well.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -250,7 +250,7 @@ <h1 id="enmeshed-app">Enmeshed App</h1>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/manually-fill-attributes-of-your-identity.html b/use/manually-fill-attributes-of-your-identity.html
index 5ff1d52c1..194bb9a9e 100644
--- a/use/manually-fill-attributes-of-your-identity.html
+++ b/use/manually-fill-attributes-of-your-identity.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Manually fill Attributes of your Identity">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.The user has the option of entering personal data in the App which can be requested by other contacts. This can be done in advance by filling out the profile information.Alternatively, if a contact requests an Attribute which is so far not filled in the profile yet, the user can fill in this Attribute when responding to the Request.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -247,7 +247,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/process-received-enmeshed-onboarding-package-and-create-relationship.html b/use/process-received-enmeshed-onboarding-package-and-create-relationship.html
index 9442abc31..9c0c45106 100644
--- a/use/process-received-enmeshed-onboarding-package-and-create-relationship.html
+++ b/use/process-received-enmeshed-onboarding-package-and-create-relationship.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Process received enmeshed onboarding package and create relationship">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.This scenario describes the process when an onboarding package has been received from another Identity. This is done by scanning an enmeshed QR-Code, clicking an enmeshed link or by entering a longer string which in fact represents the content within the QR-Code.If the onboarding package is still available, the information out of the package is displayed to the user. It consists out of a single Request the user needs to decide on: Is it ok to share all the requested personal data in order to establish the contact?">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -247,7 +247,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/process-requests-of-contact.html b/use/process-requests-of-contact.html
index d509b67ef..1ca3c636e 100644
--- a/use/process-requests-of-contact.html
+++ b/use/process-requests-of-contact.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Process requests of contact">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.The user can receive Requests from contacts from time to time within the App. Each Request can contain semantically different RequestItems which are automatically processed, if the user accepts the Request.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -245,7 +245,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/rename-profile-to-distinguish-multiple-profiles.html b/use/rename-profile-to-distinguish-multiple-profiles.html
index 10f6379d2..e7732dd59 100644
--- a/use/rename-profile-to-distinguish-multiple-profiles.html
+++ b/use/rename-profile-to-distinguish-multiple-profiles.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Rename Profile to distinguish multiple Profiles">
     <meta itemprop="description" content="This section is a pre-releasePlease note that this section of our documentation is currently under construction, and we are actively working on enhancing your experience.Thus you could encounter typos, mistakes, or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this part of the documentation, e.g. by filing an issue in our feedback repository.To distinguish the different Profiles within the App, the user can rename and select an image for every profile.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -245,7 +245,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/secure-device-setup.html b/use/secure-device-setup.html
index d485aa245..3b42136cb 100644
--- a/use/secure-device-setup.html
+++ b/use/secure-device-setup.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Secure device setup">
     <meta itemprop="description" content="We’ve summarized some tips for end-user device usage on this site. A great resource for more in-depth information about those tips is the website of the Federal Office for Information Security (BSI, Bundesamt für Sicherheit in der Informationstechnik).We do not know every security guideline and tip out there, so please also check security tips of your operating systems like (Android, or iOS).Please also understand, that we - as anybody else - cannot give you any security guaranty of your device or our system. With this page we are addressing the most common risks of end-user device usage. Even if you follow those guidances, it might happen that a security incident happens.Enable PIN/Password Authentication of DeviceThe first line of defense for your device is a strong password or PIN. It is essential to enable this feature on your device to prevent unauthorized access. A secure password should be at least between eight and twelve characters long and contain a mixture of upper and lower case letters, numbers and symbols. Additionally, you should avoid using easily guessable passwords, such as birthdays or names.Only One Person Should Use the DeviceIt is recommended that only one person uses the device, and they should not share their password with anyone. Sharing passwords can lead to unauthorized access and compromise the security of the device.Update the Operating System RegularlyOperating system updates are crucial to maintaining the security of your device. These updates often include security patches that address vulnerabilities and bugs that could compromise your device’s security. Therefore, it is important to keep your device’s operating system up-to-date with the latest patches and updates.Enable Hard-Disk EncryptionHard-disk encryption is a security feature that encrypts the data stored on your device’s hard disk. This feature adds an extra layer of security to your device, making it difficult for anyone to access your data if the device is lost or stolen.Enable a Virus ScannerViruses and malware pose a significant threat to your device’s security. It is important to enable a virus scanner on your device to protect it from potential threats. The virus scanner will scan your device for viruses and malware and alert you if it detects any threats.Expert CornerRooted DevicesRooting a device involves gaining access to the device’s root or administrative privileges. While rooting a device provides greater control over the device, it also exposes the device to potential security risks. Rooted devices are more vulnerable to malware and other security threats. Therefore, it is recommended to avoid rooting your device unless you have a good reason to do so.Developer-enabled PhonesDeveloper-enabled phones are designed for developers and come with additional features that allow them to customize the device’s software. However, these features also make the device more vulnerable to potential security risks. Therefore, it is important to be cautious when using developer-enabled phones and avoid installing apps from untrusted sources.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -273,7 +273,7 @@ <h3 id="developer-enabled-phones">Developer-enabled Phones</h3>
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>
 
diff --git a/use/send-prefabricated-request-to-contact.html b/use/send-prefabricated-request-to-contact.html
index 8fa16eaef..2e8f23c19 100644
--- a/use/send-prefabricated-request-to-contact.html
+++ b/use/send-prefabricated-request-to-contact.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-02-06T08:06:12+01:00">
+  <meta property="article:published_time" content="2024-02-09T09:55:06+01:00">
 
 
 
@@ -200,7 +200,7 @@ <h3>Use enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Send prefabricated request to contact">
     <meta itemprop="description" content="This feature (or parts of it) and its documentation are still in developmentPlease note that this section describes features which are currently in development, and we are actively working on enhancing your experience.Thus you could encounter unfinished APIs, incompatible changes, mistakes or bugs in below information.However, we would like you to receive the most up-to-date information as soon as possible, in order to understand, use and integrate enmeshed.Additionally, we would love to hear your feedback to this feature, e.g. by filing an issue in our feedback repository.In the App, the user can have additional buttons rendered on the contact screen that can send a specific prefabricated request to the contact.">
-    <meta itemprop="datePublished" content="2024-02-06T08:06:12+01:00">
+    <meta itemprop="datePublished" content="2024-02-09T09:55:06+01:00">
     
 
     <div class="page__inner-wrap">
@@ -245,7 +245,7 @@ <h1 id="page-title" class="page__title p-name" itemprop="headline">
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-06T08:06:12+01:00">February 6, 2024</time></p>
+  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-02-09T09:55:06+01:00">February 9, 2024</time></p>
 
       </footer>