Resumo

  • A página do W3C atribui w3.org/2026/08/xmldsig-more# ao XML Security, porém aponta para o rascunho mais recente, sem fixar número de revisão ou hash.
  • A revisão -08 ainda usava w3.org/tbd#; a -09, de 21 de agosto, adotou o namespace e acrescentou outros elementos. A data da página do W3C fica dois dias antes.
  • A orientação do próprio W3C diz que uma política deve explicar como nomes são definidos ou removidos e por quem. A página não faz isso, e seu silêncio não prova mutabilidade nem imutabilidade.
  • Uma constituição de mudança deve registrar versão e hash no momento da alocação, classes de edição permitidas, tratamento de compatibilidade, ato de congelamento e estados separados de W3C, IETF e IANA.
  • Não há evidência de alocação inválida, endosso de algoritmo, adoção pelo IETF, atraso da IANA ou fracasso da cooperação. A lacuna é de legibilidade institucional.

O endereço ficou estável enquanto o documento continuou em movimento

A página do namespace do W3C diz que o URI foi alocado ao XML Security, relaciona-o ao RFC 9231bis por meio do Datatracker e informa uma última revisão por Simone Onofri em 19 de agosto de 2026. Ela não identifica uma versão numerada, um hash, a decisão de autorização ou a regra para mudar nomes locais.

Alocar cedo não é, por si, precipitação. Um identificador persistente elimina marcadores improvisados, evita colisões e permite que especificações e implementações conversem antes do fim do processo. O W3C pode oferecer essa infraestrutura sem aprovar os algoritmos ou o texto que a utiliza.

O link dinâmico resolve a descoberta do presente, não a reconstrução do passado. Quem consulta a página encontra a última versão. Não descobre quais bytes fundamentaram a permissão nem se a permissão abrangia edições feitas depois.

A conversa pública mudou de formato

A issue 484 do W3C Strategy foi aberta em 17 de novembro de 2024 para propor um workshop sobre criptografia pós-quântica em XML Signature e XML Encryption. É uma evidência valiosa de coordenação aberta. Não é Recommendation, charter ou decisão formal.

Em 21 de novembro de 2024, o autor do rascunho individual ofereceu-se para incluir algoritmos no RFC 9231bis. Em 14 de junho de 2025, um comentário listou HSS/LMS, ML-DSA, SLH-DSA e ML-KEM e cogitou trocar o workshop pelo acompanhamento na própria issue. Proposta de autor e lista de discussão ajudam o trabalho, mas não criam consenso do W3C nem adoção do IETF.

Em 17 de agosto de 2026, a conversa registrou que -08 incluía as quatro famílias acompanhadas e que -09 receberia material adicional. A página do namespace é datada do dia 19. A publicação de -09 foi anunciada no dia 21. Em 26 de agosto, a função pública da issue foi redefinida: não mais organizar o workshop, mas acompanhar as necessidades de atualização.

Essa adaptação é sinal de trabalho vivo, não de falha. Exatamente por isso uma permissão de namespace precisa ter memória própria. O fórum e o texto podem mudar; o URI continuará circulando.

As fontes não revelam os bytes exatos examinados pelo W3C. Também não autorizam afirmar que nenhum registro interno existe. A constatação é menor e verificável: a página pública não faz a ligação.

Intenção editorial e estado institucional não são sinônimos

No corte da pesquisa, o Datatracker mostrava -09 como Internet-Draft individual ativo, em I-D Exists, sem RFC stream definido e sem Area Director responsável. Depositar um Internet-Draft é parte normal do trabalho aberto; não significa que o IETF o adotou.

O cabeçalho do texto diz Independent, Obsoletes: 9231 (if approved), pretende Standards Track e expira em 22 de fevereiro de 2027. Isso descreve a intenção do autor e um efeito condicional. Os metadados descrevem a posição institucional atribuível. Não há contradição necessária.

A versão -08, de 26 de maio, ainda usava w3.org/tbd#. Seu SHA-256 é cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

A versão -09, de 21 de agosto, substituiu os marcadores por w3.org/2026/08/xmldsig-more#, incorporou um schema da nova geração e acrescentou outros conteúdos. Seu SHA-256 é 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

O histórico público confirma as datas, sem registrar adoção de Working Group, stream ou Area Director.

A cronologia prova que a página de 19 de agosto antecede em dois dias a primeira revisão arquivada que usa o namespace. Não prova quando a decisão de alocação ocorreu, o que foi examinado ou se todo o restante de -09 fazia parte da permissão.

Três instituições, três atos

O ponto aprovado continua sendo o RFC 9231. Ele documenta a geração anterior e já separa o identificador de qualquer status oficial do algoritmo no W3C ou no IETF.

