Summary

  • La revisión del 27 de octubre de un Internet-Draft individual añade decision.operationKey para reconocer una operación pretendida a través de varios intentos.
  • El ejemplo del autor separa un pago de 120 libras ya retenido de otro pago igual: con 300 libras gastadas y un tope de 500, el primero deja el total en 420; el segundo lo llevaría a 540.

El robot no recibió confirmación. Vuelve a pedir el mismo pago. Hasta ahí, repetir no significa gastar dos veces: el permiso anterior continúa en espera. El problema aparece cuando llega otra instrucción igual que sí representa una segunda compra. Acción, argumentos y recurso coinciden. Si el sistema trata la huella del contenido como identidad del acto, su libro de cuentas verá un eco donde había una nueva obligación.

La revisión -02 del borrador propone poner nombre a cada operación prevista. decision.operationKey viaja en la petición firmada y se mantiene si la misma operación necesita reintentarse. Un nuevo encargo obtiene otra clave, aunque el texto del pago sea calcado. La clave queda acotada por el digest del límite delegado. Así, un auditor puede preguntar qué operación gastó qué autoridad, en lugar de comparar únicamente dos mensajes.

El cambio responde a un defecto que el propio historial de la propuesta atribuye a la versión -01: allí un reintento se identificaba por el digest de la petición. Dos pagos intencionales con idéntico contenido comparten digest. El nombre equivocado podía hacer que el segundo pareciera ya contabilizado.

El ejemplo del documento es casi una pequeña comedia de oficina, hasta que se mira el saldo. La delegación permite 50.000 peniques. Ya se consumieron 30.000 y hay un permiso de 12.000 retenido tras perderse la respuesta. Un reintento de ese permiso mantiene el compromiso en 42.000. Una segunda operación de 12.000, aunque use el mismo digest de petición, eleva la cifra a 54.000. Debe ser visible como operación nueva y fuera del límite. La contabilidad no puede ahorrarse 12.000 peniques cambiando la etiqueta de un mensaje.

El formato guarda para cada permiso pendiente la clave, el digest y el importe. La suma de esas entradas ha de cuadrar con el total reservado. Un verificador calcula withinLimit con lo consumido, lo reservado y lo solicitado, sin volver a sumar un auténtico reintento ya retenido. La propuesta también exige conservar el permiso hasta que un registro de esa misma operación indique que el efecto ocurrió o no ocurrió. Una respuesta ausente deja una duda, no una cancelación.

Después, quien conserva los registros compara revisiones sucesivas del estado. Si una autorización posterior leyó una versión antigua e ignoró un permiso pendiente, aparece la ventana en la que el mismo presupuesto pudo prometerse dos veces. El borrador deja el fallo a la vista incluso cuando el punto de decisión concedió un permiso excesivo.

El Datatracker del IETF lo registra como borrador individual en estado I-D Exists. Su propuesta para el auditor apunta a una pregunta muy real para cualquier sistema delegado: ¿cuántas decisiones distintas se tomaron con el dinero de otro?