Resumen

  • Open Cloud Mesh informa al destinatario de que se le concedió acceso, pero termina antes de la operación WebDAV, SSH o de aplicación que debe materializarlo.
  • El nuevo borrador de integración de OCM muestra una frontera útil: notificación, credencial válida y operación terminada son registros diferentes.

La invitación dice que una carpeta fue compartida. El servicio remoto la muestra. El destinatario pulsa y recibe un error. La notificación inicial no tiene por qué haber sido falsa; el fallo puede estar en haberla contado como prueba de toda la cadena posterior.

draft-ietf-ocm-integration-protocol-00, primera versión del grupo de trabajo publicada el 11 de septiembre, deja visible esa separación. OCM coordina la federación: el Sending Server avisa al Receiving Server de que una parte recibió acceso a un Resource. El acceso real ocurre después mediante WebDAV, SSH o un protocolo de aplicación. El borrador permite delegar esa tarea en un Protocol Server sin cambiar la apariencia para el par receptor.

No es sólo arquitectura. Es la diferencia entre una afirmación administrativa y un resultado producido por sistemas en ejecución.

La notificación entrega una ruta, no el resultado

La Share Creation Notification incluye partes, providerId, entradas de protocolo, permisos y vencimiento. Puede indicar dónde presentar la próxima petición, pero no contiene la respuesta a esa petición.

El providerId enlaza el estado del Share en el canal posterior con la credencial del canal frontal. El borrador insiste en que es un identificador, no una credencial; conocerlo no debe conceder acceso. La autorización procede de un token verificado o, en el modo introspected, de una credencial que el endpoint declara activa.

Un JWT válido también tiene un alcance limitado. La firma permite comprobar emisor e integridad de los claims. El Protocol Server aún debe validar issuer, audience, subject, expiración, pairing y estado del Share, y aplicar permisos. Después el almacenamiento o la aplicación tienen que ejecutar la operación. Una firma correcta no crea un archivo ausente, no identifica por sí sola la versión correcta ni convierte un error WebDAV en una transferencia completa.

Una falsa confirmación que el borrador prohíbe

En la integración provisioned, el OCM Server envía primero una Share Provisioning Request firmada. El Protocol Server verifica, guarda el Share Record y confirma. Sólo tras ese éxito puede salir la Share Creation Notification.

Si el provisioning falla, el servidor no debe crear el Share: de otro modo notificaría a la persona receptora un acceso que no puede funcionar. La norma evita el estado «anunciado aunque el servidor de acceso rechazó la preparación».

No garantiza intentos futuros. Puede fallar el intercambio de token, caducar la credencial, romperse la asociación de identidad, moverse el Resource, caer el Protocol Server o responder con error el protocolo subyacente. El comprobante honesto dice «provisioning correcto antes de notificar», nunca «el destinatario accedió».

Tres modos, tres relojes

Provisioned, self-contained e introspected producen una invitación OCM comparable, pero conservan estados diferentes.

Provisioned guarda un Share Record y admite una revocación explícita. Self-contained coloca la información del Share en el claim firmado ocm_ip; sin estado por Share, un token emitido sobrevive hasta que caduca. Introspected consulta si la credencial sigue activa, aunque una respuesta positiva en caché retrasa la revocación.

Por eso «retirado a las 14:00» no determina cuándo terminó el acceso. Según el modo, mandan la revocación del registro, la vida del último token o el horizonte de la caché. No hace falta revelar al par la topología delegada; sí hace falta que el operador guarde localmente el modo y la acción de ciclo de vida que se completó.

El protocolo de acceso aporta la última evidencia

Los errores del canal frontal mantienen la semántica de WebDAV, SSH o la aplicación. OCM no debe apropiarse de un resultado que no observa.

En WebDAV pueden ser relevantes método, estado HTTP, ETag o versión y finalización del cuerpo. En SSH, autenticar y abrir sesión no demuestra que terminó el comando o la transferencia prevista. En una aplicación web, abrir una vista autorizada no prueba la finalización de un trabajo.

La cadena mínima enlaza cinco capas: notificación del Share; emisión o introspección de la credencial; decisión del Protocol Server; respuesta del protocolo y versión del Resource; resultado en la aplicación receptora. El panel puede resumirlas, no fundirlas.

Fuentes