要約

  • Open Cloud Mesh は受信者にアクセス付与を知らせるが、WebDAV、SSH、個別アプリで行われる実アクセスは OCM の通知より後に始まる。
  • 新しい OCM 統合ドラフトが示す重要な境界は、通知、利用可能な資格情報、成功したリソース操作が別々の記録だという点にある。

共有フォルダーの通知が届き、一覧にも名前が出る。しかし開くと失敗する。このとき、通知が偽だったと即断する必要はない。誤っていたのは、通知をその後の全工程の完了証明として数えた運用モデルかもしれない。

9月11日に公開された最初の WG 版 draft-ietf-ocm-integration-protocol-00 は、この差を明確にする。OCM は Sending Server から Receiving Server へ、ある相手に Resource へのアクセスが付与されたことを知らせる。実際のアクセスは WebDAV、SSH、あるいはアプリ固有のプロトコルが担う。統合プロトコルは後半を Protocol Server に委任できるようにするが、受信側には通常の OCM サーバーと同じ姿を見せる。

ここで分けるべきなのは製品部品ではない。宣言、認可、実行、結果という現実の層である。

通知が示すのは次の入口まで

Share Creation Notification には当事者、providerId、プロトコル情報、権限、期限などが入る。次にどこへ接続するかは示せても、その接続が成功したという答えは含まれない。

providerId はバックチャネルの Share Record とフロントチャネルの資格情報を結ぶ。だがドラフトは、これは credential ではなく identifier だと明記する。通知で相手に見える値なので、知っているだけでアクセスを許してはならない。認可は検証済みのアクセストークン、または introspection で active と確認された資格情報から導かれる。

有効な JWT も万能の領収書ではない。署名は発行者と保護された claim の完全性を確認する。Protocol Server はさらに issuer、audience、subject、期限、pairing、Share 状態を照合し、権限を適用する。その後でストレージやアプリが操作を実行する。正しい署名は、存在しないファイルを作らず、古い版を新しくせず、WebDAV の失敗を完了に変えない。

通知前の失敗を一つだけ封じる

Provisioned integration では、OCM Server が署名付き Share Provisioning Request を Protocol Server に送る。Protocol Server が検証し、Share Record を保存して成功を返した後でなければ、Share Creation Notification を送れない。

provisioning が失敗したときは Share を作ってはならない。そうしなければ、実際には Resource に届かない共有を Receiving Party に知らせることになるからだ。

この順序は「委任先が受け入れていないのに通知だけ成功する」という偽陽性を除く。しかし将来のアクセス全部を保証するわけではない。鍵の変更、トークン交換の失敗、期限切れ、ID 結び付けの不一致、Resource の移動、Protocol Server の停止、基盤プロトコルのエラー、受信アプリの中断は後で起こり得る。

従って記録できるのは「通知より前に provisioning が成功した」までであり、「受信者が Resource を利用した」ではない。

同じ通知の下に三つの時計

ドラフトは provisioned、self-contained、introspected の三方式を定める。表面上は同じ共有通知でも、失効と証跡の時間軸は異なる。

Provisioned 方式は Protocol Server に Share Record を置き、明示的に revoke できる。Self-contained 方式は Share 情報を署名済み ocm_ip claim に収めるため、発行済みトークンは期限まで生きる。Introspected 方式は資格情報の active 状態を照会するが、肯定応答がキャッシュされれば、失効の反映はその期限まで遅れる。

「14時に共有を解除した」という一行では、アクセス停止時刻は分からない。見るべきものはそれぞれ Share Record の削除、最後の有効トークンの寿命、肯定 introspection キャッシュの期限だ。内部委任を相手に公開する必要はないが、運用者は採用方式と完了したライフサイクル処理を保護されたローカル記録に残す必要がある。

最後の結果はアクセスプロトコルが返す

フロントチャネルでは WebDAV、SSH、個別アプリの意味が支配する。ドラフトも Protocol Server のエラーは各アクセスプロトコルの意味に従うとしている。OCM が知らない結果を代弁しないための境界だ。

WebDAV なら HTTP status、method、ETag や版、body の完了が必要になる。SSH の認証や session 成立は、目的のコマンドやファイル操作の完了とは違う。Web アプリの認可済み画面が開いても、計算ジョブが終わったとは限らない。

実用的な証跡は、Share 通知、トークン発行または introspection、Protocol Server の認可判断、基盤プロトコルの応答と Resource の版、受信側の結果を結ぶ。集計表示はできるが、どの層がどの事実を証明したかを消してはいけない。

出典