Summary

  • draft-saha-aadp-bound-permit-00, publicado el 29 de septiembre, propone llevar una decisión AADP con estado a través de una frontera de confianza y ligarla a un receptor, una clave de presentación, una solicitud HTTP y una instancia concreta de acción.
  • Verificar el permiso no basta. El mandato referenciado debe permitir la misma transacción, la política local conserva su veto y la actualidad de la decisión debe quedar probada. Ninguna capa puede ampliar a las demás.
  • El receptor consume (iss, jti) de forma atómica al final de trece comprobaciones. Las repeticiones seguras recuperan el resultado almacenado, pero el protocolo no garantiza un efecto externo exactamente una vez.

El céntimo que invalida la autorización

La decisión original puede depender de información imposible de exportar de forma fiable: gasto acumulado, reservas vivas, aprobaciones que vencen, ejecuciones anteriores y un interruptor de emergencia. Ese estado reside en el dominio del emisor. El proveedor que realizará el pago sólo puede comprobar que alguien tomó una decisión sobre una acción específica y que lo recibido coincide con ella.

Por eso una firma correcta no resuelve el caso de 40,01 euros. Tampoco lo resuelve la identidad del agente ni un mandato amplio para pagar facturas. La pregunta es más estrecha: ¿autorizó el punto de decisión esta solicitud exacta, para este receptor, presentada por esta clave, en este momento?

El primer borrador de Shamik Saha sobre action-bound permits intenta responderla. Es un Internet-Draft individual activo, con intención Standards Track declarada en el encabezado. No es un RFC, un consenso del IETF ni prueba de uso productivo.

El documento tampoco pretende crear un sistema general de autoridad entre organizaciones. Transporta una sola decisión que el receptor no puede recalcular.

Un permiso sujeto por varios lados

El formato es un JWT JWS compacto con typ igual a aadp-permit+jwt. aud sólo puede identificar a un receptor. cnf.jkt fija la clave del presentador, y la petición debe llevar una HTTP Message Signature verificable con esa misma clave. Aceptarla sin prueba de posesión la convertiría en un bearer token; el borrador prohíbe esa modalidad entre dominios.

La firma incluye, como mínimo, método, autoridad, ruta, query, Content-Digest, Idempotency-Key y el propio campo del permiso. El receptor recalcula Content-Digest sobre los bytes recibidos antes de analizar o volver a serializar el cuerpo. Un intermediario que cambie el texto JSON, aunque mantenga el significado, provoca un fallo de enlace por diseño.

Después llega la comprobación semántica. Cada tipo de acción define cómo extraer el objeto A de la solicitud. El receptor lo canonicaliza con RFC 8785, aplica el dominio definido y compara action_digest. Así, unos bytes intactos no validan una interpretación que cambió el importe o el beneficiario; del mismo modo, una acción equivalente no disculpa bytes alterados.

El permiso también está limitado en el tiempo. No puede sobrevivir al execute_within de AADP. Si no existe esa obligación, la diferencia entre exp e iat no supera 120 segundos. El margen de reloj declarado se limita a 60 segundos y jamás alarga el plazo sustantivo.

La aparente rigidez —un receptor, una clave, una petición, una acción y pocos segundos— evita que una decisión puntual se convierta en credencial reutilizable.

El emisor no gobierna al receptor

La regla de aceptación contiene tres síes independientes. El permiso y los enlaces verifican. El mandato, cuando se referencia, permite la transacción. Y la política propia del receptor también la permite. Basta un no para detenerse.

Un Agent Authorization Envelope propuesto expresa qué fue delegado al agente. El permiso expresa qué decidió ahora un PDP que conoce su estado. Si el receptor obtiene el AAE, lo evalúa por separado contra la misma transacción y compara el digest. DENY, PENDING, una discrepancia o la indisponibilidad de un mandato obligatorio terminan en rechazo. El permiso nunca convierte PENDING en PERMIT.

La política local no es un trámite posterior. El receptor puede confirmar identidad, importe y firma y aun así denegar por fraude, cuenta, sanciones o límites de servicio. La criptografía prueba la procedencia de una decisión; no transfiere soberanía sobre el sistema que sufrirá el efecto.

También la confianza en el emisor tiene alcance. La tabla propuesta especifica claves, tipos de acción, límites de cada campo, caducidad y currentness mínimo. Confiar en un PDP para transferencias pequeñas no le autoriza a cerrar cuentas ni a decidir importes ilimitados. Una lista plana de emisores dejaría el poder residual en cualquier omisión de la política local.

Corto no significa vigente

Una política puede cambiar o un mandato ser revocado durante la breve vida del permiso. La firma seguiría siendo auténtica. El borrador obliga a declarar uno de dos modos para hacer visible esa limitación.

