Módulo Conector Gaia-X / IDSA sobre EDC — Informe de arranque

0. TL;DR (para quien tiene 2 minutos)

• Gaia-X, IDSA y EDC no compiten: IDSA define el protocolo (Dataspace Protocol, DSP), Gaia-X define la confianza (Trust Framework, identidad federada), y EDC es la implementación que hace ambas cosas.
• EDC es un framework Java 17 / Gradle, modular por extensiones. No es un producto instalable: cada quien compila su propio conector eligiendo módulos. Se opera desde fuera vía una Management API REST (JSON-LD).
• Encaje casi perfecto con Carbon: la capa de datos ya es de tres niveles — R2 (bytes Parquet), Lakekeeper (catálogo REST de Iceberg = los punteros a las tablas) y Supabase (metadata de aplicación: datasets, lineaje, permisos). El data plane de EDC habla S3 con endpointOverride → lee/escribe el mismo R2, y podemos compartir tablas Iceberg apuntando al catálogo REST de Lakekeeper (modelo zero-copy). No reescribimos EDC; lo desplegamos como servicio aparte (igual que ml-runner) y lo manejamos desde Node por su Management API.
• Identidad — resuelta por el modelo de negocio: Carbon apunta a mid-market europeo, desplegable on-prem / cloud soberano, operable por un equipo de 3. Eso fija el modelo: un conector EDC por despliegue (cada cliente = un participante del dataspace), sin multiplexado global. La identidad descentralizada (DID/VC vía IdentityHub + Gaia-X) se ofrece llave en mano, no como algo que el equipo de 3 gestione a mano. La soberanía del dato y el AI Act son el foso, no un extra (ver §8 y sección estratégica).
• Estrategia recomendada: un microservicio edc-service (conector Java) + un cliente Node (lib/dataspaces/edc-client.ts) + un executor (lib/executors/services/edc.executor.ts) + una pestaña de workspace ("Dataspaces") + un worker BullMQ. Todo sobre plumbing que Carbon ya tiene.

🎯 Posicionamiento y principios de diseño (el porqué)

Esta sección manda sobre todas las decisiones técnicas que siguen.

El producto: Carbon apunta al mid-market vertical europeo — la empresa industrial, agroalimentaria, logística o sanitaria de tamaño medio en España/Europa que necesita ontología + pipelines + gobernanza pero no puede pagar Palantir ni operar Databricks. La promesa: "un Foundry operable por un equipo de 3 personas, a precio de mid-market, con cumplimiento europeo de serie."

El foso (moat): soberanía del dato europea + AI Act. Una plataforma europea, desplegable on-prem o en cloud soberano, con gobernanza y lineaje nativos. No es un checkbox de compliance: es la razón por la que un cliente europeo nos elige frente a un hyperscaler estadounidense.

Por qué esto encaja con dataspaces: Gaia-X/IDSA son la infraestructura europea de soberanía del dato. El conector EDC no es "una feature más" — es la extensión natural del foso: convierte a Carbon en participante de primera clase de la economía del dato europea, con intercambio inter-organización gobernado por políticas (ODRL) y soberano (los datos no salen; se comparte acceso).

Principios de diseño que se derivan:

1. Los tres estándares y cómo se relacionan

Es el punto que más confusión genera, así que va primero.

Historia útil: IDSA nació del proyecto de investigación Industrial Data Space (Fraunhofer). EDC es hoy el estándar de facto porque es el que adoptan las grandes iniciativas (Catena-X / Tractus-X en automoción, y despliegues de AWS, etc.).

Conclusión para nosotros: al construir sobre EDC obtenemos DSP + compatibilidad Gaia-X "gratis". Nuestro trabajo es configurar y orquestar un conector EDC desde Carbon, no reimplementar el protocolo.

2. Anatomía de EDC — qué componentes tendríamos que desplegar

EDC separa control de datos (patrón separation of concerns). Un conector se arma eligiendo extensiones Gradle.

