Resumen

  • La Política de Datos de Registro incorporó el 12 de mayo de 2026 un acuse en dos horas, una respuesta en 24 horas y una extensión excepcional limitada a 72 horas para solicitudes urgentes autenticadas.
  • La propia política dice que las obligaciones de la sección 10.7 solo entrarán en vigor cuando ICANN implemente por completo una Política de Consenso que establezca la autenticación del solicitante.
  • El grupo sobre autenticación aporta requisitos técnicos y operativos a una prueba de concepto. No elabora política y sus hitos públicos no equivalen a la fecha de vigencia.
  • Autenticar confirma atributos acotados del solicitante. No demuestra urgencia, legalidad, necesidad ni derecho a divulgar. Un recibo de activación debe conservar esa separación.

La regla escrita

La Política de Datos de Registro reserva la vía urgente para un conjunto restringido de situaciones. La solicitud debe proceder de un Solicitante Autenticado y referirse a una amenaza inminente para la vida, lesión corporal grave, infraestructura crítica o explotación infantil, en circunstancias en las que divulgar los datos resulte necesario para combatir o atender la amenaza.

La sección 10.7 organiza el trámite. El solicitante autentificado declara que se encuentra ante una de esas circunstancias. El registrador y el operador de registro deben acusar recibo en un máximo de dos horas. Deben responder sin demora indebida y, salvo excepción, dentro de las 24 horas. Si necesitan más tiempo, deben comunicarlo dentro de esas mismas 24 horas, explicar el motivo y fijar una respuesta que no supere las 72 horas desde la recepción.

La excepción también tiene límites. Una causa de fuerza mayor o la complejidad de una petición que incluya muchos dominios puede justificarla. Los días festivos, las vacaciones previstas o un viaje planificado no. La política, por tanto, no se limita a pedir rapidez: define eventos y plazos que pueden auditarse.

El anuncio de ICANN del 12 de mayo explica la razón material. En estos supuestos, el tiempo puede afectar a la seguridad de una persona o de una infraestructura. La previsibilidad del canal importa. Sin embargo, el mismo anuncio advierte que el lenguaje no entrará en vigor hasta que exista un mecanismo de autenticación de las fuerzas del orden.

La condición que aún no se ha cumplido

La nota de implementación es más precisa: las obligaciones de la sección 10.7 serán efectivas en la fecha en que ICANN haya implementado plenamente una Política de Consenso que establezca un proceso para autenticar al solicitante. No basta con que exista una idea, un prototipo o un proveedor capaz de verificar identidades. La condición combina una fuente de autoridad —la Política de Consenso— y un estado de ejecución —su implementación completa—.

La política general sí está en vigor desde el 21 de agosto de 2025. El aplazamiento no afecta a todo el documento, sino a las obligaciones urgentes añadidas después. Esta precisión evita dos errores simétricos: afirmar que la política completa está suspendida o afirmar que la sección 10.7 ya es exigible solo porque aparece en la página oficial.

El estado de los consejos del GAC muestra cómo pueden coexistir varios cierres. La Junta cerró el elemento de asesoramiento que pedía un plazo porque el texto de 24 horas ya había sido publicado. En esa misma anotación señaló que la ejecución seguía pendiente del mecanismo de autenticación. Terminar la tarea de redactar el reloj no significa haber conectado su energía.

La diferencia tiene consecuencias prácticas. ¿Desde qué fecha puede Cumplimiento Contractual medir una infracción? ¿Qué solicitantes están dentro del conjunto protegido? ¿Qué canal constituye recepción? ¿Cuenta una petición enviada directamente a un registrador o solo la que pasa por RDRS? ¿Qué sucede con una solicitud que llega un minuto antes del cambio de estado? Una norma temporal sin un evento temporal de activación crea respuestas incompatibles aun cuando todos citen el mismo texto.

La prueba de concepto no puede suplir a la política

ICANN ha reunido al Input Group: Law Enforcement Agency Authentication Mechanisms. Su cometido es ayudar a diseñar una prueba de concepto que autentique a agentes que presenten solicitudes mediante RDRS o un sistema sucesor. El calendario prevé mostrar cambios de interfaz en octubre de 2026, iniciar pruebas en diciembre y publicar hallazgos en marzo de 2027.

Los hitos permiten evaluar el avance, no la vigencia. La página del grupo dice expresamente que no es un órgano de desarrollo de políticas. La convocatoria de participantes enumera cuestiones técnicas: integración con RDRS, atributos usados para validar al agente, flujo operativo, seguridad, privacidad, minimización, transparencia, auditoría, registros y facilidad de uso.

Un prototipo puede probar que dos sistemas intercambian una afirmación firmada. Puede medir la latencia de revocación o detectar que un atributo revela más de lo necesario. Puede demostrar que un solicitante cambia de proveedor sin rehacer toda su identidad. Lo que no puede hacer es atribuirse la autoridad normativa que la nota de implementación exige.

En paralelo trabaja el equipo de recomendaciones suplementarias de la GNSO sobre el futuro sistema estandarizado de acceso y divulgación. La coordinación entre ambos frentes es sensata: las decisiones técnicas pueden revelar decisiones de política. Pero la coordinación no fusiona mandatos. El grupo de prueba aporta evidencia; el proceso competente decide la regla.

Identidad, urgencia y divulgación son tres decisiones

La autenticación es valiosa porque reduce trabajo repetido. Un registrador debería poder saber que una credencial fue emitida por una autoridad aceptada, que sigue vigente y que quien la presenta está autorizado para utilizarla. En una emergencia, ahorrar ese tiempo es una mejora real.

