Resumen

  • El plan de RIPE Database para el tercer trimestre de 2026 llama OIDC 2.0 a una migración desde una cookie segura de alcance general, aunque el estándar de identidad revisado es OpenID Connect 1.0 sobre OAuth 2.0.
  • Una sesión válida acredita una identidad ante la aplicación, pero no concede por sí sola permiso sobre un objeto. La documentación pública sitúa esa decisión en la relación entre la cuenta SSO, las credenciales y el mntner.
  • La aceptación necesita un comprobante de corte que una el perfil técnico real, la vida de la sesión, el cierre de sesión, el retiro de la cookie anterior, las pruebas de autorización, las claves API y la posibilidad de reversión.

El caso que un ensayo positivo no ve

Imaginemos una prueba de puesta en producción. Un usuario entra por el nuevo proveedor de identidad, vuelve a la aplicación, ve su cuenta y carga un objeto. Todo parece correcto. Sin embargo, ese recorrido sólo demuestra que una identidad pudo autenticarse y que la aplicación creó algún estado de sesión. No demuestra que la misma identidad deba modificar ese objeto concreto. Tampoco demuestra que una identidad parecida, vinculada al mantenedor equivocado, sea rechazada sin dejar cambios.

El segundo punto del plan trimestral de RIPE Database convierte esta diferencia en una cuestión inmediata. La página, actualizada el 11 de junio de 2026, anuncia la sustitución de la autenticación interactiva mediante una cookie segura para todo el sitio por una sesión denominada OIDC 2.0. El estado es In progress. RIPE NCC presenta el cambio como una mejora de la seguridad de las solicitudes autenticadas.

La intención es defendible. Una capa común de identidad puede hacer más clara la procedencia de la autenticación, aplicar de manera uniforme las reglas de RIPE NCC Access y reducir dependencias propias de la interfaz. Pero la etiqueta pública mezcla dos numeraciones. OpenID Connect Core continúa siendo una especificación 1.0; su base de autorización es OAuth 2.0. La gestión de sesión y el cierre iniciado por la parte usuaria también son especificaciones 1.0 independientes.

No hace falta suponer descuido. OIDC 2.0 puede ser la abreviatura interna de OpenID Connect sobre OAuth 2.0. Puede ser el nombre de una iniciativa. Puede ser una errata. La documentación examinada no permite saberlo. El problema práctico aparece al recibir el trabajo: un equipo no puede convertir esa frase en criterios inequívocos sin elegir qué especificaciones, perfiles y comportamientos considera obligatorios.

La sesión tiene más de un final

OpenID Connect permite que una aplicación confíe en la autenticación realizada por un proveedor. Después del intercambio, la aplicación puede mantener una sesión propia. El navegador puede seguir usando una cookie local para representar esa sesión, aunque ya no sea la antigua cookie de alcance general descrita por el plan. Al mismo tiempo, el proveedor conserva otro estado de acceso.

Por eso existen documentos separados sobre Session Management y RP-Initiated Logout. El primero aborda el estado entre proveedor y parte usuaria. El segundo define cómo una aplicación pide al proveedor que cierre la sesión del usuario. Ninguno convierte todas las capas en una sola fecha de caducidad. Cerrar la sesión local, cerrar la sesión en RIPE NCC Access, dejar vencer un token y deshabilitar una cuenta pueden producir resultados relacionados, pero no son el mismo evento.

La migración crea una frontera temporal. ¿Qué ocurre con una sesión iniciada bajo la cookie anterior un minuto antes del corte? ¿Se acepta hasta su vencimiento, se revoca de inmediato o se transforma? ¿Un cierre en el proveedor termina también el estado local? ¿La retirada de una relación de mantenedor se comprueba en cada operación o sólo cuando nació la sesión? El registro público no debe responder con detalles secretos, pero sí debe declarar la política y probarla.

Un comprobante mínimo necesita cuatro relojes: autenticación en el proveedor, vigencia de tokens, vigencia de sesión local y vigencia de la relación de autorización consultada por RIPE Database. También necesita distinguir los desencadenantes: acceso, renovación, cierre local, cierre federado, deshabilitación de la cuenta, retirada del mantenedor, expiración de una clave API y reversión de la versión.

La autoridad vive en el objeto protector

La propia documentación de RIPE Database evita confundir los términos. Autenticación es comprobar quién o qué actúa. Autorización es el poder de decidir o acceder. Credencial es la evidencia que permite confiar en el ejercicio de ese poder. El modelo puede asociar una cuenta autenticada con varias credenciales, y cada objeto puede señalar a uno o más mntner que lo protegen.

