Renovação do DID no W3C precisa de um registro de estado

Resumo

A carta atual do DID Working Group, adotada em 2024 e prorrogada até 28 de outubro de 2026, já dá base ao trabalho de DID Resolution no Recommendation Track. A renovação não precisa fabricar autoridade retroativa.
Em 6 de agosto, o DID Resolution tornou-se Candidate Recommendation Snapshot. Esse Patent Review Draft abriu uma oportunidade de exclusão até 5 de outubro e definiu critérios de implementação por funcionalidade; não transformou o texto em Recommendation nem em endosso do W3C.
O refinamento da nova carta começou em 10 de agosto. Mesmo assim, a minuta pública — inclusive o head de 27 de agosto examinado para este artigo — ainda chama o resultado de Working Draft, indica 10 de julho como publicação mais recente e remete ao antigo Exclusion Draft de 2024.
O histórico oficial registra ainda um Candidate Recommendation Draft em 28 de agosto. Ele é o texto técnico integrado mais novo, mas não herda automaticamente a função patentária do Snapshot anterior.
Antes da revisão pelo Advisory Committee, a renovação deveria incluir um registro curto que una autoridade vigente, texto legível mais recente, Snapshot controlador, janela de exclusão, funcionalidades em risco e evidência de implementação datada. Isso documenta o processo; não cria uma aprovação adicional.

Uma passagem de turno sem lista de entrega

Imagine uma equipe que troca de plantão diante de quatro painéis. O primeiro mostra a versão do texto. O segundo, a referência usada para compromissos de patentes. O terceiro, o último ensaio de interoperabilidade. O quarto, a autorização institucional da equipe. Todos podem estar corretos e, ainda assim, a passagem de turno falhar se alguém copiar apenas a data mais nova.

É essa a situação do DID Resolution. No painel editorial, 28 de agosto é a publicação mais recente: um Candidate Recommendation Draft. No painel patentário, a referência relevante continua sendo o Candidate Recommendation Snapshot de 6 de agosto, que abriu a Call for Exclusions até 5 de outubro. No painel de implementação, o relatório público exibe uma execução em 27 de março de 2026. No painel institucional, a carta de 2024 continua vigente, após prorrogação, até 28 de outubro.

“Atual” não significa a mesma coisa nos quatro casos. O texto mais novo pode não ser o corpo de referência da revisão de patentes. O teste mais recente visível pode anteceder uma mudança editorial. A minuta da próxima carta não substitui a carta em vigor. Transformar essas dimensões em uma única coluna de status produz uma resposta simples, mas errada.

A resposta de governança é uma junção: cada registro conserva sua função, seu identificador e sua data, enquanto um pequeno mapa explica as relações entre eles.

A autoridade existente não depende da minuta futura

A carta aprovada em abril de 2024 incluiu o DID Resolution como novo deliverable no Recommendation Track. Ela deveria terminar em abril de 2026, mas foi prorrogada até 28 de outubro. A página do grupo apresenta esse período como o mandato atual.

Portanto, as publicações de agosto não surgiram em um vazio institucional. Não é preciso tratar a nova carta como fonte retroativa de legitimidade. Tampouco se deve confundir uma minuta em refinamento com a autoridade que já governa o grupo.

A issue 562 do repositório de estratégia descreve a proposta sem grandiloquência: trata-se da renovação de um grupo existente, sem mudanças substantivas; o grupo precisa de mais tempo porque o consenso sobre DID Resolution demorou mais do que se esperava.

Essa continuidade torna o recibo mais importante, não menos. Quando o escopo muda, a diferença chama atenção. Quando o escopo permanece igual, uma linha com o mesmo nome pode atravessar a fronteira institucional escondendo perguntas essenciais: sob qual carta o Snapshot foi publicado? Qual texto abriu a oportunidade de exclusão? Que requisito de implementação ainda está aberto? Qual funcionalidade pode ser removida? Qual versão do relatório sustenta uma afirmação de interoperabilidade?

Uma carta proposta não é um mandato. O ponto aqui é o inverso: se vier a ser aprovada, ela deve receber com precisão um trabalho autorizado pela carta anterior.

Snapshot e Draft não são duas versões do mesmo carimbo

Os nomes são próximos o bastante para induzir uma leitura apressada. No estágio de Candidate Recommendation, porém, Snapshot e Draft cumprem papéis diferentes.

