Resumo

  • A revisão de 12 de maio de 2026 criou, para solicitações urgentes autenticadas, confirmação em duas horas, resposta em 24 horas e limite excepcional de 72 horas.
  • A nota de implementação da própria política determina que a seção 10.7 só será efetiva quando a ICANN implementar integralmente uma Política de Consenso que estabeleça o processo de autenticação.
  • O grupo de insumos sobre autenticação assessora uma prova de conceito e não desenvolve política. Seus testes previstos para dezembro de 2026 e resultados para março de 2027 não são, por si só, o evento de vigência.
  • A autenticação comprova atributos delimitados do solicitante. Urgência, jurisdição, base legal, necessidade e decisão de divulgar continuam sendo avaliações separadas.

A regra não é vaga

A Política de Dados de Registro define Solicitação Urgente como uma categoria restrita de pedido de divulgação de dados não públicos. Ela precisa ser apresentada por um Solicitante Autenticado e tratar de ameaça iminente à vida, lesão corporal grave, infraestrutura crítica ou exploração infantil, quando a divulgação for necessária para combater ou enfrentar a ameaça.

A seção 10.7 transforma essa definição em uma sequência. O solicitante declara que o caso atende aos critérios. O registrador e o operador de registro acusam o recebimento em até duas horas. Respondem sem demora indevida e, salvo circunstância excepcional, em até 24 horas. Se houver uma exceção, a notificação ainda deve sair dentro de 24 horas, com justificativa e uma previsão que não ultrapasse 72 horas desde o recebimento.

O texto também limita a exceção. Força maior e complexidade decorrente, por exemplo, de muitos nomes de domínio podem justificá-la. Feriado, férias programadas e viagem planejada não podem. Trata-se de um relógio operacional: o momento de entrada, o recibo, a resposta e a extensão têm estados próprios.

O comunicado de 12 de maio explica a urgência material. Em situações que envolvem vida, segurança física, crianças ou infraestrutura crítica, a demora pode ampliar o dano. É razoável que a política procure substituir filas informais por um prazo verificável.

Mas o mesmo comunicado diz que a nova linguagem não entrará em vigor antes da implementação de um mecanismo de autenticação para autoridades policiais.

A trava está dentro da política

A nota de implementação é ainda mais específica. As obrigações da seção 10.7 passam a valer na data em que a ICANN implementar plenamente uma Política de Consenso que estabeleça um processo de autenticação do solicitante. Portanto, são necessários tanto uma base normativa com a autoridade correta quanto um estado de implementação completo.

A política como um todo está em vigor desde 21 de agosto de 2025. Não se deve dizer que todos os seus deveres aguardam autenticação. A condição se aplica à seção urgente adicionada em 2026. Também não se deve inverter o erro e concluir que os deveres urgentes já podem ser fiscalizados porque o texto está publicado.

A página de status dos pareceres do GAC registra esse desdobramento. A Diretoria encerrou o item que pedia um cronograma porque a regra de 24 horas havia sido publicada. No mesmo registro, observou que a fiscalização do prazo dependia da disponibilidade do mecanismo de autenticação. O produto solicitado pelo parecer — uma regra escrita — ficou pronto; a condição de execução não.

Essa distinção precisa sobreviver fora da página oficial. Um resumo pode capturar o verbo obrigatório e perder a nota. Uma equipe policial pode preparar o caso contando com 24 horas. Um registrador pode interpretar a dependência como motivo para não testar seus fluxos. Um sistema de compliance pode iniciar o denominador cedo demais. A mesma fonte produz expectativas incompatíveis quando o estado de vigência não acompanha cada reprodução da regra.

Engenharia comprova funcionamento, não cria competência

O Grupo de Insumos sobre Mecanismos de Autenticação de Órgãos Policiais foi organizado para apoiar uma prova de conceito ligada ao RDRS ou a um sucessor. Ele examina como autenticar agentes, como integrar sistemas existentes e como desenhar o fluxo. O cronograma público prevê wireframes em outubro de 2026, início dos testes em dezembro e publicação de resultados em março de 2027.

São marcos relevantes. Não são uma data de vigência escondida. A própria página diz que o grupo não é um órgão de desenvolvimento de políticas e não produzirá recomendações de política. A chamada para participação lista assuntos operacionais: atributos para validação, interoperabilidade, privacidade, minimização, segurança, transparência, auditabilidade, logs e usabilidade.

Um teste pode mostrar que uma credencial é aceita em diferentes jurisdições, que uma revogação chega em tempo hábil ou que a integração expõe informação pessoal excessiva. Pode produzir evidência para uma decisão de política. Não pode tomar para si a competência de formular a Política de Consenso exigida pela nota de implementação.

O trabalho ocorre ao lado da Equipe de Recomendações Suplementares da GNSO, que considera questões de credenciamento em um futuro sistema padronizado de acesso e divulgação. A ligação entre os grupos impede que uma decisão operacional ignore uma dependência normativa. Ela não torna o grupo técnico uma extensão da GNSO.

Assim, dezembro deve ser descrito como teste e março como entrega de achados. A ativação só ocorrerá quando uma fonte com autoridade declarar e comprovar que a condição escrita foi cumprida.

A credencial é uma afirmação pequena

Há um bom motivo para autenticar de forma comum. Um pedido urgente não deveria desperdiçar horas enquanto cada registrador volta a confirmar a existência da agência, o vínculo do agente, sua autorização e a validade do documento. Uma afirmação assinada, portátil e revogável pode reduzir esse atrito.

