Resumo

  • O Open Cloud Mesh avisa que o destinatário recebeu acesso, mas termina antes da operação WebDAV, SSH ou de aplicação que precisa concretizar esse acesso.
  • O novo rascunho de integração do OCM expõe uma fronteira essencial: notificação, credencial válida e operação concluída são registros diferentes.

O convite informa que uma pasta foi compartilhada. O serviço remoto mostra o nome. O destinatário clica e encontra um erro. A primeira mensagem não precisa ser falsa; o erro pode estar no sistema que a contou como recibo de toda a cadeia posterior.

draft-ietf-ocm-integration-protocol-00, primeira versão do grupo de trabalho publicada em 11 de setembro, torna a distinção explícita. OCM coordena a federação: um Sending Server informa ao Receiving Server que alguém recebeu acesso a um Resource. O acesso acontece depois por WebDAV, SSH ou protocolo da aplicação. O rascunho permite delegar essa etapa a um Protocol Server sem mudar o que o par receptor enxerga.

É uma separação de camadas da realidade: anúncio, autorização, execução e resultado não são sinônimos.

A notificação aponta o próximo passo

A Share Creation Notification leva partes, providerId, entradas de protocolo, permissões e prazo. Pode dizer onde apresentar a próxima requisição, mas não contém a resposta dela.

O providerId liga o estado do Share no canal posterior à credencial usada no canal frontal. Ainda assim, o texto o define como identificador, não credencial. Conhecê-lo não pode conceder acesso. A autorização deve vir de um access token verificado ou, no modo introspected, de uma credencial que o endpoint confirme como ativa.

Mesmo um JWT válido prova uma afirmação limitada. A assinatura confirma emissor e integridade dos claims. O Protocol Server ainda verifica issuer, audience, subject, expiração, pairing e estado do Share e aplica permissões. Depois, armazenamento ou aplicação executa a ação. Assinatura correta não cria arquivo inexistente, não escolhe a versão certa e não transforma erro WebDAV em transferência concluída.

Um falso sucesso que o rascunho proíbe

No modo provisioned, o OCM Server primeiro envia uma Share Provisioning Request assinada. O Protocol Server verifica, grava o Share Record e confirma. Só então a Share Creation Notification pode sair.

Se o provisioning falhar, o Share não deve ser criado, pois o destinatário receberia aviso de acesso que não pode funcionar. A regra elimina o estado “anunciado apesar da rejeição pelo servidor de acesso”.

Ela não comprova acessos futuros. A troca de token pode falhar, a credencial expirar, o vínculo de identidade divergir, o Resource mudar, o Protocol Server ficar indisponível ou o protocolo retornar erro. O recibo honesto é “provisioning bem-sucedido antes da notificação”, não “destinatário acessou o Resource”.

Três modos, três relógios

Provisioned, self-contained e introspected podem produzir o mesmo convite, mas guardam estados e revogações diferentes.

Provisioned mantém um Share Record e aceita pedido explícito de revogação. Self-contained põe dados do Share no claim assinado ocm_ip; sem estado por Share, o token emitido permanece até expirar. Introspected consulta se a credencial está ativa, mas uma resposta positiva em cache posterga a revogação.

Assim, “removido às 14h” não diz quando o acesso terminou. Conforme o modo, valem a revogação do registro, a vida do último token ou o horizonte do cache. Não é preciso mostrar a topologia delegada aos pares; o operador precisa registrar localmente o modo escolhido e a ação de ciclo de vida que realmente terminou.

O protocolo de acesso dá a última resposta

Erros no canal frontal conservam a semântica de WebDAV, SSH ou da aplicação. OCM não deve alegar um resultado que não observa.

Em WebDAV, método, status HTTP, ETag ou versão e conclusão do corpo podem compor o recibo. Em SSH, autenticar e abrir sessão não prova que o comando ou arquivo pretendido foi concluído. Numa aplicação web, abrir uma tela autorizada não demonstra o fim do trabalho de computação.

A cadeia mínima liga cinco níveis: notificação do Share; emissão ou introspecção da credencial; decisão do Protocol Server; resposta do protocolo e versão do Resource; resultado na aplicação receptora. Um painel pode resumir, mas não apagar a origem de cada fato.

Fontes