diff --git a/docu/Concepts/TechnicalRequirements/Federation.md b/docu/Concepts/TechnicalRequirements/Federation.md index 3cd1e1ea3..f86a94fb3 100644 --- a/docu/Concepts/TechnicalRequirements/Federation.md +++ b/docu/Concepts/TechnicalRequirements/Federation.md @@ -221,14 +221,50 @@ For the first federation release the DHT-node will be part of the apollo server, ### Stage2 - Authentication -The 2nd stage of federation is called authentication, because during the 1st stage the hyperswarm dht only ensures the knowledge that one node is the owner of its keypairs pubkey and private key. The exchanged data between two nodes during the *direct exchange* on the hyperswarm dht channel must be verified, means ensure if the proclaimed url and apiversion of a node is the correct address to reach the same node outside the hyperswarm infrastructure. +The 2nd stage of federation is called *authentication*, because during the 1st stage the *hyperswarm dht* only ensures the knowledge that one node is the owner of its keypairs *pubkKy* and *privateKey*. The exchanged data between two nodes during the *direct exchange* on the *hyperswarm dht channel* must be verified, means ensure if the proclaimed *url(s)* and *apiversion(s)* of a node is the correct address to reach the same node outside the hyperswarm infrastructure. + +As mentioned before the *DHT-node* invokes the *authentication* stage on *apollo server* *graphQL* with the previous stored data of the foreign node. + +#### Sequence - view of existing Community + +1. the authentication stage starts by reading for the *foreignNode* from the previous federation step all necessary data + 1. select with the *foreignNode.pubKey* from the tables *CommunityFederation* and *CommunityApiVersion* where *CommunityApiVersion.validFrom* <= NOW + 2. the resultSet will be a list of data with the following attributes + * foreignNode.pubKey + * foreignNode.url + * foreignNode.apiVersion +2. read the own keypair and uuid by `select uuid, privateKey, pubKey from CommunityFederation cf where cf.foreign = FALSE` +3. for each entry of the resultSet do + 1. encryptedURL = encrypting the foreignNode.url and foreignNode.apiVersion with the foreignNode.pubKey + 2. signedAndEncryptedURL = sign the result of the encryption with the own privateKey + 3. invoke the request `https:////(onetimecode, encryptedOwnUUID)` and + 6. wait for the response with the `encryptedForeignUUID` + 7. decrypt the `encrpytedForeignUUID` with the foreignNode.pubKey + 8. write the encrypted foreignNode.UUID in the database by updating the CommunityFederation table per `update CommunityFederation cf set values (cf.uuid = foreignNode.UUID, cf.pubKeyVerifiedAt = NOW) where cf.pubKey = foreignNode.pubkey` + +After all redirect requests are process, all relevant authentication data of the new community are well know here and stored in the database. + + +#### Sequence - view of new Community {Sequence - view of new Community} + +ongoing -As mentioned the DHT-node invokes the authentication stage on apollo server with the received data from *direct exchange*. -#### Sequence ### Stage3 - Autorized Business Communication +ongoing + + # Review von Ulf ## Communication concept diff --git a/docu/Concepts/TechnicalRequirements/graphics/FederationHyperSwarm.drawio b/docu/Concepts/TechnicalRequirements/graphics/FederationHyperSwarm.drawio index 6bfce4310..b5f120f52 100644 --- a/docu/Concepts/TechnicalRequirements/graphics/FederationHyperSwarm.drawio +++ b/docu/Concepts/TechnicalRequirements/graphics/FederationHyperSwarm.drawio @@ -1,6 +1,6 @@ - + @@ -140,9 +140,9 @@ - + - + @@ -158,7 +158,7 @@ - + @@ -246,7 +246,7 @@ - + @@ -300,7 +300,7 @@ - + diff --git a/docu/Concepts/TechnicalRequirements/image/FederationHyperSwarm.png b/docu/Concepts/TechnicalRequirements/image/FederationHyperSwarm.png index 13e1f3d72..526da1721 100644 Binary files a/docu/Concepts/TechnicalRequirements/image/FederationHyperSwarm.png and b/docu/Concepts/TechnicalRequirements/image/FederationHyperSwarm.png differ