diff --git a/docs/Detailinformationen/Encryption.md b/docs/Detailinformationen/Encryption.md index 894fce62a2e689f0dee05c8e11237137b3bcc929..bc78ab36479c10883c946d48762f8845d7d58f19 100644 --- a/docs/Detailinformationen/Encryption.md +++ b/docs/Detailinformationen/Encryption.md @@ -16,11 +16,9 @@ Im Folgenden werden Beschrieben: Im Kontext von Anträgen an Behörden werden häufig höchstsensible Daten übermittelt, die im Rahmen der [Vorgaben des BSI für eGovernment-Dienste](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03107/TR-03107-1.pdf?__blob=publicationFile&v=4) nur Ende-zu-Ende-Verschlüsselt übertragen werden dürfen. Bei fitconnect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist richtig implementierte Krypotgraphie ein fundamentaler Teil von fitconenct und kannn nicht ohne diese umgesetzt werden. -## Architektur -Jedes fitconenct-System verfügt über einen Endpunkt, an den Anträge gesendet werden (Fachverfahren/Subscriber-API) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …). - - - +### Architektur im fitconnect Kontext +Jedes fitconenct-System verfügt über einen Endpunkt, von dem Anträge empfangen werden (Fachverfahren/Subscriber-API) und einen oder mehreren Endpunkten, von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …). In diesem Abschnitt der Dokumentation werden einerseits Regeln und Standards definiert, denen Public-Keys (JSON Web Keys), die von Fachverfahren bereitgestellt werden, entsprechen müssen. Andrerseits wird erklärt, wie diese JSON Web Keys durch Clients verifiziert und danach zur Verschlüsselung der Inhaltsdaten eingesetzt werden sollten. +Dazu relevant: **TODO(@Lilith) auf die anderen Seiten verweisen die die Architektur erklären**