要約

  • Open Cloud Mesh WGは統合プロトコルの作業を採用し、2026年9月11日にdraft-ietf-ocm-integration-protocol-00が公開された。現段階は更新可能なInternet-Draftであり、RFCではない。
  • プロビジョニング型、自己完結型、イントロスペクション型では、状態、可用性、失効の効き方が異なる。トークン発行を別のToken Serverへ委任する構成もある。
  • 受信側には内部構成を知らせないのが仕様上の目的である。Daniel Kadeは、運用者が役割と変更結果を保護された別の台帳で結ぶことを提案する。これはOCMの要件ではない。

採用されたのは完成品ではなく作業対象

Datatrackerの履歴は、9月11日にWG版-00が提出され、個人草案を置き換えたことを記録している。採用結果のメールも、二つの文書を今後変わっていく出発点と位置づけた。WGが文書を引き受けたことは事実だが、IETF標準の完成や実装の普及まで意味しない。

WG版00では、連携上の送信主体はOCM Serverのままである。その背後に置くProtocol ServerがWebDAV、SSH/SFTP、Webアプリケーションなどの実処理を担う。別のソフトウェアでも、別の基盤でもよい。

さらに、トークンのエンドポイントをToken Serverへ移せる。軽量な構成では、OCM Serverに残るのはディスカバリー、共有の管理、通知、招待といった連携ロジックで、資源アクセスと認証情報の発行は外部コンポーネントが行う。相手に提示するOCM上の顔は同じでも、信頼される実行主体は増える。

個人版01からの重要な追加は脅威モデルである。そこでは、送受信のOCM Server、ペア設定済みのProtocol Server、委任されたToken Serverが侵害されておらず、ローカル方針を正しく実施することを前提にする。通信路への攻撃は署名やTLSで扱えるが、信頼済み端点そのものの侵害は仕様の外側に残る。

失効を一語で扱えない三つの方式

プロビジョニング型では、アクセスが始まる前にOCM Serverが署名付きバックチャネルで共有情報を渡し、Protocol ServerがShare Recordを保持する。共有の終了時には失効要求を送り、関連資源の解放も求める。SSHに対応するのはこの方式だけであり、共有ごとに計算セッションを起動するアプリにも向く。

自己完結型には共有単位のバックチャネルがない。署名付きJWTのocm_ipクレームに必要な情報を収めるため、Protocol Serverは共有状態を保存せずに済む。その代わり、発行済みトークンは期限まで取り消せない。同一共有でプロビジョニング型と混ぜると、Share Recordを消した後も古いトークンが効く恐れがあるため、草案は混用を禁じている。

イントロスペクション型は、提示された認証情報をRFC 7662のエンドポイントへ照会する。旧来のsharedSecretを直接送る受信サーバーとの互換性を維持できる一方、キャッシュされていない要求ごとにOCM ServerまたはToken Serverへ依存する。肯定応答をキャッシュすれば、その期限までは失効が反映されない。

三方式は同じ機能の実装違いではない。状態の置き場所、停止時の依存先、メタデータの開示範囲、「共有停止」が実際に成立する時刻を変える。

相手側の透明性と運用側の透明性は別物

草案のTransparency Requirementは受信側の負担をなくす規則だ。受信サーバーはOCM-IPを実装する必要も、その存在を知る必要もない。通知されたアドレスの先がOCM Server、リバースプロキシ、別ホストのProtocol Serverのどれでも、OCM層から区別できない。発見用の能力表示も設けない。

しかし送信側の内部では、運用者が帯域外でペア設定を行う。担当プロトコルと資源種別、方式、ドメイン、API、JWKSの位置などを双方へ設定する。Protocol Serverは許可済みOCMドメインのリストを持ち、未設定の発行者を拒否しなければならない。

バックチャネルはHTTP Message Signaturesと公開されたJWK Setで確認し、アクセス側は署名付きJWTを使う。署名は鍵と主張を結び、ペア設定はその主張にローカルな権限を与える。

ただし、誰が構成変更を承認したか、なぜ方式を変更したか、鍵の前任関係は何か、失効後にアプリのセッションを本当に削除したかまでは残さない。草案はProtocol Serverを送信側のtrusted computing baseに含め、Token Serverには署名権限と共有・識別情報を渡す。負荷分散というより、信頼役割の移転である。

IANA登録はまだ将来形

IANA Considerationsは、文書がRFCになった時点でocm_ipをJWTクレームとOAuthイントロスペクション応答メンバーとして登録するよう求める。調査時点のIANA JWTレジストリとOAuth Parametersには、同名の正式項目がない。

WG採用と登録実施を分けて読めば矛盾はない。試験実装は依拠する草案版を明示し、申請予定の名称を割当済み標準値として扱わないことが重要だ。

外から見えない関係を内側で消さない

Daniel Kadeが提案するのは、アクセス制御された委任責任マップである。OCM Server、各Protocol Server、Token Serverについて、役割、対象プロトコルと資源、選択方式、エンドポイントと鍵の識別子、有効期間、変更を承認した人物または処理、失効と資源解放の結果、障害連絡先、裏付けログの保管場所を関連づける。

これはIETFやOCMの規定ではない。トークンに全情報を埋めたり、受信側へ内部トポロジーを開示したりする提案でもない。公開用の証票が必要なら、不透明なマップID、役割の種類、有効期間、確認済み結果だけでよい。内部ホスト名、個人情報、秘密鍵は非公開のままにする。

マップは権限を作らず、決定と観測を残す。コンポーネントを交換したら旧記録を上書きせず、後継関係を張る。失効要求の配送と資源の解放を分け、トークン期限の経過とアクセス停止の観測も混同しない。

Heng LuのThe Policy Mirrorが示すように、主体、規則、証拠は相互に代用できない。Minimum Initial Specificationの考え方なら、共通プロトコルは小さく保ちつつ、各運用者が必要な説明責任を追加できる。相手側へ見せない設計と、自分たちの履歴を残す運用は両立する。

情報源

  1. OCM Integration Protocol WG版00
  2. Datatrackerの現行記録
  3. Datatrackerの文書履歴
  4. WG採用結果のメール
  5. 個人草案版01
  6. Open Cloud Mesh WG
  7. IETF 126 OCM議事録
  8. OCM基本プロトコル 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. IANA JWTレジストリ
  14. IANA OAuth Parameters
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification