Tenants e identidad

Darwin es multi-tenant por diseño. Esta página describe el modelo de identidad: qué es un tenant, cómo se ubican las organizaciones debajo, cómo se autentican los usuarios, y cómo los DIDs anclan todo on-chain.

La jerarquía

Tenant
 ├─ Organizaciones (múltiples)
 │   ├─ Miembros (usuarios)
 │   └─ Roles (Operator / Admin / Auditor / Compliance)
 ├─ Mapas de procesos (config: qué eventos, qué transformaciones)
 ├─ API keys (server-to-server)
 └─ contrato on-chain dedicado + DID

Tenant

Un tenant es el cliente comercial. Un tenant por relación de pago (cooperativa de alimentos, proveedor automotriz, marca textil, etc.). Cada tenant tiene:

• Un DID (Decentralized Identifier, W3C). El anclaje on-chain de la identidad del tenant.
• Un smart contract dedicado del tenant. Todos los eventos on-chain que pasan por este tenant están controlados por él.
• Un sub-árbol de configuración propio: definiciones del mapa de procesos, asset types, normativas de compliance habilitadas, branding.

Los tenants están aislados off-chain: los datos operativos (eventos crudos, fotos, documentos, registros de captura, PII) del Tenant A no son visibles para el Tenant B. La capa on-chain almacena hashes y referencias, diseñados para ser verificables sin exponer datos sensibles, ya que los payloads originales viven off-chain bajo control de acceso del tenant.

Organización

Dentro de un tenant, una organización es una entidad legal que participa en la cadena de valor: una cooperativa, un proveedor tier-2, un ensamblador tier-1, un distribuidor, un auditor. Múltiples organizaciones bajo un mismo tenant colaboran en una cadena de custodia compartida.

Cada organización tiene su propio DID. Los eventos de transferencia de custodia entre organizaciones están firmados por ambos DIDs y registrados on-chain.

Miembro (usuario)

Un usuario es una persona con credenciales. Pertenece a una o más organizaciones dentro de un tenant. Los usuarios tienen roles que determinan a qué partes de la API pueden acceder:

• Operator: captura eventos vía Captia (write-only sobre su org)
• Admin: gestiona mapas de procesos, organizaciones, miembros
• Auditor: read-only en todo el tenant
• Compliance: read + sign-off en paquetes regulatorios

Los roles mapean a scopes en el JWT. Ver Autenticación para el formato de transmisión.

Formatos de identidad

Tipo	Formato	Vida útil	Uso
JWT bearer	Bearer <jwt>	corta (1h típico, refresh disponible)	calls user-driven
API key	X-API-Key: <key>	larga, rotable	server-to-server
DID	did:web:<dominio> o did:ethr:<addr>	permanente (rotación = nuevo DID)	anclaje on-chain
SIWE	nonce de Sign-In with Ethereum	por sesión	login con wallet

Modelo de permisos

Los process-scope grants extienden el acceso por rol con least-privilege por proceso:

Ejemplo: un Operator en la cooperativa solo puede capturar eventos de wool_shearing; no puede capturar garment_assembly aunque el rol técnicamente lo permita en escritura. El grant está delimitado a los procesos que él opera.

Esto es la base para abrir una organización a múltiples colaboradores sin exponer el mapa de procesos completo. La semántica canónica de permisos está implementada a nivel de los contratos on-chain.

Whitelabel branding

Cada tenant puede personalizar su branding en sus interfaces operativas y portales públicos:

• Logo (light + dark)
• Paleta de colores (primary / secondary / acentos)
• Dominio propio (ej. passport.<tenant>.com)
• Idioma (es / en / fr / pt-BR / extensible)
• Anulaciones de copy

La elección de marca se aplica durante el aprovisionamiento del tenant y se propaga a Captia, Tracium y al visor de Fidenta.

Qué expone el dev portal

Este portal documenta las APIs REST y GraphQL que Darwin expone a integradores. Los flujos de aprovisionamiento de tenant son operaciones internas y no se exponen públicamente.