┌─────────────────────────────────────────────────────────────┐
│                      CONECTOR EDC (participante)              │
│                                                              │
│  ┌────────────────────┐        ┌────────────────────────┐   │
│  │   CONTROL PLANE     │        │      DATA PLANE        │   │
│  │  (administración)   │◀──────▶│   (mueve los bytes)    │   │
│  │                     │ signal │                        │   │
│  │ · Assets            │        │ · HTTP push/pull       │   │
│  │ · Policies (ODRL)   │        │ · S3 / AmazonS3  ◀──── │───┼─▶ R2
│  │ · Contract Defs     │        │ · Kafka, Azure Blob…   │   │
│  │ · Negociación       │        └────────────────────────┘   │
│  │ · Transfer Process  │                                     │
│  │ · Management API ◀──┼── REST JSON-LD (aquí engancha Node) │
│  │ · DSP endpoints  ◀──┼── protocolo entre conectores        │
│  └────────────────────┘                                     │
└─────────────────────────────────────────────────────────────┘
        │                                    │
        │ DCP (credential exchange)          │ DSP (catalog / negotiation / transfer)
        ▼                                    ▼
┌──────────────────┐              ┌──────────────────────┐
│   IDENTITY HUB    │              │  OTROS PARTICIPANTES  │
│  DIDs + VCs (W3C) │              │   (Provider/Consumer) │
└──────────────────┘              └──────────────────────┘

Runtime / build (importante para el fit):

• Lenguaje: Java 17+, build con Gradle (Kotlin DSL, build.gradle.kts).
• Los módulos incluidos (= capacidades del conector) se declaran en el build.gradle.kts de un subdirectorio launcher.
• EDC no ship un binario instalable: se compila un launcher propio → imagen Docker.
• Backing services típicos en producción: PostgreSQL (persistencia) + HashiCorp Vault (secretos).

3. Modelo de datos de EDC — el "lenguaje" del conector

Estos son los objetos que crearemos/consultaremos por la Management API. Entenderlos es entender el 80% del trabajo.

Flujo end-to-end (consumer pide un dato a un provider):

Para Carbon esto significa: cada dataset del lakehouse que queramos compartir se expone como un Asset EDC; y cada dataset externo que consumamos entra por un Transfer Process cuyo destino es R2 → se registra como snapshot Iceberg con el withNativeControlPlane() que ya tenemos.

3.1 Cómo mapear un dataset de Carbon a un Asset EDC

Un dataset del lakehouse no es un fichero: es una tabla Iceberg (punteros en Lakekeeper → Parquet en R2). Hay dos formas de exponerlo como Asset, y la elección es estratégica:

4. La plataforma Carbon hoy (lo que ya tenemos)

Resumen del mapa del código relevante para este proyecto. (Detalle completo en el informe de arquitectura; aquí solo lo que toca al conector.)

Identidad del repo: C:\Carbon es un symlink a C:\storelyAI. Es un único proyecto, nombre oficial "Node" (package.json → "name": "node"), no un monorepo separado.

Stack:

• Frontend: Next.js 16 (App Router) + React 19 + TypeScript 5.9 + Tailwind 4 + Zustand + React Query. Deploy en Vercel.
• Backend: Next.js Route Handlers (Node 20+) + workers BullMQ sobre Redis (Upstash).
• Datos (3 niveles): R2 (bytes Parquet) · Lakekeeper (catálogo REST de Iceberg = punteros a las tablas; Rust, OSS Apache-licensed, Postgres-backed, authz OpenFGA) · Supabase Postgres con RLS (metadata de aplicación: registro de datasets, lineaje, ledger de txn, permisos).
• Auth: Clerk (sesión JWT + orgs) → puente a RLS de Supabase.
• Servicios externos (contenedores orquestados por docker-compose.yml): ml-runner (FastAPI/Python, PyIceberg+PyArrow), jupyterhub, kuzu-service.

Piezas clave para el conector:

5. Encaje EDC ↔ Carbon (análisis de fit)

Lectura: el 80% del trabajo es plomería de integración (que Carbon facilita) y DevOps (desplegar el conector Java). El 20% genuinamente nuevo es identidad de dataspace y mapear datasets↔assets.

6. Arquitectura de integración propuesta

