Skip to content

Java-SDK: Einreichung überprüfen (automatischer Upload eines Reject-Events)

Warum?

Die in der Dokumentation beschriebenen Prüfungen beim Empfang von Anträgen sollen durch das SDK abgebildet werden, um Entwickler:innen bei der Implementierung von Subscribern Arbeit zu ersparen und häufige Fehlerfälle auszuschließen.

Relevante Links und Bemerkungen

Akzeptanzkriterien

  1. Die in der Dokumentation beschriebenen Prüfungen wurden vom Assignee dieses Issue für sinnvoll befunden. Falls nicht -> Info an PO
  2. Die Folgenden Prüfungen in der Kategorie "Überprüfung des Event-Logs" werden durchgeführt:
    1. Struktur- und Signaturprüfung der Security-Event-Tokens
    2. Genau ein Submit-Event
    3. Authentication-Tags im Submit-Event -> 4.1
    4. Liste der Anlagen abgleichen -> 5.2
  3. Die Folgenden Prüfungen in der Kategorie "Überprüfung des Metadatensatzes" werden durchgeführt:
    1. Authentication-Tag prüfen
    2. Entschlüsselung
      • In der Doku heißt es: "Sofern ein falscher oder veralteter Schlüssel verwendet wurde, der Metadatensatz aber dennoch entschlüsselt werden konnte, sollte Verarbeitung fortgesetzt werden, aber eine entsprechende Meldung erfolgen." Wie ist für sendende Systeme erkennbar, dass eine Entschlüsselung erfolgreich/nicht erfolgreich war.
      • Falsche Schlüssel sollten nie akzeptiert werden.
      • "Veraltete Schlüssel" muss definiert werden: Nur im Rahmen eines Key Rollover übergangsweise erlaubt.
      • Vorschlag: Diesen Satz aus der Dokumentation streichen und o.g. Hinweise ergäzen.
      • Entscheidung: Da das aktuelle SDK nur einen privaten Schlüssel unterstützt, wird bei Verwendung eines alten/falschen Schlüssels immer ein reject-submission-Event erstellt. Key-Rollover wird behandelt in neuem Issue #753
    3. Syntax-Validierung
    4. Schema-Referenz (Reject bei 2.x.y-Schemaversion)
    5. Metadatenschema
    6. Schema-Prüfung
    7. Sicherstellen der Integrität einer Submission -> 4.3 und 5.4
    8. Verwaltungsleistung abgleichen (I) -> fällt weg mit #866 (closed)
    9. Verwaltungsleistung abgleichen (II)
    10. Fachdatensatz
    11. Fachdatenschema
    12. Liste der Anlagen abgleichen
    13. Rückkanal
  4. Die Folgenden Prüfungen in der Kategorie "Überprüfung des Fachdatensatzes" werden durchgeführt:
    1. Authentication-Tag prüfen
    2. Entschlüsselung
    3. Hash-Prüfung
    4. Syntax-Validierung
    5. Schema-Prüfung -> #928 (closed)
  5. Die Folgenden Prüfungen in der Kategorie "Überprüfung der Anlagen" werden durchgeführt:
    1. Anlage laden
    2. Authentication-Tag prüfen
    3. Entschlüsselung
    4. Hash-Prüfung
    5. Inhaltliche Prüfung
  6. Die Folgenden Prüfungen in der Kategorie "Weitere Fehler" werden durchgeführt:
    1. Technischer Fehler
  7. Bei auftretenden Fehlern werden gemäß der Dokumentation Events im Event-Log hinterlegt (automatischer Upload).
  8. Bei auftretenden Fehlern wird durch die Methode RequestSubmission() eine Exception geworfen.
  9. Die Inhalte der Attribute title und details werden auf englisch verfasst.
  10. NEU: AuthenticationTags im SET gegen AutenticationTags der JWE-Objekten (Metadaten, Fachdaten, Anlagen) prüfen bereits in den Akzeptanzkriterien oben enthalten

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

Edited by Marco Holz