O Snapshot de 6 de agosto é um ponto estável de revisão. O Process Document do W3C o caracteriza como Patent Review Draft. Sua publicação desencadeia uma oportunidade de exclusão. A página de propriedade intelectual do grupo registra justamente 6 de agosto como início e 5 de outubro como encerramento da oportunidade atual.

O Candidate Recommendation Draft de 28 de agosto é outra coisa. Seu próprio status informa que ele integra mudanças pretendidas desde a Candidate Recommendation anterior para possível incorporação em um Snapshot posterior. É trabalho em andamento, sujeito a alteração, substituição ou retirada. Um CR Draft não cria, por si, uma nova oportunidade de exclusão.

O registro de transição precisa, por isso, guardar dois campos:

texto técnico integrado mais recente: CR Draft de 28 de agosto;
referência estável para a revisão de patentes: CR Snapshot de 6 de agosto;
oportunidade de exclusão vigente: de 6 de agosto a 5 de outubro;
próxima referência estável: somente quando um novo Snapshot for efetivamente publicado.

Se alguém usar o Draft mais novo como referência patentária, deslocará o corpo de comparação sem o ato processual que produz esse efeito. Se alguém ler apenas o Snapshot, poderá ignorar mudanças que os implementadores já estão convidados a examinar. As duas superfícies precisam aparecer juntas e rotuladas de forma diferente.

O registro de patentes existe e está ativo

Na linha de DID Resolution, a minuta da carta ainda menciona o Working Draft de 28 de novembro de 2024 como Exclusion Draft e o período encerrado em 27 de abril de 2025. Isolada, essa linha ficou para trás.

Mas a superfície especializada de IPR está atualizada. Ela mostra a oportunidade de 2026, conserva o período de 2024–2025 como histórico anterior e aponta as datas corretas. A Call for Exclusions explica ainda que a nova oportunidade é limitada à matéria que não estava presente nem era aparente no corpo de referência anterior.

Essa diferença delimita o achado. Não há base para dizer que o W3C omitiu a oportunidade, perdeu o histórico ou deixou de publicar o registro aplicável. As páginas oficiais mostram o contrário. O problema é a reconciliação da minuta antes que ela passe a representar o estado no momento da aprovação.

Uma janela aberta também não é notícia de litígio. A página de IPR informa que não há divulgações de patentes conhecidas para as especificações do grupo. A oportunidade é uma condição processual; não prova a existência de uma reivindicação, de uma exclusão futura ou de um conflito.

O recibo deve apontar para o Snapshot, o corpo anterior, a abertura, o prazo e a página pública de IPR. Não precisa resumir posições jurídicas, muito menos antecipá-las.

Quatro implementadores não equivalem a duas provas para cada funcionalidade

O Snapshot pede implementações experimentais e estabelece critérios de saída detalhados. Para cada funcionalidade, são esperadas pelo menos duas implementações independentes e interoperáveis, verificadas por testes abertos. Afirmações normativas testáveis por máquina requerem duas implementações conformes por funcionalidade; as não testáveis por máquina requerem duas demonstrações. Os implementadores também devem suportar pelo menos dois métodos DID de especificação aberta, cada um implementado de forma interoperável por mais de uma implementação.

É uma regra por funcionalidade, não uma contagem de nomes no cabeçalho de uma tabela.

O relatório público traz uma matriz extensa e vários implementadores. Também mostra a execução de 27 de março, anterior aos dois documentos de agosto. Nada disso, sozinho, permite declarar aprovação ou reprovação.

Uma execução de março pode continuar relevante para trechos que não mudaram. Um resultado marcado como falha ou não implementado pode depender da versão testada, do agrupamento de afirmações e da definição de funcionalidade. E uma lista de fornecedores não demonstra, sem explicação adicional, a independência exigida.

O registro de implementação deveria permitir reconstruir a cadeia:

publicação ou commit da especificação testada;
commit da suíte e horário da execução;
afirmações normativas agrupadas em cada funcionalidade;
duas implementações ou demonstrações qualificadas por funcionalidade;
critério usado para considerar as implementações independentes;
métodos DID abertos usados na interoperabilidade;
itens pulados, não resolvidos ou em risco;
responsável pela próxima atualização.

Assim, o código em funcionamento disciplina o rótulo institucional. A carta pode exigir evidência, mas não pode produzir interoperabilidade por declaração.