┌────────────────────────── CARBON (repo Node) ──────────────────────────┐
│                                                                        │
│  UI:  components/workspace/tabs/dataspaces/DataspacesTab.tsx            │
│         │  (catálogo, negociaciones, transferencias, assets propios)    │
│         ▼                                                               │
│  API:  app/api/dataspaces/*  ·  app/api/integrations/edc/*              │
│         │                                                               │
│         ▼                                                               │
│  Executor:  lib/executors/services/edc.executor.ts                     │
│         │   (asset:list · catalog:browse · contract:negotiate ·         │
│         │    asset:transfer · testConnection)                           │
│         ▼                                                               │
│  Cliente:  lib/dataspaces/edc-client.ts   (fetch a la Management API)   │
│         │                                                               │
│  Worker:  lib/workers/dataspaces/edc-sync-worker.ts (BullMQ)           │
│         │   (poll estados async de negociación/transfer → landing)      │
│         ▼                                                               │
│  Landing: lib/lakehouse/iceberg-native-write.ts  (snapshot en R2)      │
│                                                                        │
└──────────────────────────────────┬─────────────────────────────────────┘
                                    │ Management API (REST JSON-LD)
                                    ▼
        ┌──────────────────── services/edc-service/ ────────────────────┐
        │  Conector EDC (launcher Java/Gradle → imagen Docker)          │
        │   · Control Plane  (Management API + DSP)                      │
        │   · Data Plane     (S3 → R2)                                   │
        │   · IdentityHub    (DID + VC)          + Postgres + Vault      │
        └───────────────────────────────┬────────────────────────────────┘
                                         │ DSP / DCP
                                         ▼
                                 Otros participantes del dataspace

Componentes a crear (nombres tentativos):

Contrato del executor (borrador):

// lib/executors/services/edc.executor.ts
export const edcExecutor: ServiceExecutor = {
  name: 'EDC / Dataspace Connector',
  supportedOperations: [
    'catalog:browse',       // GET catálogo DSP de una contraparte
    'asset:list',           // assets propios publicados
    'asset:publish',        // envolver un dataset Carbon como Asset EDC
    'policy:create',        // definir una ODRL policy
    'contract:negotiate',   // iniciar negociación → devuelve negotiationId
    'contract:status',      // consultar estado (async)
    'asset:transfer',       // iniciar transfer → destino R2 → snapshot Iceberg
  ],
  async execute(req) { /* switch por `${resource}:${operation}` */ },
  async testConnection(creds) { /* GET /api/management/v1/version */ },
};

7. Topología de despliegue

Referencia oficial — el Minimum Viable Dataspace (MVD): dos participantes ("Provider Corp" / "Consumer Corp") en Kubernetes (KinD), cada uno con Control Plane + IdentityHub (+ Data Plane en el provider) + PostgreSQL + Vault; con Keycloak y Traefik compartidos. Es un playground, no producción.

Adaptación recomendada para Carbon (arranque):

docker-compose.yml (añadir)
└── edc-service            # 1 conector (nosotros somos el participante)
    ├── control-plane      # Management API :8081  +  DSP :8282
    ├── data-plane         # S3 → R2
    ├── identityhub        # DID + VC
    ├── edc-postgres       # persistencia del conector (aparte de Supabase)
    └── vault              # secretos del conector

• PoC / dev: stores en memoria + vault en memoria (como el MVD desde IntelliJ) → cero infra extra.
• Staging/prod: Postgres + Vault dedicados del conector. Ojo: el Postgres del conector es independiente del Supabase de Carbon (el conector persiste su propio estado DSP).
• Vercel: el frontend/API de Carbon sigue en Vercel; el conector EDC vive donde corren hoy los otros contenedores (host de ml-runner/workers), no en Vercel (es un servicio Java de larga vida).

8. Identidad y autorización — resuelto por el modelo de negocio

El posicionamiento (mid-market, on-prem/soberano, equipo de 3) resuelve lo que antes parecía la decisión más delicada.

8.1 Modelo de despliegue → un conector por instancia

Como Carbon se despliega on-prem o en cloud soberano dedicado, cada cliente corre su propia instancia. Por tanto:

Nada de multiplexar un conector global entre tenants. Esto elimina de un plumazo el aislamiento multi-tenant del conector, encaja con on-prem y mantiene el footprint bajo (principio de precio mid-market).

8.2 Tres capas de autorización, cada una en su frontera

No hay "un choque de identidades" sino tres planos ortogonales que ya casi tenemos:

