要約

  • Release 5は、別々のCAPIF Core Function（CCF）間でサービスAPIを共有する仕組みを加えた。
  • 相互接続は、相手の識別、相互TLS、提供者の共有指定、呼び出し元ごとの可視性規則を通る。

API隣人のドアが見つかった。Release 5は、いきなりノックせずに台帳を開く。

ETSIは10月26日、OpenCAPIF 5.0.0を発表した。中心機能はCAPIF Interconnection。別々に運用されるCAPIF環境が、組織をまたいでAPIを公開し、発見できる。あるCCFにつながる呼び出し元が、別のCCFの背後にあるサービスAPIを使えるようになる。発表文では「共有」と一語で済むが、運用では相手を確認し、持ち出すAPIを選び、見せる相手を決める。

接続はローカルCCFの管理者が開始する。CCF-Aは相互TLSでCCF-Bに接続し、CCF ID、ドメイン、認証局情報、公開鍵を送る。CCF-Bは相手を記録して自らの情報を返す。両者は共有対象のAPIを同期する。まず相手の身元、その次にサービス一覧。電話帳より先に名刺を交換する順序だ。

APIを共有するかは提供者の指定で決まる。isShareable が true であり、capifProvDoms に接続先ドメインが含まれ、APIの元がその相手ではなく、公開経路に同じ相手がすでに入っていないことが条件だ。受信側のコピーは共有不可として登録される。同じAPIがループして戻るのを防ぐ。

Open Discoverは加入前の確認を受け持つ。呼び出し元はRegister Serviceから得た有効なトークンで、API、バージョン、エンドポイントがあるかを調べられる。APIがなければ、先に加入手続きへ進まずに済む。棚に商品があるか聞いてから会員証を作る順番だ。

Visibility Controlは検索結果を呼び出し元に合わせる。提供者や管理者は提供者、API、API Exposing Function（AEF）を対象にしたルールを作り、呼び出し元の例外、既定の許可・拒否、ルールの有効状態と期間を設定できる。Discover Serviceは各要求に有効なルールを適用する。同じAPIでも、誰に見えるかは一律ではない。

Release 5では、別のAEFなら同じAPI名を公開できる。同一AEF内の重複は拒否される。名前の衝突をプラットフォーム全体で扱うのではなく、APIを公開する機能単位に区切った。

3GPP Release 16はCAPIF相互接続を導入し、CAPIF-6/6e参照点とセキュリティ手順を定めた。実装の細部には仕様が決めていない部分があり、OpenCAPIFはその領域を埋める自らの実装提案を公開している。Release 5の見どころは、提案を動かせる形にし、接続、同期、可視性の順序を文書化したことだ。

新しいテストは31件。内訳は相互接続11、可視性12、Open Discover 6、AEF間の同名API 2。公開テスト数は新機能の輪郭を見せる。運用者に残る仕事は、どの関係が有効か、どのAPIが通ったか、終了時に遠隔コピーを消せたかを継続して記録することだ。

Sources