From 8b7d4616c6da6f67df6390ef2c5698a0d5b1c1aa Mon Sep 17 00:00:00 2001
From: github-actions-bot <support+actions@github.com>
Date: Fri, 8 Mar 2024 15:25:43 +0000
Subject: [PATCH] Updates

---
 assets/css/main.css.map                       | 106 +++----
 explore.html                                  |   6 +-
 explore/addresses.html                        |   6 +-
 explore/app.html                              |   6 +-
 explore/backbone.html                         |   6 +-
 explore/blockchain.html                       |   6 +-
 explore/connector.html                        |   6 +-
 explore/cryptography.html                     |   6 +-
 explore/example-scenarios.html                |   6 +-
 explore/faq.html                              |   6 +-
 explore/features.html                         |   6 +-
 explore/how_does_enmeshed_work.html           |   6 +-
 explore/integration.html                      |   6 +-
 explore/layers/backbone.html                  |   6 +-
 explore/layers/consumption.html               |   6 +-
 explore/layers/integration.html               |   6 +-
 explore/layers/transport.html                 |   6 +-
 explore/layers/user-experience.html           |   6 +-
 explore/privacy.html                          |   6 +-
 explore/runtime.html                          |   6 +-
 explore/security.html                         |   6 +-
 feed.xml                                      |   2 +-
 integrate.html                                |   6 +-
 integrate/access-the-connector.html           |   6 +-
 integrate/attribute-values.html               |   6 +-
 integrate/connector-events.html               |   6 +-
 integrate/create-attribute-for-peer.html      |   6 +-
 integrate/create-attribute-for-yourself.html  |   6 +-
 integrate/data-model-overview.html            |   6 +-
 integrate/error-codes.html                    |   6 +-
 ...sh-a-relationship-to-another-identity.html |   6 +-
 integrate/event-introduction.html             |   6 +-
 integrate/integration-example.html            |   6 +-
 integrate/propose-attribute-to-peer.html      |  16 +-
 integrate/read-attribute-from-peer.html       |   6 +-
 .../request-and-response-introduction.html    |   6 +-
 .../request-persistent-consent-of-peer.html   |   6 +-
 integrate/requesting-one-time-consents.html   |   6 +-
 integrate/requests-and-requestitems.html      |   6 +-
 integrate/requests-over-messages.html         |   6 +-
 integrate/requests-over-templates.html        |   6 +-
 integrate/sending-messages.html               |   6 +-
 integrate/share-own-attribute-to-peer.html    |   6 +-
 ...ing-attributes-to-update-their-values.html |   6 +-
 integrate/use-cases.html                      |   6 +-
 operate.html                                  |   6 +-
 operate/configuration.html                    |   6 +-
 operate/log-event-ids.html                    |   6 +-
 operate/modules.html                          |   6 +-
 operate/overview-of-connector-operations.html |   6 +-
 operate/performance-considerations.html       |   6 +-
 operate/privacy-considerations.html           |   6 +-
 operate/security-considerations.html          |   6 +-
 operate/setup-with-docker-compose.html        |   6 +-
 operate/setup-with-helm-charts.html           |   6 +-
 operate/support.html                          |   6 +-
 operate/troubleshooting-guide.html            |   6 +-
 sitemap.xml                                   | 294 +++++++++---------
 ...-id-and-key-without-having-an-account.html |   6 +-
 ...d-reference-without-having-an-account.html |   6 +-
 ...e-consumption-accept-incoming-request.html |   6 +-
 ...k-if-incoming-request-can-be-accepted.html |   6 +-
 ...k-if-incoming-request-can-be-rejected.html |   6 +-
 ...ck-if-outgoing-request-can-be-created.html |   6 +-
 ...sumption-create-a-repositoryattribute.html |   6 +-
 ...mption-create-a-shared-attribute-copy.html |   6 +-
 ...t-from-relationship-template-response.html |   6 +-
 ...ate-and-share-a-relationshipattribute.html |   6 +-
 ...e-consumption-create-outgoing-request.html |   6 +-
 ...consumption-discards-outgoing-request.html |   6 +-
 ...-execute-a-relationshipattributequery.html |   6 +-
 ...on-execute-a-thirdpartyattributequery.html |   6 +-
 ...ion-execute-an-identityattributequery.html |   6 +-
 use-case-consumption-get-attribute.html       |   6 +-
 ...ase-consumption-get-attributelistener.html |   6 +-
 ...se-consumption-get-attributes-of-peer.html |   6 +-
 ...umption-get-attributes-shared-to-peer.html |   6 +-
 ...case-consumption-get-incoming-request.html |   6 +-
 ...case-consumption-get-outgoing-request.html |   6 +-
 ...red-versions-of-a-repositoryattribute.html |   6 +-
 ...sumption-get-versions-of-an-attribute.html |   6 +-
 ...-about-repositoryattribute-succession.html |   6 +-
 ...-consumption-query-attributelisteners.html |   6 +-
 use-case-consumption-query-attributes.html    |   6 +-
 ...e-consumption-query-incoming-requests.html |   6 +-
 ...e-consumption-query-outgoing-requests.html |   6 +-
 ...e-consumption-reject-incoming-request.html |   6 +-
 ...nsumption-share-a-repositoryattribute.html |   6 +-
 ...relationshipattribute-and-notify-peer.html |   6 +-
 ...umption-succeed-a-repositoryattribute.html |   6 +-
 use-case-device-delete_-rest-endpoint.html    |   6 +-
 ...evice-get-profile-by-enmeshed-address.html |   6 +-
 use-case-device-get-profile.html              |   6 +-
 use-case-device-get-profiles.html             |   6 +-
 use-case-device-get-support-information.html  |   6 +-
 ...evice-get-the-connector-health-status.html |   6 +-
 ...get-the-connector-version-information.html |   6 +-
 ...s-that-were-returned-by-the-connector.html |   6 +-
 use-case-device-get_-rest-endpoint.html       |   6 +-
 use-case-device-post_-rest-endpoint.html      |   6 +-
 use-case-device-put_-rest-endpoint.html       |   6 +-
 use-case-device-rename-profile.html           |   6 +-
 use-case-human-cancel_-action.html            |   6 +-
 use-case-human-device_-external-usecase.html  |   6 +-
 use-case-human-enter_-data-on-screen.html     |   6 +-
 ...case-human-navigate-to-screen_-screen.html |   6 +-
 use-case-human-negative_-action.html          |   6 +-
 use-case-human-positive_-action.html          |   6 +-
 ...man-scan_-qr-code-on-different-device.html |   6 +-
 use-case-human-select_-item-on-screen.html    |   6 +-
 ...e-transport-accept-relationshipchange.html |   6 +-
 ...sport-create-own-relationshiptemplate.html |   6 +-
 use-case-transport-create-own-token.html      |   6 +-
 ...elationship-with-relationshiptemplate.html |   6 +-
 use-case-transport-create-token-for-file.html |   6 +-
 ...e-token-for-own-relationship-template.html |   6 +-
 ...transport-download-file-of-attachment.html |   6 +-
 use-case-transport-download-file.html         |   6 +-
 ...sport-get-attributes-for-relationship.html |   6 +-
 ...e-transport-get-currently-used-device.html |   6 +-
 ...transport-get-currently-used-identity.html |   6 +-
 ...-transport-get-device-onboarding-info.html |   6 +-
 ...transport-get-device-onboarding-token.html |   6 +-
 use-case-transport-get-device.html            |   6 +-
 ...sport-get-file-metadata-of-attachment.html |   6 +-
 ...se-transport-get-message-by-messageid.html |   6 +-
 use-case-transport-get-or-load-file.html      |   6 +-
 use-case-transport-get-own-file.html          |   6 +-
 ...transport-get-relationship-by-address.html |   6 +-
 ...rt-get-relationship-by-relationshipid.html |   6 +-
 ...e-transport-get-relationship-template.html |   6 +-
 ...-synchronization-status-with-backbone.html |   6 +-
 use-case-transport-get-token-by-tokenid.html  |   6 +-
 ...rt-load-item-from-truncated-reference.html |   6 +-
 ...lationship-template-created-by-others.html |   6 +-
 ...ransport-load-token-created-by-others.html |   6 +-
 use-case-transport-query-devices.html         |   6 +-
 use-case-transport-query-files.html           |   6 +-
 use-case-transport-query-messages.html        |   6 +-
 ...ransport-query-relationship-templates.html |   6 +-
 use-case-transport-query-relationships.html   |   6 +-
 ...-transport-query-tokens-by-parameters.html |   6 +-
 ...e-transport-reject-relationshipchange.html |   6 +-
 ...-transport-send-message-to-recipients.html |   6 +-
 ...sport-synchronize-updates-of-backbone.html |   6 +-
 use-case-transport-update-device.html         |   6 +-
 use-case-transport-upload-own-file.html       |   6 +-
 use.html                                      |   6 +-
 use/install-the-app.html                      |   6 +-
 use/secure-device-setup.html                  |   6 +-
 150 files changed, 647 insertions(+), 647 deletions(-)