En un intercambio zero-copy (§3.1 Estrategia B) las tres se apilan de forma natural: EDC valida contrato+credenciales → Lakekeeper/OpenFGA valida acceso a la tabla → creds temporales sobre R2. Autorización soberana, defendible ante un auditor.

8.3 Identidad descentralizada, pero llave en mano

La identidad de participante (DID/VC + Gaia-X Trust Framework) es parte del foso, no overhead — pero no puede caer sobre el equipo de 3. Diseño: IdentityHub pre-configurado, claves generadas y rotadas automáticamente, credenciales verificables emitidas con defaults sensatos. El operador ve "conectar a un dataspace", no "gestionar un DID document".

Decisiones que quedan (menores, ya acotadas):

1. ¿Emitimos las Verifiable Credentials nosotros (Carbon como issuer gestionado) o nos federamos con un emisor Gaia-X existente del vertical? → empezar auto-emitidas, federar cuando haya un dataspace real.
2. Para el PoC: IAM simple (in-memory / OAuth); IdentityHub entra en Fase 6.

9. Riesgos y decisiones abiertas

10. Roadmap por fases (estilo "Stage / Fase")

• Fase 0 — Recopilación (este documento). ✅ Estándares, fit y arquitectura mapeados.
• Fase 1 — PoC local aislado. Levantar un conector EDC (stores en memoria) desde el sample oficial; ejecutar un ciclo completo catálogo → negociación → transferencia entre dos conectores locales. Sin tocar Carbon todavía. Objetivo: entender la Management API de primera mano. → approach detallado: fase-1-poc-approach.md.
• Fase 2 — Data plane sobre R2. Configurar el data plane S3 del conector contra nuestro R2; transferir un objeto Parquet de prueba a un prefijo del lakehouse.
• Fase 3 — Cliente + executor en Node. lib/dataspaces/edc-client.ts + edc.executor.ts + rutas app/api/dataspaces/*. Consumir el catálogo EDC desde Carbon.
• Fase 4 — Consumir → lakehouse. edc-sync-worker que, tras una transferencia, aterriza el dato como snapshot Iceberg vía withNativeControlPlane().
• Fase 5 — Publicar datasets como assets. Empezar con copia S3/R2 (Estrategia A, §3.1); luego el DataSource Iceberg zero-copy vía Lakekeeper (Estrategia B). Cada dataset → Asset + Contract Definition + ODRL policy. Carbon como provider.
• Fase 6 — Identidad de dataspace. IdentityHub / DID + Verifiable Credentials; decidir modelo por-tenant vs global (§8).
• Fase 7 — UI + governance. Pestaña "Dataspaces" en el workspace: catálogo, editor de políticas ODRL, panel de negociaciones/transferencias.
• Fase 8 — Producción. Postgres + Vault dedicados, Federated Catalog, hardening, alta en un dataspace real (Gaia-X Trust Framework).

11. Fuentes

Estándares y visión general

• Eclipse Dataspace Components (EDC) — sitio oficial
• Proyecto EDC — Eclipse Foundation
• International Data Spaces Association — EDC & IDSA
• Gaia-X & IDSA: pilares de los espacios de datos europeos (Inverbis)
• Building a Dataspace: Technical Overview (Gaia-X Hub Austria, whitepaper)
• The EDC Connector: Driving Data Sovereignty (Think-it)
• EDC: Architecture and benefits (doubleSlash)
• A Survey of Dataspace Connector Implementations (arXiv)
• A Service Architecture for Dataspaces (arXiv, 2025)

Técnico / implementación

• EDC Connector — repo · autodoc del Connector
• EDC Samples — transfer / negotiation
• Minimum Viable Dataspace (MVD)
• EDC Technology-AWS (S3/MinIO data plane)
• Developer handbook (Java 17 / Gradle / extensiones)
• Set up a minimum viable data space (AWS Prescriptive Guidance)
• Tractus-X EDC (despliegue real, Catena-X)
• Lakekeeper — Iceberg REST Catalog (Rust, OSS) · docs · authorization (OpenFGA)
• Iceberg en EDC / compute2data (Tractus-X discussion #1541)
• Apache Iceberg REST Catalog spec

Documento vivo. Siguiente paso sugerido: Fase 1 — levantar el sample oficial de EDC y recorrer un ciclo de transferencia end-to-end.