Resumen

  • El borrador activo de REGEXT permite expresar qué atributos de contacto RDAP fueron comprobados y añadir fecha, verificador, marco, método y clase de evidencia; casi todos esos datos son opcionales y ninguno concede una autorización universal de divulgación.
  • La operación debería conservar un recibo de audiencia y vigencia que documente qué se mostró, a quién, con qué finalidad y durante cuánto tiempo se considera útil. Es una propuesta editorial de Daniel Kade, no una obligación del borrador.

El dato no trae incorporado a su público

Pensemos en tres consultas sobre el mismo registro. La primera procede de un lector anónimo. La segunda, de un equipo de respuesta a abusos que se ha autenticado y ha declarado el motivo de la solicitud. La tercera, de una autoridad competente que actúa bajo una base jurídica específica. En la base del registrador existe una sola comprobación de correo electrónico, pero no por ello las tres respuestas tienen que ser idénticas.

La verificación describe un hecho sobre el proceso. La divulgación es una decisión sobre el destinatario. La confianza que un tercero deposita en el resultado constituye una tercera decisión. Cuando un sistema mezcla las tres, una observación limitada —por ejemplo, que se pulsó un enlace el día del alta— se transforma en una afirmación general sobre la persona.

Este error no requiere mala fe. Basta con que una plataforma consuma un objeto rico y muestre una marca verde. La siguiente plataforma exporta la marca, pero no el atributo comprobado. Otra conserva el atributo, pero pierde la fecha. Al final, «correo alcanzable en marzo» se ha convertido en «titular verificado» sin que nadie haya aprobado esa ampliación semántica.

Un borrador activo, no una norma aprobada

La revisión 04 de Registration Data Access Protocol (RDAP) Extension for Verified Contact Information está fechada el 24 de agosto de 2026. El Datatracker de la IETF la muestra como Internet-Draft activo en el entorno de REGEXT, «Candidate for WG Adoption», con estado IESG «I-D Exists». No tiene respaldo formal de la IETF ni ha completado el proceso de estandarización. La cabecera señala Standards Track como destino pretendido, algo distinto de haber alcanzado ese destino.

Su propuesta consiste en un arreglo verifiedContacts_data dentro de objetos de entidad RDAP. Cada elemento puede señalar los atributos comprobados, como correo, teléfono, fax, dirección, nombre o fecha de nacimiento. También puede incluir fecha, identidad del verificador, identificador de la operación, marco de confianza, método, evidencia, observaciones y extensiones.

El uso de un arreglo permite representar verificaciones independientes. El nombre pudo cotejarse con un documento, mientras que el correo se confirmó por un enlace y la dirección se comparó con una base de datos. Cada operación puede tener fecha, actor y alcance distintos. Reducirlas a una propiedad general del contacto anula precisamente la expresividad que aporta el modelo.

Además, los campos centrales son opcionales. Esto obliga a tratar la ausencia como ausencia, no como confirmación implícita. Si no aparece verificationDate, la propia revisión 04 advierte que ello no significa que la comprobación esté vigente. Si sí aparece, indica cuándo terminó el proceso; no establece automáticamente su caducidad. Un operador tiene que decidir cuánto dura la utilidad del resultado para cada caso de uso y qué cambios fuerzan una nueva comprobación.

Método, evidencia y conclusión admisible

El borrador separa el método de la evidencia. Una comprobación de alcance o reachability exige una respuesta activa: introducir un código, pulsar un enlace o confirmar la recepción por otro mecanismo apropiado. Las demás opciones abarcan controles documentales, consultas de registros, validaciones criptográficas, autenticación electrónica, tokens, preguntas de conocimiento y comparaciones físicas o biométricas.

Las evidencias posibles incluyen documentos de identidad y viaje, permisos de residencia, extractos bancarios o de suministros, registros fiscales o de nacimiento, atestaciones y bitácoras de verificación por correo electrónico o postal. El mismo documento puede examinarse con métodos diferentes, y un método puede aplicarse a fuentes distintas. La conclusión depende del conjunto, no de una etiqueta aislada.

Un buzón alcanzable demuestra que se completó una interacción con ese canal en un momento. No demuestra necesariamente identidad. Una identidad contrastada no demuestra representación societaria. La representación tampoco prueba control actual del recurso de Internet. Y ninguna de estas comprobaciones garantiza que todos los campos del registro sean completos.

Esta cadena de negativas no resta valor a la verificación. La vuelve utilizable. Un equipo de abusos puede considerar suficiente una señal reciente de alcance para priorizar una comunicación. Un proceso de transferencia puede exigir pruebas diferentes. La disciplina consiste en ajustar la decisión al alcance real de la evidencia.

