Recientemente, el Grupo de Análisis Técnico del Acceso a los Datos de Registración sin Carácter Público (TSG-RD) se reunió durante tres días en Washington D.C., donde llevó a cabo intensas conversaciones colaborativas para desarrollar una versión preliminar detallada del Modelo Técnico para Datos de Registración sin Carácter Público. Nueve de los diez miembros del equipo trabajaron junto a representantes de la organización de la ICANN para adaptar los requisitos necesarios para el modelo. También vimos cómo simplificar la experiencia de los usuarios del sistema y agregamos nuevos principios a nuestra carta orgánica. Estamos trabajando arduamente para compartir la versión preliminar del modelo con la comunidad de la ICANN antes de la reunión ICANN64 en Kobe.
Al iniciar nuestras conversaciones, acordamos los requisitos necesarios para la versión preliminar del modelo técnico, que se basará en el Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP). Luego analizamos si todos los requisitos se aplicarían a los dos protocolos de autenticación/ autorización que identificamos: uno basado en Open ID Connect/OAuth y el otro basado en autenticación mutua mediante Seguridad de la Capa de Transporte (TLS). Este ejercicio nos ayudó a determinar que una solución basada en Open ID Connect/OAuth cumple con todos los requisitos identificados. También determinamos que la autenticación mutua mediante TLS podría usarse en la comunicación entre la organización de la ICANN y sus partes contratadas. La solución de Open ID Connect/OAuth permite que los usuarios utilicen varias tecnologías; estamos considerando certificados digitales y de nombre de usuario/contraseña. Al analizar los requisitos, notamos que los proveedores de identidad –las entidades que autentican la identidad de los usuarios– deben aplicar al menos una de estas tecnologías cuando implementen Open ID Connect/OAuth y pueden optar por ambas. El rol del proveedor de identidad es clave para garantizar la integridad y fidelidad en un modelo de acceso unificado. Por tal motivo, invitamos a dos representantes de Europol a participar en una breve conversación sobre algunos de estos enfoques.
También tuvimos una sesión importante sobre la experiencia de los usuarios. Se consensuó diseñar un sistema que sea simple y práctico a la vez. Acordamos un orden de complejidad encabezado por la ICANN. Luego, le siguen las partes contratadas, los proveedores de identidad, los implementadores del cliente RDAP y los usuarios finales. Sobre la base del principio de simplicidad, separamos los componentes de autorización/autenticación de los componentes del flujo del RDAP.
Como resultado de este trabajo, creemos haber logrado un esquema preliminar para un modelo operativo. Debido a que los futuros desafíos en materia de políticas e interpretación de la ley pueden afectar la manera en que se implemente la versión preliminar del modelo técnico, agregamos nuevos principios a nuestra carta orgánica.
En las próximas semanas, los miembros del equipo trabajarán con representantes de la organización de la ICANN para continuar desarrollando la versión preliminar del modelo técnico y compartirla con la comunidad antes de la reunión en Kobe. Durante nuestro encuentro presencial, también analizamos la manera de presentar nuestro trabajo fuera la comunidad de la ICANN, lo cual incluye a la Comisión Europea. Una vez que hayamos concluido nuestra tarea en torno al modelo técnico después de la reunión en Kobe, le presentaremos nuestro informe al Presidente y Director Ejecutivo de la ICANN, Göran Marby.
Esperamos interiorizarlos con estas conversaciones durante la reunión ICANN64 y los invitamos a la sesión participativa que tenemos previsto llevar a cabo junto a la comunidad. La mayoría de los miembros de nuestro equipo estará en Kobe y espera tener la oportunidad de reunirse con ustedes. Si desean comunicarse con nosotros, no duden en escribirnos a gdpr@icann.org. Para más información sobre nuestro trabajo, los invito a visitar nuestra página en https://www.icann.org.