Resumo

  • O RFC 3341 escolhia a entrada owner/actor mais específica; ao excluir a entrada exata, uma concessão curinga mais ampla podia voltar a valer.
  • Para negar tudo era necessário manter a entrada exata com all:none; exclusão, resposta, aviso ao owner, decisão efetiva e bloqueio observado eram recibos diferentes.

No exemplo normativo, uma entrada exata permite a um actor enviar dados, assinar presença e observá-la. Outra entrada permite a qualquer actor do mesmo domínio apenas enviar dados. A exclusão da primeira remove duas capacidades, mas não a última. A regra ampla volta a responder pela decisão.

A linha foi realmente excluída. O problema não é persistência defeituosa, mas precedência. O melhor candidato deixou de existir e o próximo passou a ser selecionado. Para cortar toda permissão, o RFC orienta modificar a entrada específica para all:none. A negativa permanece mais específica do que o grant curinga.

A política não morava em uma linha

Cada entrada tinha owner, actor, ações e lastUpdate atribuído pelo serviço. Owner era o endpoint ou subendereço cuja política estava em questão. Actor nomeava a entidade ou conjunto autorizado. Uma ação juntava serviço e operação; core:data, por exemplo, era consultada para enviar dados pela malha ao owner.

As partes local e de domínio do actor aceitavam curingas limitados. Uma identidade concreta podia corresponder a várias entradas. A seleção filtrava pelo owner e pela correspondência, ordenava primeiro a exatidão do domínio e depois a parte local. Valores exatos venciam; entre curingas, a correspondência menor e mais específica tinha prioridade.

Logo, permissão era o resultado de um conjunto, um algoritmo e uma operação. A ausência de uma linha prova a mutação da tabela, não a decisão de acesso. Uma auditoria que guarda apenas o objeto alterado perde justamente o candidato que herdou a prioridade.

Havia ainda defaults por owner. O próprio owner e serviços APEX do domínio recebiam permissões amplas; serviços APEX de qualquer domínio recebiam core:data; outros atores globais recebiam all:none. Uma entrada explícita substituía somente o default com o mesmo actor. Estado efetivo incluía linhas e padrões predefinidos.

A negação precisava existir

Para excluir, o aplicativo enviava set com owner, actor e versão, mas sem actions. O serviço apagava a entrada, respondia ao originador e enviava separadamente ao owner um set sem ações como notificação.

O texto então avisa que, devido aos curingas, excluir pode modificar a permissão em vez de removê-la. all:none representa nenhuma operação. Mantê-lo na entrada exata faz a avaliação parar nessa negativa, sem cair para o grant amplo.

Esse registro contém informação negativa. Ausência quer dizer usar o padrão; negação explícita quer dizer não herdar. Se uma rotina genérica de limpeza remover a negativa como se fosse um tombstone inútil, o acesso reaparece sem uma nova concessão.

Concorrência de escrita não era convergência

Uma atualização normalmente começava com get, que devolvia a entrada e lastUpdate. Substituir ou excluir exigia repetir esse valor. Se a entrada já não existisse ou a versão fosse semanticamente diferente, o serviço respondia com código 555. A criação não trazia versão.

O compare-before-replace impedia sobrescrever uma mudança posterior à leitura. Após criar ou atualizar, o serviço definia novo horário, diferente do anterior.

Mesmo assim, a versão só protegia aquela mutação. Não provava que o owner recebeu a notificação, que todos os relés observaram o conjunto novo ou que uma ação seria negada. A cadeia precisa guardar leitura, versão, pedido, aceite ou conflito, estado novo, aviso emitido, aviso entregue, recálculo, propagação e teste no enforcement.

Consultar também era um privilégio

Ao receber query, o serviço validava o subject e seu domínio. Depois buscava a entrada do subject que correspondia ao originador e exigia access:query. Só então selecionava a entrada do actor investigado e verificava se todas as ações pedidas estavam presentes.

Quem pergunta e quem é testado são sujeitos distintos. Permissão de consultar não é permissão de agir. allow também descreve uma avaliação no tempo e versão presentes, não o resultado posterior de uma operação.

As entradas deviam ficar em armazenamento persistente mesmo quando o owner não estava conectado. Sair da malha não revogava a política. Persistência prolongava o estado, mas não certificava réplica, atualização ou aplicação em todo lugar.

Uma especificação tornada Historic

O RFC 3341 saiu em julho de 2002 no Standards Track, com núcleo, opções e presença APEX. Em 29 de julho de 2012, o histórico IETF registrou a reclassificação dos RFCs 3340–3343 como Historic. Pelo conhecimento do IETF, não havia implementações implantadas, e a função era fornecida pelo XMPP amplamente implantado dos RFCs 6120 e 6121.

Esse registro não atribui o resultado aos curingas e não prova falha ou incidente. Ele delimita adoção. A distinção técnica continua precisa: excluir objeto, revogar direito e observar negação são acontecimentos diferentes.

Um sistema atual pode usar a disciplina sem se dizer APEX. Registre candidatos e algoritmo, preserve negativas cuja presença sustenta precedência, releia a decisão e teste o ponto real. A resposta de mudança prova o que o serviço aceitou; revogação exige provar o que o actor já não consegue fazer.

Fontes