diff --git a/assets/css/main.css.map b/assets/css/main.css.map
index 3fd265618..64d27cec3 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-20240306-1794-mjjsz0/_sass/minimal-mistakes/skins/_air.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_variables.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_context.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_helpers.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_parsers.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/_query.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/_single.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/single/_default.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/_double.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default-pair.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_double-string.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/_triple.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/triple/_default.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/_resolution.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/parsers/resolution/_resolution.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_no-query.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_respond-to.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/breakpoint/_legacy-settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/magnific-popup/_magnific-popup.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/magnific-popup/_settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/_susy.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/_susy-prefix.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_utilities.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_su-validate.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_settings.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_normalize.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_parse.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_api.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_mixins.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_reset.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_base.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_forms.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_tables.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_animations.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_buttons.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_notices.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_masthead.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_navigation.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_footer.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_search.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_syntax.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_utilities.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_page.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_archive.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_sidebar.scss",
-		"../../../../../tmp/jekyll-remote-theme-20240306-1794-mjjsz0/_sass/minimal-mistakes/_print.scss"
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/skins/_air.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_variables.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_context.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_helpers.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_parsers.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/_query.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/_single.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/single/_default.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/_double.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default-pair.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_double-string.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/double/_default.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/_triple.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/triple/_default.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/_resolution.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/parsers/resolution/_resolution.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_no-query.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_respond-to.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/breakpoint/_legacy-settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/magnific-popup/_magnific-popup.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/magnific-popup/_settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/_susy.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/_susy-prefix.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_utilities.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_su-validate.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_settings.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_normalize.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_parse.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_api.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_mixins.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_reset.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_base.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_forms.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_tables.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_animations.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_buttons.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_notices.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_masthead.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_navigation.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_footer.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_search.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_syntax.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_utilities.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_page.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_archive.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_sass/minimal-mistakes/_sidebar.scss",
+		"../../../../../tmp/jekyll-remote-theme-20240308-1794-o0jn6l/_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 4e28211cd..476133cf4 100644
--- a/explore.html
+++ b/explore.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/addresses.html b/explore/addresses.html
index d7b7a1e79..e9315359b 100644
--- a/explore/addresses.html
+++ b/explore/addresses.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/app.html b/explore/app.html
index b55167062..a663d303c 100644
--- a/explore/app.html
+++ b/explore/app.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/backbone.html b/explore/backbone.html
index 0959f378b..ae1ffd19a 100644
--- a/explore/backbone.html
+++ b/explore/backbone.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/blockchain.html b/explore/blockchain.html
index 616cb1e55..de14ffa03 100644
--- a/explore/blockchain.html
+++ b/explore/blockchain.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/connector.html b/explore/connector.html
index bf35dd69e..0ab8826b6 100644
--- a/explore/connector.html
+++ b/explore/connector.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/cryptography.html b/explore/cryptography.html
index f19f6562f..ca688812b 100644
--- a/explore/cryptography.html
+++ b/explore/cryptography.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/example-scenarios.html b/explore/example-scenarios.html
index d44565e0b..7f3ce9773 100644
--- a/explore/example-scenarios.html
+++ b/explore/example-scenarios.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/faq.html b/explore/faq.html
index 92ece21a0..e14b96aa3 100644
--- a/explore/faq.html
+++ b/explore/faq.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/features.html b/explore/features.html
index e2186d2e8..500de97f6 100644
--- a/explore/features.html
+++ b/explore/features.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/how_does_enmeshed_work.html b/explore/how_does_enmeshed_work.html
index 06fa593aa..be050553d 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/integration.html b/explore/integration.html
index 49e5cf705..33a283502 100644
--- a/explore/integration.html
+++ b/explore/integration.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/backbone.html b/explore/layers/backbone.html
index 34fe40061..3ce7124f2 100644
--- a/explore/layers/backbone.html
+++ b/explore/layers/backbone.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/consumption.html b/explore/layers/consumption.html
index 64a10337b..8892791ae 100644
--- a/explore/layers/consumption.html
+++ b/explore/layers/consumption.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/integration.html b/explore/layers/integration.html
index 736cdb725..076f2b48d 100644
--- a/explore/layers/integration.html
+++ b/explore/layers/integration.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/transport.html b/explore/layers/transport.html
index 3fa8c97f8..d2fa01a63 100644
--- a/explore/layers/transport.html
+++ b/explore/layers/transport.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/layers/user-experience.html b/explore/layers/user-experience.html
index 826099074..ed581446c 100644
--- a/explore/layers/user-experience.html
+++ b/explore/layers/user-experience.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/privacy.html b/explore/privacy.html
index 5463ed9ec..27b031248 100644
--- a/explore/privacy.html
+++ b/explore/privacy.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/runtime.html b/explore/runtime.html
index 7f1dfdf6a..0146ac637 100644
--- a/explore/runtime.html
+++ b/explore/runtime.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/explore/security.html b/explore/security.html
index 19c24ba21..99bcf2b42 100644
--- a/explore/security.html
+++ b/explore/security.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/feed.xml b/feed.xml
index b2d8556af..5b44b10bc 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-03-06T15:56:29+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-03-08T16:25:32+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 0d0095576..83b80f1f2 100644
--- a/integrate.html
+++ b/integrate.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -589,7 +589,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/access-the-connector.html b/integrate/access-the-connector.html
index 1c6a9071e..6cf85bdef 100644
--- a/integrate/access-the-connector.html
+++ b/integrate/access-the-connector.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -434,7 +434,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/attribute-values.html b/integrate/attribute-values.html
index 9435171a5..9935fe19b 100644
--- a/integrate/attribute-values.html
+++ b/integrate/attribute-values.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -2939,7 +2939,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/connector-events.html b/integrate/connector-events.html
index 80823ad60..0164db80a 100644
--- a/integrate/connector-events.html
+++ b/integrate/connector-events.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -534,7 +534,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/create-attribute-for-peer.html b/integrate/create-attribute-for-peer.html
index 2ea51471b..dcfb3bd3a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -665,7 +665,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/create-attribute-for-yourself.html b/integrate/create-attribute-for-yourself.html
index 7e82949ac..0419b84f5 100644
--- a/integrate/create-attribute-for-yourself.html
+++ b/integrate/create-attribute-for-yourself.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create Attribute for yourself">
     <meta itemprop="description" content="This guide explains the end to end flow of creating an Attribute for your own Connector as its Integrator. As there are two types of Attributes, IdentityAttributes and RelationshipAttributes, a distinction must be made between them when creating an Attribute for yourself.Create an IdentityAttribute for yourselfThis section is about how to create an IdentityAttribute for your own Connector that is not initially shared with any other Identity. From a technical point of view, this corresponds to the creation of a LocalAttribute whose content is given by the IdentityAttribute that is intended to be created and whose shareInfo is undefined. Such a LocalAttribute is referred to as a RepositoryAttribute.Since knowledge about IdentityAttributes is required in the following, you should take a look at our IdentityAttribute introduction before you continue reading this guide. In particular, a description of the two kinds of IdentityAttributes, the simple IdentityAttributes and the complex IdentityAttributes, can be found there.Input for creating a RepositoryAttributeTo create a RepositoryAttribute, proceed as described in the Create a RepositoryAttribute use case documentation. As input for the creation of a RepositoryAttribute, the following content must be used:{  &quot;content&quot;: {    &quot;validFrom&quot;: &quot;&lt;start of IdentityAttribute&#39;s validity&gt;&quot;,    &quot;validTo&quot;: &quot;&lt;end of IdentityAttribute&#39;s validity&gt;&quot;,    &quot;value&quot;: {      // IdentityAttributeValue      ...    },    &quot;tags&quot;: [&quot;&lt;additional information 1&gt;&quot;, ..., &quot;&lt;additional information n&gt;&quot;]  }}You need to replace the placeholders marked with &lt;...&gt; appropriately. Also, it is necessary that you insert one of the available IdentityAttributeValues into the value property. Note that the properties validFrom, validTo and tags are optional, so you can omit them.Process of creating a RepositoryAttributeAs you can see from the diagram below, after you have entered the input for creating a RepositoryAttribute, a check is performed whether the input values for the properties of the specified IdentityAttributeValue meet the validation criteria documented on the Attribute Values page. If the validation is not successful, an error message is sent in response. Otherwise, a RepositoryAttribute is created that contains the IdentityAttribute in its content property. If it is a simple IdentityAttribute, a success response is sent directly. In the case of a complex IdentityAttribute, on the other hand, another RepositoryAttribute is created beforehand for each of its appropriate properties. These RepositoryAttributes for the properties are also referred to as children of the RepositoryAttribute belonging to the complex IdentityAttribute. The id of their parent is contained within their parentId property. Note that the successful creation of a LocalAttribute, and therefore in particular the creation of a RepositoryAttribute, triggers the consumption.attributeCreated Connector event.Example of creating a simple IdentityAttributeAn example of a simple IdentityAttribute is one of type DisplayName. To create one for your own Connector without specifying optional parameters, the following content must be used:{  &quot;content&quot;: {    &quot;value&quot;: {      &quot;@type&quot;: &quot;DisplayName&quot;,      &quot;value&quot;: &quot;&lt;display name of your own Connector&gt;&quot;    }  }}Assuming that the input value for the Connector’s display name specified in the value.value property meets the validation criterion, which means that the entered name does not have more than 100 characters, the IdentityAttribute is saved as a RepositoryAttribute and a success response is sent.Example of creating a complex IdentityAttributeAn example of a complex IdentityAttribute is one of type BirthDate. To create one for your own Connector without specifying optional parameters, the following content must be used:{  &quot;content&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;    }  }}Assuming that the input values ​​for the properties value.day, value.month and value.year meet the validation criteria, which means, for example, that the input value for value.month is an integer between 1 and 12, the IdentityAttribute is saved as a RepositoryAttribute. The properties value.day, value.month and value.year can each be understood as an additional simple IdentityAttribute of type BirthDay, BirthMonth and BirthYear, respectively. For this reason, another RepositoryAttribute is created internally for each of these properties before a success response is sent. So for the RepositoryAttribute, which belongs to the complex IdentityAttribute of type BirthDate, a total of three children are created.What’s next?When you have successfully created an IdentityAttribute for your own Connector, you will receive a success response. From the result, you can get the id of the corresponding RepositoryAttribute belonging to the IdentityAttribute. You will need this id, for example, if you want to share the underlying IdentityAttribute with other Identities later, as in the Share own Attribute to peer scenario.Create a RelationshipAttribute for yourselfIf you want to create a RelationshipAttribute, you must proceed differently than when creating an IdentityAttribute for yourself. This is because a RelationshipAttribute can only exist in the context of a Relationship with a peer, which means that they must also agree to the creation of it. This is achieved by sending a Request whose items property contains an appropriate RequestItem, which must be accepted by the peer. Depending on whether you or your peer should set the RelationshipAttributeValue and depending on other factors, a CreateAttributeRequestItem, ReadAttributeRequestItem, ProposeAttributeRequestItem or ShareAttributeRequestItem should be used for this.From a technical point of view, the creation of a RelationshipAttribute corresponds to the creation of one LocalAttribute for yourself and one LocalAttribute for your peer, whereby their content is given by the RelationshipAttribute that is intended to be created and the shareInfo of both LocalAttributes contains a correspondingly suitable LocalAttributeShareInfo.Utilization of a CreateAttributeRequestItemYou can use a CreateAttributeRequestItem to create a RelationshipAttribute in the context of a Relationship between you and your peer if you want the RelationshipAttributeValue to be set by yourself. Your peer can only accept or reject the creation of the RelationshipAttribute, but cannot modify the RelationshipAttributeValue. A RelationshipAttribute that you want to create using a CreateAttributeRequestItem can be owned by yourself or by your peer. For full details on how to create a RelationshipAttribute using a CreateAttributeRequestItem, please refer to the Create Attribute for peer guide.Utilization of a ReadAttributeRequestItemYou can use a ReadAttributeRequestItem to create a RelationshipAttribute in the context of a Relationship between you and your peer if you want the RelationshipAttributeValue to be set by your peer. Even if it seems misleading to use a ReadAttributeRequestItem to create a RelationshipAttribute, this terminology makes sense insofar as the RelationshipAttributeValue should be read from the peer in order to be able to create the RelationshipAttribute. A RelationshipAttribute that you want to create using a ReadAttributeRequestItem can be owned by yourself, your peer or even a third party. For full details on how to create a RelationshipAttribute using a ReadAttributeRequestItem, please refer to the Read Attribute from peer guide.Utilization of a ProposeAttributeRequestItemYou can use a ProposeAttributeRequestItem to create a RelationshipAttribute in the context of a Relationship between you and your peer if you want to propose a potentially suitable RelationshipAttributeValue to your peer, but your peer has the option to modify it before the RelationshipAttribute is created. A RelationshipAttribute that you want to create using a ProposeAttributeRequestItem must be owned by your peer. All details on how to create a RelationshipAttribute using a ProposeAttributeRequestItem can be found in the Propose Attribute to peer guide.Utilization of a ShareAttributeRequestItemYou can use a ShareAttributeRequestItem to create a RelationshipAttribute in the context of a Relationship between you and your peer if you want to use an existing RelationshipAttribute between you and a third party as the source for creating the new RelationshipAttribute. Your peer can only accept or reject the creation of it, but cannot modify it. A RelationshipAttribute that you want to create using a ShareAttributeRequestItem can be owned by yourself or the third party, but not by your peer. All details on how to create a RelationshipAttribute using a ShareAttributeRequestItem can be found in the Share own Attribute to peer guide.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -484,7 +484,7 @@ <h3 id="utilization-of-a-shareattributerequestitem">Utilization of a ShareAttrib
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/data-model-overview.html b/integrate/data-model-overview.html
index 1de8708d5..bcc1eee4a 100644
--- a/integrate/data-model-overview.html
+++ b/integrate/data-model-overview.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <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 RelationshipTemplate 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 RelationshipTemplate 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 RelationshipTemplate. The enmeshed App for example expects a RelationshipTemplate 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 RelationshipTemplate starts with the letters “RLT”. This way you can tell apart a RelationshipTemplate ID from any other ID just by looking at the prefix.                     isOwn      boolean      true if the RelationshipTemplate 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 RelationshipTemplate.                     createdByDevice      string      The ID of the Device that created the RelationshipTemplate. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the RelationshipTemplate was created                     content      RelationshipTemplateContent | unknown      The content of the RelationshipTemplate. 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 RelationshipTemplate expires on the Backbone. An expired RelationshipTemplate cannot be fetched from the Backbone anymore. However, the cached version of the RelationshipTemplate 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 RelationshipTemplate 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.                     secretKey      string      The key with which the RelationshipTemplate was encrypted.      saved only locally              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.      saved only locally      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 RelationshipTemplate 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 RelationshipChange 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 RelationshipChanges come into play. Whenever one party wants to make a change to the Relationship (like create or terminate it), it sends a RelationshipChange 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 RelationshipChange changes its mind, it can revoke the RelationshipChange. The Backbone makes sure that a RelationshipChange can only be completed in one of those three ways (accepted, rejected, revoked). So for example if you try to accept a RelationshipChange 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 RelationshipChange starts with the letters “RCH”. This way you can tell apart a RelationshipChange 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 RelationshipChange.                     type      &quot;Creation&quot;      The type of the RelationshipChange. Currently the only existing type is Creation. As soon as the termination of Relationships is supported, Termination will be a second RelationshipChange type.                     request      RelationshipChangeRequest      Information about the request of the RelationshipChange.                     response      RelationshipChangeResponse | undefined      Information about the response of the RelationshipChange.             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 RelationshipChangeRequest.                     createdByDevice      string      The ID of the Device that created the RelationshipChangeRequest. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the RelationshipChangeRequest was created                     content      RelationshipCreationChangeRequestContent | unknown      The content of the RelationshipChangeRequest. You can add whatever you want here. However, if the other party uses the enmeshed App, and the type of the RelationshipChange 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 RelationshipChangeResponse.                     createdByDevice      string      The ID of the Device that created the RelationshipChangeResponse. You can use this information to track back who exactly did what.                     createdAt      string      A timestamp that describes when the RelationshipChangeResponse was created                     content      unknown      The content of the RelationshipChangeResponse. 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 Messages with such a normalized content. 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.                     isOwn      boolean      Indicates whether you are the sender (true) or recipient (false) of the Message.                     wasReadAt      string | undefined      A timestamp indicating when the Message was firstly read. If a Message is marked as unread, this will be undefined. If a Message is read again, after having marked it as unread, the timestamp is updated. However, if a Message marked as read is read again, it won’t be updated.             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 RelationshipTemplate.            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 RelationshipChange.            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. In the context of IdentityAttributes, 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 an unshared LocalAttribute “RepositoryAttribute”. Its shareInfo property is undefined.  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. We call this LocalAttribute an “own shared IdentityAttribute”.  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. We call this LocalAttribute a “peer shared IdentityAttribute”.In contrast, RelationshipAttributes always exist in the context of a Relationship.Thus, it is not possible for an Identity to have an unshared RelationshipAttribute.  We refer to the LocalAttribute of the owner as “own shared RelationshipAttribute”.  The peer’s LocalAttribute we referred to as “peer shared RelationshipAttribute”.            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 RelationshipTemplate. 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 RelationshipTemplate. 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 RelationshipTemplate. However, if your peer uses the enmeshed App, it will only be able to process RelationshipTemplates 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 RelationshipTemplate. 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 RelationshipChanges, 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -3048,7 +3048,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/error-codes.html b/integrate/error-codes.html
index acea772ed..fb4a00860 100644
--- a/integrate/error-codes.html
+++ b/integrate/error-codes.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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.connector.attributes.cannotCreateNotSelfOwnedRepositoryAttribute       When createing an repository attribute the owner musst not be someone else.              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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -674,7 +674,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/establish-a-relationship-to-another-identity.html b/integrate/establish-a-relationship-to-another-identity.html
index 2b54c3697..d855e0318 100644
--- a/integrate/establish-a-relationship-to-another-identity.html
+++ b/integrate/establish-a-relationship-to-another-identity.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Establish a Relationship to another Identity">
     <meta itemprop="description" content="Communication and sharing of information between two Identities requires the existence of a Relationship between them. This guide describes how a Connector can establish an active Relationship to another Identity. Firstly, we explain how to create a RelationshipTemplate on a Connector, the so-called Templator, and how to make the RelationshipTemplate available to the other Identity. The RelationshipTemplate can then be used by the other Identity, the so-called Requestor, to send a RelationshipRequest to the Templator. This RelationshipRequest can finally be accepted by the Templator in order to establish an active Relationship between them.Create a RelationshipTemplateThe creation of a RelationshipTemplate on the Templator is the first required step in the process of establishing a Relationship.A RelationshipTemplate is a formal description of the aspects of a Relationship that can be established between two Identities. In particular, it can specify a Request sent from the Templator to the Requestor, which must be accepted by the Requestor as a prerequisite for the establishment of the Relationship.Input for creating a RelationshipTemplateTo create a RelationshipTemplate on the Templator, you need to follow the instructions described in the Create own RelationshipTemplate use case documentation using the following JSON payload as input:{  &quot;maxNumberOfAllocations&quot;: &lt;maximum number of allocations&gt;,  &quot;expiresAt&quot;: &quot;&lt;expiration date of RelationshipTemplate&gt;&quot;,  &quot;content&quot;: {    // Content of RelationshipTemplate    ...  }}You need to replace the placeholders marked with &lt;...&gt; appropriately as usual. The maxNumberOfAllocations property is optional, so you can omit it. If you need help filling the content property or the maxNumberOfAllocations property with appropriate values, see the RelationshipTemplate description in the Data Model Overview. It is important to note that if you intend to use the RelationshipTemplate to establish a Relationship between the Templator and an App user, you must use a RelationshipTemplateContent as the value of the content property. In this case, the input must be as follows:{  &quot;maxNumberOfAllocations&quot;: &lt;maximum number of allocations&gt;,  &quot;expiresAt&quot;: &quot;&lt;expiration date of RelationshipTemplate&gt;&quot;,  &quot;content&quot;: {    // RelationshipTemplateContent    &quot;@type&quot;: &quot;RelationshipTemplateContent&quot;,    &quot;title&quot;: &quot;&lt;title of RelationshipTemplate&gt;&quot;,    &quot;metadata&quot;: &lt;custom metadata&gt;,    &quot;onNewRelationship&quot;: {      // Specification of a Request      ...    },    &quot;onExistingRelationship&quot;: {      // Specification of another Request      ...    }  }}The properties content.title, content.metadata and content.onExistingRelationship are optional, so you can omit them. In case the content property of the RelationshipTemplate contains a RelationshipTemplateContent and therefore in particular at least one Request, you should test the Requests’ Validity before you create the RelationshipTemplate. An Identity to which the RelationshipTemplate will be made available and which does not yet have a Relationship to the Templator will receive the Request specified in the onNewRelationship property of the RelationshipTemplateContent. However, if a Relationship already exists between them and a Request has been specified in the onExistingRelationship property of the RelationshipTemplateContent, the Identity will receive this Request instead.How to send a Request via a RelationshipTemplate is explained in detail in the Requests over Templates guide.Successfully created RelationshipTemplateIf you have successfully created the RelationshipTemplate on the Templator, you will receive a success response from which you can read its id. As the Templator is the creator of the RelationshipTemplate, the createdBy property contains the Address of the Templator. For this reason, the value of the isOwn property is set to true in this context.                    Save the id of the RelationshipTemplate so that you can refer to it and make it available to other Identities later. For the same reason, save the values of the properties truncatedReference and secretKey.    Make the RelationshipTemplate availableBefore an Identity can establish a Relationship to the Templator, it must send a RelationshipRequest using a valid RelationshipTemplate which is owned by the Templator. Depending on whether the Identity is a Connector or an App user, a different approach must be used to make the RelationshipTemplate available to the Identity:  Make it available to a Connector: Load the RelationshipTemplate onto it.  Make it available to an App user: Scan the QR Code of the RelationshipTemplate.Make it available to a ConnectorIf a Connector wants to send a RelationshipRequest to the Templator, it must first load a RelationshipTemplate, which is owned by the Templator, onto itself. This can be done by following the Load RelationshipTemplate created by others use case description and providing the input:{  &quot;reference&quot;: &quot;&lt;truncated reference of RelationshipTemplate&gt;&quot;}In doing so, it is necessary to insert the value of the truncatedReference property read from the created RelationshipTemplate into the reference property. Alternatively, it is possible to specify the id and the secretKey of the created RelationshipTemplate and use the following input:{  &quot;id&quot;: &quot;&lt;ID of RelationshipTemplate&gt;&quot;,  &quot;secretKey&quot;: &quot;&lt;secret key of RelationshipTemplate&gt;&quot;}When the RelationshipTemplate of the Templator is successfully loaded onto the Connector, the transport.peerRelationshipTemplateLoaded Connector event is triggered and a success response is sent. This success response looks like the success response you receive when you have successfully created a RelationshipTemplate on the Templator, except that the value of the property isOwn is now false instead of true. Assuming that there is no Relationship between the Connector and the Templator yet and that the RelationshipTemplate contains a RelationshipTemplateContent in its content property, the Connector will additionally receive a new incoming Request. The Integrator of the Connector can accept it if they want to send a RelationshipRequest to the Templator.Make it available to an App userIf an App user wants to send a RelationshipRequest to the Templator, the App user must first scan a QR Code that contains the reference to a RelationshipTemplate which is owned by the Templator. To create this QR Code on the Templator, proceed as described in the documentation of the Get RelationshipTemplate use case, use the id of the created RelationshipTemplate and specify the value image/png in the Accept header field. After scanning the QR Code, the App user receives the conditions for establishing a Relationship to the Templator as specified in the RelationshipTemplate. If these are accepted, the App user can now send a RelationshipRequest to the Templator.Send a RelationshipRequestAfter the Templator has created a RelationshipTemplate and made it available to another Identity, this Identity can use it to send a RelationshipRequest to the Templator. For this reason, this other Identity is also referred to below as the Requestor.Send it as a ConnectorAssuming that the Requestor in this section is a Connector, our starting situation is that the Requestor has successfully loaded the created RelationshipTemplate onto itself. The received RelationshipTemplate may or may not contain a RelationshipTemplateContent in its content property. We now describe separately in both cases how the Requestor can use the RelationshipTemplate to send a RelationshipRequest to the Templator. An overview of this procedure is given in the following diagram.RelationshipTemplate with RelationshipTemplateContentWe assume that there is no Relationship between the Requestor and the Templator yet and that a RelationshipTemplateContent is used within the RelationshipTemplate. In this case, the Requestor receives a new incoming Request after loading the RelationshipTemplate and the consumption.incomingRequestReceived Connector event is triggered. By proceeding as described in the Query incoming Requests use case documentation and specifying source.reference=&lt;ID of RelationshipTemplate&gt; as a query parameter, this Request can be queried on the Requestor. The result contains the corresponding LocalRequest, from which you can read the id of the Request.                    Save the id of the incoming Request so that you can accept or reject it.    The content of the LocalRequest is the Request specified in the onNewRelationship property of the RelationshipTemplateContent. This Request defines the conditions for establishing an active Relationship between the Requestor and the Templator. If the Requestor agrees to them, it can send a RelationshipRequest to the Templator by accepting the Request. This is done by following the instructions of the Accept incoming Request use case and providing the id of the Request as well as an appropriate input to build the Response of the Requestor to the Request. In case of success, the status of the LocalRequest will change from &quot;ManualDecisionRequired&quot; to &quot;Decided&quot; and the consumption.incomingRequestStatusChanged Connector event will be triggered. The Response of the Requestor to the Request will be contained within the response.content property of the LocalRequest. By accepting the Request, a data object of type Relationship with &quot;Pending&quot; as status is created additionally and the transport.relationshipChanged Connector event is triggered. An associated RelationshipChange, which has &quot;Creation&quot; as type and &quot;Pending&quot; as status, can be found within the changes property of the Relationship. The request.content.response property of the RelationshipChange contains the Response of the Requestor to the Request.It is not necessary, but you can query this Relationship by proceeding as described in the Query Relationships use case documentation, using the query parameter template.id=&lt;ID of RelationshipTemplate&gt;. If you decide to do this, you will receive a result as response from which you can read the id of the Relationship and the id of the associated RelationshipChange.Note that it is of course also possible to reject the incoming Request, if the Requestor does not wish to establish an active Relationship to the Templator under the given conditions. In order to do this, make use of the documentation of the Reject incoming Request use case. More detailed information about how to reject as well as how to accept an incoming Request can also be found in the Requests over Templates guide.RelationshipTemplate without RelationshipTemplateContentWe now consider the situation in which the RelationshipTemplate loaded onto the Requestor does not contain a RelationshipTemplateContent in its content property. In this case, the Requestor does not receive an incoming Request. Nevertheless, it can send a RelationshipRequest to the Templator by explicitly creating a data object of type Relationship with &quot;Pending&quot; as status based on the RelationshipTemplate. To do this, follow the instructions of the Create Relationship with RelationshipTemplate use case and provide as input:{  &quot;templateId&quot;: &quot;&lt;ID of RelationshipTemplate&gt;&quot;,  &quot;content&quot;: {    // Customized content    ...  }}Note that the content property is optional and can therefore be omitted. In case of success, the transport.relationshipChanged Connector event will be triggered and you will receive a result as response, which contains the created data object of type Relationship and in particular an associated RelationshipChange. The RelationshipChange has &quot;Creation&quot; as type and &quot;Pending&quot; as status. If you have specified a customized content within the content property of the input, it is contained within the request.content property of the RelationshipChange.Saving the id of the Relationship and the id of the associated RelationshipChange is useful if you want to return to the created Relationship later in order to retrace changes to the Relationship.Send it as an App userAs already mentioned in the description of the input for creating a RelationshipTemplate, a RelationshipTemplateContent must be used as the value of the content property of the RelationshipTemplate if you intend to use the RelationshipTemplate to establish a Relationship between the Templator and an App user. Assuming that there is no Relationship between them yet, the App user receives the Request specified in the onNewRelationship property of the RelationshipTemplateContent after scanning the QR Code associated with the RelationshipTemplate. The App user has the option of accepting or rejecting the Request. If they accept the Request appropriately, a RelationshipRequest is sent to the Templator. Internally, this corresponds to the creation of a data object of type Relationship with &quot;Pending&quot; as status and an associated RelationshipChange within its changes property. The RelationshipChange has &quot;Creation&quot; as type and &quot;Pending&quot; as status. The Response of the App user to the Request is contained within the request.content.response property of the RelationshipChange.Please note that the general procedure is the same if an App user instead of a Connector wants to send a RelationshipRequest to the Templator. The difference is that the RelationshipTemplate does not need to contain a RelationshipTemplateContent in its content property if it is intended to be used by a Connector.Establish an active RelationshipAfter the Requestor has sent the RelationshipRequest, the Integrator of the Templator can accept it if they want to establish an active Relationship to the Requestor. We now explain all required steps for establishing an active Relationship, including the necessary synchronization of the Templator and any other Connector that may be involved at certain points in time. Please note that the synchronization can also be automated by using the Sync Module.Receive the RelationshipRequestThe Templator must first synchronize the updates of the Backbone in order to receive the data object of type Relationship with &quot;Pending&quot; as status previously created by the Requestor and therefore the RelationshipRequest. The synchronization causes the transport.relationshipChanged Connector event to be triggered and the result of the response after synchronization contains the information about the created Relationship. In particular, the id of the Relationship and the id of the associated RelationshipChange with &quot;Creation&quot; as type and &quot;Pending&quot; as status can be read from it.                    Read the id of the Relationship from the relationships.id property and the id of the RelationshipChange from the relationships.changes.id property of the synchronization result for the next step.    Accept the RelationshipRequestIf the Templator accepts the RelationshipRequest, the status of the data object of type Relationship will change from &quot;Pending&quot; to &quot;Active&quot; and therefore an active Relationship between the Templator and the Requestor will be established. In addition, the transport.relationshipChanged Connector event will be triggered. To accept the RelationshipRequest, consult the Accept RelationshipChange use case description and specify the id of the Relationship and the id of the associated RelationshipChange.For rejecting the RelationshipRequest and therefore not establishing an active Relationship between the Templator and the Requestor, take a look at the documentation of the Reject RelationshipChange use case.Get informed about the acceptance of the RelationshipRequestAssuming the Requestor is a Connector, it must synchronize the updates of the Backbone after the Templator has accepted the RelationshipRequest. The synchronization causes the transport.relationshipChanged Connector event to be triggered and the result of the response after synchronization shows in particular that the status of the Relationship has been changed from &quot;Pending&quot; to &quot;Active&quot; and that the status of the associated RelationshipChange with &quot;Creation&quot; as type has been changed from &quot;Pending&quot; to &quot;Accepted&quot;. Now the Requestor is informed that the Templator has accepted the RelationshipRequest and therefore an active Relationship has been established between them. If the Requestor is an App user instead, they are informed about the acceptance of the RelationshipRequest analogously.What’s next?After an active Relationship between the two Identities is established, they are able to share information with each other. For example, they can exchange Messages. A possible scenario that demonstrates how a Connector can send a Message to another Identity with which it has an active Relationship is described in the Requests over Messages scenario documentation.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -567,7 +567,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/event-introduction.html b/integrate/event-introduction.html
