[EPIC]: MVP Javascript-SDK

Warum?

Ziel des MVP ist es, mit minimalem Aufwand eine erste veröffentlichungsfähige Version des SDKs zu entwickeln.

Out-of-Scope: Erstellung des Grundgerüst für Methodensignaturen -> #415 (closed)

Relevante Links und Bemerkungen

• SDK-Konzept im Wiki
• inoffizielles Python-SDK
• Demo zur Verschlüsselung von JSON und Dateien im Browser: [https://github.com/codedust/simplejose\] (basiert auf [https://github.com/panva/jose\])
• Vergleich zwischen [https://github.com/square/js-jose\] und [https://github.com/panva/jose\]: [https://github.com/codedust/jwe-file-encryption-demo\]
  • tl;dr: square/js-jose hat Schwierigkeiten mit dem Verschlüsseln von Binärdaten und ist langsamer
• Im MVP des JavaScript-SDK ist keine Unterstützung beim Aufruf der Submission API enthalten.
• Das MVP des JavaScript-SDK hat Onlinedienste (Sender) als primäre Zielgruppe und ist noch nicht für die Nutzung im Subscriber geeignet -> Follow-Up-Issue

Akzeptanzkriterien

Aus #415 (closed)

1. Die Codebasis ist in Typescript geschieben.
2. Im GitLab findet sich unter https://git.fitko.de/fit-connect/sdk-javascript ein Grundgerüst des SDKs mit Methodensignaturen.
3. Jede Methode ist ausführlich mittels Methodenkommentaren dokumentiert.
4. Alle Methoden werfen eine NotImplementedException (o.ä.) - genau das wurde in dem Issue implementiert.
5. Die folgenden Funktionalitäten sind abgebildet (nicht jede Funktionalität muss zwangsläufig über eine eigene Methode abgebildet werden, ggf. reicht auch ein // TODO: implement xyz):
   • Sender: Verschlüsselung von Fachdaten (JSON, XML) mittels JWE
   • Sender: Verschlüsselung von Anhängen (Binärdaten) mittels JWE
   • Sender: Korrekte Erzeugung eines Metadatensatzes inkl. Hashwerte
   • Sender + Subscriber: SET Parsen inkl. Signaturprüfung
     • erfolgt im Backend und wird im Frontend angezeigt
     • Im Frontend würden wir auf die CORS Problematki stoßen (siehe unten)
   • Logging
     • PO Review: ist für die Entwickler der Onlinedienste soweit vorbereitet
     • Doku: Fehlermeldung des JS-SDKs sollten angemessen dem User angezeigt werden

ursprüngliche Kriterien

1. Die auf Basis des SDK-Grundgerüst vorgegebenen Funktionalitäten sind vollständig implementiert.
2. Alle Vorgaben aus den Vorgaben für kryptographische Verfahren werden eingehalten.
   • PO Review: Prüfungen erfolgen im Backend im .NET oder JAVA SDK
   • PO Review: technisch ggf. möglich es im Frontend zu machen (jedoch problematisch auf Grund benötigter CORS Aufrufe (Im Browser könnte der User die Validierung umgehen)
   • PO Review: falls .NET oder JAVA nicht genutzt wird, soll im Doku vorgeschrieben werden die Prüfung (am besten mit unserem JWK Validator) zu machen
3. Schlankes Backend implementieren und deployen auf einer temporären DEV-Umgebung (mit Team Infrastruktur)
   1. Musteronlinedienst kann das bereits mit 0.1.0
   2. Nachtest notwendig, sobald die 1.0.0 veröffentlich ist
4. Testautomatisierung mit SSP Team - ?Cypress?
   1. Die Implementierung ist in gängigen Browsern (tbd) lauffähig.
      • PO Review: da dies bis auf den Bürger durchschlagen kann, sollten wir bis zur Abdeckung höchstens als RC publishen
   2. Für die implementierten Funktionalitäten des SDK liegen Unit Tests vor.
   3. Die Funktionalität des SDK wurde durch einen E2E-Test überprüft.
   4. mindestens monatliche Tests (nicht nur neue Versionen von uns, sondern auch von Browsern)
5. 1. [ ] Die Codebeispiele in der Dokumentation nutzen des SDK -> neues Issue

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

• Lesen der Wiki-Seite, Klärung von offenen Fragen
• Zusammentragen, was es aktuell für diese Programmiersprache schon an Code gibt (Tests, Tools, Beispiele, etc.)
• ...
• ...
• Definition of Done wurde geprüft