DS12 — Connecting external partners: Gitea instance, GitCover.IdP, API/MCP
Trigger S7
An entrepreneur/SME doesn't just deliver documents — in project execution (example: GDT, GitCover Developer Tooling during the term of an order), externals (customers, clients, co-workers) need access to the process history and evidence: Which milestones have been achieved? Which documents have been signed? How is the voucher and signature trail documented in a revision-safe manner?
The classic SME way: a PDF folder in cloud storage, a chat attachment, an email chain — or an expensive project portal subscription. All variants break the evidence chain that Part I/II have built up.
The scaling levels
The Git repo approach allows the small entrepreneur to scale the same service that his partners need — in three levels:
Offline-Paket"] --> B["Stufe 2
Gitea-Instanz
per Internet"] B --> C["Stufe 3
GitCover.IdP +
API/MCP"] style C fill:#e8eef7,stroke:#2c5282
Level 1 — Offline package (without infrastructure)
The container package (DS10: *.gcpn.zip) is delivered to the partner
as a file — self-verifying, without a server, without an account.
Sufficient for one-time evidence (e.g., acceptance of a contracted
work).
Level 2 — Gitea instance accessible via the internet
When externals need ongoing access, the entrepreneur makes his (or a dedicated) Gitea instance accessible via the internet — as can be seen in the example of the GCUV, where the corporate association offers its repos via its own Gitea instances (git.gitcover.org / git.gitcover.de) on the internet:
| Aspect | Implementation |
|---|---|
| Access control | Gitea org/teams (partners only in the case repos, not in PII) |
| Evidence view | The GCPN container as process index (DS05): the partner navigates to the individual docs |
| Signature evidence | GVB/GCPN with signature note — the partner sees the chain (SHA-256, events, facsimile reference) |
| Revision security | Git history remains in the repo; the partner can clone (complete chronology) |
For the small entrepreneur: A Gitea instance costs a small server and maintenance — no per-user license subscription. Access control is repo-based (Repo → Team → Member), and the PII boundary remains in the gitignored directory (not in the internet repo).
Level 3 — GitCover.IdP, API/MCP
The real lever: GitCover.IdP (BSFZ research project) turns the Git
repo into an Identity Provider — access is controlled via
claims (tenant_id, org_unit_id, two-level PII model), and the
API/MCP (Model Context Protocol) provides the partner with
programmatic access:
| Component | Service for the partner |
|---|---|
| GitCover.IdP | Authentication + authorization via Git claims (access only to case repos, PII remains excluded) |
| GitCover API | Structured retrieval: container index, signature chain, verification manifest — without Git knowledge |
| MCP | Agent partners (the customer's AI co-workers) can query the cases by machine — guardrails via OPA/Rego policies |
| GCPN container | remains the evidence layer: every access and state change is sha256-anchored |
It is precisely THERE that the strength of the Git repo approach becomes apparent: The evidence layer (container, sidecars, SHA chain) is the same — whether the partner reads the package offline (level 1), navigates the Gitea portal (level 2), or consumes it by machine via API/MCP (level 3). The entrepreneur scales the interface, not the evidence — and retains control over PII and access rights.
Practical consequence for the SME
| Situation | Level | Costs |
|---|---|---|
| One-time contract evidence to a customer | 1 | 0 (ZIP) |
| Ongoing project execution with co-workers (GDT) | 2 | small server + Gitea (OSS) |
| Partners with their own AI agents / automation | 3 | IdP + API/MCP integration |
The levels are cumulative: Anyone who has reached level 3 continues to offer levels 1 and 2. The evidence chain (Part I/II) is identical at all levels.
Legal classification
- Access control is GDPR-relevant (Art. 32 TOM): The PII boundary (gitignored directories) remains — externals receive only case repos.
- Processing operations for clients are covered, where applicable, by data processing agreements (Art. 28 DSGVO) — the containers document the cases as evidence.
- eIDAS remains unaffected: The signature chain is the same; the access layer is not part of the signature.
Cross-references
- GitCover.IdP — BSFZ research project
(
ORG-1-Partner/FY2026/BSFZ/): Gitea/GitCover as Identity Provider - Part IV (planned) — PII/GPG circle: identity schemas, Trust Registry
- Axis 5: Approaches — two-level claim model
(
tenant_id/org_unit_id), Inlet pipeline - DS10 — the container package as a level-1 delivery
Created: 260913 | Part II, Article DS12 | Series: digital-signage