Audiencias de autenticación — operador, máquina, end-user

Una de las preguntas más frecuentes que llega al equipo es alguna variante de “¿el operador de un tenant también debería usar el wallet?”. La respuesta es a veces sí, a veces no, y la diferencia importa. Este documento fija las tres audiencias del ecosistema y qué mecanismo de autenticación usa cada una, con la lógica detrás.

Las tres audiencias

┌──────────────────────┬──────────────────────┬──────────────────────┐
│  END USER            │  OPERADOR            │  MÁQUINA             │
│  (Diego)             │  (Ana, sus empleados)│  (backend de Ana)    │
├──────────────────────┼──────────────────────┼──────────────────────┤
│  Persona real con    │  Humano que opera un │  Proceso server-side │
│  identidad propia    │  tenant (configura,  │  que llama APIs en   │
│  que vive su vida    │  audita, soporta)    │  nombre del tenant   │
├──────────────────────┼──────────────────────┼──────────────────────┤
│  Wallet SSI          │  Sign-in with bjungle│  X-API-Key con       │
│  + passkey           │  → wallet operador   │  scopes + rotation   │
│  + face MFA opcional │  con scope al tenant │  + IP allowlist      │
├──────────────────────┼──────────────────────┼──────────────────────┤
│  Identidad           │  Identidad           │  No es identidad —   │
│  AUTOSOBERANA        │  FEDERADA            │  es CREDENCIAL       │
│  El usuario decide.  │  El tenant le da     │  El tenant la genera │
│  bjungle nunca tiene │  acceso, le quita    │  y la rota cuando    │
│  la clave privada.   │  acceso, lo audita.  │  hace falta.         │
└──────────────────────┴──────────────────────┴──────────────────────┘

Cada audiencia tiene un modelo de propiedad distinto. Confundirlos lleva al patrón que vemos en SaaS legacy (todos usan “user + password”, desde el intern hasta el cron job), que termina siendo o demasiado restrictivo para los humanos o demasiado permisivo para los procesos.

Por qué no unificar todo en el wallet

La idea “todos usan SSI” suena elegante pero rompe el modelo:

El wallet no es para empleados

La identidad autosoberana asume que el dueño controla su identidad sin depender de la empresa. Un empleado de una fintech no es autosoberano respecto a su empleo: cuando renuncia o lo despiden, la empresa debe poder cortar su acceso instantáneamente. Eso es lo opuesto de SSI.

Caso por caso:

• End user: cumple los requisitos de SSI. El usuario tiene un wallet con passkey en su device, las claves nunca salen del Secure Enclave, los datos son suyos. Si bjungle desaparece, el wallet sigue funcionando (las VCs emitidas son verificables contra el did:web mientras el DNS exista).
• Operador: NO cumple SSI porque la organización debe poder revocar su acceso. Pero sí puede usar un wallet bjungle con scope al tenant — el operador tiene su propio passkey, el audit log identifica al humano, y la organización (el tenant) puede revocar individualmente.
• Máquina: no necesita identidad personal. Necesita una credencial que pruebe que es ese servicio. La API key con scopes + rotation + audit es el patrón estándar (AWS IAM Roles, GCP service accounts).

La matriz de decisión

Cuestión	End user	Operador	Máquina
¿Quién controla la identidad?	El usuario	El tenant	El tenant
¿Puede usar la misma identidad en múltiples tenants?	Sí (SSI)	No (scope al tenant)	No (scope al tenant)
¿Quién revoca acceso?	El propio usuario	El tenant (admin)	El tenant (admin)
¿Hay claves privadas en el device?	Sí (Secure Enclave)	Sí (Secure Enclave)	No (API key plaintext en server config)
¿Audit log identifica al actor?	Sí (wallet_id)	Sí (operator_id)	Sí (api_key_id)
¿Aplica step-up para acciones críticas?	Sí (otra passkey)	Sí (otra passkey o face)	No (la key es el factor único)
¿Rotation periódica obligatoria?	No (passkey es permanente)	No	Sí (90 días default)

Implicaciones para el ecosistema

Para el tenant-portal (hoy)

El login actual con X-API-Key + email mezcla dos audiencias. La API key es credencial de máquina, el email es para identificar al humano. Lo correcto es separarlos:

1. Cada operador (humano) entra al portal con “Sign in with bjungle” (ADR-003) — wallet propio, scope al tenant, audit individual.
2. La API key queda solo para máquinas: el backend del tenant que llama nuestras APIs server-to-server.

Esto requiere implementar multi-operator (ADR-005). El paso de transición mantiene el modo legacy “API key como login humano” disponible para tenants que aún no migraron, con warning en el portal.

Para el wallet PWA

Sigue siendo solo para end users. Cualquier intento de meter operadores ahí significa que estás resolviendo el problema equivocado — el operador necesita un wallet con scope al tenant, no un wallet personal.

Implementación: el wallet del operador es una segunda instalación del PWA (o de la app mobile) accediendo al endpoint /operator-portal/$tenant con su propio passkey enrolado. Comparte código con el PWA del end user pero la UI y los endpoints son diferentes.

Para el admin-console (staff bjungle)

Staff interno no usa wallet bjungle: usa OIDC corporate (Google Workspace) con MFA forzado. El motivo es el mismo que con los operadores (no es identidad autosoberana, es identidad de empleo) pero con el plus de que bjungle como empresa ya tiene una IdP corporativa que es el sistema autoritativo: quien deja la empresa pierde acceso en todos lados al desactivarlo en Google Workspace, no solo en bjungle.

Anti-patrones que esta separación previene

• Compartir API key entre humanos porque “es más fácil”. Audit log pierde el actor real. Migración: multi-operator (ADR-005).
• Pedirle a todo empleado un wallet bjungle personal para entrar al portal. Friction excesivo, confusión sobre quién controla los datos.
• Usar el wallet SSI del end user para auto-loguearse en admin-console porque “todos somos personas”. Confunde identidad personal con identidad de empleo.
• Tratar la API key como password humano con políticas de “complejidad mínima” y “rotación cada 60 días via formulario”. Las API keys de máquina son distintas: scope + rotation programática + IP allowlist.

Roadmap derivado

Este ADR habilita / requiere:

• ADR-003 · Sign-in with bjungle — el bridge OIDC que materializa “wallet del operador” sin reinventar OAuth.
• ADR-004 · Endurecimiento de API keys — scopes, rotation, audit, IP allowlist.
• ADR-005 · Multi-operator wallet — modelo de invitaciones, roles y revocación a nivel de tenant.
• ADR-006 · OIDC corporate para staff (pendiente).

Decisión

Aspecto	Decisión
Status	Accepted (2026-05-30)
Supersedes	n/a
Aplicable a	bmonkey, platform, bhawk, bseal — todos los módulos que tengan que autenticar requests
Re-evaluar	cuando consideremos federar identidad cross-organization (e.g. consortium banking)