Jeder eingegangene Antrag verfügt über einen Eventlog, indem Statusänderungen am Antrag festgehalten werden. Das ist zu vergleichen mit einem Sendungsverfolgungssystem bei einem Paketdienst und dient einerseits dazu, die Nutzer*innen über den Status ihres Antrags zu informieren und andrerseits stellte ist es eine signierte Nachweiskette, die beweisen kann, das ein Antrag übermittelt und bei der Fachanwendung eingegangen ist.
Der Eventlog basiert auf dem Prinzip der Security Event Tokens [RFC 8417](https://tools.ietf.org/html/rfc8417). Einträge können einerseits durch de Übermittlungsdienst und andrerseits die Fachanwendung hinzugefügt werden.
## Format eines Events
Alle Eventeinträge müssen nach dem in "[Anforderungen an das kryptografische Material](Encryption_Key_Requirements.md)" für Security Event Tokens (SET) festgelegten Vorgaben signiert werden. Außerdem müssen alle Einträge über folgende Felder verfügen:
| iss | Identifizierungsmerkmal des Token Issuers | Dient dazu, um herauszufinden, wer den Token ausgestellt hat. Ist entweder client id der Fachanwendung oder "fitconnect" für den Übermittlungsdienst |
| iat | Timestamp | Zeitpunkt der Ausstellug des SETs |
| sub | UUID des Antrags | Dient dazu um die |
| events | Dict der Events in diesem Event-Token | Key Value mapping von schema zu Inhaltsdaten des eigentlichen Tokens. Liste der erlaubten Schemas findet sich hier. (**TODO**) |
Zur Übermittlug der Tokens wird das in [RFC 7515, Abschnitt 7.1](https://tools.ietf.org/html/rfc7515#section-7.1) beschriebene Verfahren "JWS Compact Serialization" verwendet, welches auch die Signatur des Tokens beinhaltet. (Siehe auch "[Anforderungen an das kryptografische Material](Encryption_Key_Requirements.md)" )
## Darstellen des Eventlogs
Wenn ein Onlinedienst den Eventlog darstellen möchte, muss dieser sicherstellen, das die im Eventlog enthaltenen Einträge über eine valide Signatur verfügen und falls sich Einträge mit einer invaliden Signatur im Eventlog befinden, muss das für den User erkennbar sein.
