[Feature] Add FIT-Connect connector #1

Open
opened 2026-07-10 22:08:16 +02:00 by zemion · 3 comments
Owner

Moved from add-ideas/govoplan-core#126.

Reason: FIT-Connect work belongs to the FIT-Connect module.

Original issue body:

Imported from a backlog-like text file.

  • Source: /mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/split-concept-action-plan.md
  • Line: 331
  • Source kind: product
  • Section: GovOPlaN Split Concept and Action Plan > Product Roadmap > Milestone C: Public-Sector Integration Platform

Imported item:

Add FIT-Connect connector.
Moved from add-ideas/govoplan-core#126. Reason: FIT-Connect work belongs to the FIT-Connect module. Original issue body: <!-- codex-generic-backlog-fingerprint:200819e404cc1dd70764478a --> Imported from a backlog-like text file. - Source: `/mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/split-concept-action-plan.md` - Line: `331` - Source kind: `product` - Section: `GovOPlaN Split Concept and Action Plan > Product Roadmap > Milestone C: Public-Sector Integration Platform` Imported item: ```text Add FIT-Connect connector. ```
Author
Owner

The connector boundary can be provider-neutral, but an end-to-end FIT-Connect profile needs a selected environment and journey.

Decisions required:

  • first submission/service journey and API/profile version;
  • inbound, outbound, or bidirectional scope (recommend inbound receipt plus acknowledgement evidence first);
  • responsibility for attachment malware checks, form/message validation, duplicate detection, status receipts, retention, and retry/outcome-unknown handling;
  • tenant credential hierarchy and certificate-rotation policy.

Manual inputs required:

  • sandbox base URLs, client/certificate material, service identifiers, approved fixtures, callback/network allow-listing, and expected receipt/error examples.

With those inputs, implementation can proceed through a credential-envelope-backed adapter, dry connection test, replay-safe intake, immutable receipts, and operator reconciliation.

The connector boundary can be provider-neutral, but an end-to-end FIT-Connect profile needs a selected environment and journey. Decisions required: - first submission/service journey and API/profile version; - inbound, outbound, or bidirectional scope (recommend inbound receipt plus acknowledgement evidence first); - responsibility for attachment malware checks, form/message validation, duplicate detection, status receipts, retention, and retry/outcome-unknown handling; - tenant credential hierarchy and certificate-rotation policy. Manual inputs required: - sandbox base URLs, client/certificate material, service identifiers, approved fixtures, callback/network allow-listing, and expected receipt/error examples. With those inputs, implementation can proceed through a credential-envelope-backed adapter, dry connection test, replay-safe intake, immutable receipts, and operator reconciliation.
zemion added
status
needs-info
and removed
status
triage
labels 2026-08-21 14:20:48 +02:00
Author
Owner

Decision recorded 2026-08-23: the recommended first slice is approved—inbound submission receipt and acknowledgement, preserving FIT-Connect transport provenance while module-owned workflows retain business authority. Provider-neutral contracts can proceed autonomously. A target-tested implementation still needs the concrete FIT-Connect journey/profile, sender/receiver role, test environment and credentials, attachment constraints, and exact receipt/acknowledgement semantics.

Decision recorded 2026-08-23: the recommended first slice is approved—inbound submission receipt and acknowledgement, preserving FIT-Connect transport provenance while module-owned workflows retain business authority. Provider-neutral contracts can proceed autonomously. A target-tested implementation still needs the concrete FIT-Connect journey/profile, sender/receiver role, test environment and credentials, attachment constraints, and exact receipt/acknowledgement semantics.
Author
Owner

Autonomous foundation published in v0.1.19 (ded8509).

Implemented a provider-neutral, effect-free inbound receipt and technical acknowledgement contract: exact destination/profile revisions, cryptographic content evidence, durable-handoff gating, retry versus permanent-rejection classification, and non-dispatchable accept/reject plans. Acceptance is only planable after complete download, decryption, validation, authentication-tag verification, and module-owned durable handoff. Added English/German user and administrator documentation, permissions/roles, manifest contributions, release packaging, and tests.

No API version, destination, endpoint, credentials, key material, environment, wire-format signed event, or transport is selected. The broader connector issue remains open for those configured deployment decisions and an end-to-end adapter.

Autonomous foundation published in v0.1.19 (ded8509). Implemented a provider-neutral, effect-free inbound receipt and technical acknowledgement contract: exact destination/profile revisions, cryptographic content evidence, durable-handoff gating, retry versus permanent-rejection classification, and non-dispatchable accept/reject plans. Acceptance is only planable after complete download, decryption, validation, authentication-tag verification, and module-owned durable handoff. Added English/German user and administrator documentation, permissions/roles, manifest contributions, release packaging, and tests. No API version, destination, endpoint, credentials, key material, environment, wire-format signed event, or transport is selected. The broader connector issue remains open for those configured deployment decisions and an end-to-end adapter.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-fit-connect#1