Resumen

  • El borrador del grupo ACE del 2 de noviembre permite que el servidor de autorización suba un token al servidor de recursos por cuenta del cliente y le comunique el resultado. Sigue siendo un Internet-Draft.
  • La nueva sección 10.1 espera registros fechados de solicitudes, entregas y ciclo de vida del token. El servidor de recursos puede registrar sus propios resultados hasta donde lleguen su memoria y energía.
  • Los secretos operativos quedan fuera de los registros por obligación. Antes de compartirlos con gestores externos, el depósito designado debería borrar datos que permitan seguir a clientes y servidores, salvo autorización específica.

El mensajero también escribe el acta

En el ACE original, un cliente recibe el token del servidor de autorización y lo lleva al servidor de recursos. La cadena corta propone que el primer servidor haga la entrega. Si funciona, avisa al cliente; si falla, le da el token para que lo suba por la vía habitual. Una instalación puede incluso configurar la emisión y entrega para clientes que desconocen la existencia del intercambio de tokens. La comunicación entre ambos servidores debe protegerse.

El cambio convierte al servidor de autorización en testigo del recorrido. La versión -09, publicada el 2 de noviembre, añade un capítulo de operaciones que no estaba en -08. Allí se esperan marcas de tiempo para peticiones, emisión, resultado de la subida, vencimiento, revocación y registro de clientes y servidores de recursos. También se considera deseable que el servidor de recursos anote tokens aceptados, rechazados o eliminados y accesos denegados, dentro de sus límites de memoria, cómputo y energía. Es la diferencia entre comprobar que se expidió un permiso y saber que llegó a destino.

El acta puede contar demasiado. Direcciones e identificadores de credenciales permiten relacionar un dispositivo con sus contactos. Un punto de almacenamiento designado puede administrar los registros y ponerlos a disposición de aplicaciones externas autorizadas por consulta o aviso. El texto prohíbe guardar secretos operativos, claves privadas y material de claves derivado. Recomienda eliminar los elementos sensibles antes de compartir el registro; sólo una autorización concreta, respaldada por la política de privacidad aplicada, justifica la excepción. Cuánto se registra y durante cuánto tiempo queda a cargo de la aplicación y el operador.

Son dos niveles de fuerza distintos: «MUST NOT» para secretos y «SHOULD» para la supresión de metadatos en la entrega externa. El borrador no aporta cifras de instalación ni casos de vigilancia. Deja una pregunta de diseño: cuando el servidor entrega el token, ¿qué parte de la trayectoria del cliente necesita ver quien administra el sistema?

Fuentes originales