Summary

  • The Open Cloud Mesh Working Group adopted the integration-protocol work, and draft-ietf-ocm-integration-protocol-00 appeared on 11 September 2026. It remains an evolving Internet-Draft, not an RFC.
  • Three modes let an OCM Server delegate access-protocol work. A separate Token Server can also issue credentials, while the receiving server must not need to know that any of this delegation exists.
  • Cryptographic checks bind requests and tokens to configured pairings. Operators still need a separate, access-controlled map of delegated roles, changes and revocation outcomes; that map is an editorial proposal, not an OCM requirement.

A federation face with several systems behind it

The Datatracker history records a new Working Group version on 11 September and says it replaces the individual draft-nordin-ocm-integration-protocol series. In the adoption-result message, the chair describes the documents as starting points that will keep evolving. The distinction matters: the OCM Working Group now owns the work, but the current text is neither an IETF-approved standard nor evidence that anyone has deployed it.

The news is architectural. WG revision 00 separates the OCM Server—the system that speaks for the sending side of the federation—from one or more Protocol Servers that perform the actual access work. A Protocol Server might expose WebDAV, SSH/SFTP or an interactive web application. It may use different software and run on different infrastructure from the OCM Server.

This is not simply a reverse-proxy recipe. In one topology, the OCM Server can be reduced to discovery, share bookkeeping, notifications and invitations. Resource access happens elsewhere. The draft even allows the token endpoint to be delegated to a Token Server, so token issuance can move out too. The federation still sees the OCM Server as the sending party even when the operational path is divided among several components.

The document is also more explicit than its predecessor about where trust stops. Compared with individual revision 01, the first WG version records adoption and adds a threat model. That model assumes the paired OCM and Protocol Servers, and any delegated Token Server, are uncompromised and correctly enforce local policy. The new section is valuable precisely because it does not pretend the cryptography can repair a compromised trusted endpoint.

Three modes, three operational liabilities

Provisioned integration sends Share information to the Protocol Server before access. The back channel carries signed provisioning and revocation requests, and the Protocol Server stores a Share Record. This is the only mode specified for SSH and the preferred option where a service allocates per-share resources, because the revocation request can also tell it to release them.

Self-contained integration has no per-share back channel. The OCM Server places the information needed to authorize access in an ocm_ip claim inside a signed JWT. The Protocol Server can therefore remain stateless about shares. The price is revocation latency: an issued token cannot be withdrawn before it expires. The draft warns against mixing this path with provisioned state for the same share, because an older self-contained token could survive a provisioning-side revocation.

Introspected integration validates each presented credential through an RFC 7662 endpoint. It exists for compatibility with receiving servers that still present the legacy shared secret instead of performing token exchange. This mode restores a per-request dependency on the OCM Server or its Token Server, and a cached positive answer delays revocation until the cache expires.

These are not equivalent implementation styles. They relocate state, availability dependence, metadata exposure and the time at which “unshare” becomes effective. A procurement sheet that says only “supports OCM-IP” would conceal the most important operational choice.

Transparency to the peer is intentional

The draft makes its compatibility objective unusually clear. The receiving server must not be required to implement or even know about OCM-IP. Endpoints may terminate on the OCM Server, a reverse proxy or a Protocol Server on another hostname, but the OCM layer presents an ordinary access endpoint. There is no OCM capability for a remote peer to discover the integration arrangement.

That invisibility is bounded. It does not say operators should be ignorant of their own topology. OCM Server and Protocol Server are paired out of band, normally by their operators. They configure protocols, resource types, integration modes, domains, endpoints and JSON Web Key Set locations. The Protocol Server must keep an allowlist of paired OCM Server domains and reject unpaired issuers.

The technical trust chain is concrete. Back-channel calls use HTTP Message Signatures verified through published JWK sets. Access tokens use signed JWTs. Introspection requests are signed in the opposite direction when that mode is used. A valid signature proves that a key made an assertion; the allowlist and share state determine whether that assertion has authority here.

It does not prove why a Token Server received signing authority, who approved a Protocol Server replacement, whether the key visible today was the key used last month, or whether a revoked notebook session was actually dismantled. Those are organisational facts. Treating signature success as a complete accountability record would ask one evidence object to speak for decisions it never observed.

The draft itself makes the stakes visible. It places each Protocol Server inside the sending side's trusted computing base for the protocols it serves. A delegated Token Server receives token-signing authority and the share and identity information needed to issue credentials. Moving those functions is not merely load distribution; it reallocates trusted roles.

The requested registry names are not live assignments

The document asks IANA to register ocm_ip both as a JWT claim and as a token-introspection response member once the draft is in RFC form. At this cutoff, the live JWT registry and OAuth Parameters registries contain no exact ocm_ip entry.

That is expected. Working Group adoption makes a document the group's work item; it does not execute its IANA Considerations. Implementers experimenting with the draft should identify the revision they use and should not describe a requested name as an assigned standard value.

Keep a local delegation-accountability map

The receiving side does not need a new discovery signal. The sending operator does need an evidence object that survives changes behind the federation face. A protected delegation-accountability map could bind the OCM Server, each Protocol Server and any Token Server to its role, protocols and resource types; the selected integration mode; endpoint and key identifiers; effective dates; the person or process that authorized a change; revocation and resource-cleanup results; incident contact; and the retention location for supporting logs.

This is Daniel Kade's editorial proposal, not an IETF or OCM requirement. It should not be copied wholesale into tokens or exposed to every receiving peer. A public receipt, where one is useful, needs only an opaque map identifier, the delegated role class, an effective period and a verified outcome. Internal hostnames, personal identifiers, private keys and sensitive topology remain access controlled.

The map also should not grant authority. It records an operator decision and an observed result; the live pairing, key and protocol rules still govern access. When a component changes, a new entry links to the superseded one instead of rewriting history. When provisioned mode revokes a share, the record distinguishes delivery of the request from release of the resource. When a self-contained token expires, it distinguishes elapsed lifetime from proof that no copied credential remains in use.

This separation follows Heng Lu's Policy Mirror: actor, rule and evidence should not impersonate one another. The Minimum Initial Specification also leaves room for a small shared protocol and richer local records. OCM-IP can preserve a clean federation surface without forcing operators to erase the delegation choices that make that surface work.

Sources

  1. OCM Integration Protocol, WG revision 00
  2. Current Datatracker record
  3. Datatracker document history
  4. OCM chair adoption-result message
  5. Individual predecessor, revision 01
  6. Open Cloud Mesh Working Group
  7. IETF 126 OCM minutes
  8. Open Cloud Mesh base protocol, WG revision 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. IANA JSON Web Token registry
  14. IANA OAuth Parameters registries
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification