DS12 — Conectar socios externos: instancia Gitea, GitCover.IdP, API/MCP
Desencadenante S7
Un empresario/Pyme no solo entrega documentos — en la ejecución de proyectos (ejemplo: GDT, GitCover Developer Tooling durante la vigencia de un encargo) los externos (clientes, comitentes, Co-Worker) necesitan accesos al transcurso del proceso y evidencias: ¿Qué hitos se han cumplido? ¿Qué documentos se han firmado? ¿Cómo está documentado de forma auditable el transcurso de comprobantes y firmas?
El camino clásico de la Pyme: una carpeta PDF en el almacenamiento en la nube, un adjunto de chat, una cadena de correos electrónicos — o una costosa suscripción a un portal de proyectos. Todas las variantes rompen la cadena de evidencias que la Parte I/II ha construido.
Los niveles de escalado
El enfoque de repositorio Git permite al pequeño empresario escalar el mismo servicio que sus socios necesitan — en tres niveles:
Offline-Paket"] --> B["Stufe 2
Gitea-Instanz
per Internet"] B --> C["Stufe 3
GitCover.IdP +
API/MCP"] style C fill:#e8eef7,stroke:#2c5282
Nivel 1 — Paquete offline (sin infraestructura)
El paquete contenedor (DS10: *.gcpn.zip) se entrega al socio como
archivo — autoverificable, sin servidor, sin cuenta. Es suficiente para
evidencias puntuales (p. ej., aceptación de una obra contractual).
Nivel 2 — Instancia Gitea accesible por Internet
Cuando los externos necesitan acceso permanente, el empresario hace que su (o una dedicada) instancia Gitea sea accesible por Internet — como se ve en el ejemplo de GCUV, donde el grupo empresarial ofrece sus repos a través de sus propias instancias Gitea (git.gitcover.org / git.gitcover.de) en Internet:
| Aspecto | Implementación |
|---|---|
| Control de accesos | Gitea-Org/Teams (socios solo en los repos de expedientes, no en PII) |
| Vista de evidencias | El contenedor GCPN como índice de proceso (DS05): el socio navega hacia los documentos individuales |
| Evidencias de firma | GVB/GCPN con nota de firma — el socio ve la cadena (SHA-256, Events, referencia Facsimile) |
| Seguridad de auditoría | El historial Git permanece en el repo; el socio puede clonarlo (cronología completa) |
Para el pequeño empresario: Una instancia Gitea cuesta un pequeño servidor y mantenimiento — sin suscripción de licencia por usuario. El control de accesos se basa en repos (Repo → Team → Member), el límite de PII permanece en el directorio gitignored (no en el repo de Internet).
Nivel 3 — GitCover.IdP, API/MCP
La verdadera palanca: GitCover.IdP (proyecto de investigación BSFZ)
convierte el repositorio Git en un Identity Provider — el acceso se
controla mediante Claims (tenant_id, org_unit_id, modelo de PII
de dos niveles), y la API/MCP (Model Context Protocol) proporciona
al socio acceso programático:
| Componente | Servicio para el socio |
|---|---|
| GitCover.IdP | Autenticación + autorización mediante Git-Claims (acceso solo a los repos de expedientes, la PII permanece excluida) |
| GitCover API | Consulta estructurada: índice del contenedor, cadena de firmas, manifiesto de verificación — sin conocimientos de Git |
| MCP | Los socios-agentes (Co-Worker de IA del cliente) pueden consultar los expedientes de forma automatizada — Guardrails mediante políticas OPA/Rego |
| Contenedor GCPN | sigue siendo la capa de evidencias: cada cambio de acceso y de estado está anclado mediante sha256 |
Precisamente AHÍ se muestra la fortaleza del enfoque de repositorio Git: la capa de evidencias (contenedor, sidecars, cadena SHA) es la misma — ya sea que el socio lea el paquete offline (Nivel 1), navegue en el portal Gitea (Nivel 2) o lo consuma de forma automatizada mediante API/MCP (Nivel 3). El empresario escala la interfaz, no la evidencia — y conserva el control sobre la PII y los derechos de acceso.
Consecuencia práctica para la Pyme
| Situación | Nivel | Costes |
|---|---|---|
| Evidencias contractuales puntuales a un cliente | 1 | 0 (ZIP) |
| Ejecución continua de proyectos con Co-Workers (GDT) | 2 | servidor pequeño + Gitea (OSS) |
| Socios con agentes de IA propios / automatización | 3 | IdP + integración API/MCP |
Los niveles son acumulativos: quien ha llegado al Nivel 3 sigue ofreciendo los Niveles 1 y 2. La cadena de evidencias (Parte I/II) es idéntica en todos los niveles.
Clasificación jurídica
- El control de accesos es relevante para el RGPD (Art. 32 TOM): el límite de PII (directorios gitignored) se mantiene — los externos reciben solo repos de expedientes.
- Las operaciones de tratamiento para comitentes quedan, en su caso, cubiertas mediante contratos de encargo de tratamiento (Art. 28 RGPD) — los contenedores documentan los expedientes como evidencia.
- eIDAS permanece intacto: la cadena de firmas es la misma; la capa de acceso no es parte de la firma.
Referencias cruzadas
- GitCover.IdP — proyecto de investigación BSFZ
(
ORG-1-Partner/FY2026/BSFZ/): Gitea/GitCover como Identity Provider - Parte IV (planificada) — círculo PII/GPG: esquemas de identidad, Trust Registry
- Eje 5: Procedimientos — modelo de claims de dos niveles
(
tenant_id/org_unit_id), Inlet-Pipeline - DS10 — el paquete contenedor como entrega de Nivel 1
Creado: 260913 | Parte II, artículo DS12 | Serie: digital-signage