A
AleluIA
Anexo · Etapa 2 · App Móvil CPCEMZA
← Volver a la cotización
Anexo técnico · Etapa 2 de 4

Etapa 2 — Fase 1 MVP

El corazón de la app: identidad verificada, credencial digital offline y notificaciones. Al cierre de esta etapa existe un build instalable en dispositivos reales.

DuraciónMes 2 (4 semanas)
Entregable claveBuild instalable
Depende deEtapa 1 aprobada
HabilitaEtapa 3 (módulos)
Objetivo

¿Qué logra esta etapa?

Construir el núcleo de la app: que un matriculado real pueda validar su identidad, activar el desbloqueo biométrico de su dispositivo y ver su credencial digital incluso sin conexión. Es la parte de mayor complejidad técnica y la que define la seguridad de todo el producto.

Actividades

  • Setup del proyecto: repositorio, CI, entornos (dev/staging/prod) y arquitectura de la app.
  • Validación de identidad: según el mecanismo que defina el Consejo — validación biométrica contra RENAPER vía proveedor especializado, o acceso con credenciales institucionales del Consejo + desbloqueo biométrico local (Face ID / huella). La decisión se toma en el kickoff.
  • Autenticación y biometría: Face ID / Touch ID con fallback a PIN, sesión segura y cierre forzado.
  • Credencial digital offline: almacenamiento cifrado local, vencimiento y revalidación periódica.
  • Módulo Matrícula: datos del matriculado, padrón y débito automático.
  • Notificaciones push: infraestructura de envío y 3 tipos (institucional, capacitaciones, pagos/trámites).
  • Dashboard inicial: resumen del matriculado con datos reales.
  • Primer build de prueba: instalación en iOS y Android físicos del equipo y del Consejo.

Entregables

  • App con login + validación de identidad funcionando end-to-end.
  • Credencial digital con QR, modo offline y compartir.
  • Push notifications operativas (3 tipos).
  • Dashboard con datos del matriculado.
  • Build instalable en dispositivos iOS y Android físicos.
  • Documentación técnica del núcleo (arquitectura, seguridad, flujos).
Criterio de aceptación: un matriculado de prueba completa el flujo completo — validar identidad, enrolar biometría y ver su credencial offline — en dispositivos físicos de ambas plataformas.
Seguridad

Principios de la etapa

Datos biométricos

Ningún dato biométrico ni credencial se almacena en el dispositivo. La app captura y transmite; la verificación ocurre en el backend. El proveedor de verificación (IDwall / Truora / Verifik), si se opta por validación con RENAPER, es a decisión de Gerencia del Consejo.

Offline seguro

La credencial se cachea cifrada en el dispositivo con vencimiento y revalidación periódica contra el servidor. Si el dispositivo se pierde, la credencial caduca sola y puede revocarse remotamente.

Dependencia externa (opción RENAPER): si el Consejo opta por validación biométrica contra RENAPER, esta se realiza a través de un proveedor de verificación de identidad. La cuenta y el contrato del proveedor son a nombre del CPCEMZA; AleluIA integra el SDK y configura el flujo completo. Si se opta por credenciales institucionales + biometría local, no se requiere proveedor externo.
Definición pendiente

Dos caminos para la validación de identidad

El mecanismo de validación del matriculado se define en el kickoff con el Consejo. Ambos caminos están contemplados en esta etapa; la diferencia está en el nivel de seguridad del alta y en la necesidad de un proveedor externo.

Opción A · Validación con RENAPEROpción B · Credenciales + biometría local
Qué esAlta del matriculado con captura de DNI + prueba de vida (liveness), verificada contra RENAPER vía proveedor especializado.Login con las credenciales que el Consejo ya asigna a sus matriculados, más desbloqueo biométrico del dispositivo (Face ID / huella) para reingresar.
Seguridad del altaMáxima — certifica que el DNI pertenece a la persona que se registra.Estándar — depende de la vigencia de las credenciales del portal del Consejo.
Proveedor externoSí — proveedor de verificación de identidad (cuenta a nombre del CPCEMZA, por verificación).No — usa la infraestructura existente del Consejo.
Cuándo convieneSi el Consejo quiere que el alta sea 100% autoservicio y a prueba de suplantación.Si el Consejo prefiere validar altas manualmente (como hoy) y mantener la app simple.
Recomendación de AleluIA: arrancar con la Opción B (más simple, sin dependencias externas) y dejar la arquitectura preparada para incorporar la Opción A más adelante si el volumen de altas lo justifica. La decisión no afecta el plazo de esta etapa.

¿Avanzamos?

Aprobá el presupuesto o consultanos lo que necesites — respondemos el mismo día.

WhatsApp Web · +54 9 223 656-5296 · Diego Linares, AleluIA