index 89803b9fe..31f296e88 100644
--- a/integrate/event-introduction.html
+++ b/integrate/event-introduction.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -435,7 +435,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/integration-example.html b/integrate/integration-example.html
index 91059e38f..3d65e558c 100644
--- a/integrate/integration-example.html
+++ b/integrate/integration-example.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -740,7 +740,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/propose-attribute-to-peer.html b/integrate/propose-attribute-to-peer.html
index c2327e7bd..275dacb08 100644
--- a/integrate/propose-attribute-to-peer.html
+++ b/integrate/propose-attribute-to-peer.html
@@ -10,7 +10,7 @@
     <meta charset="utf-8">
 
 <!-- begin _includes/seo.html --><title>Propose Attribute to peer - enmeshed</title>
-<meta name="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 Attributes  The 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 ProposeAttributeRequestItem  To 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 ProposeAttributeRequestItem  The 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 IdentityAttribute  In 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 RelationshipAttribute  Let’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 Attributes  Proposing 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 Request  The 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 Template  If 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 Message  The 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 Attributes  After 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 ProposeAttributeRequestItem  The 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 ProposeAttributeRequestItem  Even 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 RequestItemGroup  Let’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 Request  We 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 name="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 Attributes  The 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 ProposeAttributeRequestItem  To 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 ProposeAttributeRequestItem  The 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 IdentityAttribute  In 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 RelationshipAttribute  Let’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 Attributes  Proposing 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 Request  The 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 Template  If 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 Message  The 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 Attributes  After 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 ProposeAttributeRequestItem  The 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 ProposeAttributeRequestItem  Even 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 RequestItemGroup  Let’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;&lt;Address of Recipient&gt;&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;&lt;Address of Recipient&gt;&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 Request  We 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 name="author" content="Enmeshed Team">
@@ -26,7 +26,7 @@
 <meta property="og:url" content="/integrate/propose-attribute-to-peer">
 
 