O alcance dessa afirmação, porém, precisa ser pequeno. A identidade de um agente não comprova que o fato descrito aconteceu. A qualidade de autoridade não demonstra que o caso cabe na definição de urgência. A credencial não resolve jurisdição, fundamento legal, necessidade, proporcionalidade ou quais campos podem ser revelados.

A política mantém essas etapas. O solicitante apresenta uma declaração de urgência separada. A análise pode considerar direito aplicável e jurisdição. A resposta pode deferir, deferir parcialmente ou negar com razões. A seção 10.8 permite medidas contra pedidos ou solicitantes abusivos.

Autenticar é dizer: este sujeito possui estes atributos, neste instante, segundo este nível de garantia. Não é dizer: a alegação é verdadeira e os dados devem sair. O registrador ou operador de registro continua responsável pela decisão posterior.

Uma camada global que confirme apenas o mínimo necessário pode ser útil. Uma autoridade que credencie, classifique urgência, resolva conflitos de lei e determine divulgação se torna um centro de decisão transnacional por meio de uma especificação técnica. Esse poder não está implícito na tarefa de autenticar.

O diálogo com a Índia mostra onde a autoridade termina

Na resposta de 11 de agosto ao governo da Índia, o CEO da ICANN afirma que a política contém o prazo de 24 horas, mas a fiscalização depende de um mecanismo de autenticação adequado. Ele menciona o trabalho do Grupo de Trabalho de Segurança Pública do GAC, de representantes policiais e do novo grupo de insumos.

A carta também aborda a proposta indiana de um prazo de verificação de 15 dias e novas obrigações de relatório. A resposta não transforma essas preferências em deveres imediatos. Novas obrigações para partes contratadas precisam passar pelo processo de política ou contrato competente. A GNSO desenvolve a política de gTLD e administra seus PDPs; o CEO pode apoiar e implementar o que foi adotado, mas não dirigir prioridades nem resultados.

A sequência é uma proteção. Governos identificam necessidades. O GAC aconselha. Grupos técnicos testam. A GNSO trabalha dentro de seu mandato. A Diretoria age segundo o Estatuto. A organização implementa. Registradores e registros respondem. Se a prova de conceito for apresentada como fonte da obrigação, a cadeia perde o elo que tornaria a obrigação legítima e previsível.

Um recibo para o instante em que o estado muda

Daniel Kade propõe que a ICANN publique um recibo de ativação curto e versionado. Não seria política vigente, cadastro de policiais ou autorização de caso. Seria a prova pública de que a dependência da seção 10.7 passou de pendente para satisfeita.

O recibo deve registrar a versão exata e a impressão digital da política, a Política de Consenso dependente, o ato que concluiu sua implementação, a autoridade responsável, data, hora, fuso e fonte canônica. Deve listar classes de solicitantes, versão do perfil de garantia, significado dos atributos, modo de verificar revogação e superfícies de entrada aceitas.

Também deve definir recebimento. O relógio começa quando o RDRS aceita, quando o sistema da parte contratada recebe ou quando uma pessoa abre o caso? Qual marca vale após uma repetição? Como um canal direto funciona durante uma falha? Solicitações em trânsito no momento da ativação entram em qual regime? Um prazo exato não pode depender de um início implícito.

O caminho excepcional — duas horas, 24 horas, aviso de extensão e teto de 72 — e o denominador de compliance devem fazer parte do mesmo registro. Um caso anterior à vigência, um erro de credencial e uma solicitação autenticada válida são estados diferentes.

Por fim, uma frase negativa deve acompanhar toda validação: a credencial prova apenas os atributos indicados. Não prova urgência, jurisdição, legalidade, necessidade, proporcionalidade ou direito de receber dados. A parte pública não precisa conter nomes de agentes, investigações, domínios-alvo ou dados de registro não públicos.

Contar respostas sem transformar divulgação em meta

O SAC122 recomendou métricas agregadas sobre quantidade, velocidade, pedidos inválidos e cumprimento dos prazos. Alguns detalhes foram substituídos pelo texto final, mas a ideia de medir o fluxo sem expor os casos permanece correta.

Depois da ativação, o denominador deve começar pelas solicitações urgentes autenticadas recebidas em canal válido. Falha de credencial, formato incompleto, reclassificação como não urgente, necessidade de informação adicional, negativa jurídica, divulgação parcial, divulgação integral, extensão e falha do sistema precisam ficar separados. O tempo do recibo, o tempo da resposta e o tempo da conclusão também.

Uma negativa fundamentada dentro do prazo pode cumprir o dever de responder. Uma divulgação tardia pode violá-lo. A taxa de divulgação não é uma nota de qualidade. Transformá-la em objetivo premiaria a saída de dados em vez da aplicação cuidadosa da lei.

Limites da evidência

As fontes examinadas não fixam data final de ativação, provedor de identidade, modelo de federação, perfil de garantia, regra de transição ou denominador de compliance. Elas não dizem que o teste de dezembro de 2026 ativa a seção 10.7. Este texto não conclui que pedidos urgentes não possam ser tratados por outros processos lícitos antes da vigência. O recibo de ativação e a autenticação de escopo reduzido são propostas de Daniel Kade.

Fontes

  1. ICANN — Política de Dados de Registro
  2. ICANN — Anúncio sobre solicitações urgentes
  3. ICANN — Grupo de Insumos sobre Autenticação
  4. ICANN — Chamada para participação
  5. ICANN — Status dos pareceres do GAC
  6. ICANN — Carta de Kurt Erik Lindqvist a S. Krishnan
  7. SSAC — Resumo executivo do SAC122
  8. ICANN — Resumo do trabalho do RDRS