Resumo

  • O Internet-Draft em discussão no REGEXT permite indicar quais dados de contato no RDAP foram checados e associar data, verificador, arcabouço, método e tipo de evidência; quase todos esses elementos são opcionais e nenhum define uma autorização universal de exposição.
  • A operação precisa de um recibo de público e validade que mostre para quem cada dado foi entregue, por qual finalidade, sob qual regra e até quando o resultado serve. Esse recibo é uma proposta editorial de Daniel Kade, não um requisito da IETF.

Verificação e divulgação não são o mesmo ato

O mesmo registro pode atender a três consultas. Uma vem de um visitante anônimo. Outra parte de uma equipe de combate a abuso, autenticada e com um caso concreto. A terceira é feita por uma autoridade competente com base jurídica própria. O banco de dados do registrador contém a mesma verificação de e-mail, mas não há motivo para concluir que as três respostas devam conter os mesmos detalhes.

A verificação descreve um procedimento aplicado a uma alegação. A divulgação decide quais informações um destinatário pode receber. A confiança operacional decide o que esse destinatário pode fazer com elas. Misturar as três coisas transforma um fato pequeno — alguém respondeu por aquele e-mail em certo dia — numa certificação ampla sobre pessoa, organização ou recurso.

Esse desvio costuma acontecer depois de uma integração tecnicamente bem-sucedida. O primeiro sistema preserva o campo checado, a data e o método. O painel seguinte mostra apenas um ícone verde. Uma exportação leva o ícone, mas não a data. Um motor de risco o converte em pontuação. No fim da cadeia, “e-mail alcançável no cadastro” virou “titular confiável”. O dado original não precisava estar errado para o resultado final ser enganoso; bastou retirar seus limites.

A posição exata da revisão 04

A revisão 04 de Registration Data Access Protocol (RDAP) Extension for Verified Contact Information é de 24 de agosto de 2026. No Datatracker da IETF, ela aparece como Internet-Draft ativo no contexto do REGEXT, na situação “Candidate for WG Adoption”, com estado IESG “I-D Exists”. Não é um padrão aprovado nem conta com endosso formal da IETF. O cabeçalho indica Standards Track como intenção, não como etapa concluída.

O texto propõe um array verifiedContacts_data dentro de objetos de entidade RDAP. Cada item pode apontar as alegações verificadas, como e-mail, telefone, fax, endereço, nome ou data de nascimento. Também pode registrar data de conclusão, identificador e nome do verificador, identificador da operação, arcabouço de confiança, método, evidência, observações e extensões.

Representar várias verificações é uma vantagem. O nome pode ter sido conferido em um documento; o e-mail, por link; o endereço, em uma base de referência. Cada evento pode ocorrer em momento diferente e sob regras distintas. A interface que resume tudo em um único booleano elimina a separação que o próprio modelo procurou manter.

Os principais campos descritivos são opcionais. Portanto, ausência não pode virar confirmação implícita. A revisão 04 esclarece que verificationDate marca quando o processo terminou e que a falta da data não significa que a verificação seja atual. Mesmo presente, ela não define prazo de expiração. A validade para um uso concreto depende da política do operador, de mudanças posteriores e do risco da decisão.

A comparação entre as revisões 03 e 04 mostra a correção dos exemplos JSON e a inclusão dessa explicação sobre o momento de conclusão, além de ajustes ligados ao trabalho de versionamento do RDAP. O histórico da própria revisão resume as mudanças como correção de exemplos, atualização para o texto mais recente de versionamento e limpeza editorial. O documento continua em evolução; uma implantação deve conservar a versão exata que interpretou.

A pergunta certa é “o que foi conferido?”

O rascunho separa método e evidência. Em reachability, o destinatário precisa realizar uma ação, como inserir um código, clicar num link ou confirmar recebimento. Outros métodos envolvem inspeção documental, consulta a registros, verificação criptográfica, autenticação eletrônica, token, perguntas de conhecimento, conferência presencial ou remota e biometria.

As categorias de evidência incluem documento de identidade, passaporte, autorização de residência, extrato bancário, conta de serviço público, documento fiscal, registro de nascimento ou população, atestados e logs de verificação eletrônica ou postal. A mesma evidência pode ser testada de formas diferentes, e o mesmo método pode ser aplicado a evidências diferentes. A conclusão só é inteligível quando alegação, método, evidência e arcabouço permanecem juntos.

Alcançar um e-mail não é provar identidade legal. Provar identidade não é demonstrar poderes vigentes para agir por uma empresa. Esses poderes não são prova automática de controle sobre um domínio ou recurso de numeração. E a conferência de um atributo não garante a completude do cadastro.

Essas negativas não diminuem o valor do sinal. Elas impedem que o sinal seja usado além do que suporta. Uma equipe de abuso pode considerar a confirmação recente de alcance suficiente para escolher um canal de contato. Uma transferência de domínio pode demandar prova mais forte de identidade e autoridade. Cada processo mantém seu próprio limiar de evidência.

O significado de private precisa de versão