time-bounded considera vigente el permiso hasta exp sin otra consulta. Sólo se acepta para emisores y acciones cuya tabla admita ese riesgo. status-checked exige comprobar en el momento de la recepción que permiso, versión de política y mandato siguen actuales, mediante una lista de estado o una declaración fresca firmada por el emisor.

Si el estado no puede obtenerse, llega ilegible o ya está viejo, el resultado normal es status-unavailable. Un fail-open sólo puede ser local, explícito, auditado y reservado a una clase de bajo riesgo. Debe quedar registrado como excepción; no como una variante silenciosa de “firma válida”.

Las capas de realidad de Lu Heng ayudan a ordenar la prueba. El permiso representa una decisión pasada. El estado representa una observación posterior. La ejecución y sus consecuencias pertenecen a otra capa. La cadena necesita las tres; ningún símbolo puede fingir ser el hecho siguiente.

El identificador no concede una segunda oportunidad

jti no es el permit_id interno de AADP. Debe acuñarse de forma independiente y no ser derivable. El emisor conserva el mapa entre ambos, pero sólo jti cruza la frontera y se convierte en Idempotency-Key. Separarlos impide que un identificador interno adquiera significado de credencial externa.

El orden de verificación termina con el estado. Antes se comprueban estructura, emisor, audiencia, tiempo, tipo, alcance, digest de contenido, firma del presentador, acción, currentness, mandato y política local. Sólo entonces el receptor consume (iss, jti) atómicamente y después intenta el efecto.

Consumir al final evita que una petición corrupta queme un permiso legítimo y garantiza que un veto local no lo gaste. Si el almacén atómico está caído, el receptor marca could-not-check y se detiene. Un clúster sin un almacén duradero y compartido no puede aceptar estos permisos.

En la primera presentación se consume, se actúa y se guarda el resultado. La repetición con el mismo digest devuelve ese resultado y queda anotada como repetición. El mismo jti con otro cuerpo produce idempotency-conflict. Si la primera aún sigue en marcha, la respuesta es reintentable sin iniciar otro efecto.

Lo que no debe ocurrir es obtener un permiso nuevo cuando se perdió la respuesta. El presentador informa timeout, consulta por jti o por el identificador de acción del receptor y escala si no puede saber qué pasó. Una clave de idempotencia permite reconciliar; no convierte lo desconocido en “no ocurrió”.

La otra parte firma su versión

Tras consumir y tratar de ejecutar, el receptor devuelve una confirmación firmada. Nombra el permiso, los digests de la solicitud y de la base de firma, la acción, el veredicto del mandato, el resultado y su identificador local. El presentador incorpora el digest de la confirmación al informe AADP como descarga de present_bound.

La dirección de las firmas evita que una suplante a otra. El PDP firma la decisión. El presentador firma la petición. El receptor firma lo que hizo. Una negativa firmada permite acreditar failure con no_effect: true; un error no firmado no demuestra que el efecto no sucedió. La ausencia de confirmación mantiene el resultado como timeout.

El diseño es de un solo salto. Un campo parent se rechaza como chained-permit-unsupported. Si B debe llamar después a C, el dominio de B toma una decisión nueva. Puede adjuntar referencias previas como procedencia, pero C no debe tratarlas como autorización ni omitir controles.

Eso encarna una Minimum Initial Specification: compartir las reglas mínimas que permiten comprobar el mismo intento, sin que el emisor decida por todos los participantes. La aceptación futura sigue siendo local donde vive la consecuencia.

Dos huecos visibles en la implementación

El borrador cita una implementación de referencia en onedoor y fija un commit público. El manifiesto enumera 24 vectores; el mapa de trazabilidad declara 22 implementados. Quedan fuera V17, detección de política sustituida en status-checked, y V22, verificación de una confirmación que nombra otro digest. El documento informa además de 92 pruebas permit superadas.

Es evidencia reproducible, no validación independiente. El código está ligado al autor, el mensaje del commit corresponde a otro mantenimiento del repositorio y no existe aquí una medición productiva. Running-Code Primacy obliga a ejecutar, comparar y publicar discrepancias, especialmente en los dos huecos; no eleva un snapshot a consenso.

Fuentes y límites

Las fuentes acreditan una propuesta individual activa, sus dependencias y un snapshot de implementación vinculado al autor. No acreditan consenso IETF, RFC, interoperabilidad independiente, despliegue seguro, decisiones honestas ni efectos exactamente una vez. Este Artículo posee sólo la tesis de la revisión 00: transportar una decisión AADP con estado como un intento ligado al receptor, presentador, petición y acción, consumido una vez y respondido con firma del receptor.