Resumen

  • La revisión 01 de Using KYAPay Tokens, publicada el 2 de octubre de 2026, llama “recipient” y no “verifier” al sistema que recibe el token. El texto afirma que identificar no equivale a admitir: validar aporta contexto autenticado, mientras aceptar, limitar, pedir otro factor o rechazar sigue siendo decisión local.
  • El límite continúa después de la firma. Un token al portador no prueba posesión de clave, una autorización emitida no demuestra control humano continuo y un PAY con datos de compra no acredita aceptación, compensación ni liquidación.

Las arquitecturas de confianza suelen fallar no porque una firma sea falsa, sino porque un resultado verdadero recibe más autoridad de la que contiene. La revisión 01 de draft-skyfire-oauth-using-kyapay-tokens corrige precisamente ese riesgo al cambiar el nombre del consumidor: ya no es sólo quien verifica, sino quien recibe y decide.

El destinatario puede ser un servidor de recursos, una capa de borde, un gestor de bots, un sistema antifraude, una defensa contra toma de cuentas o una plataforma de identidad de clientes. Todos pueden reconocer la misma firma y, sin contradicción, aplicar políticas diferentes. Una solicitud de lectura y un cambio de titularidad no tienen la misma consecuencia.

KYA organiza afirmaciones sobre el principal humano, la plataforma donde funciona el agente y la instancia concreta. PAY añade parámetros de una transacción. La utilidad es real: el servicio deja de inferir identidad únicamente desde una dirección IP o un User-Agent. Pero lo validado responde “¿qué afirma este emisor sobre esta solicitud?”, no “¿qué debe hacer mi aplicación?”.

El borrador revisado hace explícita esa distancia. El token entra en una política configurada por el sitio. Según el riesgo, la salida puede ser admisión, limitación, verificación reforzada o denegación. Convertir el conjunto en un semáforo verde universal ocultaría los niveles de seguridad que el propio formato preserva.

Tampoco debe adelantarse el estatus institucional. Ambos documentos son Internet-Drafts individuales. Las copias congeladas de Datatracker no muestran stream, nivel de estándar ni adopción de grupo. La lista de OAuth es el foro indicado para conversar, no evidencia de consenso. Las solicitudes de campos HTTP y claims JWT siguen siendo propuestas mientras no aparezcan en los registros activos de IANA.

La validación útil es una secuencia, no una casilla. El destinatario elige emisores de confianza, valida cabecera y firma JOSE, comprueba exp, iat, jti, aud y entorno, identifica KYA o PAY y evalúa por separado la seguridad atribuida a persona, plataforma y agente. Que exista una cabecera KYAPay-Token no prueba que haya un humano presente.

El modo bearer deja una exposición propia. Quien obtenga el token puede presentarlo mientras siga vigente. TLS, vida breve, audiencia limitada y una memoria de jti dificultan captura y repetición, pero no demuestran que el emisor de la solicitud controle una clave privada del agente.

La revisión 02 del formato admite cnf, en línea con el modelo de confirmation claims. Esa referencia puede participar en un token ligado al emisor sólo cuando otro mecanismo exige y verifica una prueba efectiva. El nombre de una clave dentro del JWT no es la prueba. Por eso conviene almacenar “firma válida” y “posesión validada” como hechos distintos.

La autorización humana también envejece. Según el texto, un token válido dice que el principal autorizó al agente en el momento de emisión. No garantiza supervisión durante toda la vida. El host puede ser comprometido, la plataforma dada de baja o el mandato retirado. La revisión 01 no define revocación. Una acción sensible necesita una señal reciente en vez de estirar una afirmación antigua.

La firma tampoco califica al emisor. Sólo muestra que una clave seleccionada firmó el objeto. No certifica la calidad de la prueba de identidad, el registro del agente o los controles de plataforma. El propio borrador llama problema abierto a la confianza escalable entre emisores y reconoce arreglos fuera de banda. La lista de confianza y su versión son parte del recibo, no configuración invisible.

PAY merece la misma disciplina. Vincular comercio, importe y moneda, y usar un identificador acotado con criptograma único, reduce reutilización y permite cotejar intención. No demuestra que el comercio aceptara, que una red autorizara, que hubiera compensación, que la liquidación sea final o que se entregara el bien. Es evidencia previa a varios acontecimientos independientes.

El recibo operativo debería conservar borrador y perfil exactos; emisor y juego de claves; evidencia y seguridad declaradas; hash inmutable del token; resultados de firma y claims; audiencia y entorno; decisión de repetición; bearer o prueba de posesión; política y step-up; y acción final. En pagos, debe enlazar, sin fusionar, autorización, compensación, liquidación y reversión.

La Especificación Inicial Mínima de Heng Lu ofrece el criterio correcto: compartir el vocabulario mínimo y los invariantes que permiten interoperar, dejando la consecuencia donde existe el riesgo. La primacía del código en ejecución obliga a probar el resultado real de la aplicación. Las capas de realidad impiden llamar “autorizado” a una mezcla de afirmación, criptografía, posesión, política y efecto visible.

El término “recipient” devuelve el verbo decisivo a su dueño. El emisor afirma; el token transporta; el validador comprueba. El destinatario decide y la aplicación registra qué ocurrió.

Fuentes