O trustFramework pode ser ampliado. O texto define eidas e private; este último indica uma verificação realizada segundo a política do operador do servidor, e não sob um arcabouço externo registrado. Não é sinônimo de inválido. É um aviso de que a interpretação depende de uma regra local.

Guardar apenas a palavra private equivale a citar “a política” sem dizer qual edição estava em vigor. O operador pode alterar documentos aceitos, periodicidade de nova conferência, atores autorizados e exceções. Para reconstruir o significado de uma decisão, o consumidor precisa de um identificador estável e da versão ou impressão digital da política aplicada.

Até um arcabouço externo exige contexto. Seu nome não substitui a alegação verificada, o nível de garantia, a jurisdição nem o método. Interoperabilidade não é pintar resultados diferentes com o mesmo selo; é poder comparar diferenças sem apagá-las.

O metadado da evidência também é sensível

Não publicar a imagem do passaporte ou o extrato bancário é apenas o começo. Informar que um passaporte foi usado, que um registro fiscal foi consultado ou que houve comparação biométrica já revela a trajetória de identificação de alguém. Para um destinatário autorizado isso pode ser essencial. Para o público anônimo, pode ser excessivo.

As Considerações de Segurança do draft reconhecem possíveis implicações de privacidade e determinam que a divulgação observe as leis e políticas de proteção de dados aplicáveis. A introdução, por sua vez, admite tanto um serviço RDAP público quanto um serviço fechado que exige autorização prévia de solicitantes legítimos ou autoridades.

O formato, portanto, atravessa modelos distintos de acesso sem escolher um público único. Cabe à operação decidir quais elementos são públicos, quais dependem de autenticação e quais não devem ser distribuídos por RDAP. O fato de o texto citar o artigo 28 da NIS2, no contexto de dados de registro de nomes de domínio exatos e completos, não cria uma obrigação geral de publicar os metadados do processo. Coletar, manter, verificar, conceder acesso e divulgar ao público são decisões diferentes.

O que um selo único esconde

Uma marca genérica omite pelo menos cinco respostas: qual objeto RDAP; qual atributo; qual método e evidência; em que data e sob qual regra de validade; para qual público. Ela pode continuar verde depois que o e-mail muda de mãos, a política é atualizada ou o evento é substituído.

Há ainda o erro inverso. Se a resposta pública não mostra a verificação, isso não prova que ela não ocorreu. Pode apenas significar que o leitor atual não tem autorização para ver seus detalhes. Qualidade do dado e estado de divulgação precisam ser eixos separados.

A cópia agrava tudo. Uma vez que o selo entra em buscadores, bases comerciais ou arquivos de casos, uma correção na origem talvez nunca alcance todos os destinos. Uma afirmação pequena, válida no início, pode sobreviver como reputação ampla e desatualizada.

Um recibo de público e validade

A resposta operacional é gerar um recibo quando os dados de verificação armazenados passam a integrar uma resposta RDAP. Não se trata de alterar o wire format do draft. Trata-se de conservar, no lado do operador, a decisão que produziu aquela divulgação.

O recibo liga o objeto RDAP e o conjunto exato de alegações ao identificador da verificação, ao verificador e à data disponível. Registra método, categoria de evidência e arcabouço, além da política e da versão usadas para interpretá-lo. Um campo ausente permanece ausente; o sistema não o preenche com certeza inventada.

Depois, documenta o destinatário: público anônimo, usuário autenticado, equipe interna ou autoridade; identidade do solicitante quando necessária; finalidade declarada; canal público ou restrito; campos mostrados, ocultados e redigidos. A base de autorização — lei, contrato, política publicada ou decisão do caso — deve ser recuperável, assim como o responsável e o caminho para revisão.

Por fim, o recibo registra o horizonte operacional. Inclui intervalo de nova checagem, eventos que disparam revisão, tratamento para data ausente e estado de correção, revogação ou substituição. Isso não cria uma validade protocolar que o draft não definiu; apenas torna explícita a decisão local de reutilizar o resultado para uma finalidade atual.

O recibo não duplica documentos, material biométrico nem segredos do verificador. Ele preserva a razão e o limite da entrega.

Começar pequeno para manter a reversibilidade

A combinação defendida por Heng Lu — especificação inicial mínima, decisões futuras localizadas e adoção voluntária — ajuda a escapar da escolha falsa entre uma política global única e nenhuma coordenação. Um vocabulário compartilhado para alegações, métodos e evidências pode conviver com regras locais de acesso, desde que sejam documentadas.

Uma implantação inicial pode abranger um único atributo, uma política versionada, um público autenticado e um prazo curto para revisão. A resposta pública pode sinalizar campos redigidos conforme o RDAP sem revelar a categoria de evidência. Antes de expandir, o operador observa dados vencidos, contestações, usos indevidos e demanda real.

A sintaxe comum torna os resultados comparáveis; o recibo local mantém a responsabilidade. O objetivo não é congelar a experiência inicial, mas garantir que ela possa ser corrigida sem transformar um teste operacional em reputação pública permanente.

Fontes