Resumo

  • O Datatracker da IETF mantém o pedido de BoF do AUDIT em estado Declined. A lista não-WG aberta em 31 de agosto serve para revisar uma proposta de BoF e de charter, mas não criou um Working Group.
  • O IESG reconheceu o valor de auditar ações de agentes, considerou amplo demais o escopo apresentado e pediu uma demonstração melhor das lacunas deixadas por OAuth, WIMSE, OpenTelemetry e trabalhos relacionados.
  • O draft individual separa registros de interação, ação, delegação e transição de autorização. Ele próprio não resolve recusa de registro, conluio de todos os papéis, alinhamento do modelo nem ainda um threat model detalhado.
  • Um recibo público de estado de autoridade deve distinguir fórum, decisão de BoF, charter, adoção de documento, revisão da IETF, publicação de RFC e implantação real.

Duas verdades que cabem no mesmo registro

Em 31 de agosto, a Secretaria da IETF anunciou a lista AUDIT. É correto enxergar continuidade: os proponentes agora dispõem de um canal próprio para reduzir o problema, examinar sobreposições e escrever uma proposta mais defensável. É incorreto converter essa continuidade em aprovação retroativa.

O pedido de BoF do AUDIT, versão 02, ainda aparece com o tipo “Declined BOF request” e o estado “Declined”. O índice geral de pedidos de BoF confirma o enquadramento. A ficha foi atualizada pela última vez em 6 de julho e não traz liderança responsável. Os Security Area Directors e Yaroslav Rosomakho aparecem no texto como ADs e chair propostos. O adjetivo é parte da evidência: proposta não é nomeação.

A descrição da nova lista também preserva a fronteira. O índice de listas não-WG diz que ela discutirá um possível BoF AUDIT, atualizará um charter proposto e trabalhará na direção de formar um novo WG. No corte, o arquivo público continha apenas o anúncio de criação. Há um futuro institucional em construção, não um presente escondido.

As diretrizes para listas não-WG contemplam explicitamente canais destinados a formar um WG. Um Area Director apropriado aprova o pedido da lista. O objeto dessa decisão é a infraestrutura de discussão; BoF, charter, milestones e chairs exigem atos próprios.

O RFC 2418 deixa clara a diferença. Um WG opera sob charter limitado, responsáveis nomeados e processo reconhecido. Ele precisa de mailing list. Mas não se pode inverter a implicação: a existência da lista não produz o grupo, assim como uma audiência aberta não produz por si só uma decisão vinculante.

O histórico não precisa escolher uma palavra única

O retorno do IESG de 3 de junho usou “deferred”. O texto foi preservado na resposta dos proponentes em 5 de junho. Ali, a ideia de auditar atos de agentes foi considerada boa, mas a proposta atual, ampla demais. O IESG pediu um recorte menor, diálogo com OAuth e WIMSE e uma explicação sobre por que o trabalho existente ou um perfil de OpenTelemetry não atenderia à necessidade. Também indagou se certas noções de intenção e política estariam mais bem tratadas em um quadro jurídico do que em uma arquitetura de protocolo.

Os autores questionaram o significado processual e o momento do adiamento, defenderam a necessidade de reunir provas produzidas sob administrações diferentes e mantiveram a discussão de escopo. A troca registra uma divergência substantiva e oferece matéria para nova versão. Não funciona como votação substituta.

Um relato fiel mantém “deferred” como linguagem daquela comunicação e “Declined” como estado atual do Datatracker. O primeiro não é uma aprovação ainda não revelada; o segundo não é uma sentença eterna contra o tema. Data, fonte e autoridade permitem que uma revisão futura crie um estado novo sem reescrever o anterior.

Essa disciplina evita o salto analisado por Heng Lu no ensaio sobre a miragem multistakeholder: comparecer e participar não identificam automaticamente um principal, nem fornecem procuração para representá-lo. Em padrões, “discutido na IETF” não pode virar “aprovado pela IETF” apenas porque ambas as frases soam próximas.

Uma arquitetura para evidências que não moram juntas

O draft de arquitetura AUDIT, datado de 18 de maio, tenta resolver um problema concreto. Uma pessoa instrui um agente; o agente delega, chama ferramentas em domínios diferentes, solicita elevação de permissão e produz um efeito. Logs locais podem ser corretos e, ainda assim, não ligar intenção inicial, poder transmitido, alteração de autorização e ato realizado.

O documento distribui a prova em quatro famílias. Interaction Records guardam prompts, respostas e aprovações na superfície do usuário. Action Records descrevem o que aconteceu no limite de execução. Delegation Records delimitam a autoridade passada a outro ator. Authorization Transition Records registram concessão inicial, step-up, redução, revogação e expiração.

Um contexto de auditoria compartilhado relacionaria eventos e referências anteriores. Cada participante produziria sua própria perspectiva, e um audit store parcialmente confiável poderia normalizar o material. Serviços de atestação ou transparência seriam reforços opcionais. O ganho conceitual é separar três perguntas: o que foi solicitado, o que era permitido e o que de fato ocorreu.

O draft também expõe falhas que a palavra “audit” poderia ocultar. O agente não é presumido confiável. O store recebe apenas confiança parcial. A arquitetura não obriga um serviço a registrar o que aconteceu em sua fronteira, não resolve conluio entre todos os papéis relevantes e não resolve o alinhamento do modelo. A análise de segurança e o threat model detalhado ainda são trabalho futuro. Um conjunto autêntico pode não ser completo.

