Permitir que estudiantes de centros de Formación Profesional resuelvan problemas en sus plataformas LMS locales y que sus evaluaciones automáticas se procesen mediante el sistema PKST del Backend EAC centralizado, federando datos seudonimizados a través del VFDS para mejorar colaborativamente el sistema educativo.
Decisión de diseño:
Ventajas de este modelo:
Trade-offs aceptados:
Color: Verde
Permisos:
Credencial Verificable:
StudentCredentialstudentId, institution, enrolledPrograms, validUntilColor: Azul
Permisos:
Credencial Verificable:
TeacherCredentialteacherId, institution, subjects, adminLevel, validUntilFlujo de integración con el servicio:
TeacherCredentialColor: Naranja
Permisos:
Credencial Verificable:
OperatorCredentialoperatorId, organization, role: ["dataspace_admin"], validUntilResponsabilidades adicionales:
Color: Morado Permisos:
Credencial Verificable:
ResearcherCredentialresearcherId, institution, projectId, approvedDatasets, validUntilProceso de acceso:
ResearcherCredential con scope limitadoLos centros FP siguen actuando como VC Issuers para emitir StudentCredential y TeacherCredential.
Rol: Emisor de Credenciales Verificables
Ejemplo: IES Ingeniero de la Cierva (Murcia)
DID: did:web:ies-cierva.edu.es
¿Qué son las Credenciales Verificables (W3C VC)?
Tipos de VCs emitidas por el centro:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://vfds.org/credentials/student/v1"
],
"id": "https://ies-cierva.edu.es/credentials/std_12345",
"type": ["VerifiableCredential", "StudentCredential"],
"issuer": "did:web:ies-cierva.edu.es",
"issuanceDate": "2025-09-01T00:00:00Z",
"expirationDate": "2026-09-01T23:59:59Z",
"credentialSubject": {
"id": "did:web:student-wallet.example.com:std_12345",
"studentId": "std_12345",
"institution": "ies_cierva",
"enrolledProgram": "FP Comercio - TBM",
"academicYear": "2025-2026"
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2025-09-01T10:00:00Z",
"verificationMethod": "did:web:ies-cierva.edu.es#key-1",
"proofPurpose": "assertionMethod",
"jws": "eyJhbGc...signature..."
}
}
{
"@context": [...],
"type": ["VerifiableCredential", "TeacherCredential"],
"issuer": "did:web:ies-cierva.edu.es",
"credentialSubject": {
"teacherId": "teacher_789",
"subjects": ["TBM", "Marketing"],
"adminLevel": "coordinator"
},
...
}
Proceso de emisión:
Wallet del Usuario:
Función: Verificar Credenciales Verificables de usuarios que acceden al sistema
Flujo de autenticación:
1. Usuario intenta acceder al VFDS
↓
2. Sistema redirige a VC Verifier (Keycloak)
↓
3. Usuario presenta VC desde su wallet
[Protocolo: DIDComm o OIDC4VC]
↓
4. VC Verifier valida:
- Firma criptográfica (usando DID del issuer)
- Fecha de expiración
- Revocation status (opcional)
- Claims requeridos (role, institution)
↓
5. Si válido, extrae claims y genera token JWT interno:
{
"sub": "did:web:student-wallet.example.com:std_12345",
"role": "student",
"institution": "ies_cierva",
"scope": "eac:submit eac:results:read"
}
↓
6. Token JWT usado para autenticación en servicios internos
Ventajas vs. OAuth2 tradicional:
Tecnología:
keycloak-vc-issuer o similar¿Qué es Gaia-X? Iniciativa europea para crear una infraestructura de datos soberana, segura e interoperable. Define estándares y servicios para dataspaces federados.
Componentes Gaia-X en el VFDS:
Flujo de validación Gaia-X:
Servicio Backend EAC quiere publicarse
↓
1. Genera Self-Description (metadatos del servicio)
↓
2. Envía a Gaia-X Compliance Service
↓
3. Compliance Service verifica:
- Identidad del proveedor (IES Cierva)
- Cumplimiento de políticas GDPR
- Transparencia en SLAs
- Portabilidad de datos
↓
4. Si cumple, emite certificado de compliance
↓
5. Servicio se publica en Federated Catalogue con badge ⭐
Self-Description del Backend EAC (ejemplo simplificado):
{
"@context": "https://www.w3.org/2018/credentials/v1",
"type": "gx:ServiceOffering",
"gx:providedBy": {
"gx:legalName": "IES Ingeniero de la Cierva",
"gx:legalAddress": {
"gx:countryCode": "ES",
"gx:city": "Murcia"
}
},
"gx:name": "Backend EAC v1.2.3",
"gx:description": "Sistema de Evaluación Automática Competencial con PKST",
"gx:dataAccountExport": {
"gx:requestType": "API",
"gx:format": "JSON-LD"
},
"gx:termsAndConditions": {
"gx:URL": "https://ies-cierva.edu.es/eac/terms"
},
"gx:policy": [
"https://ies-cierva.edu.es/eac/usage-policy.json"
]
}
Implementación: CKAN + Gaia-X Federated Catalogue Extensions
Funcionalidad:
Servicios Publicados (ejemplos):
Publisher: VFDS Consortium (Nodo Central)
Operator: Equipo central de operaciones
Provider: Nodo Central Coordinador
Category: Learning Analytics
Type: REST API + NGSI-LD
Standards: LTI 1.3 (submission), NGSI-LD v1.6.1, W3C VC
Endpoint: https://eac-central.vfds.org/api/v2
Access Mode: API Key + OAuth2 (for integrations)
SLA: 99.5% uptime, <500ms p95 latency
Capacity: 10,000 evaluations/hour
Pricing: Free (pilot phase), usage-based after pilot
License: Educational use only (CC BY-NC 4.0)
Gaia-X Compliance: ✓ Certified
Self-Description: [Ver JSON-LD]
Documentation: https://eac-central.vfds.org/docs
Sandbox: https://sandbox.eac-central.vfds.org
Support: soporte-eac@vfds.org (L-V 9:00-18:00)
Interacción con Marketplace:
PASO 1: Descubrimiento
Docente del CIFP Carlos III busca "evaluación automática"
↓
CKAN devuelve: Backend EAC v1.2.3 (servicio central)
↓
Docente revisa:
- Endpoint: https://eac-central.vfds.org/api/v2
- Capacidad: 10k evaluaciones/hora (compartida)
- Reviews: 4.7/5 estrellas de otros centros
PASO 2: Solicitud de Acceso
Docente solicita acceso al servicio
↓
Presenta TeacherCredential (VC)
↓
Formulario:
- Centro: CIFP Carlos III
- Estudiantes estimados: 50
- Uso esperado: 200 evaluaciones/semana
- Acepta términos de uso: [✓]
PASO 3: Aprobación y Provisioning
Operador del Nodo Central valida:
- Centro es participante activo del VFDS
- Capacidad disponible en el servicio
↓
Sistema genera:
1. API Key: sk_cifp_carlos_iii_prod_abc123xyz
2. Política en Authzforce:
- Allows: POST /api/v2/evaluate
- Rate limit: 500 req/hora
- Propósito: evaluación educativa
3. Contrato de servicio:
- Vigencia: 2025-2026
- Prohibiciones: uso comercial, redistribución
- Retención datos: hasta fin de curso
PASO 4: Integración en LMS del Centro
Docente configura Moodle:
- URL: https://eac-central.vfds.org/api/v2/evaluate
- Authentication: Bearer sk_cifp_carlos_iii_prod_abc123xyz
- LTI Launch URL: https://eac-central.vfds.org/lti/launch
↓
Prueba en sandbox: ✓ OK
↓
Activa en producción
PASO 5: Uso del Servicio
Estudiantes del CIFP Carlos III resuelven problemas
↓
LMS envía evaluaciones al endpoint central
↓
FIWARE Dataspace Connector valida API Key + políticas
↓
Backend EAC central procesa evaluaciones
↓
Retorna resultados al LMS del CIFP Carlos III
↓
Datos agregados se publican en Orion-LD Hub
🎯 El Connector está **SOLO en el nodo central, no en los centros FP.
Función actualizada:
Tecnología:
Responsabilidades del Connector Central:
Si excede límite: → 429 Too Many Requests → Header: Retry-After: 1800
4. **Auditoría y Trazabilidad**
Para cada request, registra:
Flujo completo del Connector Central:
┌─────────────────────────────────────────────────────────────┐
│ Request desde LMS del Centro FP │
│ POST https://eac-central.vfds.org/api/v2/evaluate │
│ Authorization: Bearer sk_cifp_carlos_iii_prod_abc123xyz │
│ Content-Type: application/json │
│ Body: { "submission": {...}, "problem_id": "..." } │
└─────────────────────────┬───────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────────┐
│ FIWARE Dataspace Connector (Nodo Central) │
│ │
│ 1. Autenticación │
│ ✓ Valida API Key │
│ ✓ Identifica centro: CIFP Carlos III │
│ │
│ 2. Verificación de Políticas (Authzforce) │
│ ✓ Centro tiene contrato activo │
│ ✓ Rate limit OK (120/500 req/h) │
│ ✓ Endpoint permitido │
│ │
│ 3. Rate Limiting │
│ ✓ Incrementa contador del centro │
│ ✓ Dentro del límite │
│ │
│ 4. Auditoría │
│ ✓ Registra transacción en log │
│ ✓ Timestamp, center, endpoint, contract │
│ │
│ 5. Decisión: PERMIT │
│ → Request pasa al Backend EAC │
└─────────────────────────┬───────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────────┐
│ Backend EAC Central (Servicio) │
│ │
│ • Recibe submission para evaluar │
│ • Procesa con sistema PKST │
│ • Genera feedback personalizado │
│ • Actualiza métricas agregadas en Orion-LD │
│ • Retorna resultado │
└─────────────────────────┬───────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────────┐
│ Response al LMS del Centro FP │
│ 200 OK │
│ { │
│ "evaluation_result": { │
│ "score": 7.5, │
│ "feedback": "...", │
│ "next_recommendation": "prob_042" │
│ } │
│ } │
└─────────────────────────────────────────────────────────────┘
Ejemplo de política ODRL en el Connector:
{
"@context": "http://www.w3.org/ns/odrl/2/",
"@type": "Agreement",
"uid": "https://eac-central.vfds.org/contracts/cifp-carlos-iii-2025-2026",
"profile": "http://vfds.org/odrl:profile:backend-eac",
"assigner": "https://vfds.org#nodo-central",
"assignee": "https://cifp-carlos-iii.edu.es#organization",
"permission": [{
"target": "https://eac-central.vfds.org/api/v2",
"action": ["use", "access"],
"constraint": [
{
"leftOperand": "purpose",
"operator": "eq",
"rightOperand": "educational_evaluation"
},
{
"leftOperand": "elapsedTime",
"operator": "lt",
"rightOperand": "P365D"
}
],
"duty": [{
"action": "attribute",
"target": "https://vfds.org",
"constraint": [{
"leftOperand": "payAmount",
"operator": "eq",
"rightOperand": "0",
"unit": "EUR"
}]
}]
}],
"prohibition": [{
"target": "https://eac-central.vfds.org/api/v2",
"action": ["commercialize", "redistribute"]
}]
}
Self-Description del Backend EAC Centralizado:
{
"@context": {
"gx": "https://registry.lab.gaia-x.eu/...",
"vfds": "https://vfds.org/ontology#"
},
"@type": "gx:ServiceOffering",
"gx:providedBy": {
"@type": "gx:LegalParticipant",
"gx:legalName": "VFDS Consortium - Nodo Central",
"gx:legalRegistrationNumber": {
"gx:taxID": "Q9999999X"
},
"gx:headquarterAddress": {
"gx:countrySubdivisionCode": "ES-MC",
"gx:locality": "Murcia"
}
},
"gx:name": "Backend EAC v1.2.3",
"gx:description": "Servicio centralizado de Evaluación Automática Competencial basado en PKST",
"gx:serviceType": "Centralized Educational Service",
"gx:endpoint": {
"@type": "gx:Endpoint",
"gx:endpointURL": "https://eac-central.vfds.org/api/v2",
"gx:standardConformity": [
{"gx:title": "NGSI-LD", "gx:standardReference": "https://www.etsi.org/..."},
{"gx:title": "W3C VC", "gx:standardReference": "https://www.w3.org/..."}
]
},
"gx:dataAccountExport": {
"gx:requestType": "API",
"gx:accessType": "digital",
"gx:formatType": "JSON-LD"
},
"gx:aggregationOf": [
{
"@type": "gx:Resource",
"gx:name": "Backend EAC Compute Instance",
"gx:hostedOn": {
"gx:legalName": "Nodo Central Infrastructure"
}
}
],
"vfds:accessControl": {
"vfds:authenticationType": "API_Key + OAuth2",
"vfds:authorizationService": "Authzforce PDP",
"vfds:gatewayService": "FIWARE Dataspace Connector"
},
"vfds:serviceLevel": {
"vfds:availability": "99.5%",
"vfds:responseTime": "<500ms p95",
"vfds:capacity": "10000 evaluations/hour",
"vfds:support": "L-V 9:00-18:00 CET"
},
"gx:termsAndConditions": {
"gx:URL": "https://eac-central.vfds.org/terms",
"gx:hash": "sha256:abc123..."
},
"gx:policy": [
"https://eac-central.vfds.org/policies/usage-policy.json",
"https://eac-central.vfds.org/policies/data-retention.json"
]
}
Política actualizada para acceso al servicio central:
<Policy PolicyId="backend-eac-central-access" RuleCombiningAlgId="first-applicable">
<Description>Política de acceso al Backend EAC centralizado</Description>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="string-equal">
<AttributeValue>Backend EAC Central v1.2.3</AttributeValue>
<AttributeDesignator AttributeId="service-id" Category="resource"/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule RuleId="center-with-valid-contract" Effect="Permit">
<Condition>
<Apply FunctionId="and">
<!-- Centro tiene contrato activo -->
<Apply FunctionId="string-equal">
<AttributeDesignator AttributeId="contract-status" Category="subject"/>
<AttributeValue>active</AttributeValue>
</Apply>
<!-- Rate limit no excedido -->
<Apply FunctionId="integer-less-than">
<AttributeDesignator AttributeId="request-count-last-hour" Category="subject"/>
<AttributeDesignator AttributeId="rate-limit" Category="subject"/>
</Apply>
<!-- Propósito es evaluación educativa -->
<Apply FunctionId="string-equal">
<AttributeDesignator AttributeId="purpose" Category="action"/>
<AttributeValue>educational_evaluation</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule RuleId="deny-by-default" Effect="Deny"/>
</Policy>
Función: Agregar y sincronizar entidades NGSI-LD entre nodos del dataspace.
Entidades gestionadas:
urn:ngsi-ld:VocationalSkill:s3_seguridad_visualmasteryRate: 0.65 ± 0.12 (47 estudiantes)Suscripciones:
Ejemplo de query NGSI-LD:
GET /ngsi-ld/v1/entities?type=SkillMasteryAggregate&q=skillId==s3;masteryRate<0.70
Retorna skills con baja mastery para priorizar generación de problemas.
Métricas adicionales para servicio centralizado:
Por servicio Backend EAC:
Por centro consumidor: | Centro | Requests/h | Success % | Avg Latency | Rate Limit Used | |——–|———–|———–|————-|—————–| | IES Cierva | 340 | 99.5% | 138ms | 68% (340/500) | | CIFP Carlos III | 120 | 98.9% | 145ms | 24% (120/500) | | IES María Guerrero | 85 | 99.8% | 132ms | 17% (85/500) |
Alertas específicas del modelo centralizado:
Función: Interfaz donde los estudiantes resuelven problemas. La aplicación LTI actúa como cliente del servicio Backend EAC central.
Integración actualizada:
Opción A: Integración LTI 1.3 (Recomendada)
Estudiante accede a actividad EAC en Moodle
↓
Moodle genera LTI Launch Request
↓
Envía a: https://eac-central.vfds.org/lti/launch
↓
Backend EAC central valida firma LTI
↓
Renderiza interfaz de problema en iframe
↓
Estudiante resuelve problema
↓
Backend EAC procesa y retorna grade via LTI AGS
↓
Moodle actualiza calificación en libro de notas
Opción B: Integración REST API directa
Estudiante envía respuesta en Moodle
↓
Plugin Moodle captura submission
↓
Moodle hace POST:
URL: https://eac-central.vfds.org/api/v2/evaluate
Headers:
Authorization: Bearer sk_cifp_carlos_iii_prod_abc123xyz
Content-Type: application/json
Body:
{
"student_id_hash": "anon_xyz123",
"problem_id": "prob_tbm_042",
"submission": { ... },
"context": {
"course_id": "curso_tbm_2025",
"institution": "cifp_carlos_iii"
}
}
↓
Request pasa por FIWARE Dataspace Connector (validación)
↓
Backend EAC central procesa evaluación
↓
Retorna resultado:
{
"evaluation_result": {
"score": 7.5,
"feedback": "...",
"skill_assessment": { "s1": 0.85, "s3": 0.65 },
"next_recommendation": "prob_043"
}
}
↓
Moodle muestra resultado al estudiante
Configuración en Moodle (ejemplo):
// Archivo: config.php del plugin EAC
define('EAC_API_URL', 'https://eac-central.vfds.org/api/v2/evaluate');
define('EAC_API_KEY', 'sk_cifp_carlos_iii_prod_abc123xyz');
define('EAC_TIMEOUT', 30); // segundos
define('EAC_RETRY_ATTEMPTS', 3);
define('EAC_INSTITUTION_ID', 'cifp_carlos_iii');
Gestión de errores en el LMS:
Si Backend EAC retorna error:
- 401 Unauthorized → API Key inválida → Contactar operador
- 429 Too Many Requests → Rate limit excedido → Reintentar en 30 min
- 503 Service Unavailable → Servicio temporalmente no disponible → Cola local
- 422 Unprocessable Entity → Datos malformados → Validar submission
Si timeout (>30s):
- Guardar submission en cola local
- Mostrar al estudiante: "Evaluación en proceso, recibirás resultado pronto"
- Reintentar en background cada 5 minutos
Función: Preparar datos antes de enviarlos al servicio central, eliminando PII.
⚠️ Importante: Aunque el Backend EAC es centralizado, la seudonimización se hace en el centro antes de enviar datos.
Flujo:
Estudiante envía submission con datos personales
↓
Plugin Moodle captura submission
↓
Aggregator local (integrado en plugin):
1. Elimina nombre, email, ID real del estudiante
2. Genera hash irreversible: std_12345 → anon_abc123xyz
3. Remueve metadata sensible (IP address, ubicación exacta)
4. Generaliza edad (22 años → rango 21-25)
↓
Submission seudonimizada lista para enviar
↓
POST a Backend EAC central con datos limpios
Ejemplo de transformación:
// Antes de seudonimizar (local, nunca sale del centro)
{
"student_id": "std_12345",
"student_name": "María García López",
"student_email": "maria.garcia@cifp-carlos-iii.edu.es",
"submission": { ... },
"timestamp": "2026-02-20T10:35:42Z",
"ip_address": "192.168.1.50"
}
// Después de seudonimizar (enviado al servicio central)
{
"student_id_hash": "anon_sha256_abc123xyz",
"submission": { ... },
"timestamp": "2026-02-20T10:35:42Z",
"context": {
"institution": "cifp_carlos_iii",
"age_range": "21-25",
"program": "fp_comercio"
}
}
Ventaja: El Backend EAC central nunca ve datos personales, cumplimiento RGPD por diseño.
Función: Almacenar datos sensibles que NO se envían al servicio central.
Tablas principales:
-- Datos de estudiantes (PII protegido, nunca sale del centro)
CREATE TABLE students (
student_id UUID PRIMARY KEY,
full_name VARCHAR(255) NOT NULL,
email VARCHAR(255) UNIQUE NOT NULL,
enrollment_date DATE NOT NULL,
program VARCHAR(100),
age INTEGER,
consent_evaluation BOOLEAN DEFAULT TRUE,
consent_research BOOLEAN DEFAULT FALSE
);
-- Submissions originales (con PII, solo local)
CREATE TABLE submissions_raw (
submission_id UUID PRIMARY KEY,
student_id UUID REFERENCES students(student_id),
problem_id VARCHAR(100),
submission_data JSONB,
submitted_at TIMESTAMP DEFAULT NOW(),
ip_address INET
);
-- Resultados recibidos del servicio central (sin PII)
CREATE TABLE evaluation_results (
result_id UUID PRIMARY KEY,
submission_id UUID REFERENCES submissions_raw(submission_id),
student_id_hash VARCHAR(255), -- El hash que usó el servicio central
score DECIMAL(4,2),
feedback TEXT,
skill_assessment JSONB,
evaluated_at TIMESTAMP,
service_request_id VARCHAR(255) -- Para trazabilidad
);
-- Cola de reintentos (en caso de fallo temporal)
CREATE TABLE submission_queue (
queue_id UUID PRIMARY KEY,
submission_id UUID REFERENCES submissions_raw(submission_id),
retry_count INTEGER DEFAULT 0,
last_attempt TIMESTAMP,
next_retry TIMESTAMP,
error_message TEXT,
status VARCHAR(50) -- 'pending', 'processing', 'failed', 'completed'
);
Datos que PERMANECEN local (nunca al servicio central):
Datos que SÍ se envían (seudonimizados):
┌────────────────────────────────────────────────────────────┐
│ NODO CENTRO FP (Cliente Ligero) │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ LMS Moodle + Plugin EAC │ │
│ │ • Interfaz estudiante │ │
│ │ • Captura submissions │ │
│ │ • Muestra resultados │ │
│ └───────────────────┬──────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Aggregator/Anonymizer (integrado) │ │
│ │ • Elimina PII │ │
│ │ • Genera hashes │ │
│ │ • Prepara payload limpio │ │
│ └───────────────────┬──────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌──────────────────────────────────────────────┐ │
│ │ PostgreSQL (Base de Datos Local) │ │
│ │ • students (PII protegido) │ │
│ │ • submissions_raw (con PII) │ │
│ │ • evaluation_results (sin PII) │ │
│ │ • submission_queue (reintentos) │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ↓ HTTP POST (TLS 1.3) │
│ Authorization: Bearer API_KEY │
│ Body: Submission seudonimizada │
└────────────────────────┬───────────────────────────────────┘
│
│ Internet
↓
┌────────────────────────────────────────────────────────────┐
│ NODO CENTRAL COORDINADOR │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ FIWARE Dataspace Connector (API Gateway) │ │
│ │ • Valida API Key │ │
│ │ • Verifica políticas (Authzforce) │ │
│ │ • Rate limiting por centro │ │
│ │ • Auditoría completa │ │
│ └───────────────────┬──────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Backend EAC Central (Servicio PKST) │ │
│ │ • Rubric Evaluator │ │
│ │ • Recommendation Engine │ │
│ │ • Problem Generator (LLM) │ │
│ │ • Student Model Manager │ │
│ └───────────────────┬──────────────────────────┘ │
│ │ │
│ ↓ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Orion-LD Hub (Context Broker) │ │
│ │ • Agrega skills mastery de todos │ │
│ │ • Publica entidades NGSI-LD │ │
│ │ • Notifica a suscriptores │ │
│ └──────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────┘
1. Estudiante presenta StudentCredential al sistema
[ZONA 1 → ZONA 3: VC Verifier]
2. Sistema valida VC y genera sesión autenticada
[ZONA 3: VC Verifier → JWT Token]
3. Estudiante accede a LMS Moodle de su centro
[ZONA 1 → ZONA 4: LMS]
4. Selecciona actividad EAC en su curso
[ZONA 4: LMS - muestra aplicación LTI]
5. Estudiante resuelve y envía solución
[ZONA 4: App LTI captura submission]
6. Plugin Aggregator local seudonimiza datos
[ZONA 4: Aggregator elimina PII]
[Etiqueta: "Seudonimización local (RGPD)"]
7. App LTI envía POST al servicio central
[ZONA 4 → ZONA 3: HTTP POST con API Key]
[Etiqueta: "POST con submission seudonimizada"]
8. FIWARE Dataspace Connector valida request
[ZONA 3: Connector → Authzforce → Backend EAC]
[Etiqueta: "Validación API Key + políticas"]
9. Backend EAC central procesa evaluación
[ZONA 3: Backend EAC → Rubric Evaluator + Recommendation Engine]
10. Backend EAC actualiza Orion-LD con métricas agregadas
[ZONA 3: Backend EAC → Orion-LD Hub]
[Etiqueta: "Skills federados (agregados)"]
11. Backend EAC retorna resultado a la app LTI del centro
[ZONA 3 → ZONA 4: HTTP 200 + resultado JSON]
[Etiqueta: "Resultado + feedback personalizado"]
12. App LTI muestra resultado al estudiante
[ZONA 4: App LTI → Estudiante]
13. App LTI almacena resultado en BD local (vinculado a student_id real)
[ZONA 4: App LTI → PostgreSQL local]
[Datos: vincula resultado con PII local para uso del docente]
Datos en tránsito:
Ya NO hay flujo separado de "federación de datos agregados" desde el centro.
En su lugar:
Backend EAC Central procesa evaluación
↓
Actualiza directamente métricas en Orion-LD Hub
(todo ocurre dentro del ZONA 3 - Nodo Central)
↓
Otras entidades (investigadores, otros centros) consultan Orion-LD
[ZONA 3: Orion-LD → Consumidores]
Ventaja: Simplificación radical del flujo de federación.
1. Docente presenta TeacherCredential
[ZONA 1 → ZONA 3: VC Verifier]
2. Busca "Backend EAC" en Marketplace
[ZONA 1 → ZONA 3: Marketplace]
[Etiqueta: "Busca servicio EAC centralizado"]
3. Marketplace muestra servicio con metadata Gaia-X
[ZONA 3: Marketplace consulta Self-Descriptions]
[Detalle: "Backend EAC v1.2.3 - Servicio Central"]
4. Docente revisa:
- Endpoint: https://eac-central.vfds.org/api/v2
- SLA: 99.5% uptime
- Capacidad: 10k eval/hora (compartida)
- Pricing: Free (pilot phase)
- Reviews: 4.7/5 estrellas
5. Docente solicita acceso
[ZONA 1 → ZONA 3: Marketplace]
[Etiqueta: "Solicita acceso con TeacherCredential"]
6. Sistema verifica con Policy Engine
[ZONA 3: Marketplace → Authzforce PDP]
7. Operador aprueba (manual o automático)
[ZONA 3: Operador Dataspace]
8. Sistema provisiona:
- API Key: sk_cifp_carlos_iii_prod_abc123xyz
- Política en Authzforce (rate limit 500 req/h)
- Contrato ODRL (vigencia 2025-2026)
[ZONA 3: Sistema central]
9. Docente recibe API Key por email
[ZONA 3 → ZONA 1]
10. Docente configura API Key en Moodle
[ZONA 1 → ZONA 4: Configuración LMS]
11. Estudiantes del centro pueden usar el servicio
[ZONA 1 → ZONA 4 → ZONA 3: Flujo normal de evaluación]
Ya NO es "cada centro publica su Backend EAC".
En su lugar:
1. Nodo Central decide publicar el servicio Backend EAC
[ZONA 3: Operador Dataspace]
2. Genera Self-Description Gaia-X del servicio
[ZONA 3: proceso interno del nodo central]
3. Envía Self-Description a Gaia-X Compliance Service
[ZONA 3: interno → Gaia-X Trust Framework]
[Etiqueta: "Valida compliance del servicio"]
4. Compliance Service valida y emite certificado ⭐
[ZONA 3: Gaia-X Trust Framework]
5. Self-Description registrada
[ZONA 3: Self-Descriptions Registry]
6. Servicio publicado en Marketplace
[ZONA 3: Marketplace/CKAN]
[Visible para todos los docentes del VFDS]
7. Centros FP pueden descubrirlo y solicitarlo
[ZONA 1 → ZONA 3: flujo de descubrimiento]
Nota: Aunque el Connector está solo en el nodo central, sigue cumpliendo estándares Gaia-X.
Riesgo: Si el Backend EAC central cae, todos los centros se ven afectados.
Mitigación:
Riesgo: 10,000 eval/hora puede no ser suficiente en picos de uso.
Mitigación:
Riesgo: Centralizar procesamiento podría exponer datos sensibles.
Mitigación:
Riesgo: Centros dependen del proveedor del servicio central.
Mitigación:
Nodo Central:
Centro Piloto 1 (IES Carlos III):
Métricas de éxito:
Nodo Central:
Centros Adicionales:
Métricas de éxito:
Métricas de éxito:
[Sin cambios respecto a v2.0]
[Sin cambios respecto a v2.0]
Respuesta: Después de analizar las capacidades técnicas de los centros FP participantes, se decidió que un modelo centralizado reduce barreras de entrada y costes operativos. Los centros más pequeños pueden participar sin necesidad de infraestructura compleja.
Respuesta: Solo datos seudonimizados. El PII (nombre, email, ID real) NUNCA sale del centro. La seudonimización se hace localmente antes de enviar cualquier dato al servicio central.
Respuesta: El LMS del centro guarda las submissions en una cola local y reintenta automáticamente. En el peor caso, el docente puede evaluar manualmente hasta que el servicio se recupere. El SLA es 99.5% (máximo 3.6h downtime/mes).
Respuesta: Rate limiting por centro (500 requests/hora por defecto). Si un centro necesita más capacidad, puede solicitarlo al operador.
Respuesta: En el futuro (v3.0), se planea permitir nodos híbridos donde centros con capacidad técnica puedan operar su propia instancia y federarla con el servicio central.
Respuesta: Sí. Aunque no es IDS bilateral completo (peer-to-peer), sigue cumpliendo Gaia-X mediante el uso del Dataspace Connector como API Gateway, Self-Descriptions del servicio, y políticas ODRL aplicadas.
Versión: 2.1
Fecha: Febrero 2026
Cambio principal: FIWARE Dataspace Connector ubicado únicamente en el Nodo Central
Autores: Equipo VFDS-EAC
Licencia: Documentación bajo CC BY 4.0