Resumo

  • O plano trimestral do RIPE Database, atualizado em 11 de junho de 2026, prevê trocar o cookie seguro compartilhado no site por uma sessão chamada de “OIDC 2.0”; o item ainda aparece como em andamento.
  • OpenID Connect autentica a pessoa, mas não decide sozinho qual objeto ela pode modificar: essa autoridade continua dependendo das relações entre a conta SSO, credenciais e objetos mntner.
  • A prova útil da mudança seria um recibo de transição que una perfil de protocolo, sessão local, logout, corte do cookie antigo, chaves de API e testes positivos e negativos de autorização, sem revelar segredos.

O detalhe que a tela de login não mostra

Há uma diferença prática entre conseguir entrar e ter permissão para agir. Ela é fácil de ignorar quando o produto apresenta as duas coisas em sequência: o usuário conclui a autenticação, abre o formulário e envia uma alteração. A interface faz o percurso parecer único. O RIPE Database, no entanto, precisa responder a três perguntas distintas. Quem acabou de se autenticar? Qual sessão ou credencial permanece válida? Qual mntner autoriza a mudança daquele objeto?

O planejamento trimestral do RIPE Database torna a primeira passagem visível. O plano do terceiro trimestre de 2026, atualizado em 11 de junho, contém a tarefa “Switch DB web application to OIDC 2.0”. A descrição diz que a autenticação interativa na aplicação web passará de um cookie seguro válido no site para uma sessão “OIDC 2.0”. O status público é “In progress”. Isso é uma intenção de engenharia clara, não uma confirmação de implantação nem uma descrição completa do perfil usado.

O ponto não é discutir um rótulo por preciosismo. O nome escolhido comprime decisões que determinam o que a transição realmente muda. O conjunto público de padrões consultado inclui OpenID Connect Core 1.0, OpenID Connect Session Management 1.0 e OpenID Connect RP-Initiated Logout 1.0. OIDC Core é uma camada de identidade construída sobre OAuth 2.0. Esses documentos não apresentam uma especificação final chamada “OIDC 2.0”. A expressão do plano pode ser abreviação, convenção interna, erro de redação ou referência a uma combinação específica. As fontes examinadas não permitem escolher entre essas hipóteses.

Esse limite importa porque uma migração de autenticação deveria ser aceita pelo comportamento comprovado, e não apenas pelo nome que aparece no quadro de trabalho. Um registro público suficientemente preciso poderia informar a versão do padrão e o perfil adotados, a identidade do emissor e do cliente em nível não sensível, a opção de fluxo e PKCE quando aplicável e a fronteira entre a sessão do provedor de identidade e a sessão mantida pela aplicação. Nenhum desses detalhes exige publicar tokens, cookies, endereços de conta ou topologia interna.

A sessão continua pertencendo à aplicação

OpenID Connect não elimina o estado local do serviço que confia no provedor. O documento de Session Management distingue o estado de login mantido pelo OpenID Provider do estado da relying party. O padrão de RP-Initiated Logout, por sua vez, define como a aplicação pode pedir o encerramento no provedor. Ainda resta à aplicação dizer quando cria seu próprio cookie ou sessão, quanto tempo ela dura, como expira por inatividade, o que ocorre depois de uma renovação e qual estado é removido quando o usuário encerra a sessão.

Isso cria uma pergunta de corte que o simples teste “o login funcionou” não resolve. Quando a nova sessão for ativada, o cookie antigo deixará de ser aceito imediatamente? As sessões já abertas serão encerradas, convertidas ou toleradas durante uma janela de compatibilidade? Um logout local encerrará apenas o estado do RIPE Database, também chamará o provedor ou fará as duas coisas? Há diferença entre sair em uma aba, revogar uma sessão na conta e invalidar uma credencial usada por automação?

O plano público não responde a essas perguntas, e não há razão para fingir que responde. Também não há, nas fontes consultadas, prova de sessão obsoleta ativa, falha de segurança ou conta comprometida. A conclusão mais estreita é outra: enquanto o item estiver em andamento, o marco de conclusão precisará dizer qual população de sessões foi encerrada e qual permaneceu válida. Sem esse marco, duas pessoas podem concordar que “OIDC foi lançado” e ainda falar de estados diferentes.

Autenticação não é autoridade de mntner

