Resumo

  • Datado de 6 de setembro de 2026 e atualizado no Datatracker no dia 7, draft-zhang-dawn-agent-discovery-framework-01 é um Internet-Draft individual ativo, sem posição formal no processo de padronização do IETF.
  • A arquitetura divide a descoberta local da federação entre domínios. Um gateway aplica política de exportação, sanitiza metadados e assina um Federation Metadata Record para pares autenticados.
  • A revisão 01 liga o modelo MDI aos campos do FMR. Há origem, capacidade, validade e proveniência, mas não audiência autorizada, regra de repasse ou versão da política que aprovou a saída.
  • Daniel Kade propõe um envelope de distribuição vinculado ao hash do registro. Ele guardaria a decisão de compartilhamento sem certificar identidade, confiança, competência ou permissão para acionar o agente.

Antes do protocolo, o estado institucional

O Datatracker apresenta o texto de Bin Zhang como submissão individual. Não há RFC stream, Area Director responsável ou telechat. O próprio documento se define como informativo. Portanto, a nova versão oferece material para debate; não prova que o IETF tenha escolhido essa arquitetura.

O cuidado vale também para a expressão “grupo de trabalho DAWN” usada no rascunho. A página oficial da DAWN ainda classifica o grupo como BoF e informa que ele não foi constituído por charter. As atas do IETF 126 registram uma reunião destinada a avaliar a formação do grupo, com uma proposta de charter que ainda não representava consenso. O vocabulário de uma contribuição individual não antecipa essa decisão.

Respeitado o limite, a revisão 01 faz uma separação útil. Dentro do site, o Local Discovery Plane coleta anúncios por mDNS, diretórios de agentes ou outro mecanismo local. Na fronteira administrativa, o Federation Gateway escolhe o que pode sair. Seu Export Policy Engine esconde agentes, remove dados sensíveis e produz um FMR leve para intercâmbio externo.

O Capability Card completo fica no site de origem. Quem precisar dos detalhes deve buscá-los por unicast autenticado, sujeito a controle de acesso. A federação sincroniza apenas o índice. Além de reduzir volume, a arquitetura permite mostrar listas diferentes a pares diferentes. A decisão inicial de exportação é o ponto concreto de soberania de dados.

Um mapa novo deixa a ausência mensurável

A comparação oficial entre as versões 00 e 01 acrescenta a correspondência entre Minimum Discoverable Information e Federation Metadata Record. A política pode agora ser confrontada com os campos que de fato atravessam o limite.

O registro pode levar identificador e tipo da entidade, endpoint quando acessível, resumo de capacidade e referência ao Capability Card. Também contém dica de autenticação, referência de confiança, data de publicação, TTL, proveniência, identificador do gateway de origem e sinalizador do registro. Um Geographic-Hint aproxima o Scope Hint do MDI.

O receptor consegue confirmar o gateway que originou os bytes, avaliar se o registro está válido e localizar a descrição rica. A proveniência sobrevive à mudança de domínio sem que a federação copie todo o documento sensível.

Mas o mapa não diz quem pode receber a ficha depois da primeira entrega. Não há classe de confidencialidade, conjunto de audiência, proibição de redistribuição, limite de saltos, identificador de política ou época. A dica geográfica indica contexto espacial, não autorização. O TTL determina quando o dado envelhece, não onde pode circular antes disso. Proveniência registra de onde veio, não os termos do compartilhamento.

No primeiro salto, o gateway A mantém o contexto da decisão: envia uma versão a B e nada a C. O texto permite explicitamente subconjuntos por par. Quando B insere o FMR em seu diretório federado e entra em outra sincronização, porém, o registro não informa se A autorizou o caminho até D.

Autenticidade não concede redistribuição

A arquitetura exige que o gateway de origem assine cada FMR. O receptor verifica a assinatura e descarta o que falhar. Isso impede um membro de alterar silenciosamente o registro de outro gateway ou assinar em seu nome. O limite também é explícito: um participante malicioso já admitido pode inventar alegações sobre seus próprios agentes locais. A admissão à federação depende de política administrativa fora do protocolo.

Se B entregar a D exatamente os bytes assinados por A, D poderá confirmar a origem. Essa prova não mostra que A incluiu D entre os destinatários permitidos. “Produzido por A” e “autorizado para D” continuam afirmações distintas.

O modelo de peering estruturado pode sustentar a segunda afirmação por configuração. O apêndice prevê importação e exportação por par. Em uma federação fechada, operadores conhecem as sessões, podem restringir reflexão e reconstituir o caminho de um vazamento.

O modelo gossip busca escala e resistência. Cada gateway troca resumos de seu Federated Agent Directory com poucos vizinhos e envia os registros novos ou ausentes. O próprio rascunho reconhece a dificuldade de aplicar políticas precisas por registro nesse modelo. Em uma federação mista, um bridge pode transportar o FMR comum entre peering estruturado e gossip. A carga comum melhora a interoperabilidade, mas uma restrição mantida apenas na configuração do primeiro transporte não aparece magicamente no segundo.

Gossip não precisa ser descartado. O que não deve acontecer é transformar uma assinatura válida numa licença silenciosa de cópia.

Um envelope pequeno para a decisão

O FMR pode continuar leve se uma distribution-envelope for ligada criptograficamente ao seu hash exato. Ela indicaria gateway de origem, identificador e época da política. Definiria uma classe de audiência ou segmento nomeado da federação e escolheria a regra de continuidade: não redistribuir, entregar apenas ao próximo salto indicado ou circular num segmento limitado.

O envelope teria validade, ponteiro de retirada ou revogação e um identificador opaco do recibo de exportação. A origem poderia conferir a saída do Policy Engine sem publicar sua configuração confidencial. Na tradução entre protocolos, um recibo do salto anterior mostraria qual bridge assumiu a obrigação de manter o limite.

Um par desonesto ainda consegue copiar dados fora do protocolo. A mudança produz outra forma de controle: software compatível pode recusar o repasse, o log pode registrar a política aplicada e o auditor pode separar um caminho permitido de um registro apenas autêntico. Um bridge incapaz de preservar a condição deve rejeitar a conversão, não eliminar a condição em silêncio.

O mecanismo não é um contêiner para tudo que a DAWN deixou em aberto. Emissão de identificadores estáveis, avaliação abrangente de confiança, negociação de capacidades, indexação aberta da Internet e governança comercial são declaradas fora do escopo. O envelope não diz se o agente é seguro ou se deve ser acionado. Só conserva a resposta a uma pergunta limitada: sob qual política estes metadados podem seguir adiante?

Fontes