Resumo

  • A primeira etapa do AIP valida a assinatura com a chave apresentada; a segunda confere se essa chave está vinculada ao agentDid no cadastro do verificador ou em um documento DID resolvido.
  • A revisão 03 distingue a autoridade de did:web, restrita ao provedor, daquela de did:opena2a, voltada ao ecossistema. Tipo, propósito e capacidade autodeclarados não concedem autorização.

Uma equipe de fraude recebeu duas respostas com aparência igualmente correta. Ambas estavam dentro da janela de cinco minutos, usavam nonces inéditos e continham assinaturas válidas. Uma correspondia à chave cadastrada para o agente. A outra apenas se verificava com a chave que ela própria trazia.

O cálculo não diferenciava as respostas porque essa não era a pergunta do cálculo. Ele demonstrava que cada remetente possuía a chave privada associada à chave pública apresentada. Somente uma fonte independente poderia dizer qual chave estava autorizada a representar o agentDid.

Essa é a fronteira operacional da revisão 03 do OpenA2A Agent Identity Protocol (AIP). Publicada em 2 de outubro de 2026, ela é um Internet-Draft individual com expiração em 3 de abril de 2027. Não é RFC, produto de grupo de trabalho, consenso do IETF nem evidência de implantação. O texto pretende Standards Track; intenção editorial não equivale a status aprovado.

O que entra na assinatura

O verificador emite um desafio com 32 bytes aleatórios, o agentDid alegado, nonce aleatório de 16 bytes, issuedAt, expiresAt e issuerDid. Os horários usam UTC no formato RFC 3339 e a validade é de cinco minutos.

A entrada assinada é:

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

A resposta inclui também publicKey, keyId, signedAt e algorithm. Esses quatro campos não estão na cadeia assinada. A chave embutida permite testar a posse, mas não pode declarar a própria legitimidade. Se a política aceitar qualquer identidade cuja assinatura valide sob a chave enviada por ela, gerar um par de chaves basta para cumprir a política.

O resultado correto da etapa um é limitado: assinatura válida sob a chave apresentada. “Agente autenticado” só pode aparecer depois de uma fonte de vínculo.

A segunda regra vem de fora da resposta

O AIP manda verificar a assinatura e, em seguida, comparar a chave apresentada com a chave já vinculada ao agentDid no registro local ou em um documento DID resolvido. O rascunho diz explicitamente que a publicKey embutida não deve ser confiada sozinha.

Validade temporal, nonce de uso único e issuerDid confiável são controles adicionais. Nenhum deles cria pertencimento. Uma assinatura recente e não repetida feita por uma chave sem vínculo continua sem vínculo.

Essa divisão precisa aparecer nos registros operacionais. O serviço criptográfico pode estar saudável enquanto o resolvedor está fora do ar, usa cache vencido ou devolve um documento adulterado. Um DID correto também não salva uma assinatura incorreta. Um único campo booleano elimina a capacidade de reconstruir o erro.

Dois escopos, dois centros de controle

Na revisão 03, identidades restritas ao provedor usam did:web, e o provedor publica o documento DID. Domínio, TLS, pipeline de publicação, cache e recuperação deixam de ser detalhes de hospedagem e passam a controlar identidade.

did:opena2a é reservado a identidades de escopo ecossistêmico; o provedor de identidade não publica esses documentos. A forma antiga did:aip:aim_ vira alias obsoleto. O identificador deve ser tratado como opaco e encaminhado ao resolvedor adequado, sem inferir confiança do prefixo.

Essa distinção distribui poder. A identidade did:web herda a disponibilidade e a autoridade de recuperação do provedor. A identidade ecossistêmica depende de outra governança, outro mecanismo de atualização e outra forma de resolver disputas. Um fallback silencioso entre os métodos transfere autoridade, mesmo quando é vendido como compatibilidade.

O texto observa que, em 8 de setembro de 2026, o resolvedor da implementação de referência respondia apenas ao alias anterior. Isso não prova o estado atual de uma implantação, mas revela o risco de migração: o método especificado pode não ser o método que o código entende. O recibo de decisão deve dizer qual método e qual documento foram realmente usados.

Atributos não escrevem permissões

O type do agente é informativo e não deve orientar decisões de segurança. O declaredPurpose opcional pode contextualizar identidade ou atestação, porém sua ausência não autoriza rejeição e sua presença não pode entrar como autorização.

“Agente de compras” e “assistente de pesquisa” parecem funções, mas continuam declarações próprias sem evidência independente. Uma pontuação de confiança também deve usar entradas verificáveis, não dados autorrelatados.

Mesmo o vínculo correto só autentica. Ele não mostra que o agente podia executar aquela operação, que ela ocorreu corretamente ou que o sistema externo chegou ao resultado pretendido. Desafio, assinatura, resolução, confiança do emissor, autorização, execução e resultado exigem recibos distintos.