Resumen

  • RFC 9560 permite que un servidor RDAP identifique usuarios y valide Bearer Tokens con OpenID Connect y OAuth sin exigir una credencial distinta en cada servicio.
  • Las declaraciones opcionales de propósito y no rastreo son entradas de la política local; no prueban la intención, el derecho de una consulta, la ausencia total de registros ni la calidad del dato registral.
  • Una traza defendible enlaza la validación con la versión de política, el propósito solicitado, los campos revelados, la procedencia del registro y el resultado posterior.

El Bearer Token ha superado la validación. Emisor, audiencia, caducidad y estructura aportan evidencia suficiente para que el servidor continúe. Es un logro concreto, pero el lenguaje suele inflarlo: “usuario autenticado” pasa a significar “consulta autorizada”; un propósito admitido se vuelve “intención legítima”; una respuesta se cita como “realidad verificada”. RFC 9560 no fusiona esas categorías.

Publicado en abril de 2024 en la vía de estándares del IETF, RFC 9560 introduce autenticación federada en el Registration Data Access Protocol. El cliente descubre OpenID Providers y usa un flujo orientado a sesión o a token. La capa compartida evita cuentas aisladas, mientras conserva la decisión de acceso en la política de cada servidor RDAP.

Autenticar resuelve una sola pregunta

En una consulta con token, el servidor debe validarlo conforme a su política y confirmar que es un token de acceso legítimo. Puede aplicar introspección RFC 7662 o analizar un JWT. La audiencia importa: un token para otra parte puede no ser aceptable, aunque el intercambio de RFC 8693 permite obtener uno con audiencia adecuada.

La prueba dice que el servidor acepta esa credencial en esta interacción. Todavía no dice qué datos verá la identidad. Tras validar, el servidor evalúa las declaraciones, calcula un nivel de autorización y decide sobre cada consulta. Rechazar, omitir, redactar y divulgar son decisiones distintas.

El propósito es un privilegio asignado, no una lectura de la mente

rdap_allowed_purposes enumera, de forma opcional, los propósitos que una identidad puede invocar. El proveedor solo debe asignarlos a identidades autorizadas. farv1_qp declara el propósito de la consulta concreta; si no pertenece al conjunto permitido, el servidor debe responder 403.

La regla ordena el acceso, pero no observa la motivación humana. Que una identidad tenga una categoría, que la declare ahora y que use después los datos dentro de ella son hechos separados. El servidor puede ignorar propósito y claim cuando contradicen su política local. Sin parámetro de propósito, conserva la obligación de decidir con la demás información disponible.

Una tarjeta de empleado puede identificar a quien entra y abrir una puerta. No certifica por qué entró, qué expediente necesitaba ni qué hará con él. Esa limitación no debilita la federación; impide exigirle una prueba que nunca produjo.

No rastrear sustituye una garantía por otra

rdap_dnt_allowed puede obligar a no registrar la asociación entre identidad y consulta. Deben concurrir identificación, autorización, valor true y compatibilidad con la normativa local. El RFC advierte que la promesa depende de la buena voluntad del servidor y sus proxies, de confianza previa fuera de banda y de una pérdida de información capaz de perjudicar la auditoría.

Una investigación delicada puede necesitar confidencialidad. La decisión debe nombrar quién concede el privilegio, qué intermediarios cubre, qué evidencia alternativa queda y cuándo caduca. “No rastreo aceptado” es un acto de política, no una prueba criptográfica de que ningún sistema conservó una asociación.

La respuesta tiene otra carga probatoria

farv1 declara conformidad con la extensión, no con la verdad material del registro. Una respuesta correcta puede ser un subconjunto; la fuente mantiene su propia fecha, método de verificación, historial de corrección y ambigüedad. HTTP 200 no prueba exhaustividad ni utilidad. HTTP 403 no prueba mala conducta.

La capa común mínima debe estandarizar descubrimiento, tratamiento de tokens, nombres de claims y parámetros. No debe fingir que normaliza todos los fines lícitos, umbrales de divulgación o resultados de investigación. Con la disciplina de capas de realidad de Lu Heng, identidad, token, permiso de propósito, decisión, registro revelado y resultado real son hechos diferentes y ninguno hereda automáticamente la autoridad del siguiente.