Resumen

  • La revisión 02 sustituye un único objeto de puntuación por una matriz de resultados y exige un esquema y una URI de emisor en cada entrada.
  • Nombrar al emisor no autentica su afirmación: la confianza se configura fuera del protocolo y la republicación añade otro intermediario.
  • La automatización debe conservar sujeto, esquema, emisor, publicador, fecha, vigencia, estado y prueba; el número por sí solo no es una decisión.

El problema no comienza cuando una puntuación es falsa. Comienza antes, cuando una pantalla presenta el 8 de un tercero como si el protocolo hubiese verificado quién lo calculó y qué autoridad tiene para hacerlo.

draft-bertoldi-regext-rdap-reliability-scoring-02, presentado el 6 de septiembre, corrige buena parte de esa ilusión. Cambia reliabilityScoring por reliabilityAssessment, renombra el miembro como reliabilityAssessment_results y permite resultados de varios emisores o esquemas. scoreScheme y scoreIssuer pasan a ser obligatorios; aparecen validUntil, assessmentId y los estados activo, en revisión y retirado. Los autores declaran que todavía no conocen ninguna implementación.

Tres preguntas que no deben fusionarse

La URI del emisor responde a quién se atribuye un resultado. La confianza responde por qué un consumidor acepta a esa entidad. La autenticidad responde si la afirmación realmente salió de ella y llegó sin alteraciones.

La extensión resuelve la atribución. No resuelve la autenticidad. scoreIssuer debe ser una URI global, estable y preferentemente controlada por el evaluador, pero no contiene una firma. El borrador deja la confianza fuera de banda y reserva la afirmación firmada para un trabajo posterior.

Tampoco basta con invocar HTTPS. El RFC 7481 protege el canal y autentica el servidor que responde. Eso permite saber qué extremo entregó los bytes, no si un evaluador externo citado dentro de la respuesta los originó. La integridad del transporte y la exactitud de una afirmación son propiedades distintas.

El mismo JSON puede recorrer tres cadenas

La configuración principal es un servicio de evaluación operado por el propio evaluador. También puede haber republicación por un registro, un registrador u otro servidor, y puede existir autoevaluación. La sintaxis no cambia; la cadena de confianza sí.

En un servicio de primera parte, el consumidor puede haber configurado conjuntamente la URI y el punto final. En una republicación debe confiar en quien evalúa y en quien retransmite. En la autoevaluación, la atribución puede ser correcta, pero el incentivo económico acompaña a quien se califica.

Por esa razón, la propuesta no inserta estos servicios en el bootstrap del RFC 9224, que localiza servidores autorizados para datos de registro. Tampoco recomienda que el servidor autorizado publique un enlace genérico al evaluador: el enlace podría parecer un aval. La localización del servicio no concede confianza.

La puntuación pierde sentido fuera de su contexto

El orden de la matriz no significa preferencia, autoridad ni actualidad. Un 7 bajo dos metodologías no es necesariamente comparable. validUntil indica hasta cuándo el emisor afirma que el resultado está al día, sin borrar su existencia histórica. La falta de estado no equivale a activo. Un resultado retirado puede seguir visible para corregir copias almacenadas. La ausencia del miembro completo no es una calificación favorable ni negativa.

La unidad mínima de decisión es un conjunto: sujeto correctamente vinculado, esquema estable, emisor, servidor publicador, identificador, fecha, vigencia, estado y evidencia retenida.

La vinculación del sujeto funciona mejor para dominios que para registradores. Un dominio tiene ldhName y una consulta conocida. El registrador aparece mediante un identificador local del servicio; el IANA Registrar ID se observa en publicIds después de recuperar el objeto. Quien solo posee ese ID no puede construir la consulta en banda. El etiquetado del RFC 8521 es una pregunta abierta, y los registradores de ccTLD siguen sin una regla completa.

El protocolo exige salvaguardas, no se proclama juez

La revisión obliga al documento de cada esquema publicable a exponer su modelo de amenaza, notificar al evaluado, abrir un plazo de corrección o impugnación, justificar la minimización de datos y defender específicamente la publicación a nivel de dominio. Es una respuesta sensata al riesgo de que un resultado bajo funcione como lista de reconocimiento para atacantes.

Sin embargo, no fija la duración, el árbitro, el gobierno del proceso ni la consecuencia de una impugnación exitosa. Esas decisiones pertenecen al esquema y a su marco operativo. La envoltura común transporta una afirmación; no convierte a su publicador en legislador.

El valor de esta revisión está en reconocer lo que falta. Las puntuaciones son informativas, no certificaciones ni mecanismos de ejecución. Pueden quedar obsoletas. La evidencia enlazada puede mutar o desaparecer. Un valor alto no garantiza ausencia de vulnerabilidades. La propuesta será útil si las implementaciones conservan esas advertencias en lugar de ocultarlas detrás de un semáforo.

Fuentes

  1. Registro de IETF Datatracker
  2. Borrador RDAP, revisión 02
  3. Borrador RDAP, revisión 01
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy