01 · Autenticación & JWT
Los ocho endpoints corren sobre HTTPS con autenticación por token JWT Bearer. Cada parte emite y
valida su propio token: tu institución emite el token con el que la PUI te invoca; la PUI emite
el token con el que tú consumes sus endpoints.
Login hacia tu sistema — POST /login
{
"usuario": "PUI",
"clave": "<cadena alfanumérica de 16-20 chars>"
}
Respuesta esperada:
{
"token": "eyJhbGciOi...",
"expiracion": "2026-04-18T15:30:00Z"
}
Reglas del token
- Expiración obligatoria y no reutilizable (sin refresh tokens de larga duración).
- Vigencia recomendada: 1 hora. Renovación proactiva al 80% del TTL.
- MFA obligatorio en accesos administrativos a consolas o paneles de operación.
- Validación por endpoint, método HTTP y recurso; 401 / 403 sin exponer detalles internos.
Consulta PUI → tu institución: la PUI primero llama /login, obtiene token y recién después invoca /activar-reporte. Modela el flujo completo en tus pruebas, no sólo el endpoint de negocio.
02 · Las 3 fases de búsqueda
Un mismo endpoint de respuesta — /notificar-coincidencia — opera en tres modos
discriminados por el campo fase_busqueda.
| Fase | Alcance | Disparo | Campos extra |
Fase 1 Datos básicos | Valores más recientes de la CURP | Al recibir /activar-reporte | Un único registro si hay al menos un dato |
Fase 2 Histórica | Registros desde la fecha de desaparición (máx 12 años) | Tras fase 1, una sola vez | tipo_evento, fecha_evento, direccion_evento |
Fase 3 Continua | Registros nuevos o modificados | Siempre, hasta /desactivar-reporte | tipo_evento, fecha_evento, direccion_evento |
Gap 02 / Gap 03: el manual dice «lo antes posible» (fase 1) y «a criterio de la institución» (fase 3). No hay SLA ni frecuencia mínima obligatoria. Documenta tu política.
03 · Estructura de datos
Entrada — POST /activar-reporte
Campos obligatorios: id (FUB + UUID4), curp, lugar_nacimiento (Anexo 3). Todo lo demás es opcional y, si existe, debe respetar el contrato de tipos del manual.
{
"id": "FUB-001-abcd1234-...",
"curp": "XXXX800101HDFNNN00",
"lugar_nacimiento": "DIF",
"nombre": "...", "primer_apellido": "...",
"fecha_nacimiento": "1980-01-01",
"fecha_desaparicion": "2024-11-10",
"sexo_asignado": "M",
"telefono": "...", "correo": "...",
"direccion": { "calle": "...", "numero": "...",
"colonia": "...", "cp": "...", "municipio": "...",
"entidad": "DIF" }
}
Salida — POST /notificar-coincidencia
Siempre envía: id, curp, institucion_id, fase_busqueda, lugar_nacimiento. Incluye opcionales cuando existan. Fases 2 y 3 exigen datos de evento.
Encoding: UTF-8 en todo el tránsito. Raw-JSON, sin XML y sin multipart. No hay excepciones.
04 · Biométricos
Fotos
- Resolución mínima ≥ 300 ppi, peso máximo ≤ 240 KB.
- Formatos png / jpg / bmp (declarados en
formato_fotos).
- Array de strings
base64 cifradas con AES-256-GCM.
- Clave entregada al Enlace Técnico PUI; nunca publicada en repositorios.
Huellas
- Resolución ≥ 500 ppi, grises de 8 bits, típicamente WSQ (
formato_huellas).
- Objeto JSON con etiquetas del Anexo 2:
rone, rtwo, ..., lpalm.
- Mismo esquema de cifrado que fotos. La PUI no almacena biométricos permanentemente.
Gap 05: no hay protocolo publicado para rotar la clave biométrica ni para actuar en caso de compromiso. Trátala como secreto rotable y mantén un runbook interno.
05 · Ciberseguridad (Sección 11 del Manual)
El manual adopta explícitamente OWASP API Security Top 10, OWASP ASVS, NIST SP 800-53 y NIST SP 800-115.
| Dominio | Requisito |
| Autenticación | JWT no reutilizable, MFA admin, expiración obligatoria. |
| Cifrado | TLS 1.2+, HSTS, biométricos AES-256-GCM. |
| Validación | Regex por tipo/longitud/formato; rechazo de payloads inesperados. |
| Anti-abuso | Rate limiting por IP/usuario/token, detección de enumeración, 429. |
| Exposición mínima | Sólo métodos necesarios; sin stacktraces ni banners; CORS cerrado. |
| Respuestas | Sin tokens, contraseñas o PII innecesaria; logs sin datos sensibles. |
SAST · DAST · SCA: los tres reportes son obligatorios antes de pasar a productivo. Cero vulnerabilidades críticas/altas/medias/bajas. Los reportes deben venir firmados por la herramienta (no manuales) o la ATDT regresa el trámite.
06 · Códigos HTTP esperados
| Código | Significado | Contexto |
| 200 | Éxito | /login, /activar-reporte, /busqueda-finalizada |
| 300 | Coincidencias múltiples | /notificar-coincidencia con más de una persona |
| 400 | Solicitud incorrecta / payload inválido | Todos los endpoints |
| 401 | Token inválido o expirado | Todos los endpoints protegidos |
| 403 | Credenciales inválidas | /login (PUI) |
| 429 | Too Many Requests — rate limit | Todos los endpoints |
| 500 | Error interno del servidor | Todos los endpoints |
| 504 | Timeout del servidor | Endpoints de largo procesamiento |
Gap 08: el manual define el código 300 pero no describe cómo se resuelven los casos de coincidencias múltiples ni qué información adicional enviar.
07 · Infraestructura mínima
El Anexo 1 es referencial; en la práctica, para pasar SAST/DAST/SCA la institución debe tener en pie al menos lo siguiente:
| Componente | Descripción |
| IP pública fija | IPv4 registrada en el portal; ACL contra origen PUI. |
| URL del webhook | <URL_BASE> única; endpoints se concatenan directamente. |
| Certificado TLS 1.2+ | Emitido por CA reconocida. Deshabilitar TLS 1.0/1.1 y SSL 2/3. |
| Base de datos interna | Relacional o NoSQL; indexable por CURP; consulta 100% interna. |
| Ambientes QA & Productivo | Credenciales, IPs y certificados distintos. |
| Resincronización | Cola o buffer para reintentar cuando el webhook está caído. |
| Trazabilidad local | Log por caso (id, fase, timestamp, resultado). |
| Motor de fase 3 | Scheduler configurable (1 h / 4 h / diario). |
| Stack | Java, .NET, Node.js o Python sobre Linux on-premise, nube pública, privada o híbrida. |
08 · Marco legal, autoridad supervisora y sanciones
Obligación. Art. 12 Bis fracción V de la
Ley General en Materia de Desaparición Forzada de Personas (LGMDFP).
Aplica a los 11 sectores de sujetos obligados (financiero, telecom, transporte, salud, educación, aviación, migración, seguridad pública, entre otros).
Emisión regulatoria.
Autoridad.
- Rectoría técnica (no vinculante): Agencia de Transformación Digital y Telecomunicaciones (ATDT).
- Supervisión y sanción: SEGOB vía RENAPO (Comisión Nacional de Búsqueda / Registro Nacional de Población).
- Reguladores sectoriales: CNBV (banca y valores), IFT (telecom), COFEPRIS (salud), SCT (transporte), INM (migración), etc. Ejercen supervisión complementaria en su sector.
Sanciones — Art. 43 Bis LGMDFP: el incumplimiento de la obligación de conectarse al PUI se sanciona con multa de 10 000 a 20 000 UMAs (aprox. $1.1 M a $2.3 M MXN a UMA 2026) impuesta por SEGOB, independientemente de las observaciones o sanciones adicionales que impongan los supervisores sectoriales.
Criterio CNBV sobre secreto bancario (oficio VSGIF-B-140-053-2026, 31/mar/2026, aplicable únicamente a entidades supervisadas por la CNBV): la interconexión con la PUI no vulnera las obligaciones de secrecía bancaria, no implica transferencia de datos ni acceso directo a información financiera, y opera bajo esquema de coincidencias con cifrado, autenticación, monitoreo y trazabilidad.
Conclusión: la adhesión a la PUI es un requerimiento de autoridad en términos del Art. 12 Bis V y no requiere autorización expresa del titular del dato. No cumplir activa el Art. 43 Bis y, para entidades reguladas, abre observaciones ante el supervisor sectorial.