Summary

  • Open Cloud Mesh tells a Receiving Party that access has been granted, but the OCM layer deliberately stops before the WebDAV, SSH or application transaction that exercises the grant.
  • The new OCM integration draft makes the evidence boundary unusually visible: a notification, a valid credential and a successful resource operation are three different records.

The email says a folder has been shared. The remote service lists it. The recipient clicks, and the request fails.

Nothing in that sequence requires the first message to have been false. It requires the operator to stop treating the message as a receipt for everything that should have happened after it.

That is the useful operational lesson in draft-ietf-ocm-integration-protocol-00, the first Working Group version of the Open Cloud Mesh Integration Protocol posted on 11 September. Open Cloud Mesh coordinates federation: a Sending Server notifies a Receiving Server that a party has been granted access to a Resource. Actual access comes later through WebDAV, SSH or an application-specific protocol. The integration draft lets the OCM Server delegate that later work to a Protocol Server without changing what the receiving peer sees.

The distinction is not cosmetic. It divides an administrative assertion from a running result.

A notification is an offer to continue

An OCM Share Creation Notification carries the parties, a providerId, protocol entries, permissions and other information needed to continue the exchange. It may tell the receiver where to make the next request. It does not contain the response to that request.

The providerId makes the boundary especially clear. It links the back-channel Share state to the credential used on the front channel, but the draft calls it an identifier, not a credential. The Receiving Server learns it in the notification; possession must not grant access. Authorization must instead derive from a verified access token or, in the introspected compatibility mode, a credential whose active state is checked at the OCM Server.

Even a valid credential answers a bounded question. A signature can establish who issued the token and whether protected claims were altered. The Protocol Server still has to check issuer, audience, subject, expiry, pairing and Share state, then enforce the permissions. The storage system or application must still execute the operation. A valid grant cannot make an absent file exist, make a stale version current or turn a failed WebDAV request into a completed transfer.

This is the reality-layer problem in its smallest useful form. Notification is not authorization. Authorization is not execution. Execution is not recipient outcome.

The draft refuses one obvious false positive

Provisioned integration supplies the strongest evidence that the protocol designers understand the danger. In this mode, the OCM Server sends a signed Share Provisioning Request to the Protocol Server. The Protocol Server verifies it, stores the Share Record and acknowledges. Only then may the OCM Server send the Share Creation Notification.

The ordering is mandatory. If provisioning fails, the OCM Server must not create the Share, because the Receiving Party would otherwise be notified of a Share whose Resource access cannot work.

That rule removes one bad state: “announced although the access server rejected provisioning.” It does not prove all future access. A key can rotate. A token exchange can fail. A token can expire. An account binding can disagree. The Resource can move. The Protocol Server can be unavailable. The underlying protocol can return its own error. The recipient application can stop before completion.

The correct receipt is therefore narrow: provisioning succeeded before notification. It should never be relabelled “recipient accessed Resource.”

Three modes, three different clocks

The draft defines provisioned, self-contained and introspected integration. All can lead to the same OCM-facing announcement, but their later evidence and revocation behaviour differ.

Provisioned mode keeps a Share Record at the Protocol Server and supports an explicit revocation request. Self-contained mode puts Share information inside the signed ocm_ip claim. The Protocol Server has no per-Share back-channel state, so an issued token can remain effective until it expires. Introspected mode asks an endpoint whether the presented credential is active; revocation takes effect after any cached positive introspection response expires.

Those clocks matter. “The Share was withdrawn at 14:00” is not enough to infer when access ended. In one mode the critical receipt is revocation of the Share Record. In another it is the lifetime of the last valid token. In the third it is the expiry horizon of cached introspection. The same visible invitation can sit above three different control systems.

This is not a reason to expose the internal topology to every peer. The draft intentionally makes delegated serving indistinguishable from the OCM Server serving the protocol itself. It is a reason for the operator to retain a local, protected record of which mode governed the Share and which lifecycle action actually completed.

The last mile belongs to the access protocol

The front channel ends at WebDAV, SSH or the relevant application. The draft says errors returned there use the semantics of that access protocol. That keeps OCM from pretending to know more than it does.

For a WebDAV resource, a useful record may include the HTTP status, method, ETag or content version and whether the response body completed. For SSH, authentication and session establishment are distinct from the command or file operation the user intended. For a web application, opening an authorized page is not the same as completing the computational job behind it.

The receipt chain should join five layers: the Share notification; credential issuance or introspection; the Protocol Server's authorization decision; the underlying protocol response and resource version; and the recipient-side result. A dashboard may summarize the chain, but it must preserve which layer supplied each fact.

Sources