%% You should probably cite draft-ietf-ocm-integration-protocol instead of this I-D. @techreport{nordin-ocm-integration-protocol-00, number = {draft-nordin-ocm-integration-protocol-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-nordin-ocm-integration-protocol/00/}, author = {Micke Nordin and Giuseppe Lo Presti and Mahdi Baghbani}, title = {{Open Cloud Mesh Integration Protocol}}, pagetotal = 38, year = 2026, month = jun, day = 15, abstract = {The Open Cloud Mesh Integration Protocol (OCM-IP) defines how an Open Cloud Mesh (OCM) Server can integrate supporting servers, such as SSH/SFTP servers, web application platforms, or stand-alone WebDAV servers, to perform protocol-specific work on its behalf. OCM-IP makes it possible for existing OCM Servers to offload protocol specific interactions to stand-alone servers, or even implement OCM as a lightweight server that handles only the OCM parts of a deployment: discovery, share creation, token issuance and signing. Anything protocol-specific, such as serving files over WebDAV, providing SSH access, or running an interactive web application, can be handed off to one or more Protocol Servers running elsewhere, possibly operated with different software and on different infrastructure. OCM-IP defines three integration modes: a provisioned mode, in which the OCM Server pushes Share information to the Protocol Server over a signed back channel; a self-contained mode, in which the Share information is embedded in the signed access token itself, so that the Protocol Server needs no per-share state and no inbound API at all; and an introspected mode, in which the Protocol Server validates presented credentials through a token introspection endpoint, restoring compatibility with Receiving Servers that do not support token exchange. OCM-IP is a protocol between the Sending OCM Server and its Protocol Servers only. The Receiving Server is not involved in, and does not need to be aware of, this protocol: everything it observes is indistinguishable from the Sending Server serving the access protocols itself. For this reason, an OCM Sending Server MAY adopt a different strategy to interoperate with Protocol Servers, including e.g. establishing trust via shared keys, without compromising compliance with the OCM protocol.}, }