Skip to main content

El Grupo de Análisis Técnico avanza hacia un modelo preliminar

Tsg advances draft model 1349x769 21feb19 es

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.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."