-  <meta property="og: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 Attributes  The 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 ProposeAttributeRequestItem  To 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 ProposeAttributeRequestItem  The 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 IdentityAttribute  In 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 RelationshipAttribute  Let’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 Attributes  Proposing 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 Request  The 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 Template  If 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 Message  The 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 Attributes  After 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 ProposeAttributeRequestItem  The 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 ProposeAttributeRequestItem  Even 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 RequestItemGroup  Let’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 Request  We 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 property="og: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 Attributes  The 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 ProposeAttributeRequestItem  To 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 ProposeAttributeRequestItem  The 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 IdentityAttribute  In 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 RelationshipAttribute  Let’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 Attributes  Proposing 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 Request  The 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 Template  If 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 Message  The 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 Attributes  After 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 ProposeAttributeRequestItem  The 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 ProposeAttributeRequestItem  Even 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 RequestItemGroup  Let’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;&lt;Address of Recipient&gt;&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;&lt;Address of Recipient&gt;&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 Request  We 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.">
 
 
 
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -351,8 +351,8 @@ <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-03-06T15:56:29+01:00">
+    <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;&lt;Address of Recipient&gt;&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;&lt;Address of Recipient&gt;&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-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -622,7 +622,7 @@ <h3 id="example-of-accepting-a-requestitemgroup">Example of accepting a RequestI
       </span><span class="nl">"accept"</span><span class="p">:</span><span class="w"> </span><span class="kc">true</span><span class="p">,</span><span class="w">
       </span><span class="nl">"attribute"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
         </span><span class="nl">"@type"</span><span class="p">:</span><span class="w"> </span><span class="s2">"IdentityAttribute"</span><span class="p">,</span><span class="w">
