Identity

Ámbito: Producto Tikin — Identity es hoy el auth de la app de Tikin, no un primitivo de plataforma; para tenants llega vía el portal (roadmap).

La relación empieza aquí. Identity es el dominio que responde "¿quién es esta persona?" a través de toda la plataforma: su perfil, sus sesiones y sus membresías — de qué cuentas es miembro y con qué rol.

Hoy

La identidad de los usuarios finales vive en la app de cada tenant: tu sistema autentica a tu gente y el API opera sobre cuentas con tu token de tenant. La noción de miembro ya existe en la plataforma — es la que decide las aprobaciones de doble firma y la que responde authority_insufficient cuando un rol no alcanza — pero todavía no se expone como recurso propio.

Lo que viene

Los endpoints de Identity llegan con el portal (roadmap):

• profile — el perfil de una persona, uno solo aunque toque varias cuentas.
• sessions — sus sesiones activas, para verlas y cerrarlas.
• memberships — sus membresías: en qué cuentas está y qué puede hacer en cada una.

Mientras tanto, todo lo que una integración necesita saber de una persona vive en su cuenta y su verificación.

Lo que sí es de la plataforma: el cumplimiento

Hay una parte de "quién es esta persona" que no es delegable y no espera al portal: verificar identidades, revisarlas contra listas y volver a revisarlas cuando el mundo cambia es trabajo de Tikin, para todo tenant y sin opción de apagarlo. Lo que una integración consume es el resultado —esta cuenta opera, esta quedó retenida, esta está bloqueada— y su efecto sobre el dinero.

Ese contrato de lectura, con los estados, qué hacer cuando una cuenta queda retenida y qué se puede reintentar, vive en verificación y cumplimiento. En el API su superficie hoy es el campo verification de una cuenta y el evento account.verified.