DS12 — Externe Partner anbinden: Gitea-Instanz, GitCover.IdP, API/MCP
Auslöser S7
Ein Unternehmer/KMU liefert nicht nur Dokumente aus — in der Projekt- Abwicklung (Beispiel: GDT, GitCover Developer Tooling während der Laufzeit eines Auftrags) benötigen Externe (Kunden, Auftraggeber, Co-Worker) Zugriffe auf den Prozess-Verlauf und Nachweise: Welche Meilensteine sind erbracht? Welche Dokumente gezeichnet? Wie ist der Beleg- und Signatur-Verlauf revisionssicher dokumentiert?
Der klassische KMU-Weg: Ein PDF-Ordner im Cloud-Speicher, ein Chat-Attachment, eine E-Mail-Kette — oder ein teurer Projekt-Portal-Abonnement. Alle Varianten brechen die Nachweiskette, die Teil I/II aufgebaut haben.
Die Skalierungs-Stufen
Der Git-Repo-Ansatz erlaubt es dem kleinen Unternehmer, dieselbe Leistung zu skalieren, die seine Partner benötigen — in drei Stufen:
Offline-Paket"] --> B["Stufe 2
Gitea-Instanz
per Internet"] B --> C["Stufe 3
GitCover.IdP +
API/MCP"] style C fill:#e8eef7,stroke:#2c5282
Stufe 1 — Offline-Paket (ohne Infrastruktur)
Das Container-Paket (DS10: *.gcpn.zip) wird dem Partner als
Datei ausgeliefert — selbst-verifizierend, ohne Server, ohne Konto.
Genügt für einmalige Nachweise (z. B. Abnahme eines Vertragswerks).
Stufe 2 — Gitea-Instanz per Internet zugänglich
Wenn Externe laufend Zugriff benötigen, macht der Unternehmer seine (oder eine dedizierte) Gitea-Instanz per Internet zugänglich — wie am Beispiel der GCUV ersichtlich, wo der Unternehmensverbund seine Repos über eigene Gitea-Instanzen (git.gitcover.org / git.gitcover.de) im Internet anbietet:
| Aspekt | Umsetzung |
|---|---|
| Zugriffssteuerung | Gitea-Org/Teams (Partner nur in die Vorgangs-Repos, nicht in PII) |
| Nachweis-Sicht | Der GCPN-Container als Prozess-Index (DS05): Partner navigiert zu den Einzel-Docs |
| Signatur-Nachweise | GVB/GCPN mit Signaturvermerk — der Partner sieht die Kette (SHA-256, Events, Facsimile-Verweis) |
| Revisionssicherheit | Git-Historie bleibt im Repo; der Partner kann klonen (vollständige Chronologie) |
Für den kleinen Unternehmer: Eine Gitea-Instanz kostet einen kleinen Server und Wartung — kein Lizenz-Abonnement pro Nutzer. Die Zugriffssteuerung ist repo-basiert (Repo → Team → Member), die PII-Grenze bleibt im gitignored-Verzeichnis (nicht im Internet-Repo).
Stufe 3 — GitCover.IdP, API/MCP
Der eigentliche Hebel: GitCover.IdP (BSFZ-Forschungsvorhaben) macht aus
dem Git-Repo einen Identity Provider — der Zugriff wird über
Claims (tenant_id, org_unit_id, zwei-Ebenen-PII-Modell) gesteuert,
die API/MCP (Model Context Protocol) stellt dem Partner
programmatischen Zugriff bereit:
| Baustein | Leistung für den Partner |
|---|---|
| GitCover.IdP | Authentisierung + Autorisierung über Git-Claims (Zugriff nur auf Vorgangs-Repos, PII bleibt ausgeschlossen) |
| GitCover API | Strukturierter Abruf: Container-Index, Signatur-Kette, Verifikationsmanifest — ohne Git-Kenntnis |
| MCP | Agent-Partner (KI-Coworker des Kunden) können die Vorgänge maschinell abfragen — Guardrails über OPA/Rego-Policies |
| GCPN-Container | bleibt die Nachweis-Ebene: Jeder Zugriffs- und Zustandswechsel ist sha256-verankert |
Genau DA zeigt sich die Stärke des Git-Repo-Ansatzes: Die Nachweis- Ebene (Container, Sidecars, SHA-Kette) ist dieselbe — ob der Partner das Paket offline liest (Stufe 1), im Gitea-Portal navigiert (Stufe 2) oder per API/MCP maschinell konsumiert (Stufe 3). Der Unternehmer skaliert die Schnittstelle, nicht den Nachweis — und behält die Kontrolle über PII und Zugriffsrechte.
Praktische Konsequenz für das KMU
| Situation | Stufe | Kosten |
|---|---|---|
| Einmalige Vertrags-Nachweise an einen Kunden | 1 | 0 (ZIP) |
| Laufende Projekt-Abwicklung mit Co-Workern (GDT) | 2 | kleiner Server + Gitea (OSS) |
| Partner mit eigenen KI-Agenten / Automatisierung | 3 | IdP + API/MCP-Integration |
Die Stufen sind kumulativ: Wer bei Stufe 3 angekommen ist, bietet weiterhin Stufe 1 und 2 an. Die Nachweiskette (Teil I/II) ist in allen Stufen identisch.
Rechtliche Einordnung
- Zugriffssteuerung ist DSGVO-relevant (Art. 32 TOM): Die PII-Grenze (gitignored-Verzeichnisse) bleibt — Externe erhalten nur Vorgangs-Repos.
- Verarbeitungsvorgänge für Auftraggeber werden über Auftragsverarbeitungsverträge (Art. 28 DSGVO) ggf. abgedeckt — die Container dokumentieren die Vorgänge als Nachweis.
- eIDAS bleibt unberührt: Die Signatur-Kette ist dieselbe; die Zugriffs-Ebene ist kein Teil der Signatur.
Querverweise
- GitCover.IdP — BSFZ-Forschungsvorhaben
(
ORG-1-Partner/FY2026/BSFZ/): Gitea/GitCover als Identity Provider - Teil IV (geplant) — PII/GPG-Kreis: Identity-Schemas, Trust Registry
- Achse 5: Vorgehensweisen — zwei-Ebenen-Claim-Modell
(
tenant_id/org_unit_id), Inlet-Pipeline - DS10 — das Container-Paket als Stufe-1-Lieferung
Erstellt: 260913 | Teil II, Artikel DS12 | Serie: digital-signage