-        </span><span class="nl">"owner"</span><span class="p">:</span><span class="w"> </span><span class="s2">""</span><span class="p">,</span><span class="w">
+        </span><span class="nl">"owner"</span><span class="p">:</span><span class="w"> </span><span class="s2">"&lt;Address of Recipient&gt;"</span><span class="p">,</span><span class="w">
         </span><span class="nl">"value"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
           </span><span class="nl">"@type"</span><span class="p">:</span><span class="w"> </span><span class="s2">"PersonName"</span><span class="p">,</span><span class="w">
           </span><span class="nl">"givenName"</span><span class="p">:</span><span class="w"> </span><span class="s2">"&lt;given name that the Sender proposes to the Recipient&gt;"</span><span class="p">,</span><span class="w">
@@ -639,7 +639,7 @@ <h3 id="example-of-accepting-a-requestitemgroup">Example of accepting a RequestI
           </span><span class="nl">"accept"</span><span class="p">:</span><span class="w"> </span><span class="kc">true</span><span class="p">,</span><span class="w">
           </span><span class="nl">"attribute"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
             </span><span class="nl">"@type"</span><span class="p">:</span><span class="w"> </span><span class="s2">"IdentityAttribute"</span><span class="p">,</span><span class="w">
-            </span><span class="nl">"owner"</span><span class="p">:</span><span class="w"> </span><span class="s2">""</span><span class="p">,</span><span class="w">
+            </span><span class="nl">"owner"</span><span class="p">:</span><span class="w"> </span><span class="s2">"&lt;Address of Recipient&gt;"</span><span class="p">,</span><span class="w">
             </span><span class="nl">"value"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
               </span><span class="nl">"@type"</span><span class="p">:</span><span class="w"> </span><span class="s2">"EMailAddress"</span><span class="p">,</span><span class="w">
               </span><span class="nl">"value"</span><span class="p">:</span><span class="w"> </span><span class="s2">"&lt;Recipient's corrected version of the email address&gt;"</span><span class="w">
@@ -690,7 +690,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/read-attribute-from-peer.html b/integrate/read-attribute-from-peer.html
index ff7bf6ef7..2eaa397ef 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -650,7 +650,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/request-and-response-introduction.html b/integrate/request-and-response-introduction.html
index 4122a9ba8..b9b25817a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -590,7 +590,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/request-persistent-consent-of-peer.html b/integrate/request-persistent-consent-of-peer.html
index fadb77161..1751734c7 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -562,7 +562,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requesting-one-time-consents.html b/integrate/requesting-one-time-consents.html
index f6f76b6a8..47f9269bd 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -524,7 +524,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requests-and-requestitems.html b/integrate/requests-and-requestitems.html
index 7345695d0..0c0a0eb8b 100644
--- a/integrate/requests-and-requestitems.html
+++ b/integrate/requests-and-requestitems.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -626,7 +626,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requests-over-messages.html b/integrate/requests-over-messages.html
index 69ead6225..cba5633d4 100644
--- a/integrate/requests-over-messages.html
+++ b/integrate/requests-over-messages.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 Webhooks 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -607,7 +607,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/requests-over-templates.html b/integrate/requests-over-templates.html
index d39e8876e..cf8772a48 100644
--- a/integrate/requests-over-templates.html
+++ b/integrate/requests-over-templates.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 Webhooks 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -612,7 +612,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/sending-messages.html b/integrate/sending-messages.html
index ba44aa892..c944618d4 100644
--- a/integrate/sending-messages.html
+++ b/integrate/sending-messages.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -463,7 +463,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/share-own-attribute-to-peer.html b/integrate/share-own-attribute-to-peer.html
index fdb2cf030..0dfdd5762 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 Attribute for yourself 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -724,7 +724,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/succeeding-attributes-to-update-their-values.html b/integrate/succeeding-attributes-to-update-their-values.html
index fd7728454..cdeebea96 100644
--- a/integrate/succeeding-attributes-to-update-their-values.html
+++ b/integrate/succeeding-attributes-to-update-their-values.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Succeeding Attributes to update their values">
     <meta itemprop="description" content="The way enmeshed handles updates to your personal data is by succeeding old Attributes with new ones.Instead of simply replacing old data, a completely new Attribute is created which succeeds its predecessor.Thus, you and your peers are provided with a coherent history of all past versions.How the Attribute succession works in detail depends on the type of Attribute.Succeeding own IdentityAttributesWhen talking about IdentityAttributes, we need to distinguish three cases:  The Identity maintains an unshared Attribute about itself. This IdentityAttribute is stored in the content field of a LocalAttribute, whose shareInfo is undefined. Since this LocalAttribute is created for the Identity’s private repository of Attributes, it is referred to as RepositoryAttribute.  When sharing a RepositoryAttribute with a peer, a copy of the IdentityAttribute is created for the Sender and stored in the content field of a LocalAttribute with a defined shareInfo. We call this LocalAttribute an own shared IdentityAttribute.  Receiving a shared IdentityAttribute from a peer leads to the creation of a LocalAttribute with according content and a defined shareInfo for the Recipient. We call this LocalAttribute a peer shared IdentityAttribute.Discussing the succession of IdentityAttributes requires some background knowledge about this differentiation and the behavior of shared Attributes.Hence, we will look at the process of creating, sharing and succeeding an IdentityAttribute step by step.Creating a RepositoryAttributeEnmeshed allows you to store data about yourself in the form of IdentityAttributes.When creating an IdentityAttribute, it is not necessary to share it immediately with a peer.Instead, it will be stored in the content property of a LocalAttribute with an undefined shareInfo.We refer to these unshared LocalAttributes as RepositoryAttributes, since they make up your private repository of Attributes.In the following examples, the createdAt property all occuring LocalAttribute is omitted, since it isn’t required for the explanation.Sharing a RepositoryAttributeNow, in order to share a RepositoryAttribute, you need to send an according Request to the peer you want to share it with.If they accept your Request, a new LocalAttribute will be created at the peer’s side.This peer shared IdentityAttribute has the same content like your RepositoryAttribute and, in addition, a defined shareInfo property.It stores the Address of the peer who shared the Attribute with them, i.e. your Address, and a reference to the Request that was used to share the Attribute.Receiving the Response, an own shared IdentityAttribute with equal content will be created at your side.Its shareInfo stores the same requestReference and the peer’s Address, as well as the id of the RepositoryAttribute, whose content was copied, in the field sourceAttribute.Concluding, sharing an IdentityAttribute will create an own shared IdentityAttribute copy for every peer you shared the Attribute with at your side and a peer shared IdentityAttribute copy for each peer at their side.Succeeding a RepositoryAttributeNext, let’s consider the case that the value of your IdentityAttribute changes and you want to update it.To succeed the RepositoryAttribute, a new LocalAttribute with the updated content will be created.This successor stores the id of the old version, the predecessor, in its succeeds property.The predecessor is updated, too, such that its succeededBy property links to the successor.Consequently, the different versions of a LocalAttribute created by Attribute successions make up a doubly linked list.Notifying a peer about a RepositoryAttribute successionAfter succeeding a RepositoryAttribute, you can check with which of your peers you have previously shared the succeeded Attribute to choose those, you’d like to notify about the succession.Your own shared IdentityAttributes associated with the peers chosen will be succeeded in the same manner as your RepositoryAttribute before.Then, a Notification is sent to the peers, containing a PeerSharedAttributeSucceededNotificationItem.In the successorContent property of the latter the updated IdentityAttribute is transmitted and automatically a likewise succession at the peers’ side will be triggered, such that their LocalAttribute versions replicate the succession chain at your side.Succeeding own RelationshipAttributesRelationshipAttributes are, as the name suggests, always associated with a Relationship.Thus, it is not possible to have unshared instances of them.Instead, you and your peer will always each have a LocalAttribute with the same RelationshipAttribute as content.We refer to the LocalAttribute of the owner as own shared RelationshipAttribute and to the peer’s LocalAttribute as peer shared RelationshipAttribute.Creating and sharing a RelationshipAttributeWanting to create a RelationshipAttribute always involves sharing it directly with a peer.To this end, a Request containing a CreateAttributeRequestItem with the RelationshipAttribute will be created and will be sent to the peer.Only if the peer accepts this Request will a LocalAttribute with the RelationshipAttribute as content be created at their side and after you receive their Response, at your side, too.Hence, you and your peer will always have an identical shared RelationshipAttribute, only differing in the LocalAttribute’s shareInfo.peer property.Succeeding a RelationshipAttribute and notifying the peerEqually to IdentityAttributes, again only the owner can succeed a RelationshipAttribute to update its value.Doing so, a new version of the own shared RelationshipAttribute will be created at your side.The succeeds property of this LocalAttribute links to the old version, whose succeededBy property in turn is updated to the id of the newly created successor.Then, a Notification is sent automatically to the peer, which triggers the creation of a new peer shared RelationshipAttribute at their side, such that their LocalAttribute versions replicate the succession chain at your side.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -475,7 +475,7 @@ <h3 id="succeeding-a-relationshipattribute-and-notifying-the-peer">Succeeding a
 
         
 
