Resumo

  • A RFC 9670 permite omitir ShareNotifications de mudanças derivadas de Principal de grupo quando o volume seria excessivo; o silêncio da caixa de avisos não é um recibo negativo de autorização.
  • O estado de compartilhamento precisa ser correlacionado com identidade, mapa shareWith, myRights do destinatário, assinatura do recurso, execução concreta e alcance das cópias após revogação.

Uma equipe perdeu acesso a um calendário compartilhado depois de uma alteração de grupo. Ninguém recebeu um aviso individual. O painel de segurança concluiu que a política não havia mudado, porque sua única fonte era a contagem de ShareNotifications.

O servidor podia estar em conformidade. A RFC 9670 diz que o servidor deve criar uma notificação quando os direitos mudam, mas pode dispensar notificações de alterações em um Principal de grupo quando elas forem mais avassaladoras do que úteis. O erro foi transformar um canal opcionalmente resumido em inventário de autorização.

O mapa comum não torna iguais todos os direitos

A RFC 9670 define Principal e ShareNotification e fornece uma moldura para tipos de dados compartilháveis. Cada tipo precisa expor isSubscribed, myRights e shareWith.

shareWith associa IDs de Principal a mapas de direitos. myRights descreve as permissões atuais do usuário que lê o objeto. isSubscribed informa se ele quer acompanhar aquele recurso na experiência cotidiana.

A especificação não define o que pode ser compartilhado nem a granularidade das permissões. Um tipo de calendário e um tipo de lista de tarefas podem usar chaves diferentes ou dar consequência diferente à mesma aparência de “editar”. Por isso, uma plataforma não deve normalizar tudo em um selo genérico “tem acesso”.

O proprietário da Account não aparece em shareWith, pois seus direitos são implícitos. O mapa é uma superfície de concessões a outros Principals, não um censo total de autoridade.

Depois de uma gravação bem-sucedida, o operador deve reler o mapa do lado do dono, consultar myRights como o destinatário e tentar a operação exata em questão. Um direito de leitura não comprova atualização; um direito administrativo não comprova que o cliente o apresenta corretamente.

Grupo, pessoa e Account formam relações diferentes

Um Principal pode representar indivíduo, grupo, sala, equipamento ou outra entidade. Ele pode se relacionar com zero ou várias Accounts. A capacidade de owner liga uma Account ao Principal que a possui e à Account em que o objeto Principal pode ser encontrado.

Gerenciar o conjunto de Principals fica fora do escopo da RFC. Diretório, ciclo de vida de grupo, contas de serviço e identidade humana pertencem ao sistema local. Um recibo sério registra ID imutável, geração do diretório, tipo de Principal, Account de identidade, Account do objeto e owner.

Nome e email servem à apresentação. A própria RFC alerta que, se editáveis, podem permitir spoofing. Impedir apenas nomes idênticos não bloqueia pequenas grafias falsas ou caracteres Unicode visualmente semelhantes. O seletor pode parecer correto e ainda apontar para o Principal errado.

Para grupos, a investigação também precisa guardar como e quando a associação foi resolvida. A RFC não padroniza esse cálculo. Um myRights observado em determinado instante é mais útil do que deduzir acesso apenas pela presença do grupo no mapa.

Estado evita sobrescrever outra decisão

O shareWith costuma ser uma propriedade composta. Duas alterações concorrentes podem substituir o mapa inteiro. A RFC 8620 fornece ifInState: o cliente envia o estado em que baseou sua edição; se o servidor já avançou, responde stateMismatch e não aplica a operação.

A resposta /set ainda separa updated de notUpdated e devolve estado anterior e novo. O recibo deve conter hash do mapa lido, oldState, precondição, patch ou mapa enviado, resultado por objeto e newState.

Esse encadeamento comprova uma mutação condicionada. Não comprova quem controlava o Principal, como o grupo foi calculado, se houve notificação, se o cliente exibiu o recurso ou se a ação pretendida ocorreu. State token é um mecanismo de sincronização, não um relatório de auditoria completo.

Permissão não obriga assinatura

Uma pessoa pode ter permissão para acessar muitos recursos e assinar apenas alguns. O isSubscribed separa interesse de autoridade. O servidor pode até recusar a assinatura de certos recursos sem retirar a permissão.

Essa regra afeta visibilidade e push. Accounts entram na Session quando pertencem ao usuário ou contêm pelo menos um registro assinado. StateChange normalmente acompanha dados assinados. Um recurso ausente da tela principal pode continuar acessível por consulta direta.

Diagnóstico correto pergunta duas coisas: “a operação foi autorizada?” e “o produto colocou esse objeto na vista esperada?”. Misturá-las produz incidentes fantasmas e também esconde acessos reais.

Notificação é uma fila sujeita a política

ShareNotification guarda objeto, Account, direitos antigos e novos, momento e entidade que causou a mudança. O principalId dessa entidade pode ser nulo. O registro ajuda até quem perdeu acesso, porque preserva o nome do objeto no momento da mudança.

Mas o servidor pode agrupar eventos, limitar o total, expirar registros e remover o mais antigo quando o limite é alcançado. A RFC adverte que apagar silenciosamente pode esconder uma mudança de segurança e recomenda preferir coalescimento e outras defesas contra negação de serviço.

Portanto, medir apenas a quantidade de notificações mistura autorização com capacidade da fila. A telemetria precisa diferenciar alteração, decisão de suprimir/agrupar, criação, entrega ao cliente, exibição e confirmação humana.

Revogar o serviço não recolhe o que saiu dele

Na revogação, remova o Principal ou grupo do mapa com controle de estado, releia myRights e faça uma nova tentativa de operação. Isso pode provar que a autoridade viva foi encerrada.

Não prova que arquivos exportados, cópias offline ou dados guardados por um cliente durante o período legítimo desapareceram. A RFC 9670 não define essa eliminação. Políticas de classificação, DRM ou gestão de dispositivos podem ter outro alcance, com outros comprovantes.

A seção de segurança reforça a separação. Um acesso breve a um cliente destravado pode virar persistência pela criação de um share para o atacante. Mudanças repetidas podem gerar negação de serviço de notificação. Abertura pública do cadastro de Principals aumenta compartilhamento acidental, conteúdo abusivo e spam.

O modelo comum reduz ambiguidade de protocolo. A organização ainda precisa provar identidade, cálculo de direitos, observabilidade e resultado no código em execução.

Fontes