69 lines
3.3 KiB
Markdown
69 lines
3.3 KiB
Markdown
# FIT-Connect inbound receipt and acknowledgement
|
|
|
|
This slice models the receiving system's safe boundary around a FIT-Connect
|
|
submission. It does not choose a journey, environment, destination, API
|
|
profile, or credential, and it does not call FIT-Connect.
|
|
|
|
FIT-Connect distinguishes its technical receipt confirmation from subsequent
|
|
business review. An `accept-submission` event confirms that the receiver could
|
|
download, decrypt, and validate the submission. It must carry the matching
|
|
authentication tags. Successful acknowledgement can transition and remove the
|
|
service-side submission, so GovOPlaN must durably hand all content to its owning
|
|
workflow first.
|
|
|
|
## Ingress receipt
|
|
|
|
The configured profile binds the exact destination, Submission API version,
|
|
metadata-schema version, profile revision, and references to connection,
|
|
decryption, and event-signing credentials. Credential values never enter the
|
|
contract.
|
|
|
|
The submission evidence records SHA-256 values and authentication tags for
|
|
metadata, business data, and at most 100 uniquely identified attachments. The
|
|
receipt binds these values to submission, transaction, public service, region,
|
|
destination, profile, and receive time. It starts with both `acknowledged` and
|
|
`business_accepted` set to false.
|
|
|
|
## Acknowledgement decision
|
|
|
|
An acceptance plan requires all of the following:
|
|
|
|
- every component was downloaded;
|
|
- decryption succeeded;
|
|
- metadata and business-data schemas validated;
|
|
- all authentication tags were verified;
|
|
- an owning service, form, or case workflow durably stored the exact handoff.
|
|
|
|
Failed local download or durability always produces `defer`, leaving recovery
|
|
possible. A `reject` plan additionally requires a complete download, explicit
|
|
technical rejection classification, and bounded problem codes. Problem details
|
|
are operator evidence and are not suitable as applicant-facing messages.
|
|
|
|
The internal event request and plan are canonical and digest-bound. The request
|
|
is not a protocol-conformant SET wire payload. Plans always have
|
|
`dispatch_allowed=False`: a later target adapter must translate the request,
|
|
create and sign the Security Event Token, send it, reconcile the event log after
|
|
unknown outcomes, and prove recovery against the selected FIT-Connect
|
|
environment.
|
|
|
|
## Datenschutz und Betrieb
|
|
|
|
Das Modul speichert derzeit weder Antragsdaten noch Anlagen, Eingangsbelege,
|
|
Pläne oder Schlüssel. Das fachlich verantwortliche Service-, Forms- oder
|
|
Cases-Modul übernimmt Daten und Aufbewahrung, bevor eine technische Bestätigung
|
|
zulässig wird. Eine technische Eingangsbestätigung ist keine fachliche Annahme
|
|
oder positive Entscheidung über den Antrag.
|
|
|
|
Für den Zieltest werden Verwaltungsleistung, Zustellpunkt, Umgebung,
|
|
API-/Metadatenschemaversion, Client und Schlüssel, Anlagengrenzen,
|
|
Fachschema, Rückkanal, Ereignisprotokoll sowie Verfahren für Zeitüberschreitung,
|
|
Doppelabruf und Wiederherstellung benötigt.
|
|
|
|
Official orientation:
|
|
|
|
- [Receiving overview](https://docs.fitko.de/fit-connect/docs/receiving/overview/)
|
|
- [Download a submission](https://docs.fitko.de/fit-connect/docs/receiving/download-submission/)
|
|
- [Verify a submission](https://docs.fitko.de/fit-connect/docs/receiving/verification/)
|
|
- [Technical receipt acknowledgement](https://docs.fitko.de/fit-connect/docs/receiving/process-and-acknowledge/)
|
|
- [FIT-Connect events](https://docs.fitko.de/fit-connect/docs/getting-started/event-log/events/)
|