O registro XML Security URIs da IANA segue corretamente vinculado ao RFC 9231, com política Specification Required e especialistas designados. Enquanto o sucessor não for aprovado ou não houver outra ação válida, esse é o estado esperado, não atraso.

O W3C controla um URI em seu espaço web. Um processo do IETF pode desenvolver, adotar, avaliar e eventualmente aprovar uma especificação. A IANA aplica a política do registro. O autor controla o texto de um rascunho, não a política do namespace do W3C. O W3C aloca um endereço, não aprova um RFC. A IANA registra identificadores, não manda implantá-los.

O registro que falta não deve fundir essas competências. Deve mostrar a sequência e o limite de cada uma.

A política geral do W3C já contém o teste

O guia de namespaces do W3C reconhece formatos datados e diz que @w3c/transitions aloca e autoriza os formatos listados em pull requests de w3c/ns. Explica que a persistência durante a discussão é útil e que alocação não significa endosso.

O mesmo guia recomenda que os grupos declarem como os namespaces sob seu controle mudarão ou não mudarão, no documento do namespace ou em link claro a partir dele.

O finding do TAG é explícito: se um namespace não for imutável, a especificação deve dizer como nomes podem ser definidos ou removidos e por quem. Sem declaração expressa, não se pode inferir imutabilidade.

O silêncio também não prova o contrário. A ausência de política não torna os nomes livremente editáveis. Ela deixa o estado indeterminável para o leitor público.

A política de persistência de URI inclui recursos datados na promessa de persistência e admite modificação com preservação de histórico. Manter o endereço não é congelar cada nome abaixo dele.

Isso não basta para declarar uma violação. Pode haver uma autorização válida não ligada à página. O pedido é publicar a política no lugar onde a própria orientação do W3C diz que ela deve ser encontrada.

As gerações anteriores mostram que congelar é uma decisão

-09 chama o prefixo de 2000 de “Frozen by W3C” e liga os prefixos de 2001, 2007 e 2021 aos RFCs 4051, 6931 e 9231. Cada congelamento tem uma procedência.

Para 2026, ainda não se sabe publicamente se um nome pode ser adicionado ou retirado antes do RFC, se um nome já usado precisa ser reservado, se a aprovação do RFC congela automaticamente ou se há ato separado do W3C, e se extensões futuras exigem outra data.

O objetivo não é escolher as respostas de fora. É impedir que dependências instaladas as escolham por inércia.

URI não é laudo de segurança

XML Signature 1.1 e XML Encryption 1.1 mostram por que estruturas XML precisam de identificadores interoperáveis. Não aprovam automaticamente todos os algoritmos que venham a ser nomeados.

O RFC 8126 descreve Specification Required como exigência de especificação permanente e pública, além de revisão especializada. É uma forma de governar entradas, não uma certificação geral de segurança ou implantação.

Este artigo não compara algoritmos e não afirma que qualquer um seja seguro, inseguro, final, implementado ou amplamente adotado. O problema de governança existiria para qualquer vocabulário persistente definido por um documento móvel.

Uma constituição enxuta

A primeira seção deve registrar URI, classe datada, decisão de alocação, ator, data e pull request ou transição pública. A versão e o hash examinados na alocação devem aparecer ao lado — mas separados — da versão hoje apontada.

A segunda deve classificar adição, correção, renomeação, remoção e depreciação de nomes. Para cada classe: quem propõe, quem decide e como referências já publicadas são tratadas.

A terceira deve nomear o evento de congelamento, a autoridade e a data. A regra pós-congelamento dirá se uma extensão usa o mesmo prefixo, revisão da IANA, errata, RFC sucessor ou novo namespace datado.

Depois vêm os estados institucionais: responsável pela custódia no W3C; classe, grupo, stream, adoção e Area Director no IETF, quando existirem; estado e política da IANA. A fonte da sintaxe do identificador deve ser separada da fonte da semântica do algoritmo. Correção, sucessão, expiração e próxima revisão completam o histórico.

Alocar namespace, publicar rascunho, adotar ou atribuir stream, aprovar RFC, atualizar IANA e implantar tecnologia são seis ações diferentes. Nenhuma substitui a próxima.

Não é preciso publicar debate privado ou material técnico sensível. Versão, autoridade, classe de mudança e transição bastam para tornar a história verificável.

A crítica é sobre leitura, não conduta

Há muita coisa certa no expediente: issue aberta, revisões arquivadas, URI persistente, registro IANA coerente e alertas contra endosso implícito. Não há evidência de má-fé, captura, registro indevido ou cooperação fracassada.

O ajuste é proporcional. O link dinâmico continua mostrando o presente; o recibo versionado passa a explicar a permissão passada e os limites do próximo editor.