“Em risco” é um estado controlado, não um veredito

O status de 6 de agosto identifica DID URL dereferencing como feature at risk, provavelmente sujeita a mudança ou remoção. O grupo procura saber, com os implementadores, se a funcionalidade definida tem valor. O texto também avisa que issues abertas das classes 1, 2 ou 3 podem alterar a especificação.

Isso faz parte do propósito de Candidate Recommendation. A fase existe para colher experiência real. Marcar uma funcionalidade como em risco é preservar uma incerteza de maneira governável, não admitir falência do processo.

O perigo aparece quando a transição institucional elimina o endereço dessa incerteza. Dizer apenas que o novo grupo “manterá” DID Resolution não informa se uma seção foi recebida como estável, provisória, removível ou à espera de evidência.

O recibo não deve decidir o destino técnico. Deve ligar a funcionalidade ao issue, à evidência exigida, à instância decisória e, depois, à disposição final. A competência técnica permanece no Working Group; a memória deixa de depender da interpretação de uma palavra ampla como “manutenção”.

A minuta está justamente na fase em que a divergência pode ser corrigida

A carta pública se identifica como DRAFT. As datas de início e fim são placeholders, algo compatível com uma proposta cujo início depende da aprovação e de uma futura Call for Participation. O W3C anunciou que o refinamento deveria seguir aproximadamente até 15 de setembro.

Segundo o Process Document, é nessa fase que ocorre a revisão ampla, as issues recebem tratamento formal e o Team decide se começa a revisão pelo Advisory Committee, prolonga o refinamento ou abandona a proposta.

A própria tabela da minuta diz que “Draft state” é o estado do deliverable no momento da aprovação da carta e remete à página de publicações para informações dinâmicas. Ela não promete ser um painel sincronizado a cada hora. Mas estabelece um teste claro para o momento da aprovação.

No corte desta pesquisa, o head mesclado em 27 de agosto ainda dizia Working Draft, publicação mais recente em 10 de julho e antigo Exclusion Draft. O Snapshot de 6 de agosto já existia havia três semanas; no dia 28, o CR Draft ampliou a distância.

É uma divergência de minuta, corrigível no refinamento. Chamá-la de invalidade ignoraria a finalidade da fase. Deixá-la atravessar a aprovação desperdiçaria essa mesma finalidade.

O recibo pode ser pequeno

O W3C já mantém páginas próprias para publicações, IPR, grupo e testes. Uma carta não deve virar cópia de todas elas. Basta uma camada comum, fina e verificável:

Autoridade: carta vigente, período, commit da proposta, fase de refinamento e decisão final.
Texto: documento técnico integrado mais recente e Snapshot controlador em campos separados.
Patentes: Patent Review Draft, abertura, encerramento, corpo anterior e página de IPR.
Implementação: especificação e suíte testadas, execução, cobertura por funcionalidade e independência.
Revisão: itens em risco, issues abertas, revisões horizontais, revisão ampla e destino dos comentários.
Custódia: responsável por cada campo, rota de correção e evento que substitui o estado anterior.

Cada transição deve ser acrescentada, não silenciosamente sobrescrita. Uma tabela legível e um registro estruturado podem compartilhar os mesmos identificadores.

Vincular o artigo ao tema mais amplo de identity and access management também requer contenção. DID Resolution é relevante para esse campo, mas não dá ao W3C autoridade sobre todos os produtos de IAM, todos os métodos DID ou regimes jurídicos de identidade. A própria proposta exclui protocolos de autenticação e autorização, APIs de navegador e o objetivo de “resolver identity” na Web.

Participação técnica fornece conhecimento, objeções e implementações; não cria soberania sobre atores ausentes. A adoção externa continuará sendo decisão de operadores, governos e compradores. Um bom registro torna esse limite visível.

A renovação do grupo de DID do W3C precisa receber o estado real do padrão

Por que isso importa

Resumo

Uma passagem de turno sem lista de entrega

A autoridade existente não depende da minuta futura

Snapshot e Draft não são duas versões do mesmo carimbo

O registro de patentes existe e está ativo

Quatro implementadores não equivalem a duas provas para cada funcionalidade

“Em risco” é um estado controlado, não um veredito

A minuta está justamente na fase em que a divergência pode ser corrigida

O recibo pode ser pequeno

Fontes

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance