Resumo

  • O grupo Open Cloud Mesh adotou o trabalho do protocolo de integração, e draft-ietf-ocm-integration-protocol-00 apareceu em 11 de setembro de 2026. O texto continua sendo um Internet-Draft sujeito a mudanças, não um RFC.
  • Os modos provisionado, autocontido e introspectado distribuem estado e revogação de maneiras diferentes. A emissão de tokens também pode ser entregue a um servidor separado.
  • O par receptor não precisa descobrir a delegação. Daniel Kade propõe que o operador mantenha um mapa protegido de funções, decisões e resultados; essa proposta editorial não faz parte dos requisitos do OCM.

O grupo adotou uma base de trabalho

O histórico no Datatracker registra em 11 de setembro a versão -00 do grupo e a substituição da série individual. Na mensagem com o resultado, a presidência diz que os documentos adotados são pontos de partida e continuarão evoluindo. Houve uma transferência de responsabilidade editorial para o WG; não houve aprovação final da IETF nem comprovação de implantação.

O texto atual separa a função federativa da execução dos protocolos. Para a federação, o OCM Server continua sendo o emissor. Na retaguarda, Protocol Servers podem atender WebDAV, SSH/SFTP ou uma aplicação interativa. Eles podem usar software e infraestrutura diferentes.

Até a emissão de credenciais pode sair do núcleo. Um Token Server delegado pode responder pelo endpoint de tokens. Na configuração mais enxuta descrita, o OCM Server conserva descoberta, convites, notificações e o controle dos compartilhamentos; o acesso ao recurso e a assinatura de tokens acontecem em outros componentes. A identidade externa permanece, mas a base confiável muda de forma.

Em relação à revisão individual 01, a primeira versão do WG acrescenta um modelo de ameaças. Ele pressupõe que OCM Servers, Protocol Servers pareados e qualquer Token Server delegado não estejam comprometidos e executem corretamente a política local. Assinaturas protegem o caminho de comunicação; não corrigem uma ponta confiável que foi comprometida ou mal administrada.

Cada modo encerra um compartilhamento em um momento diferente

Na integração provisionada, o OCM Server envia previamente os dados do Share por um canal assinado. O Protocol Server guarda um Share Record e recebe uma solicitação de revogação quando o acesso termina. É o único modo especificado para SSH e o mais apropriado quando a aplicação aloca uma sessão ou outro recurso por compartilhamento, pois há um aviso explícito para liberá-lo.

Na integração autocontida, não existe API de provisionamento por Share. A informação de autorização segue na declaração ocm_ip de um JWT assinado, e o Protocol Server não precisa manter estado individual. O custo aparece na revogação: um token emitido só deixa de valer ao expirar. O texto proíbe misturar esse caminho com o provisionado para o mesmo Share, evitando que um token antigo continue dando acesso depois da remoção do registro.

Na integração introspectada, cada credencial não armazenada em cache é consultada em um endpoint do RFC 7662. Isso preserva compatibilidade com receptores que ainda apresentam o sharedSecret antigo, porém cria uma dependência por requisição do OCM Server ou do Token Server. Uma resposta positiva em cache também adia a percepção de uma revogação.

Essas diferenças mudam o significado operacional de “descompartilhar”. Um inventário que registra apenas compatibilidade com OCM-IP omite onde o estado fica, qual componente precisa estar disponível e quanto tempo uma decisão de revogação leva para alcançar o acesso real.

A transparência do rascunho é voltada ao receptor

O requisito central determina que o servidor receptor não tenha de implementar nem conhecer o OCM-IP. O endpoint informado pode terminar no OCM Server, em um proxy reverso ou em outro host com o Protocol Server. O nível OCM não oferece uma capacidade que revele essa composição ao par remoto.

No domínio emissor, a relação é deliberada. Operadores fazem o pareamento fora de banda, associando protocolos, tipos de recurso, modos, domínios, APIs e endereços de JWKS. O Protocol Server precisa manter uma lista de domínios OCM autorizados e rejeitar emissores que não foram pareados.

O canal interno usa HTTP Message Signatures e conjuntos de JWK; a frente usa JWTs assinados. A verificação liga uma afirmação a uma chave. A lista e o estado do Share dizem se essa afirmação tem autoridade naquele contexto.

O resultado criptográfico não registra quem aprovou a troca de um servidor, por que uma duração foi alterada ou se uma sessão foi de fato desmontada depois da revogação. O próprio documento inclui o Protocol Server na base computacional confiável do emissor. Um Token Server delegado recebe autoridade para assinar e dados de identidade e compartilhamento. São transferências de responsabilidade, não meros detalhes de hospedagem.

A IANA ainda não atribuiu ocm_ip

O rascunho solicita duas inscrições futuras: ocm_ip como declaração JWT e como membro de resposta de introspecção OAuth, quando o documento estiver em forma de RFC. O registro JWT da IANA e os registros de parâmetros OAuth não continham a entrada exata no momento da verificação.

Esse é o estado esperado. A adoção escolhe um documento para o WG desenvolver; não executa as ações da seção IANA Considerations. Quem experimentar o protocolo precisa identificar a revisão e não apresentar o nome pedido como valor já padronizado.

Um mapa interno para a delegação real

Daniel Kade propõe um mapa de responsabilidade da delegação, protegido por controle de acesso. Ele deve vincular OCM Server, Protocol Server e Token Server às funções, protocolos e recursos atribuídos; modo escolhido; identificadores de endpoint e chave; período de vigência; pessoa ou processo que autorizou a mudança; resultado da revogação e da liberação de recursos; contato de incidente; e local dos registros de apoio.

Isso não é requisito da IETF ou do OCM. O mapa tampouco deve virar carga do token ou exposição da topologia para todos os pares. Um recibo público, quando necessário, pode conter somente um identificador opaco, a classe da função, o intervalo de validade e um resultado verificado. Nomes internos, dados pessoais e segredos continuam restritos.

O mapa documenta, mas não concede acesso. Uma substituição cria um novo registro ligado ao anterior. No modo provisionado, entrega da revogação e liberação do recurso são eventos distintos. No modo autocontido, fim do prazo e observação de que o acesso cessou não são a mesma evidência.

A separação segue o Policy Mirror de Heng Lu: ator, regra e evidência não podem falar um pelo outro. A Minimum Initial Specification permite manter o protocolo comum enxuto e adicionar uma camada local de registro. A federação não precisa expor a cozinha para que o operador saiba quem preparou cada parte.

Fontes

  1. OCM Integration Protocol, WG 00
  2. Registro atual no Datatracker
  3. Histórico do documento
  4. Mensagem com o resultado da adoção
  5. Predecessor individual, revisão 01
  6. Grupo Open Cloud Mesh
  7. Ata do OCM no IETF 126
  8. Protocolo OCM básico, WG 06
  9. RFC 9421 — HTTP Message Signatures
  10. RFC 7517 — JSON Web Key
  11. RFC 7662 — OAuth 2.0 Token Introspection
  12. RFC 7519 — JSON Web Token
  13. Registro JWT da IANA
  14. Registros OAuth da IANA
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification