Firma electrónica simple interna

1. Objetivo

Capturar la firma electrónica simple del socio y conservarla vinculada a su expediente, de modo que los documentos que la organización emite —declaración jurada, ficha de ingreso, consentimientos— puedan acreditar que la persona expresó su voluntad en el momento del registro.

2. Alcance

Cubre desde que el sistema solicita la firma al socio hasta que queda almacenada y referenciada en el expediente.

No cubre:

• El consentimiento de datos personales y sensibles, que es materia de [[wiki/entities/dispensai/protocolos/ADM-005]].
• La firma de cierre de entrevista, que es materia de [[wiki/entities/dispensai/protocolos/ENT-004]] y queda en la tabla interviews, separada del expediente de admisión.
• La generación de los PDFs que incorporan la firma, que es materia de [[wiki/entities/dispensai/protocolos/DOC-001]] y [[wiki/entities/dispensai/protocolos/DOC-002]].
• La autenticación del socio en sesiones posteriores. Este protocolo cubre la firma una vez, en el ingreso.

3. Definiciones

Firma electrónica simple. La imagen o representación HTML de la rúbrica manuscrita del socio, capturada digitalmente en el momento del registro. No es firma electrónica avanzada; no está certificada por ningún prestador acreditado; no es sello de tiempo; no prueba autoría en el sentido de la Ley 19.799 sobre firma avanzada.

Firma de perfil. La imagen PNG de la firma manuscrita, subida a almacenamiento privado y referenciada en profiles.signature_url.

Firma HTML. La representación vectorial de la firma, almacenada en profiles.signature_html, usada para incrustar la firma en documentos generados.

Repositorio privado. El bucket R2 del tenant, bajo la ruta signatures/{userId}/. El acceso requiere credenciales de servicio; la URL pública es la referencia, no el contenido.

4. Roles y responsables

Rol	Responsabilidad
Solicitante (socio en estado pending)	Capturar su firma en la interfaz habilitada para ello
Admisión	Verificar que la firma quedó registrada antes de avanzar en el expediente
Responsable de datos	Velar por la custodia y el acceso restringido al repositorio de firmas
Administrador (admin)	Única persona autorizada a borrar la firma de un socio; debe dejar constancia del motivo

5. Disparador de inicio

El socio ingresa a la sección /pending-approval y el sistema detecta que su expediente no tiene firma registrada.

6. Requisitos previos

• El socio tiene una cuenta activa en el sistema y su approval_status es pending o pending_interview.
• El dispositivo del socio tiene interfaz táctil o puntero que permita capturar la firma.

7. Entradas

• Sesión autenticada del socio.
• Datos de la imagen de firma capturada (formato base64, convertida a PNG por el sistema).
• Datos de la firma HTML (representación vectorial alternativa).

8. Procedimiento paso a paso

1. Presentación del formulario de firma. El sistema muestra al socio la interfaz de captura de firma como parte del flujo de completitud del expediente en /pending-approval.
2. Captura de la firma. El socio dibuja su rúbrica en el campo habilitado. El sistema acepta dos representaciones: imagen PNG (firma de perfil) y representación HTML (firma vectorial).
3. Almacenamiento en repositorio privado. La imagen PNG se sube al bucket R2 del tenant bajo signatures/{userId}/signature-{timestamp}.png. El sistema escribe la URL de acceso en profiles.signature_url.
4. Registro de la representación HTML. La firma vectorial se escribe en profiles.signature_html.
5. Verificación por Admisión. Admisión comprueba, al revisar el expediente en /admin/usuarios/{id}, que los campos signature_url y signature_html no son nulos.
6. Custodia. La firma queda almacenada indefinidamente mientras el expediente está activo. Solo un administrador puede borrarla, mediante la operación adminClearUserSignature, que pone ambos campos en nulo.

9. Puntos de control

#	Control	Qué impide
C1	Solo el propio socio puede actualizar su firma (verificación user.id === userId)	Que un tercero suplante la firma
C2	Solo un administrador puede borrar la firma	Que el socio la elimine unilateralmente
C3	La URL de la firma queda en el expediente del socio	Que la firma exista pero no esté vinculada

10. Criterios de decisión

Firma registrada: profiles.signature_url no es nulo y apunta a un archivo accesible en el repositorio.

Firma ausente: profiles.signature_url es nulo. El expediente no tiene firma. Admisión no debe avanzar el estado hasta subsanar esto.

Firma borrada por admin: signature_url y signature_html son nulos como resultado de adminClearUserSignature. El socio deberá capturar su firma nuevamente en su próximo ingreso.

11. Excepciones y escalamiento

• Dispositivo sin capacidad de firma manuscrita. El socio puede completar la firma en una sesión posterior o en la sede social con asistencia de Admisión.
• Firma ilegible o inadecuada. Es un juicio humano de Admisión. El sistema no valida la calidad de la imagen. Admisión puede pedir una nueva captura usando adminClearUserSignature para que el sistema la solicite de nuevo.
• Fallo de subida al repositorio. La server action devuelve error explícito. El sistema no guarda una URL inválida si la subida falló.

12. Registros generados

Registro	Contenido
profiles.signature_url	URL de la imagen PNG en el repositorio privado
profiles.signature_html	Representación HTML de la firma