A documentação de autorização do RIPE Database oferece a separação mais útil. Ela distingue autorização, autenticação e credenciais. Uma pessoa autenticada pode receber uma credencial que autoriza acesso, enquanto os objetos mntner mantêm referências a credenciais — entre elas contas SSO e chaves criptográficas — usadas para proteger objetos do banco de dados. A identidade responde quem; o mntner, em combinação com o objeto e a operação, participa da decisão sobre o quê.

Portanto, uma sessão OIDC válida não deveria ser tratada como autoridade universal. A aplicação ainda precisa resolver a identidade para a associação SSO pertinente, identificar o conjunto de mantenedores aplicável e avaliar as regras de proteção do objeto. O caso feliz é insuficiente. É preciso testar uma identidade ligada ao mntner correto e outra identidade autenticada, igualmente válida, ligada ao mantenedor errado. No segundo caso, a atualização deve ser negada e o objeto deve permanecer inalterado.

Essa formulação não é uma hipótese abstrata inventada para a migração de 2026. A pull request 1688 do repositório público whois, intitulada “Support oauth2”, foi incorporada em 3 de março de 2025. A lista de arquivos públicos da mudança mostra testes negativos em que um bearer token associado ao mantenedor errado ou a uma identidade SSO inadequada é rejeitado e o objeto não muda. O registro público de alterações inclui “Support OAuth 2.0 (#1688)” na versão 1.117.

Esse material demonstra um princípio valioso: autenticar um token e autorizar uma alteração são verificações separadas. Ele não demonstra que a migração do navegador planejada para 2026 já aconteceu. A PR trata de suporte a bearer token, tem outra data e nomeia outra superfície. Transformá-la em prova de conclusão do item “OIDC 2.0 session” seria juntar duas linhas de evidência que as fontes mantêm distintas.

As chaves de API obedecem a outro relógio

A documentação de chaves de API acrescenta uma terceira temporalidade. As chaves são associadas a uma conta RIPE NCC Access. Para autorizar mudanças, a conta precisa estar vinculada a um mntner por meio de um atributo auth: SSO; uma chave também pode ser limitada a um único mantenedor. A documentação registra validade, última utilização e revogação imediata.

O documento RIPE-843 coloca essa operação num conjunto mais amplo de regras para usuários e chaves. Ele exige autenticação de dois fatores, afirma que o nome de usuário se destina a uma pessoa, limita a vida de uma chave de API a um ano e diz que desativar a conta SSO ou retirar o usuário como mantenedor de uma conta desativa a chave associada.

Uma mudança na sessão interativa não precisa alterar essas chaves. Mas a aceitação deve dizer explicitamente se elas estão fora do corte, se compartilham alguma nova dependência ou se serão observadas por uma janela diferente. Caso contrário, “a autenticação foi migrada” pode ser interpretado como uma mudança que alcançou navegador e automação, mesmo quando apenas um deles mudou. Continuidade não é equivalência.

Um recibo de transição, não uma declaração de vitória

O artefato adequado seria curto o bastante para ser mantido e preciso o bastante para ser auditado. Ele começaria com as versões exatas de OpenID Connect e OAuth utilizadas, mais o perfil do fluxo. Identificaria o emissor e a relying party de modo seguro. Registraria quando a aplicação cria estado local, seus limites de inatividade e duração absoluta, o comportamento de renovação e as rotas de logout. Fixaria a hora a partir da qual o cookie anterior deixa de ser aceito e o tratamento dado às sessões existentes.

Depois viria a ponte para a autoridade. O recibo explicaria, sem dados pessoais, como a identidade autenticada chega à associação SSO e ao mntner; registraria casos representativos autorizados e negados; confirmaria que uma negação não altera o objeto; e declararia o tratamento das chaves de API. Por fim, indicaria a janela de observação, o número de exceções, o limite de rollback, a autoridade que aceitou o resultado e uma forma de anexar correções sem apagar a versão anterior.

Isso não seria uma exigência de revelar segredos nem a descrição de um recurso que o RIPE NCC já tenha prometido. É um desenho de controle proposto. Valores de token, identificadores de contas, credenciais de mantenedores, conteúdo privado de objetos e detalhes de topologia ficariam de fora. O registro publicaria o vínculo entre decisões, não os materiais que permitiriam abusar delas.

Fontes