Resumen

  • RVP ya no propone como requisito común una cascada de cinco capas que acumule confianza en todas las interacciones.
  • Su nueva regla de migración impide usar un token anterior, limitado al desafío de transporte, como si hubiera firmado la operación y el objetivo de una pregunta nueva.

El mismo número de confianza puede parecer tranquilizador en una puerta de acceso y peligroso en otra. No explica qué pidió el sistema, qué vio la persona ni para qué se usó después la respuesta. El borrador RVP, revisado el 29 de septiembre, abandona precisamente esa pretensión de portabilidad: una prueba satisfactoria responde a una exigencia concreta, no a una identidad suficientemente «buena» para cualquier trámite.

La versión 02 describía una vigilancia continua. Cada interacción era un momento de verificación; cinco métodos podían activarse en secuencia y sus resultados alimentaban un umbral acumulado. Ya entonces la aplicación de medidas dependía de la política local. Por eso no sería exacto presentar la revisión 03 como el primer reconocimiento de que probar no es autorizar. Lo nuevo es que retira la cascada obligatoria, trata la sesión autenticada y la presencia humana reciente como hechos distintos, y deja que cada consumidor decida cuándo necesita uno u otro.

La exigencia de evidencia se publica con identificador, versión inmutable y resumen criptográfico de su contenido. La solicitud concreta incorpora la operación, el objetivo, el sujeto, el actor si no coincide, el consumidor, el propósito, la ventana y el plazo. El compromiso de la pregunta abarca todo ese contexto junto con el desafío. Si una aplicación muestra «entrar en el equipo A», una firma sobre el desafío aislado no demuestra que esa frase estuviera ante quien respondió. El verificador debe reconstruir el compromiso a partir de su registro de la solicitud.

La migración pone a prueba la honestidad del archivo. Los tokens de la primera versión se pueden conservar como constancia de lo que sí medían. Pero, si una nueva exigencia pide vínculo explícito con operación y objetivo, no son suficientes. El propio borrador prohíbe rellenar campos ausentes con información local y atribuir retrospectivamente al firmante una aprobación que no consta en su firma. Tampoco permite degradar sin aviso una exigencia de compromiso completo a una respuesta que solo firma el desafío.

Después queda otra frontera: recibir una prueba compatible no equivale a consumirla. El resultado match dice que la respuesta encaja con la exigencia congelada. El acto bind se registra solo cuando un consumidor realmente la aplica a un propósito y a la transición actual del objetivo. Debe comprobarse su vigencia; el uso simultáneo no puede saltarse límites. Si se permiten varios consumidores, sus nombres, propósitos y alcances tenían que estar previstos desde antes. La admisión sigue siendo decisión del sistema de destino.

Para Daniel Kade, una transición responsable debería conservar una matriz breve: formato antiguo o nuevo, campos firmados, versión y resumen de la exigencia, operación, objetivo, consumidor, uso efectivo y dueño de la decisión de acceso. Es una propuesta de análisis, no un formulario normativo. Su utilidad es impedir que un puntaje heredado adquiera, por conveniencia, el significado de una autorización nueva.

Datatracker registra la revisión 03 como Internet-Draft individual activo, sin RFC stream. La solicitud de un tipo de medios application/rvp+json tampoco constituye su registro. No hay prueba de implantación ni de ataque ocurrido. Lo verificable es la rectificación escrita por sus autores: la fuerza de una respuesta termina donde termina la pregunta a la que se obligó a responder.

Fuentes