No se genera evento ISO específico al capturar la firma. Ver brecha B2 en §17.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Firmas registradas antes de primera dispensación	Socios con signature_url no nulo al momento de su primera dispensación ÷ total de socios con dispensación	100 %	Expediente vs. dispensations
Firmas borradas por admin	Operaciones adminClearUserSignature ejecutadas en un período	Seguimiento, sin meta	Log de operaciones admin

14. Riesgos y controles

Riesgo	Control	Tipo
Impugnación de documento por falta de firma	Verificación de signature_url no nulo antes de emitir documentos (C3)	Preventivo
Suplantación de firma	Verificación de identidad del usuario antes de la operación (C1)	Preventivo
Borrado no autorizado de la firma	Solo admin puede borrar (C2)	Preventivo
Firma ilegible aceptada sin revisión	Revisión humana de Admisión del expediente	Detectivo

15. Normativa y referencias

Norma	Referencia	Qué cubre en este protocolo
Ley 20.500	Requisitos de la persona incorporada	La organización debe poder acreditar quién se incorporó
Ley 21.719	Art. 13	La firma respalda la base contractual del tratamiento de datos del socio
Ley 21.719	Art. 14 quinquies	Medidas de seguridad sobre el repositorio que custodia la imagen de la firma
ISO 9001:2015	§8.5.1	Provisión controlada: el expediente debe estar completo antes de avanzar
ISO 27001:2022	A.5.34	Privacidad y protección de los datos del socio, incluida su firma

El cumplimiento de estas normas no está certificado por ninguna autoridad. Este protocolo declara qué controles ejecuta la organización, no que un tercero los haya auditado.

La firma es electrónica simple en los términos de la Ley 19.799. No es firma electrónica avanzada, no está certificada, y no prueba autoría con el estándar probatorio de esa figura. El sellado de documentos que la contienen es materia de [[wiki/entities/dispensai/protocolos/DOC-006]].

16. Anexos y formularios vinculados

• Consentimiento de datos personales y sensibles ([[wiki/entities/dispensai/protocolos/ADM-005]])
• Generación de ficha de ingreso ([[wiki/entities/dispensai/protocolos/DOC-001]])
• Generación de declaración jurada ([[wiki/entities/dispensai/protocolos/DOC-002]])
• Sellado criptográfico de documentos ([[wiki/entities/dispensai/protocolos/DOC-006]])

17. Implementación en el sistema

El protocolo está implementado en la captura y el almacenamiento de la firma. Los controles de acceso (solo el socio escribe, solo admin borra) están en el código. Lo que no hace el sistema es exigir que la firma exista para avanzar el expediente.

Elemento del protocolo	Dónde vive
Captura de firma PNG (paso 3)	app/actions/profile.ts:102 — updateProfileSignature; sube a R2 y escribe profiles.signature_url
Captura de firma HTML (paso 4)	app/actions/profile.ts:50 — updateSignature; escribe profiles.signature_html
Control de identidad del firmante (C1)	Verificación user.id === userId en updateProfileSignature antes de subir
Borrado exclusivo por admin (C2)	app/actions/profile.ts:155 — adminClearUserSignature; verifica rol admin antes de poner nulos
Columnas en el expediente (C3)	supabase/migrations/20240101000000_baseline_schema.sql:48-49 — signature_url text, signature_html text en profiles
Firma de entrevista (ENT-004, distinta)	supabase/migrations/20240101000000_baseline_schema.sql:475,477 — interviews.signature_url y interviews.signed_at, tabla separada

Brechas conocidas:

1. La firma no es precondición de ninguna operación del sistema. Las columnas signature_url y signature_html son nullable sin restricción. Ninguna server action, migración ni RLS impide aprobar, dispensar o emitir documentos si la firma está ausente. El control C3 (verificar que la URL no sea nula antes de avanzar) existe como convención de trabajo, no como barrera del sistema.
2. No existe evento ISO para la captura de firma. La tabla de tipos de evento (lib/iso-event-logger.ts) no incluye ningún tipo relacionado con firma en el perfil del socio. Si se necesita auditar si un socio firmó antes de una acción determinada, no hay rastro propio del acto; solo puede inferirse de la presencia de signature_url en el momento de la consulta, no del momento en que se capturó.

Lo que ejecuta la organización fuera del sistema: la revisión de legibilidad e idoneidad de la firma es un juicio humano de Admisión. El sistema almacena la imagen sin validar su calidad.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-28	Versión inicial. Redactada desde la corrida de evidencia 2026-08-28-ADM-resto. Dos brechas declaradas.	Admisión
1.1	2026-08-29	Verificación de evidencia completada. Columnas signature_url/signature_html confirmadas como nullable en 20240101000000_baseline_schema.sql:48-49. Ausencia de evento ISO confirmada desde lib/iso-event-logger.ts (ningún tipo de firma en el enum). Dos brechas declaradas sin cambios; ambas son reales. Protocolo ascendido a Vigente.	Inventario
1.2	2026-09-10	Corrección de numeración normativa: el deber de adoptar medidas de seguridad es el Art. 14 quinquies de la Ley 21.719, no el 14 ter (deber de información); verificado contra el texto oficial (BCN, idNorma 1209272).	Harness dispensai-protocolos