Una política privada sigue necesitando nombre y versión

El campo trustFramework es ampliable. El texto propone, entre otros, eidas y private. En el segundo caso, la comprobación responde a la política del operador y no a un marco externo registrado. Esto no significa que el resultado sea inútil. Significa que no puede interpretarse de forma responsable sin conocer la política aplicable.

Guardar únicamente la palabra private se parece a citar un reglamento sin indicar su edición. Los requisitos pueden haber cambiado: qué documentos acepta el operador, cuánto dura una comprobación, quién puede ejecutarla o qué excepciones contempla. Un consumidor necesita un identificador de política estable y una versión o huella que permita reconstruir el significado que regía cuando se tomó la decisión.

El mismo principio sirve para un marco externo. Su nombre no sustituye el nivel concreto, la jurisdicción aplicable ni el atributo que efectivamente fue verificado. La interoperabilidad no consiste en fingir que todas las etiquetas dicen lo mismo, sino en conservar información suficiente para comparar resultados distintos.

Los metadatos también pueden revelar demasiado

Proteger el documento subyacente no resuelve toda la privacidad. Saber que se usó un pasaporte, un permiso de residencia, un registro fiscal o una comparación biométrica ya describe el itinerario de identificación de una persona. Para un solicitante autorizado puede ser información necesaria; para un lector anónimo puede ser una revelación excesiva.

La sección de seguridad del borrador reconoce que los datos de verificación de contactos pueden tener implicaciones de privacidad y exige que la divulgación respete las leyes y políticas aplicables. La introducción contempla tanto servicios RDAP públicos como servicios cerrados que requieren autorización previa para solicitantes legítimos o autoridades.

Por tanto, el formato no impone una audiencia única. Mucho menos lo hace su referencia al artículo 28 de NIS2. La directiva aparece como contexto para mantener datos de registro de nombres de dominio exactos y completos. No debe leerse como una orden universal de publicar cómo se verificó cada atributo. Recoger, mantener, verificar, facilitar acceso y hacer público son operaciones diferentes y deben conservar fundamentos distintos.

El recibo de audiencia y vigencia

La medida práctica consiste en producir un recibo cada vez que los datos de verificación retenidos se convierten en una respuesta RDAP. Este recibo es una propuesta operativa de este artículo y no modifica el formato del Internet-Draft.

En la parte de origen, debe identificar el objeto RDAP, el conjunto exacto de atributos, el identificador de verificación, el verificador y la fecha cuando existan. Ha de conservar el método, la clase de evidencia y el marco de confianza, junto con la política y la versión utilizadas para interpretarlo. Si falta algún elemento, el recibo lo registra como ausente; no lo rellena con una suposición.

En la parte de destino, debe indicar la clase de solicitante, su identidad autenticada cuando proceda, la finalidad declarada, el canal público o restringido y los campos entregados, redactados u omitidos. La regla que autorizó la respuesta —ley, contrato, política de acceso o decisión individual— tiene que quedar enlazada. También deben figurar el responsable y el mecanismo de revisión.

La vigencia merece su propio apartado. El operador puede definir un intervalo de nueva verificación, eventos que obligan a revisar el dato, el tratamiento de fechas ausentes y el estado de corrección, revocación o sustitución. No se inventa una fecha de expiración en el protocolo; se documenta la política operativa que decide si el resultado todavía sirve para la finalidad solicitada.

El recibo no duplica documentos, biometría ni secretos. Guarda la justificación de la divulgación y permite contestar después una pregunta sencilla: ¿por qué esta persona vio estos metadatos en ese momento?

Empezar con poco para aprender sin encerrar el futuro

La idea de Heng Lu de una especificación inicial mínima, decisiones futuras localizadas y adopción voluntaria ofrece una salida a la falsa elección entre uniformidad total y ausencia de coordinación. Un vocabulario común puede coexistir con decisiones locales de acceso siempre que esas decisiones sean visibles y comparables.

Una primera implantación podría limitarse a un atributo, un marco documentado, una audiencia autenticada y un horizonte corto. Las respuestas públicas podrían indicar la existencia de campos redactados sin publicar la clase de evidencia. Antes de ampliar el servicio, el operador observaría reclamaciones, usos erróneos, registros obsoletos y solicitudes de revisión.

La reversibilidad exige separar configuración de reputación. Retirar un campo de una respuesta futura es relativamente sencillo; retirar una insignia ya copiada por terceros no lo es. Por eso el perímetro de audiencia debe diseñarse antes del primer despliegue y no después del primer incidente.

Fuentes