-  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2024-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/integrate/use-cases.html b/integrate/use-cases.html
index 5a277771c..314b751f8 100644
--- a/integrate/use-cases.html
+++ b/integrate/use-cases.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 RepositoryAttribute                 Consumption        Identity        Attributes        Runtime                                         Create a shared Attribute copy                 Consumption        Identity        Attributes        Runtime                                         Create and complete outgoing Request from Relationship Template Response                 Consumption        Identity        Requests        Runtime                                         Create and share a RelationshipAttribute                 Consumption        Identity        Attributes        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                                         Get shared versions of a RepositoryAttribute                 Consumption        Identity        Attributes        Runtime                                         Get versions of an attribute                 Consumption        Identity        Attributes        Runtime                                         Notify peer about RepositoryAttribute succession                 Consumption        Identity        Attributes        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                                         Share a RepositoryAttribute                 Consumption        Identity        Attributes        Runtime                                         Succeed a RelationshipAttribute and notify peer                 Consumption        Identity        Attributes        Runtime                                         Succeed a RepositoryAttribute                 Consumption        Identity        Attributes        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 RelationshipChange                 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 Relationships                 Transport        Identity        Relationships        Runtime                                         Query Tokens by parameters                 Transport        Identity        Tokens        Runtime                                         Reject RelationshipChange                 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -1557,7 +1557,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate.html b/operate.html
index 749a09816..8c93eb07c 100644
--- a/operate.html
+++ b/operate.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/configuration.html b/operate/configuration.html
index 9f2c39d11..c48785f53 100644
--- a/operate/configuration.html
+++ b/operate/configuration.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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.  webhooks Sample Configuration:{  // ...  &quot;modules&quot;: {    &quot;webhooks&quot;: {      &quot;enabled&quot;: false,      &quot;targets&quot;: {},      &quot;webhooks&quot;: []    }  }}      enabled default: false    Enable or disable the webhooks 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/log-event-ids.html b/operate/log-event-ids.html
index 12df08077..1ef8b627e 100644
--- a/operate/log-event-ids.html
+++ b/operate/log-event-ids.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/modules.html b/operate/modules.html
index f608ff378..b67715a60 100644
--- a/operate/modules.html
+++ b/operate/modules.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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.Webhooks 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/overview-of-connector-operations.html b/operate/overview-of-connector-operations.html
index 92bd05800..d7f36a206 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/performance-considerations.html b/operate/performance-considerations.html
index a246dd8e2..ca1ebdc18 100644
--- a/operate/performance-considerations.html
+++ b/operate/performance-considerations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/privacy-considerations.html b/operate/privacy-considerations.html
index d768a930b..7ab8e4dae 100644
--- a/operate/privacy-considerations.html
+++ b/operate/privacy-considerations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/security-considerations.html b/operate/security-considerations.html
index fa7d4ca7d..4205e1d75 100644
--- a/operate/security-considerations.html
+++ b/operate/security-considerations.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/setup-with-docker-compose.html b/operate/setup-with-docker-compose.html
index dbadbff90..e7056ef2a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/setup-with-helm-charts.html b/operate/setup-with-helm-charts.html
index fa77e6b5c..abe935390 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/support.html b/operate/support.html
index 5b9231a38..b446476ba 100644
--- a/operate/support.html
+++ b/operate/support.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/operate/troubleshooting-guide.html b/operate/troubleshooting-guide.html
index d4bf29c23..b47c7aeea 100644
--- a/operate/troubleshooting-guide.html
+++ b/operate/troubleshooting-guide.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/sitemap.xml b/sitemap.xml
index 4c0066a60..a4bc253a0 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,591 +2,591 @@
 <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-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/example-scenarios</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/features</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/faq</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/integration</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/security</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/privacy</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/backbone</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/transport</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/consumption</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/integration</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/layers/user-experience</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/app</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/backbone</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/connector</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/addresses</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/runtime</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/cryptography</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/explore/blockchain</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/access-the-connector</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/attribute-values</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/connector-events</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/create-attribute-for-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/create-attribute-for-yourself</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/data-model-overview</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/error-codes</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/establish-a-relationship-to-another-identity</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/event-introduction</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/integration-example</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/propose-attribute-to-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/read-attribute-from-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/request-and-response-introduction</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/request-persistent-consent-of-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requesting-one-time-consents</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requests-and-requestitems</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requests-over-messages</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/requests-over-templates</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/sending-messages</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/share-own-attribute-to-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/succeeding-attributes-to-update-their-values</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/integrate/use-cases</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/configuration</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/log-event-ids</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/modules</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/overview-of-connector-operations</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/performance-considerations</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/privacy-considerations</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/security-considerations</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/setup-with-docker-compose</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/setup-with-helm-charts</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/support</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/operate/troubleshooting-guide</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use/install-the-app</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use/secure-device-setup</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-anonymous-load-token-by-id-and-key-without-having-an-account</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-anonymous-load-token-by-truncated-reference-without-having-an-account</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-accept-incoming-request</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-check-if-incoming-request-can-be-accepted</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-check-if-incoming-request-can-be-rejected</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-check-if-outgoing-request-can-be-created</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-a-repositoryattribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-a-shared-attribute-copy</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-and-complete-outgoing-request-from-relationship-template-response</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-and-share-a-relationshipattribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-create-outgoing-request</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-discards-outgoing-request</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-execute-a-relationshipattributequery</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-execute-a-thirdpartyattributequery</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-execute-an-identityattributequery</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attributelistener</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attributes-of-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-attributes-shared-to-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-incoming-request</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-outgoing-request</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-shared-versions-of-a-repositoryattribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-get-versions-of-an-attribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-notify-peer-about-repositoryattribute-succession</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-attributelisteners</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-attributes</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-incoming-requests</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-query-outgoing-requests</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-reject-incoming-request</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-share-a-repositoryattribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-succeed-a-relationshipattribute-and-notify-peer</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-consumption-succeed-a-repositoryattribute</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-delete_-rest-endpoint</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-profile-by-enmeshed-address</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-profile</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-profiles</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-support-information</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-the-connector-health-status</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get-the-connector-version-information</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+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-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-get_-rest-endpoint</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-post_-rest-endpoint</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-put_-rest-endpoint</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-device-rename-profile</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-cancel_-action</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-device_-external-usecase</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-enter_-data-on-screen</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-navigate-to-screen_-screen</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-negative_-action</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-positive_-action</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-scan_-qr-code-on-different-device</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-human-select_-item-on-screen</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-accept-relationshipchange</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-own-relationshiptemplate</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-own-token</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-relationship-with-relationshiptemplate</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-token-for-file</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-create-token-for-own-relationship-template</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-download-file-of-attachment</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-download-file</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-attributes-for-relationship</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-currently-used-device</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-currently-used-identity</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-device-onboarding-info</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-device-onboarding-token</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-device</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-file-metadata-of-attachment</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-message-by-messageid</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-or-load-file</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-own-file</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-relationship-by-address</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-relationship-by-relationshipid</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-relationship-template</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-synchronization-status-with-backbone</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-get-token-by-tokenid</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-load-item-from-truncated-reference</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-load-relationship-template-created-by-others</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-load-token-created-by-others</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-devices</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-files</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-messages</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-relationship-templates</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-relationships</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-query-tokens-by-parameters</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-reject-relationshipchange</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-send-message-to-recipients</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-synchronize-updates-of-backbone</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-update-device</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+01:00</lastmod>
 </url>
 <url>
 <loc>/use-case-transport-upload-own-file</loc>
-<lastmod>2024-03-06T15:56:29+01:00</lastmod>
+<lastmod>2024-03-08T16:25:32+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 dcd551fa5..9edffbd07 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -488,7 +488,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 897494c27..eb0d3e5ed 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -486,7 +486,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-accept-incoming-request.html b/use-case-consumption-accept-incoming-request.html
index 0902dbd53..aa242e436 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -520,7 +520,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 9959ee389..37a88f08d 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -518,7 +518,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 368a1f2fb..adfedc67c 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -516,7 +516,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 03d9f2c86..daac794e6 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -513,7 +513,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-a-repositoryattribute.html b/use-case-consumption-create-a-repositoryattribute.html
index d2def3d8b..beea82918 100644
--- a/use-case-consumption-create-a-repositoryattribute.html
+++ b/use-case-consumption-create-a-repositoryattribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create a RepositoryAttribute">
     <meta itemprop="description" content="This use-case is intended to create a RepositoryAttribute, i.e. an unshared LocalAttributebased on a given IdentityAttribute.Parameters  The content for the LocalAttribute that ought to be created as IdentityAttribute without the ownerproperty, since it is automatically set to your AddressOn Success  A LocalAttribute is created according to the parameters and returned with an undefined shareInfo.On Failure  The LocalAttribute cannot be created if the parameter is malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 2d26b7cca..099664629 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -489,7 +489,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 dc0770c43..a79ce2be7 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-and-share-a-relationshipattribute.html b/use-case-consumption-create-and-share-a-relationshipattribute.html
index 4d62fbef0..f863101ae 100644
--- a/use-case-consumption-create-and-share-a-relationshipattribute.html
+++ b/use-case-consumption-create-and-share-a-relationshipattribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Create and share a RelationshipAttribute">
     <meta itemprop="description" content="RelationshipAttributes are always associated with a Relationship between two Identities.Consequently, in contrast to IdentityAttributes, there cannot be unshared RelationshipAttributes.Instead, you and your peer will always each have a LocalAttribute with the same RelationshipAttribute as content and which only differs in the shareInfo.peer property.Thus, wanting to create a new RelationshipAttribute, a Request is sent to the peer via Message.Only if the peer accepts this Request, the RelationshipAttribute will be created at their side.Once you receive the Response, a LocalAttribute with the same content will be created at your side.Parameters  The content of the RelationshipAttribute you want to create, following the description from the data model, except for the owner, which is automatically set to your Address  The Address of the peer  Optionally requestMetadata as described in the data model, except for the id and items, which are handled automatically.On Success  A Request is sent via Message to the peer, containing a CreateAttributeRequestItem with the RelationshipAttribute you want to create and share with the peer. Furthermore, the Request is returned.On Failure  The Request cannot be created, if the peer is unknown.  The Request cannot be created, if the parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -485,7 +485,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-create-outgoing-request.html b/use-case-consumption-create-outgoing-request.html
index 03e945301..d6360bc0a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -517,7 +517,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-discards-outgoing-request.html b/use-case-consumption-discards-outgoing-request.html
index 9b5c1aff9..b74bc9abb 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -484,7 +484,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-execute-a-relationshipattributequery.html b/use-case-consumption-execute-a-relationshipattributequery.html
index 902b3342c..bf516d951 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-execute-a-thirdpartyattributequery.html b/use-case-consumption-execute-a-thirdpartyattributequery.html
index 5244ebd4f..4c336e9c7 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -513,7 +513,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-execute-an-identityattributequery.html b/use-case-consumption-execute-an-identityattributequery.html
index f4cdccb90..221dc1b68 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-attribute.html b/use-case-consumption-get-attribute.html
index 33d7e6f14..e95ee9760 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-attributelistener.html b/use-case-consumption-get-attributelistener.html
index 9c3c02f4f..c8c98e377 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -483,7 +483,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 56332f2ff..8e1581a0d 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -513,7 +513,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 9e6c94a14..939fae72c 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -513,7 +513,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-incoming-request.html b/use-case-consumption-get-incoming-request.html
index 556af9e9e..389679d3c 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-outgoing-request.html b/use-case-consumption-get-outgoing-request.html
index ade0bb739..c2fa1f242 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-shared-versions-of-a-repositoryattribute.html b/use-case-consumption-get-shared-versions-of-a-repositoryattribute.html
index 1e17eddc5..b611a52f8 100644
--- a/use-case-consumption-get-shared-versions-of-a-repositoryattribute.html
+++ b/use-case-consumption-get-shared-versions-of-a-repositoryattribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get shared versions of a RepositoryAttribute">
     <meta itemprop="description" content="This use-case allows you to retrieve a list of own shared IdentityAttributes for a specified RepositoryAttribute.Parameters  The attributeId belonging to a RepositoryAttribute you would like to know all shared versions of  Optionally the returned LocalAttributes can be limited to those shared with specific peers.  onlyLatestVersions omits succeeded versions; by default this is set to be true.On Success  A list of own shared IdentityAttribute versions of the RepositoryAttribute given as input will be returned.  If peers were speficied, the list is limited to the entries shared with those peers.  If onlyLatestVersions is disabled, all versions will be returned, even if they already have successors.On Failure  No LocalAttributes can be returned, if the attributeId correlates to a RelationshipAttribute.  No LocalAttributes can be returned, if the attributeId correlates to an IdentityAttribute with a shareInfo.  No LocalAttributes can be returned, if the an empty list is provided for peers.  No LocalAttributes can be returned, if the peers are unknown.  No LocalAttributes can be returned, if the parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -485,7 +485,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-get-versions-of-an-attribute.html b/use-case-consumption-get-versions-of-an-attribute.html
index eafe6d32b..bdfe04300 100644
--- a/use-case-consumption-get-versions-of-an-attribute.html
+++ b/use-case-consumption-get-versions-of-an-attribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Get versions of an attribute">
     <meta itemprop="description" content="Succeeding an Attribute allows you to update its content, while keeping all versions for a coherent history.This use-case allows you to retrieve a list of all those versions of the succession chain for a specified LocalAttribute.Parameters  The attributeId belonging to a LocalAttribute you would like to know all versions ofOn Success  If the attributeId refers to a RepositoryAttribute, a list of all versions of this RepositoryAttribute will be returned.  If the attributeId refers to an own shared IdentityAttribute, a list of all versions of that Attribute shared with the same peer will be returned.  If the attributeId refers to a peer shared IdentityAttribute, a list of all versions of that Attribute received from the peer will be returned.  If the attributeId refers to a RelationshipAttribute, a list of all versions of that RelationshipAttribute will be returned.On Failure  No Attributes can be returned, if the attributeId doesn&#8217;t belong to a valid LocalAttribute.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -480,7 +480,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-notify-peer-about-repositoryattribute-succession.html b/use-case-consumption-notify-peer-about-repositoryattribute-succession.html
index b9d6df412..ad42140f3 100644
--- a/use-case-consumption-notify-peer-about-repositoryattribute-succession.html
+++ b/use-case-consumption-notify-peer-about-repositoryattribute-succession.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Notify peer about RepositoryAttribute succession">
     <meta itemprop="description" content="If you succeeded a RepositoryAttribute, whose previous version you shared with a peer, you can decide to inform the peer about the succession.If you do so, the peer will receive a Notification via Message, which handles the succession of their peer shared IdentityAttribute.Also, the associated own shared IdentityAttribute at your side will be succeeded, i.e. a new version of the LocalAttribute will be created and the predecessor will be updated to link to this successor in its succeededBy property.Note that it is possible to notify a peer about the succession of an IdentityAttribute you already shared with them, even if you didn&#8217;t inform them about every previous version.In this case the succeeds field of the newly created LocalAttribute will link to the latest shared version.Moreover, it is also possible to notify a peer about the succession of an IdentityAttribute, if this in turn is already succeeded again, in case you didn&#8217;t notify the peer about a newer version, yet.Parameters  attributeId of the succeeded RepositoryAttribute  The Address of the peerOn Success  The response returns a predecessor and a successor LocalAttribute, as well as the notificationId of the Notification sent to the peer.  The predecessor is an updated version of the own shared IdentityAttribute that was shared with the peer most recently. It has the succeededBy field set to the successor&#8217;s id.  The successor is a new own shared IdentityAttribute version with the content of the succeeded RepositoryAttribute. Its succeeds property links to the predecessor.On Failure  The response cannot be created, if the peer is unknown.  The response cannot be created, if the attributeId belongs to a RelationshipAttribute.  The response cannot be created, if the attributeId belongs to an IdentityAttribute with a shareInfo.  The response cannot be created, if you already notified the peer about the succession of the Attribute.  The response cannot be created, if you haven&#8217;t shared a version of the Attribute with the peer before. To initially share an IdentityAttribute, use the ShareIdentityAttribute use-case.  The response cannot be created, if the parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -490,7 +490,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-attributelisteners.html b/use-case-consumption-query-attributelisteners.html
index 3cdc53ca5..52bc4df03 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -484,7 +484,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-attributes.html b/use-case-consumption-query-attributes.html
index ae953db10..b746c7c76 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -514,7 +514,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-incoming-requests.html b/use-case-consumption-query-incoming-requests.html
index 6219e0416..109da2f46 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 source of 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -517,7 +517,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-query-outgoing-requests.html b/use-case-consumption-query-outgoing-requests.html
index 5c5393b46..0850b0275 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 source of 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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -516,7 +516,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-reject-incoming-request.html b/use-case-consumption-reject-incoming-request.html
index 8cbb9901a..4145ff85a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -518,7 +518,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-share-a-repositoryattribute.html b/use-case-consumption-share-a-repositoryattribute.html
index ea04d8f62..7883807bb 100644
--- a/use-case-consumption-share-a-repositoryattribute.html
+++ b/use-case-consumption-share-a-repositoryattribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Share a RepositoryAttribute">
     <meta itemprop="description" content="If you wish to share one of your private IdentityAttributes, called RepositoryAttributes, with a peer, this use-case allows you to do so.Internally, a Request with a ShareAttributeRequestItem will be created and will be sent via Message to the peer.Assuming your peer accepts the Request, at their side a peer shared IdentityAttribute will be created.The corresponding Response informs you about their acceptance and creates a LocalAttribute with a copy of the RepositoryAttribute&#8217;s content you shared.This own shared IdentityAttribute copy, however, in addition has a defined shareInfo property.It stores information about the peer you shared the attribute with, the id of the original RepositoryAttribute in the field sourceAttribute, and a reference to the Request used to share the Attribute.Note that the own shared IdentityAttribute at your side and the peer shared IdentityAttribute at your peer&#8217;s side are identical, except for the value in the shareInfo.peer field: on your side it will have the peer&#8217;s Address and on the peer&#8217;s side it will have your Address.Please note further, that this use case is meant to be used to share a version of a RepositoryAttribute for the first time.If you have already shared another version of a succeeded Attribute with the peer and you want to let them know about the changes to its value, use the NotifyPeerAboutIdentityAttributeSuccession use-case.Parameters  The attributeId of your RepositoryAttribute  The address of the peer  Optionally requestMetadata as described in the data model, except for the id and items, which are handled automaticallyOn Success  The LocalRequest is returned, that is associated with the Request which was sent to the peer.On Failure  The Request cannot be created, if the peer is unknown.  The Request cannot be created, if the attributeId belongs to a RelationshipAttribute.  The Request cannot be created, if the attributeId belongs to an IdentityAttribute with a shareInfo.  The Request cannot be created, if the Attribute has already been shared with the peer.  The Request cannot be created, if another version of the Attribute regarding succession has already been shared with the peer.  The Request cannot be created, if the parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -493,7 +493,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-succeed-a-relationshipattribute-and-notify-peer.html b/use-case-consumption-succeed-a-relationshipattribute-and-notify-peer.html
index b0530d05b..78860a517 100644
--- a/use-case-consumption-succeed-a-relationshipattribute-and-notify-peer.html
+++ b/use-case-consumption-succeed-a-relationshipattribute-and-notify-peer.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Succeed a RelationshipAttribute and notify peer">
     <meta itemprop="description" content="This use-case allows the owner to update a RelationshipAttribute, while automatically handling the coherent versioning at both your and your peer&#8217;s side.Succeeding an own RelationshipAttribute, a new LocalAttribute with the updated content will be created at your side.In its succeeds property it links to the predecessing version, which in turn is also updated and links to the newly created version in its succeededBy property.Thus, a doubly linked list is established, ensuring every version to have not more that one predecessor or successor.Once the succession at your side is completed, a Notification is sent automatically to your peer.It triggers the succession of their peer shared RelationshipAttribute in the same manner as described above, such that both your succession chains match.Parameters  predecessorId: the id of the LocalAttribute with the RelationshipAttribute content you want to succeed  The updated successorContent limited to the value, validFrom and validTo properties of a RelationshipAttribute that may be changed by a successionOn Success  The response returns a predecessor and a successor LocalAttribute, as well as the notificationId of the Notification sent to the peer.  The predecessor is an updated version of the own shared RelationshipAttribute, having the succeededBy field set to the successor&#8217;s id.  The successor is a new own shared RelationshipAttribute version with the specified successorContent. Its succeeds property links to the predecessor.On Failure  The response cannot be created, if the predecessorId doesn&#8217;t belong to a valid own LocalAttribute with RelationshipAttribute content.  The response cannot be created, if the LocalAttribute belonging to the predecessorId already has a successor.  The response cannot be created, if the parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -487,7 +487,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-consumption-succeed-a-repositoryattribute.html b/use-case-consumption-succeed-a-repositoryattribute.html
index 06ae351b2..8f71db361 100644
--- a/use-case-consumption-succeed-a-repositoryattribute.html
+++ b/use-case-consumption-succeed-a-repositoryattribute.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Succeed a RepositoryAttribute">
     <meta itemprop="description" content="If the value of a RepositoryAttribute changes, this can be replicated in enmeshed with this use-case.It allows you to update the content and keeps a coherent history of all versions by establishing a doubly linked list, using the LocalAttribute&#8217;s parameters succeeds and succeededBy.Hence, every LocalAttribute may have exactly one predecessor and one successor.In case you shared the preceeding version of the RepositoryAttribute, the corresponding own shared IdentityAttribute copy will only be succeeded, if you decide to notify the peer of the respective shared IdentityAttribute about the succession.Parameters  predecessorId: the id of the RepositoryAttribute you want to succeed  The successorContent according to the parameters of an IdentityAttribute as described in the data model, except for the owner, which is automatically set to your AddressOn Success  The response returns a predecessor and a successor LocalAttribute.  The predecessor is an updated version of the RepositoryAttribute belonging to predecessorId, having the succeededBy field set to the successor&#8217;s id.  The successor is a new RepositoryAttribute with the updated successorContent. Its succeeds property links to the predecessor.On Failure  The response cannot be created, if the predecessorId belongs to a RelationshipAttribute.  The response cannot be created, if the predecessorId belongs to an IdentityAttribute with a shareInfo.  The response cannot be created, if the LocalAttribute already has a successor.  The response cannot be created, if the successorContent contains invalid changes, e.g. of the value type.  The response cannot be created, if the parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -491,7 +491,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-delete_-rest-endpoint.html b/use-case-device-delete_-rest-endpoint.html
index 31336650f..124ab58d6 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -467,7 +467,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 f14cfa96c..238efb056 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -483,7 +483,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-profile.html b/use-case-device-get-profile.html
index 0724b36d4..44c74d46e 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -483,7 +483,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-profiles.html b/use-case-device-get-profiles.html
index 02610c609..eb97e8a9e 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -477,7 +477,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get-support-information.html b/use-case-device-get-support-information.html
index ba964c9c6..33f4d3321 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 44e8e0dce..f71c26efe 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 96362fa63..3800354e9 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -489,7 +489,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 e8b6eaf4d..e032fd327 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -489,7 +489,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-get_-rest-endpoint.html b/use-case-device-get_-rest-endpoint.html
index d8d0ffe64..a7e4cd9e9 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -467,7 +467,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-post_-rest-endpoint.html b/use-case-device-post_-rest-endpoint.html
index 2c1fa5f01..234b2692f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-put_-rest-endpoint.html b/use-case-device-put_-rest-endpoint.html
index d482d6b01..1ac3ba1d3 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-device-rename-profile.html b/use-case-device-rename-profile.html
index fccda63bc..8b69bd444 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -486,7 +486,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-cancel_-action.html b/use-case-human-cancel_-action.html
index 3c05d6fba..4a157131a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -468,7 +468,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-device_-external-usecase.html b/use-case-human-device_-external-usecase.html
index 062428846..25e614bcf 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -474,7 +474,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 9aa95f50c..9da56913f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -468,7 +468,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 84cf2ea04..e16de0c23 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-negative_-action.html b/use-case-human-negative_-action.html
index e53e4cf1d..3524dc0ac 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -468,7 +468,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-human-positive_-action.html b/use-case-human-positive_-action.html
index 397355f3d..2856e9e06 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -468,7 +468,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 58e61ba5b..d3f7c86fe 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -467,7 +467,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 7d29ab4a3..5daf70afd 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -466,7 +466,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-accept-relationshipchange.html b/use-case-transport-accept-relationshipchange.html
index 0eb6f1853..988ba2ac6 100644
--- a/use-case-transport-accept-relationshipchange.html
+++ b/use-case-transport-accept-relationshipchange.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Accept RelationshipChange">
     <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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -512,7 +512,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-own-relationshiptemplate.html b/use-case-transport-create-own-relationshiptemplate.html
index 8aac30143..54950c70b 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -514,7 +514,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-create-own-token.html b/use-case-transport-create-own-token.html
index fd58eaaa0..609cf08a1 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -513,7 +513,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 188192371..c3826f9a4 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 ad07c0095..ed7e2db34 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -515,7 +515,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 7c4cd9c9d..2d900d06f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -513,7 +513,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 805728a01..321cc8afb 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-download-file.html b/use-case-transport-download-file.html
index b9089d5fd..2c2b28d53 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -512,7 +512,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 0087c18d7..f3219dca4 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -512,7 +512,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 4ba93ff0e..64af7c002 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -465,7 +465,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 40a735140..9f3eb63ce 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 3d0f110a0..1134123f6 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -484,7 +484,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 515f6f17f..38e5b5410 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -486,7 +486,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-device.html b/use-case-transport-get-device.html
index 701f32a57..a6405eab3 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -484,7 +484,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 b7dc321a8..0588e883c 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -469,7 +469,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 69fbcc9c2..1fef409a5 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 d05568518..138ec2d6f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -511,7 +511,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-own-file.html b/use-case-transport-get-own-file.html
index 0d247dc4f..6884220bc 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 58637d0bc..4b1ac4d8a 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 5cab5b26b..b213ce672 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-get-relationship-template.html b/use-case-transport-get-relationship-template.html
index 80b0172d2..ebf87481f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 bf65796ab..6f36e12af 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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 the Synchronize updates of Backbone use-case.On Success  Returns the metadata of the last sync run.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 ece0e8f21..154e40bd0 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 e5187a487..065e14aee 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -473,7 +473,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 ae43a62a6..ff3d0686d 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -530,7 +530,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 bfb8f1e94..c61db3b0e 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -526,7 +526,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-devices.html b/use-case-transport-query-devices.html
index db2723155..0b9dab1b4 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -472,7 +472,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-files.html b/use-case-transport-query-files.html
index c2370ba60..28fb2bb2f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -521,7 +521,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-messages.html b/use-case-transport-query-messages.html
index 9326665f6..5b40bfbd4 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -520,7 +520,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-relationship-templates.html b/use-case-transport-query-relationship-templates.html
index fefbdf75b..90879e559 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -517,7 +517,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-query-relationships.html b/use-case-transport-query-relationships.html
index dfd506f94..ff31ece16 100644
--- a/use-case-transport-query-relationships.html
+++ b/use-case-transport-query-relationships.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Query Relationships">
     <meta itemprop="description" content="This use-case queries Relationships of the Identity.Parameters  peer is the enmeshed Address of the peer.  status is the status of the Relationship.  template.id is the id of the RelationshipTemplate that was used to initiate the Relationship.On Success  Returns all Relationships that match the query.On Failure  The parameters are malformed.">
-    <meta itemprop="datePublished" content="2024-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 80cee2f83..709212831 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -486,7 +486,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-reject-relationshipchange.html b/use-case-transport-reject-relationshipchange.html
index 950ac4536..3106a78ec 100644
--- a/use-case-transport-reject-relationshipchange.html
+++ b/use-case-transport-reject-relationshipchange.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,7 @@ <h3>Integrate Enmeshed</h3>
   <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
     <meta itemprop="headline" content="Reject RelationshipChange">
     <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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -512,7 +512,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 3bb493bcb..acd08a28c 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -514,7 +514,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 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 d410f33a5..5217557de 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -502,7 +502,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-update-device.html b/use-case-transport-update-device.html
index c6784307c..93df3625f 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -486,7 +486,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use-case-transport-upload-own-file.html b/use-case-transport-upload-own-file.html
index 26ca489d9..9ce2f0e36 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-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+01:00">
 
 
 
@@ -352,7 +352,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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+01:00">
     
 
     <div class="page__inner-wrap">
@@ -519,7 +519,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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use.html b/use.html
index 90a85668b..f8fe9eeb6 100644
--- a/use.html
+++ b/use.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use/install-the-app.html b/use/install-the-app.html
index 1b421f382..a5f184c7f 100644
--- a/use/install-the-app.html
+++ b/use/install-the-app.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>
 
diff --git a/use/secure-device-setup.html b/use/secure-device-setup.html
index 473b8e574..0356097de 100644
--- a/use/secure-device-setup.html
+++ b/use/secure-device-setup.html
@@ -34,7 +34,7 @@
 
 
 
-  <meta property="article:published_time" content="2024-03-06T15:56:29+01:00">
+  <meta property="article:published_time" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">
+    <meta itemprop="datePublished" content="2024-03-08T16:25:32+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-03-06T15:56:29+01:00">March 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-03-08T16:25:32+01:00">March 8, 2024</time></p>
 
       </footer>