El valor desaparece si la credencial empieza a responder preguntas que no le pertenecen. La identidad del solicitante no demuestra por sí sola que exista una amenaza inminente. La pertenencia a una agencia no establece jurisdicción sobre un dominio. Una calidad institucional no prueba la base jurídica, la proporcionalidad o la necesidad de cada campo solicitado. Tampoco convierte la entrega de datos en el único resultado posible.

La política conserva estas capas. El solicitante formula una declaración específica de urgencia. La parte contratada analiza la petición y el derecho aplicable. Puede divulgar, divulgar en parte o denegar con motivación. La sección 10.8 permite reaccionar frente a solicitudes abusivas. Una respuesta puntual no equivale necesariamente a una divulgación; un rechazo motivado también es una respuesta.

La arquitectura común debe ser deliberadamente delgada. Una federación de identidad confirma el atributo mínimo y su nivel de garantía. Mantiene revocación, registro y corrección. Después, devuelve la decisión al registrador u operador de registro que conserva la responsabilidad contractual y jurídica. Si el mismo centro autentica, califica la urgencia y ordena la entrega, la coordinación técnica se convierte en un tribunal global de facto sin el mandato necesario.

Una carta que delimita quién puede decidir

La respuesta de Kurt Erik Lindqvist al Gobierno de India, fechada el 11 de agosto, confirma el punto operativo: la política contiene el plazo, pero su cumplimiento depende del mecanismo de autenticación. La carta remite al trabajo con el Public Safety Working Group del GAC, representantes policiales y el nuevo grupo técnico.

También responde a propuestas sobre verificación en quince días y obligaciones adicionales de información. El director ejecutivo señala que cualquier deber nuevo para registros y registradores debe pasar por el proceso de política o contractual apropiado. La GNSO desarrolla la política gTLD y administra el PDP. ICANN org puede apoyar e implementar lo adoptado; el director ejecutivo no puede ordenar las prioridades de la GNSO ni decidir el resultado.

La secuencia protege la legitimidad de la obligación. Un gobierno plantea una necesidad. El GAC asesora. La comunidad y la GNSO desarrollan política dentro de su ámbito. La Junta actúa conforme a los Estatutos. ICANN org implementa. Las partes contratadas responden. Un grupo técnico puede acelerar la comprensión, no apropiarse de la cadena.

Qué debe probar un recibo de activación

Daniel Kade propone publicar un registro compacto cuando cambie el estado de la sección 10.7. No sería una base de datos de agentes ni una nueva condición de divulgación. Serviría para que un tercero compruebe que la dependencia descrita en la política se satisfizo de manera autorizada.

El recibo debería identificar la versión y la huella exacta de la política, la Política de Consenso que establece la autenticación, el acto que completa su implementación, la autoridad responsable, la fecha, hora y zona de vigencia, y la fuente canónica. Debería enumerar las clases de solicitante cubiertas, la versión del perfil de garantía, el significado de los atributos, la señal de revocación y los puntos de entrada aceptados.

También debe definir el momento de recepción. Una marca de tiempo generada por RDRS puede diferir de la llegada al sistema del registrador. Un reintento puede crear dos expedientes. Una caída puede desviar la solicitud a un canal directo. El recibo debe indicar qué evento inicia las dos horas y las 24, cómo se deduplican envíos y cómo se tratan los casos en curso durante la transición.

La declaración negativa es indispensable: la credencial prueba solo los atributos expresados. No prueba urgencia, competencia, base jurídica, necesidad, proporcionalidad ni derecho a la divulgación. El registro público no debe revelar identidades individuales, investigaciones, dominios objetivo ni datos de registro no públicos.

La métrica correcta es el trámite, no la cantidad de datos entregados

El informe SAC122 recomendó publicar agregados sobre cantidad de solicitudes, velocidad, solicitudes inválidas o no urgentes y cumplimiento temporal. Parte de sus detalles fue superada por el texto final, pero su enfoque ayuda a evitar una métrica peligrosa.

Tras la activación deben contarse las solicitudes autenticadas recibidas por un canal válido. Hay que separar errores de credencial, fallos de formato, reclasificación como no urgente, solicitudes de información adicional, denegaciones jurídicas, divulgaciones parciales, extensiones y fallos del sistema. Los tiempos del acuse, la respuesta y la resolución final son diferentes.

Una tasa alta de divulgación no demuestra calidad. Puede indicar solicitudes bien construidas o un filtro demasiado débil. Una tasa baja no demuestra obstrucción. Puede reflejar jurisdicción, necesidad o abuso. La rendición de cuentas debe verificar que la decisión llegó a tiempo y fue explicable sin premiar la exposición de datos personales.

Límites de la evidencia

Las fuentes revisadas no fijan la fecha final de activación, el proveedor de identidad, el diseño de federación, el perfil de garantía, las reglas de transición ni el denominador de cumplimiento. No identifican la prueba de diciembre de 2026 como fecha de vigencia. Este artículo no afirma que antes de la activación sea imposible atender solicitudes urgentes por otros procedimientos lícitos. El recibo de activación y la autenticación delgada son propuestas analíticas de Daniel Kade.

Fuentes

  1. ICANN — Política de Datos de Registro
  2. ICANN — Anuncio sobre solicitudes urgentes
  3. ICANN — Grupo sobre mecanismos de autenticación
  4. ICANN — Convocatoria de participantes
  5. ICANN — Estado de los consejos del GAC
  6. ICANN — Carta a S. Krishnan
  7. SSAC — Resumen ejecutivo de SAC122
  8. ICANN — Resumen de trabajo de RDRS