Lieferung LP+AN+Submission-ID durch die beiden AS an die VST

Wie in I_VST definiert hat die VST innerhalb der TI eine HTTPS-Schnittstelle und damit auch ein TLS-Serverzertifikat aus der TI-PKI (Komponenten-PKI der TI). Im TLS-Serverzertifikat gibt es eine OID oid_epa_vst als Profession-OID.

Auf Anwendungsebene erfolgt dann ein VAU-Protokoll-Verbindungsaufbau bei dem die VST ein C.FD.AUT-Zertifikat (TI-PKI) besitzt mit professionOID gleich oid_epa_vst.

Das AS als VAU-Protokoll-Client authentisiert sind wie üblich über PKI-basierte VAU-Protokoll-Client-Authentisierung beim VAU-Protokoll Verbindungsbaufbau. Zitat aus I_VST: 

"Erst nachdem sich das ePA-AS authentisiert hat und die VST die Authentifizierung erfolgreich durchführen konnte, darf das VST fachliche Zugriffe erlauben (Submission entgegennehmen)."

Ein AS stellt eine Submission her -- erzeugt dabei zufällig eine Submission-ID (256-Bit-Wert). 

Innerhalb des VAU-Protokoll schickt das AS (= hier Client) in einem inneren Request per POST an /epa/submission/api/v1/submissions/<Submission-ID-Hex> die Übersetzungstabelle mit folgender Struktur (CBOR-kodiert):

Submission = [
    {"type": "as->vst",
     "created_at": Unix-Zeit,
     "submission_id": Submission-ID,
     "call_back_url": url_aktensystem},
     [LP1, AN1],
     [LP2, AN2], …
]

Submission-ID ist ein 32 Byte Binärwert. Die Auftragsnummern (ANy) sind jeweils 32 Byte Binärwerte. Die Lieferpseudonyme (LPx) (Erzeugungsvorschrift wird ist in I_VST definiert) sind jeweils 103 Byte lange Binärwerte.

Die call_back_url verwendet das FDZ dann folgend um die pseduoynmisierten Daten vom Aktensystem per GET (TLS+VAU-Protokoll+Client-Authentisierung-FDZ) zu beziehen.

Die call_back_url muss mit https://epa-as-<ePA-Anbieter-Zahl>.<Umgebung>.epa4all.de beginnen. ePA-Anbieter-Zahl kann aktuell genau nur 1 oder 2 sein. Die "Umgebung" hat in der PU den Wert "prod".

In der call_back_url ist die Submission-ID schon vorhanden.