Resumo

  • O RFC 9560 permite que servidores RDAP identifiquem usuários e validem Bearer Tokens com OpenID Connect e OAuth, sem criar uma credencial local em cada serviço.
  • As declarações opcionais de finalidade e não rastreamento alimentam a política do servidor; elas não comprovam intenção, direito à consulta, ausência universal de logs nem qualidade do cadastro.
  • Uma trilha defensável liga a validação à versão da política, à finalidade pedida, aos campos entregues, à procedência do registro e ao desfecho posterior.

O Bearer Token passou. Emissor, audiência, prazo e estrutura forneceram evidência suficiente para o servidor continuar. Esse é um fato técnico útil e delimitado. O problema começa quando o relatório operacional amplia seu significado: “usuário autenticado” vira “consulta autorizada”; “finalidade permitida” vira “motivo verdadeiro”; a resposta acaba tratada como “realidade confirmada”. O RFC 9560 não faz essas equivalências.

Publicado em abril de 2024 na trilha de padrões do IETF, o RFC 9560 introduz autenticação federada no Registration Data Access Protocol. O cliente descobre OpenID Providers e usa um fluxo orientado a sessão ou a token. A camada comum reduz contas isoladas, mas deixa a decisão de acesso com a política local de cada servidor RDAP.

Autenticação fecha uma pergunta

Ao receber uma consulta com token, o servidor precisa validá-lo segundo a política local e confirmar que é um token de acesso legítimo. Pode usar introspecção RFC 7662 ou analisar um JWT. A audiência é relevante: um token destinado a outra parte pode não ser aceito, enquanto a troca do RFC 8693 pode produzir um token para a audiência correta.

Isso demonstra que o servidor aceita apoiar-se naquela credencial nesta interação. Ainda não define o que a identidade pode ver. Depois da validação, o servidor avalia claims, determina o nível de autorização e decide consulta por consulta. Rejeitar, omitir, ocultar e divulgar são decisões diferentes.

Finalidade concedida não revela a motivação

O claim opcional rdap_allowed_purposes lista finalidades que uma identidade pode invocar. O provedor só deve atribuí-las a identidades habilitadas. Para uma consulta específica, farv1_qp declara a finalidade; se ela não fizer parte do conjunto autorizado, o servidor devolve 403.

A regra organiza o controle de acesso, mas não observa a intenção humana. Ter uma categoria, declará-la agora e usar os dados de acordo com ela depois são três fatos distintos. O servidor pode ignorar finalidade e claim quando colidem com sua política. Sem farv1_qp, a obrigação de decidir continua, baseada nas demais informações.

Um crachá pode identificar o funcionário e abrir uma porta. Não comprova por que ele entrou, qual arquivo precisava nem o destino da informação. A mesma limitação protege a clareza da federação de identidade.

Não rastrear troca uma garantia por outra

Com rdap_dnt_allowed, o servidor pode ser obrigado a não registrar a associação entre identidade e consulta. É preciso identificar e autorizar o usuário, receber o valor true e respeitar as normas locais. O RFC reconhece que a promessa depende da boa vontade do servidor e dos proxies, de confiança prévia fora de banda e que a perda de informação pode prejudicar seriamente a auditoria.

Uma investigação sensível pode precisar dessa confidencialidade. Por isso, a decisão deve nomear quem concede, quais intermediários cobre, qual evidência substituta permanece e quando expira. “Não rastrear aceito” é um evento de política, não prova criptográfica de que nenhum sistema guardou correlação.

A resposta tem seu próprio ônus de prova

farv1 sinaliza conformidade com a extensão; não certifica o registro de origem. Uma resposta correta pode ser apenas o subconjunto permitido. O cadastro tem data de atualização, método de verificação, histórico de correção e ambiguidades próprias. HTTP 200 não prova completude nem utilidade; HTTP 403 não prova má-fé.

A camada comum mínima deve padronizar descoberta, tokens, nomes de claims e parâmetros. Não deve fingir que padroniza todas as finalidades legítimas, limiares de divulgação e conclusões de investigação. Pela disciplina de camadas de realidade de Lu Heng, identidade, token, privilégio de finalidade, decisão, dado divulgado e resultado real existem — mas nenhum herda automaticamente a autoridade do próximo.