Resumen

  • El archivo de la IETF publicó VCAP-02 el 4 de septiembre como Internet-Draft individual, sin respaldo de la IETF, posición formal, flujo RFC ni Area Director responsable.
  • La nueva sección de rendición de cuentas admite que el mercado controla de hecho resultados de liquidación al escoger verificadores y exige claves, capacidades, vías de disputa y registros.
  • No obstante, el proveedor origina service_delivery y puede incluir auto_approve, definido como omitir la comprobación automática mediante autoatestación del propio proveedor.
  • Ninguna regla asigna quién acepta la dispensa, qué cláusula la habilita, quién firma después el callback, qué controles siguen vigentes o cómo caduca y se impugna.
  • Antes de mover fondos debe existir un recibo de dispensa que una propuesta, autoridad aceptante, base contractual, límites, vencimiento, firmante, conflictos, recurso y estado final.

La revisión identifica un poder real

El aviso de publicación deja constancia de que el 4 de septiembre apareció un Internet-Draft de treinta páginas de Ben Stone. La ficha de Datatracker ofrece el límite institucional: es un borrador individual activo. Cualquier persona puede presentar uno; no implica aprobación de la IETF ni ocupa una posición formal en su proceso. No tiene flujo RFC, Area Director responsable ni fecha de teleconferencia. El destino “Informational” es una intención del autor.

La revisión 02 propone que agentes autónomos negocien un encargo, que un mercado retenga los fondos, que un proveedor entregue y que un verificador emita un callback. La variable passed guía el estado: verdadero lleva a VERIFIED y a la liberación; falso lleva a FAILED y al reembolso. El propio texto llama a ese callback el mensaje más crítico porque activa la liquidación.

El cambio oficial respecto de -01 incorpora una sección que faltaba en la versión anterior. VCAP dice ahora que el mercado controla efectivamente los resultados cuando elige a los verificadores. Antes de aceptar sus respuestas, debe registrar y confiar en su clave o método Ed25519, anotar las capacidades declaradas y definir una vía de escalamiento. Las altas, rotaciones y bajas de claves deben conservarse con fecha junto al expediente de liquidación.

Si el operador del mercado también controla al verificador, el borrador recomienda permitir a solicitante y proveedor acordar un tercero. También recomienda publicar qué tipo de verificador atiende cada servicio, cómo se tratan los conflictos y cómo se discuten los resultados. El acuerdo mutuo y la publicación son SHOULD; el registro de clave, capacidades, disputa e historial contiene obligaciones MUST.

Esa combinación es razonable para un texto mínimo: hace visible el centro de decisión sin imponer un único evaluador mundial. Pero deja una pregunta todavía más básica. ¿Quién puede decidir que el evaluador ni siquiera intervenga?

Una indicación del proveedor puede pedir que no se compruebe

El proveedor envía service_delivery cuando afirma que terminó. Además del estado, la descripción y los artefactos, puede suministrar pistas de verificación: dirección, selector, texto esperado o cambio de huella. La misma estructura incluye auto_approve. Su descripción dice que, si es verdadero, se omite la verificación automática y el proveedor se autoatestigua.

El esquema JSON de la entrega enlazado por el borrador precisa que esas pistas pueden “reemplazar o complementar” las del solicitante. Declara falso como valor predeterminado. Esa precaución evita que la ausencia del campo active la excepción, pero no crea consentimiento para activarla. El beneficiario sigue siendo quien envía el mensaje.

El término solo aparece dos veces en cada texto fijo -00, -01 y -02: en el ejemplo de mensaje y en la tabla de pistas. No existe un procedimiento que diga quién puede proponerlo, quién debe aceptarlo, qué parte del acuerdo lo autoriza, para qué importes o riesgos sirve, qué pruebas permanecen, cuándo vence, cómo se revoca o qué registro debe acompañarlo.

Tampoco se define el tratamiento de un valor no autorizado. Un mercado podría ignorarlo, mantener el dinero retenido, pedir confirmación al solicitante, usar una política propia o enviarlo a revisión humana. Todas son decisiones defendibles; ninguna puede deducirse como la única conducta interoperable del texto actual.

Esto no es una acusación de abuso. Las fuentes no demuestran que ningún despliegue procese el campo, que un proveedor haya obligado a pagar ni que haya ocurrido una pérdida. La evidencia permite una afirmación más estrecha: dos implementadores independientes no reciben una regla completa para la dispensa y pueden producir resultados distintos.

