diff --git a/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md b/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md
index 457d040b1..cff97ddba 100644
--- a/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md
+++ b/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md
@@ -286,7 +286,7 @@ Der Prozess *Neue Community erstellen* wird entweder automatisiert beim erstmali
Der oben grafisch dargestellte Ablauf wird in drei grobe Teile untergliedert:
-1. den eigentlichen Community-Prozess "*neue Community erstellen*" (links in grün gehalten), in dem die Community spezifischen Attribute erfasst, geladen und/oder angelegt werden. Dazu gehören neben dem Erfassen der Community eigenen Attributen, das Laden von vordefinierten Standard-Daten wie die Tätigkeitsliste, Berechtigungen, etc. und optional als eigenständiger Prozess die Erfassung bzw das Anlegen von neuen Community-Mitgliedern.
+1. )den eigentlichen Community-Prozess "*neue Community erstellen*" (links in grün gehalten), in dem die Community spezifischen Attribute erfasst, geladen und/oder angelegt werden. Dazu gehören neben dem Erfassen der Community eigenen Attributen, das Laden von vordefinierten Standard-Daten wie die Tätigkeitsliste, Berechtigungen, etc. und optional als eigenständiger Prozess die Erfassung bzw das Anlegen von neuen Community-Mitgliedern.
2. das Starten der "*Federation*" als Hintergrundprozess, um die neu erstellte Community im Gradido-Community-Verbund bekannt zu machen. Dietechnischen Details der *Federation* werden im Dokument [Federation](../TechnicalRequirements/Federation.md " ") beschrieben. Dabei wird
* als erstes geprüft, ob in der eigenen Community die notwendigen Attribute wie Community-Key, URL und ggf. weitere korrekt initialisiert und gespeichert sind. Falls nicht wird der Hintergrundprozess mit einem Fehler abgebrochen
* dann werden die Attribute Community-Key und URL in eine *newCommunity*-Message gepackt und asynchron an den Public-Channel der Community-Federation des Gradido-Community-Verbundes gesendet
@@ -297,7 +297,12 @@ Der oben grafisch dargestellte Ablauf wird in drei grobe Teile untergliedert:
* *newCommunity*-Messages werden von neu erstellten Communities im Rahmen derer Federation in den Public-Channel gesendet. Diese Messages sollten möglichst zeitnah von möglichst vielen schon existierenden Communities beantwortet werden. Dazu wird zuerst in der Community-Datenbank nach Einträgen gesucht, die den gleichen Community-Key aber eine unterschiedliche URL als zu den empfangenen Daten haben:
* Sollte es einen solchen Eintrag geben, dann wird eine *replyNewCommunity*-Message erzeugt mit *MessageState = requestNewKey* und ohne weitere Daten in den Public-Channel zurückgesendet. Danach wird wieder in den "Lausch-Modus" am Public-Channel gewechselt.
* Sollte es keine solche Einträge geben, dann werden die eigenen Daten *Community-Ke*y und *URL* in eine *replyNewCommunity*-Message gepackt, der *MessageState = OK* gesetzt und direkt in den Public-Channel zurückgesendet. Danach wird wieder in den "Lausch-Modus" am Public-Channel gewechselt.
-3. und die *"Community-Communication"* als Hintergrundprozess. Dieser liest zuerst die eigenen Community-Daten und geht dann per Direkt-Verbindung über die URL mit der neuen Community in Dialog, um sich zuerst gegenseitig zu authentifizieren und um dann die Community spezifischen Daten untereinander auszutauschen. Der fachlich logische Ablauf dieser Kommunikation soll wie folgt dagestellt ablaufen: Die genaue Beschreibung der dazu verwendeten APIs beider Communities erfolgt in der technischen Konzeption [CommunityCommunication](../TechnicalRequirements/CommunityCommunication.md).
+3. und die *"Community-Communication"* als Hintergrundprozess. Dieser liest zuerst die eigenen Community-Daten und geht dann per Direkt-Verbindung über die URL mit der neuen Community in Dialog, um sich zuerst gegenseitig zu authentifizieren und um dann die Community spezifischen Daten untereinander auszutauschen. Der logische Ablauf dieser Kommunikation soll wie folgt dargestellt ablaufen:
+
+
+
+
+Die genaue Beschreibung der dazu verwendeten APIs beider Communities erfolgt in der technischen Konzeption [CommunityCommunication](../TechnicalRequirements/CommunityCommunication.md).
#### Ende Status
diff --git a/docu/Concepts/BusinessRequirements/graphics/AuthenticateCommunityCommunication.drawio b/docu/Concepts/BusinessRequirements/graphics/AuthenticateCommunityCommunication.drawio
new file mode 100644
index 000000000..7fdb4cbc3
--- /dev/null
+++ b/docu/Concepts/BusinessRequirements/graphics/AuthenticateCommunityCommunication.drawio
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docu/Concepts/BusinessRequirements/graphics/CommunityCommunication.drawio b/docu/Concepts/BusinessRequirements/graphics/CommunityCommunication.drawio
deleted file mode 100644
index ef380c415..000000000
--- a/docu/Concepts/BusinessRequirements/graphics/CommunityCommunication.drawio
+++ /dev/null
@@ -1,198 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docu/Concepts/BusinessRequirements/image/Ablauf_Neue_Community_erstellen.png b/docu/Concepts/BusinessRequirements/image/Ablauf_Neue_Community_erstellen.png
index ed9c40024..95aae4d5d 100644
Binary files a/docu/Concepts/BusinessRequirements/image/Ablauf_Neue_Community_erstellen.png and b/docu/Concepts/BusinessRequirements/image/Ablauf_Neue_Community_erstellen.png differ
diff --git a/docu/Concepts/BusinessRequirements/image/AuthenticateCommunityCommunication.png b/docu/Concepts/BusinessRequirements/image/AuthenticateCommunityCommunication.png
new file mode 100644
index 000000000..2ce7e9266
Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/AuthenticateCommunityCommunication.png differ
diff --git a/docu/Concepts/TechnicalRequirements/CommunityCommunication.md b/docu/Concepts/TechnicalRequirements/CommunityCommunication.md
index ba8937730..c3092dcd2 100644
--- a/docu/Concepts/TechnicalRequirements/CommunityCommunication.md
+++ b/docu/Concepts/TechnicalRequirements/CommunityCommunication.md
@@ -2,7 +2,7 @@
This document contains the detailed descriptions of the public API of a community.
-## Authentication and Autorization
+## Authentication/Autorization of new Community
Each public API of a community has to be authenticated and autorized before.
@@ -12,34 +12,75 @@ This could be done by following the *OpenID Connect* protocoll. To fullfil these
Following the link [OpenID Connect](https://www.npmjs.com/package/openid-client) there can be found a server-side OpenID relying party implementation for node.js runtime.
-The authentication of communities base on the community-attributes *key* and *URL*, which where exchanged during the *federation process* before. In concequence a community that hasn't execute his federation well will be unknown for other communities and can't be authenticated and autorized for further API calls.
+The authentication of communities base on the community-attributes *key* and *URL*, which where exchanged during the *federation process* before. In concequence a community that hasn't execute his federation well will be unknown for other communities and can't be authenticated and autorized for further cross community API calls.
### Variant B:
-A similar solution of authentication to variant A but without autorization can be done by using private and public key encryption. The *community creation* process will create a private and public key and store them internally. As the third step of the federation the *community communication* background process of the new community will be startet and a sequence of service invocations will exchange the necessary security data:
+A similar solution of authentication to variant A but **without autorization** can be done by using private and public key encryption. The *community creation* process will create a private and public key and store them internally. As the third step of the federation the *community communication* background process of the new *community-A* will be startet and a sequence of service invocations will exchange the necessary security data:
-1. the service *authenticateCommunity* sends the own community key as input data, which will be checked against the internally stored list of communities and their keys.
-2. If the given key is found a one-time code is passed back to a predefined Redirect URI of the invoker community.
-3. The next invocation of the new community sends the one-time code, the encrypted community-key of the receiver community, the own public key to
+1. the new *community-A* encrypt the community key of the existing *community-B* with its own privat key. Then it invokes the service *authenticateCommunity* at *community-B* by sending the own community key, the encrypted community key of *community-B* and a redirect URI back to *community-A* as input data. The *community-B* will search the given community key of *community-A* in the internally stored list of communities, which are a result of the previous *federation process* collected over a different medium.
+2. If in *community-B* the given community key of *community-A* is found, a generated one-time code is kept together with the given encrypted community key, till an invocation of the service verifyOneTimeCode with this one-time-code. The one-time-code is passed back to the given Redirect URI of the *community-A*.
+3. *Community-A* will send with the next invocation to *community-B* the received one-time code and the own public key by requesting the service *verifyOneTimeCode* at *community-B*.
+4. *Community-B* will verify the given one-time-code and if valid, decrypt the previous received and encrypted community key from step 1 of the invocation-chain by using the given public key from *community-A*. If the decrypted community-key is equals the own community key, the public key of *community-A* is stored in the entry of *community-A* of the internal community list. As response of the *verifyOneTimeCode* the *community-B* will send back his own public key to *community-A*.
+5. *Community-A* will store the received public key of *community-B* in the corresponding entry of the internal community-list.
-The first invocation of a cross community communication must be the service "Authenticate Community". This service will exchange the necesarry data to ensure a sufficient security level for the community communication.
+The result of this invocation chain is the public key exchange of the involved communities, which is the foundation to authenticate a future cross community communication.
+
+To reach in Variant B nearly the same security level as in Variant A each community has to integrate several components to process this invocation chain like Variant A does.
### Variant C:
-like Variant B but without one-time code and direct response of public key of community B
+The third Variant exchange the all necessary data directly without the step in between returning a one-time code per redirection URI:
+1. the new *community-A* encrypt the community key of the existing *community-B* with its own privat key. Then it invokes the service *authenticateCommunity* at *community-B* by sending the own community key, the encrypted community key of *community-B* and its own public key as input data. The *community-B* will search the given community key of *community-A* in the internally stored list of communities, which are a result of the previous *federation process* collected over a different medium.
+2. If in *community-B* the given community key of *community-A* is found and if the decryption of the given encrypted community key with the given public key is equals the own community key, the public key of *community-A* is stored in the entry of *community-A* of the internal community list. As response of the *authenticateCommunity* the *community-B* will send back his own public key to *community-A*.
+3. *Community-A* will store the received public key of *community-B* in the corresponding entry of the internal community-list.
+
+Variant C is quite similar to Variant B, but to exchange all security relevant data in a single request-response-roundtrip bears more security risks.
## Service: "Authenticate Community"
-This service must be invoked at first before further cross community communication can be done.
+This service must be invoked at first to exchange the security relevant data before further cross community communication can be done.
The third step of the *federation process* starts the background process for community communication. As result of the previous federation steps the new community has received from at least one existing community the URL and the community key.
-To prepare the input-data for the invocation the own community key and the community key of the
+After receiving the input data the service answers directly with an empty response. Then it searches for the attribute "community-key-A" in the internal community list the entry of *community-A*. If the entry of *community-A* could be found with this key, a new one-time-code is generated and stored together with the attribute "community-key-B" till the invocation of service "verifyOneTimeCode". With the given redirection URI a callback at *community-A* is invoked by sending the generated One-Time-Code back to *community-A*.
### Route:
+POST https:///authenticateCommunity
+
+### Input-Data:
+
+```
+{
+ "community-key-A" : "the community-key of the new community-A"
+ "community-key-B" : "the community-key of the existing community-B, which was replied during the federation, encrypted by the own private key"
+}
+```
+
+### Output-Data:
+
+* none
+* redirection URI: "one-time-code" : "one-time usable code as input for the service verifyOneTimeCode"
+
+### Exceptions:
+
+
+
+## Service: "Verify OneTimeCode"
+
+This service must be invoked at first to exchange the security relevant data before further cross community communication can be done.
+
+The third step of the *federation process* starts the background process for community communication. As result of the previous federation steps the new community has received from at least one existing community the URL and the community key.
+
+To prepare the input-data for the invocation the own community key and the community key of the new community
+
+### Route:
+
+POST https:///verifyOneTimeCode
+
### Input-Data:
```
@@ -55,6 +96,27 @@ To prepare the input-data for the invocation the own community key and the commu
### Exceptions:
+
+## Service: "open Communication"
+
+
+### Route:
+
+POST https:///openCommunication
+
+### Input-Data:
+
+```
+{
+
+}
+```
+
+### Output-Data:
+
+### Exceptions:
+
+
## Service: "Familiarize communities"
This request is used to exchange data between an existing and a new community. It will be invoked by the existing community, which received a valid *newCommunity*-Message from a new community during the federation process.