Quanto mais rica a prova, maior a superfície de privacidade. Interações revelam intenção e conteúdo; ações revelam ferramentas, relações e operações; um identificador global permite correlacionar uma pessoa entre empresas. Até o registro de um hash revela que houve um evento em determinado instante. Accountability sem minimização pode construir a infraestrutura de vigilância que deveria limitar.

O draft individual sobre conversas verificáveis de agentes oferece um possível formato para a camada de interação. Não foi adotado por um WG AUDIT, pois o WG não existe. Assinar uma conversa tampouco resolve retenção, redação, divulgação seletiva e vínculo com ações posteriores sem identificador persistente.

As tecnologias vizinhas respondem a perguntas diferentes

O pedido de uma análise mais forte de sobreposição protege tanto os grupos existentes quanto o eventual AUDIT.

O RFC 8693, OAuth Token Exchange, representa delegação e cadeias de atores em trocas de token. Ele ajuda a provar que autoridade foi transportada, mas não conta sozinho a instrução humana, todas as transições seguintes, o resultado e o julgamento de política. O protocolo básico deixa fora semântica detalhada, propriedades de segurança e modelos de confiança dos tokens.

O W3C Trace Context propaga identificadores para correlacionar partes de uma requisição distribuída. A correlação indica que eventos pertencem a um fluxo; não declara permissão, redução de delegação, aprovação do usuário ou correção do ato. Continuidade operacional não é cadeia de autoridade.

O RFC 9334, arquitetura RATS, organiza Evidence, Verifier, Attestation Result e a decisão do Relying Party. É útil para avaliar componente ou ambiente. Não estabelece poder jurídico nem fidelidade ao sentido humano. Um dispositivo íntegro pode executar perfeitamente uma instrução não autorizada.

O RFC 9943, arquitetura SCITT, fornece statements assinados, serviços de transparência append-only e receipts de registro ou inclusão. Isso torna exclusão e alteração retroativa mais detectáveis. Não torna verdadeiro o conteúdo, não prova completude e não converte integridade em consentimento.

O mapa de escopo deve dizer quais mecanismos pertencem a OAuth, WIMSE, observabilidade, RATS, SCITT ou HTTP e qual junção entre domínios continua sem dono. O AUDIT só terá contorno defensável se assumir esse resíduo sem redesenhar cada peça adjacente.

Um recibo para a autoridade de padronizar

O projeto técnico quer descobrir quem autorizou uma ação de agente. O processo institucional deve permitir descobrir quem autorizou cada etapa do próprio projeto. A simetria é importante: nos dois casos, ter um registro ou um lugar de participação não substitui o principal que confere poder.

Um authority-state receipt começaria por uma identidade estável do problema e a versão exata da proposta. Registraria o estado corrente—proposal, BoF deferred/declined, discussão não-WG, BoF aprovado, chartering, WG ativo ou concluído—e o ator competente para criá-lo. A decisão original, data e URL seriam mantidas sem ampliar a redação.

Cada revisão mostraria o delta: o que saiu, o que ficou com grupos vizinhos e qual lacuna permaneceu. ADs e chairs seriam “propostos” até nomeação. Venue e autoridade teriam campos distintos. Charter sem aprovação seria null; quando aprovado, teria revisão e data. Documento individual e WG-adopted seriam identidades separadas, ligadas pelo ato de adoção.

WG Last Call, IETF Last Call, avaliação do IESG e objeções pendentes não seriam comprimidos em “em padronização”. Publicação indicaria Internet-Draft, stream e categoria de RFC. Implementação e política operacional ficariam em outra camada. Um RFC não prova implantação; uma implantação de draft não prova consenso.

O histórico precisaria ser imutável em significado. Se um novo BoF for aprovado, ele apontará para o pedido recusado e mostrará a diferença que alterou o resultado. Uma adoção posterior não transformará retroativamente versões individuais em produtos do WG. A trilha explica como o mandato foi conquistado.

Para AUDIT, o recibo atual seria: existem drafts individuais; houve pedido de BoF versão 02 e feedback de escopo; o Datatracker o marca Declined; uma lista não-WG agora prepara um possível novo BoF e charter; não existem liderança responsável nomeada, charter aprovado, Working Group, adoção ou consenso IETF.

O direito de correlacionar precisa de autorização

Uma proposta revisada deveria minimizar dados por família de registro. Conteúdo que não precisa atravessar fronteiras pode ficar destacado, representado por hash ou revelado seletivamente. Identificadores opacos ou por pares devem substituir identificadores globais sempre que a correlação universal não for necessária. Capacidade técnica de juntar não é permissão para juntar.

O auditor requer autorização separada e finalidade definida. Depuração, contrato, investigação de segurança e obrigação regulatória têm retenções diferentes. Lacunas, recusas e evidências indisponíveis devem aparecer no resultado. Um sistema não pode fabricar continuidade silenciosa nem alegar que seu receipt cobre todos os fatos quando só cobre um registro.

A nova lista é o lugar apropriado para transformar essas fronteiras em entregas verificáveis: separar protocolo, perfil de implantação, controle organizacional e obrigação jurídica; exigir privacidade e threat model; reduzir o uso de “intenção” até um objeto tecnicamente tratável. Chamá-la de lista, e não de WG, protege a credibilidade desse trabalho.