Falta el puente hasta el callback

El camino ordinario culmina con un objeto muy concreto. El callback contiene identificadores de verificación, negociación y depósito, passed, una huella, una firma, un identificador de clave, un registro de acciones y la hora. La liquidación copia el identificador y la prueba. ¿Qué objeto debe crearse cuando la comprobación automática fue omitida?

Si firma el proveedor, la autoatestación se convierte en el veredicto del beneficiario. Si firma el mercado, la firma expresa aceptación de riesgo, no observación de la entrega. Si firma una persona, ya existe una revisión manual y conviene nombrarla. El borrador no escoge entre estas semánticas ni dice qué anotar como acción cuando la acción relevante fue no verificar.

La criptografía no puede escoger por él. VCAP-02 usa SHA-256 para el paquete canónico y Ed25519 para un cuerpo que incluye referencias, resultado, huella, clave y tiempo. RFC 8032 permite comprobar que una clave firmó ese mensaje. El texto de seguridad de VCAP limita correctamente el alcance: la huella detecta alteración y la firma atribuye la prueba a un verificador autorizado. No demuestran que el pagador autorizó la dispensa ni qué condición contractual la permitió.

La atomicidad también responde a otra pregunta. Una transición de comparación e intercambio evita liberar y reembolsar el mismo saldo. La idempotencia evita que una retransmisión liquide dos veces. Garantizan una sola consecuencia terminal; no garantizan que la excepción que condujo a ella tuviera dueño legítimo.

El tratamiento del vencimiento muestra un diseño más completo. Si el verificador no termina en el plazo —1.800 segundos por defecto—, el depósito permanece HELD. Debe decidir una persona, que produce un callback normal con una sola entrada en el registro de acciones y la prueba habitual. Se conserva quién tomó la decisión excepcional y por qué ruta. auto_approve no tiene un equivalente.

El código enlazado añade otra advertencia

La especificación remite a esquemas públicos. El esquema del callback seguía exigiendo en la fecha de corte un HMAC-SHA256 hexadecimal, solo aceptaba versión 1.0 y no incluía verifier_key_id. El nuevo borrador exige Ed25519, Base64 e identificador de clave. El historial del repositorio permite ver que los esquemas enlazados no acompañaron la entrega de septiembre.

No se puede convertir ese desfase en un fallo de producción. Sí se puede observar que el texto y el artefacto ejecutable no ofrecen el mismo contrato. Para auto_approve, la ausencia de un esquema de autorización causaría una divergencia parecida aunque ambos validadores aceptaran exactamente el mismo JSON.

VCAP-02 también acota su relación con AP2. AP2 se ocupa de mandatos, roles y evidencia de pago; el nuevo texto ya no supone que AP2 define las transiciones de depósito, captura, devolución y liquidación. Por eso la autoridad de la dispensa debe resolverse en VCAP o en un acuerdo identificado, no atribuirse a AP2 por omisión.

Un recibo pequeño conserva la decisión grande

Antes de liquidar, la excepción debería generar un recibo. Debe incluir transacción, negociación y depósito; versiones y huellas del texto y los esquemas; proveedor proponente; cláusula que permite autoatestación; actor del solicitante y del mercado que la aceptan; regla de selección sustituida; criterios dispensados y conservados; motivo; tope de valor y riesgo; vigencia, vencimiento y revocación; tipo de callback y firmante; evidencia contradictoria; vía de disputa; y estado final de los fondos.

Si no se puede resolver la cláusula o la autoridad aceptante, el sistema rechaza la pista o conserva HELD. No inventa consentimiento actual a partir de una aceptación general de la negociación. Esta regla es más importante que cualquier valor predeterminado del parser.

El recibo no centraliza la política. Cada parte decide cuándo confía, cuánto arriesga y qué verificador acepta. El nivel común solo permite verificar que la excepción fue una decisión acordada y limitada, no un efecto secundario del mensaje del beneficiario.

Fuentes

  1. Anuncio de VCAP revisión 02
  2. Estado en IETF Datatracker
  3. VCAP revisión 02
  4. VCAP revisión 01
  5. Diferencias oficiales entre 01 y 02
  6. Esquema JSON de service_delivery
  7. Esquema JSON de verification_callback
  8. Historial del repositorio VCAP
  9. RFC 8032 — EdDSA
  10. Especificación de Google Agent Payments Protocol
  11. Heng Lu sobre la primacía del código ejecutado
  12. Heng Lu sobre especificación mínima y decisión local