El mntner contiene referencias como cuentas SSO y claves criptográficas. Una afirmación OIDC puede llevar la identidad hasta la puerta de la aplicación. La puerta interior exige todavía que la identidad satisfaga la protección del objeto. Si ese paso se omite en el relato de aceptación, una mejora de autenticación puede presentarse por error como una revisión completa de autoridad.

Las claves API muestran el mismo encadenamiento desde otro canal. La guía dice que una clave pertenece a una cuenta RIPE NCC Access. Antes de autenticar una actualización, esa cuenta debe estar asociada a un mntner mediante auth: SSO. Además, la clave puede limitarse a un mantenedor específico. Tiene caducidad, dato de último uso y revocación, pero esas propiedades no convierten el token en permiso universal.

RIPE-843 extiende la disciplina: segundo factor obligatorio, usuario pensado para una persona, vida máxima de un año para las claves y desactivación cuando se deshabilita la cuenta o se retira al usuario como mantenedor en la base aplicable. Esto crea una cadena de dependencia cuya prueba debería sobrevivir a la migración. La nueva sesión debe recibir la identidad correcta; el servicio debe resolver el mantenedor correcto; la operación debe quedar permitida o denegada; y una retirada debe alcanzar el punto previsto por el diseño.

Una prueba pública que ya separa identidad y permiso

El repositorio RIPE-NCC/whois ofrece una pieza de evidencia útil, pero no una clausura anticipada. Su historial anota Support OAuth 2.0 (#1688) en la versión 1.117. La solicitud 1688 fue fusionada el 3 de marzo de 2025 y añadió, entre otros cambios, pruebas de integración para autorización Bearer.

En el código visible aparecen casos negativos precisos. Un token relacionado con un mantenedor distinto no puede cambiar el objeto. Tampoco debe hacerlo una identidad SSO incorrecta aunque el resto de la configuración parezca cercana. Tras el rechazo, la prueba comprueba que el atributo del objeto sigue sin modificación. Éste es el patrón de recepción correcto: autenticar el portador no elimina la decisión del mantenedor, y el error debe venir acompañado por la ausencia de efecto.

Sin embargo, esa fusión de 2025 se refiere al recorrido Bearer del servicio Whois. El plan de 2026 se refiere a la autenticación interactiva de la aplicación web y a su sesión. Usar el primer artefacto para declarar terminado el segundo borraría la diferencia entre canal automatizado, navegador y estado local. La coincidencia conceptual sirve para diseñar pruebas, no para anticipar el estado del proyecto.

El comprobante de corte

La parte técnica del comprobante debe empezar corrigiendo o explicando OIDC 2.0. Debe identificar OpenID Connect Core, OAuth y las especificaciones complementarias que realmente forman el perfil. A continuación puede registrar, en términos no sensibles, el emisor aceptado, la identidad de cliente, la clase de flujo, las validaciones de respuesta, la creación de sesión local, los límites de inactividad y duración total, la renovación, los tipos de cierre y el último instante en que se acepta la cookie anterior.

La parte de autoridad debe recoger el instante en que se lee auth: SSO, la forma en que una retirada del mantenedor afecta a una sesión abierta, el tratamiento de claves API, las clases de objetos y operaciones ensayadas, un caso permitido, varios casos denegados y la verificación de que un rechazo no mutó el registro. Debe añadir un umbral de reversión, un periodo de observación y los cargos que aceptan cada capa.

La privacidad no impide este diseño. No se publican direcciones de correo, identificadores de sesión, tokens, cookies, secretos ni contenido privado. Se publican identificadores de ensayo anónimos, versiones, clases de relación, resultados, tiempos y huellas. Si una prueba se corrige, se añade una nueva entrada enlazada; no se borra la base con la que se tomó la decisión original.

Lo que todavía es desconocido

Las fuentes no nombran el emisor, el cliente, el flujo, los ámbitos, las afirmaciones, las vidas de token o sesión, los atributos de la cookie, el mecanismo de cierre ni la fecha de despliegue. Tampoco dicen si las claves API cambian con la interfaz. No demuestran que OIDC 2.0 sea un error, ni que la implementación actual tenga una vulnerabilidad.

No hay evidencia de secuestro de cuenta, sesión obsoleta, vínculo incorrecto, escritura no autorizada, pérdida de datos o indisponibilidad. La solicitud de un comprobante es una propuesta de control, no una afirmación de daño. Precisamente por eso puede publicarse antes del corte: permite definir qué contará como terminado sin convertir una incertidumbre documental en una acusación técnica.

Fuentes