Resumo

  • Publicada em 2 de outubro de 2026, a revisão 01 de Using KYAPay Tokens troca “verifier” por “recipient” e afirma que identificação não é admissão. Um token válido oferece contexto autenticado; aceitar, limitar, pedir uma etapa adicional ou negar continua sendo decisão local.
  • A validade não resolve etapas posteriores. Um bearer token não comprova posse de chave privada, autorização na emissão não comprova controle humano contínuo e um token PAY não comprova aceitação do comerciante nem liquidação financeira.

A revisão mais importante do uso de KYAPay não está em uma curva criptográfica. Está no nome dado ao sistema que recebe o token. draft-skyfire-oauth-using-kyapay-tokens-01 abandona “verifier” e adota “recipient”, deixando claro que a validação não encerra a decisão.

Um servidor de recursos, provedor de borda, gestor de bots, motor antifraude, proteção contra tomada de conta ou plataforma de identidade pode chegar ao mesmo resultado de assinatura. Ainda assim, cada um enfrenta consequências diferentes e pode admitir, reduzir velocidade, exigir autenticação adicional ou rejeitar. Receber evidência comum não significa executar política comum.

KYA organiza afirmações sobre o principal humano, a plataforma do agente e a instância do agente. PAY acrescenta o contexto de pagamento. Isso substitui parte das inferências frágeis baseadas em IP e User-Agent por coordenadas assinadas. Mas a pergunta respondida é “o que este emissor declara sobre a origem?”, não “o que o meu sistema deve permitir?”.

O texto novo separa identificação de admission de forma explícita. O token chega a um mecanismo de política configurado pelo destinatário. Uma consulta pública pode aceitar segurança menor; recuperação de conta, exportação de dados ou compra de alto valor podem pedir prova adicional e presença humana recente. Um selo verde único apagaria essa diferença.

O estado institucional também requer cuidado. Os dois textos continuam sendo Internet-Drafts individuais. Os registros congelados do Datatracker não mostram stream, nível de padrão ou adoção por Working Group. A lista OAuth é o local de discussão, não comprovação de consenso. Campos HTTP e claims JWT pedidos só existem como alocações quando os registros vivos da IANA os exibirem.

O processamento é uma cadeia de controles. O destinatário decide quais emissores aceita, valida cabeçalho e assinatura JOSE, depois exp, iat, jti, aud e ambiente. Identifica KYA ou PAY e avalia separadamente a segurança atribuída à pessoa, à plataforma e ao agente. A presença de KYAPay-Token sozinha não comprova presença humana.

O perfil padrão descreve bearer tokens. Quem capturar um token pode tentar apresentá-lo dentro da validade. TLS, prazo curto, audience restrita e memória contra replay reduzem o risco, mas não demonstram que o remetente controla uma chave privada do agente.

A revisão 02 do formato permite cnf, que pode indicar material de chave de confirmação. A restrição ao remetente só nasce quando o protocolo exige uma prova e o destinatário realmente a verifica. Uma referência à chave dentro do objeto assinado não é essa prova. Assinatura correta e posse comprovada precisam ser resultados distintos.

Há ainda o envelhecimento da autoridade. Segundo o draft, o token válido atesta que o principal autorizou o agente no momento da emissão. Não mostra que a pessoa manteve o controle durante todo o prazo. O host pode ser comprometido, a plataforma pode perder registro e o mandato pode ser retirado. A revisão 01 não define revogação; ações sensíveis precisam de sinal mais recente.

Confiar no emissor é uma escolha do destinatário. Uma assinatura correta comprova a chave que assinou, não a qualidade da verificação de identidade, do registro do agente ou dos controles da plataforma. O documento chama a confiança escalável entre emissores de problema aberto e admite acordos fora de banda. Por isso, a versão da trust list pertence ao recibo da decisão.

O PAY não deve ser confundido com um extrato. Ele pode vincular destino, valor e moeda e transportar credencial limitada à transação com criptograma de uso único. Isso ajuda a detectar reuso e divergência de parâmetros. Não comprova aceitação pelo comerciante, autorização da rede, compensação, liquidação final, ausência de estorno ou entrega.

Um recibo defensável preserva draft e profile exatos; emissor e conjunto de chaves; evidência e nível de segurança; hash imutável do token; resultados de assinatura e claims; audience e ambiente; decisão de replay; bearer ou prova de chave; política e step-up; e ação final da aplicação. Em pagamentos, autorização, compensação, liquidação e reversão entram como registros separados.

A Especificação Inicial Mínima de Heng Lu sustenta essa divisão: compartilhar claims e invariantes suficientes para interoperar, sem centralizar decisões sensíveis à consequência. A primazia do código em execução exige conferir a ação real da aplicação. As camadas da realidade impedem que afirmação, criptografia, posse, política e efeito para o usuário sejam comprimidos em “autorizado”.

O novo “recipient” localiza a responsabilidade. O emissor afirma, o token transporta, o validador confere. O destinatário governa a própria interface e a aplicação registra o que fez.

Fontes