Resumen

  • La revisión 01 de una propuesta individual distingue entre reproducir el contenido que debía mostrarse y demostrar lo que una pantalla no confiable mostró de verdad.
  • El texto exige resultados separados para el recibo de autorización y la evidencia de presentación; ninguno convierte por sí solo la acción en autorizada.
  • Daniel Kade plantea registrar la decisión del tercero que confía, con el mandato humano, las raíces de confianza y el riesgo residual junto a las pruebas técnicas. Es una propuesta editorial, no una norma del borrador.

El cambio importante está en lo que ya no se promete

El historial del Datatracker sitúa la revisión 01 el 12 de septiembre de 2026. La comparación oficial muestra una corrección sustantiva: desaparece la afirmación de que el método permite probar qué se mostró a la persona. La formulación nueva limita el resultado a una coincidencia verificable entre la acción firmada y la representación declarada.

Ese límite cambia la lectura de todo el sistema. Un renderizador determinista puede volver a producir la pantalla que corresponde a los bytes firmados. Si el importe, el destino o la política no coincide, el verificador descubre la diferencia. Pero un cliente comprometido todavía puede entregar al verificador la representación correcta y proyectar otros píxeles ante el usuario. La evidencia describe una relación entre objetos digitales; no observa la percepción humana.

La revisión también sustituye «persona identificada» por «clave enrolada» al describir quién genera la firma verificada por el usuario. Es una mejora de autoridad: la clave es verificable; la identidad del titular, su puesto, la vigencia de su delegación y el alcance de la aprobación pertenecen a otros registros.

La ficha pública clasifica el texto como Internet-Draft individual activo. No pertenece a un grupo de trabajo, carece de flujo IETF, Area Director responsable y estatus RFC previsto. El documento es una propuesta disponible para discusión, no una decisión de la IETF.

La igualdad de bytes cierra una brecha, no todas

El renderizador descrito debe funcionar únicamente a partir de una acción canónica. No puede consultar la hora, la configuración local, el entorno, el azar ni una entrada externa. Con la misma acción debe emitir siempre la misma secuencia de campos y el mismo resumen legible, además de un digest del resultado. RFC 8785 es la referencia para la canonicalización JSON.

La regla tiene valor operativo. El algoritmo debe neutralizar de manera reproducible controles bidireccionales, caracteres de control, secuencias susceptibles de confusión visual y valores demasiado largos. Si no puede mostrar un dato de forma segura, debe negarse, en lugar de truncarlo o adivinar. Así una discrepancia deja de ocultarse en una interfaz flexible.

La «attestation» de pantalla añade otra pieza: el cliente firma la vinculación entre el digest de la representación y el digest de la acción. Se guarda al lado del recibo, no dentro de él. La firma de esa declaración puede verificarse, pero la confianza en el software, el dispositivo y la ruta física de presentación sigue siendo una evaluación independiente.

La nueva sección 6.1 lo expresa sin ambigüedad. El recibo válido no debe elevarse automáticamente a «presentación aceptada». Una evidencia de presentación válida tampoco debe elevarse a autorización. El tercero que asumirá la consecuencia selecciona de forma independiente las entradas de confianza de cada comprobación.

El ejemplo de Android revela la parte institucional

El borrador menciona Android Protected Confirmation como mecanismo que podría perfilarse por separado; no define ese perfil. La documentación oficial de ConfirmationPrompt explica que el tercero verifica una cadena de atestación, una clave con la capacidad requerida, un nonce y el texto exacto confirmado. También advierte que se necesita soporte de hardware y que la función puede no estar disponible.

Por eso «respaldado por hardware» no debería ser un atajo de auditoría. La política ha de identificar la raíz aceptada, el dispositivo, el texto exacto, la frescura, los campos que no cupieron en la pantalla y la ruta alternativa. Si un servicio pasa a un diálogo normal cuando el mecanismo protegido falla, debe registrarse un resultado de confianza distinto.

Tampoco basta la afirmación de que existe código de referencia. Un conjunto de pruebas negativas puede demostrar que cierta implementación rechaza un renderizado inconsistente o peligroso. No demuestra adopción, despliegue, revisión independiente ni que el canal físico sea honesto. La revisión 01 no solicita acciones a IANA y pospone el registro de identificadores.

Una ficha que una evidencia y responsabilidad

Daniel Kade propone una ficha de decisión de presentación. El tercero que confía conservaría el digest de la acción y el resultado del recibo; el perfil y versión del renderizador; idioma y campos materiales; digest y resultado de la atestación de pantalla; identidad del cliente, cadena y raíz de confianza; prueba que une la clave a una persona; función, delegación y límites; riesgo residual; regla de autorización; decisión, revisor, fecha, caducidad, ruta de rechazo o contingencia y disparadores de nueva evaluación.

No es una credencial universal. Es el punto donde una organización explica por qué unas pruebas concretas bastaron —o no— para una consecuencia concreta. La respuesta puede ser más estricta para una transferencia irreversible que para una operación de red reversible. Lo común es el formato mínimo de evidencia; el umbral permanece localizado.

La Especificación Inicial Mínima de Heng Lu ofrece esa arquitectura: acordar lo indispensable y dejar visible quién decide después. The Policy Mirror exige conservar la afirmación exacta de cada autoridad. Why BTW Media Exists aporta el límite periodístico: una revisión que corrige su alcance es un hecho; la adopción y la seguridad efectiva aún no lo son.

Fuentes

  1. Registro Datatracker
  2. Historial del documento
  3. API de metadatos
  4. Revisión 01
  5. Revisión 00
  6. Diferencias oficiales
  7. Authorization Receipts
  8. Authorization Receipts, revisión 13
  9. RFC 8785
  10. Android ConfirmationPrompt
  11. Android Protected Confirmation
  12. Atestación de claves Android
  13. The Policy Mirror
  14. Minimum Initial Specification
  15. Why BTW Media Exists