idbok

Appearance

OpenID Foundation Shared Signals WG 活動レポート (2026年2月) ​

執筆日: 2026-04-18（2026年2月分の遡及執筆）

1. 概要 ​

Shared Signals Working Group（以下 SSF WG）は、OpenID Foundation が主導するセキュリティシグナル共有のための標準化グループである。主要成果物として Shared Signals and Events Framework 1.0（SSF）、Continuous Access Evaluation Profile 1.0（CAEP）、RISC Profile 1.0 を 2025 年 9 月に Final 仕様として公開しており、2026 年 2 月時点ではコンフォーマンステストの整備、インターオペラビリティ仕様の完成、そして認定プログラムのベータ立ち上げに向けた活動が中心となっていた。

2 月は毎週火曜日（太平洋時間 10:00）に定例 WG コールを 4 回開催した。CAEP インターオペラビリティプロファイルへの受信者要件追加（PR #315）のマージ、ステータスエンドポイントの GET 専用化決定、および「ポイント・イン・タイム・シグナルステータス」（Issue #321）・「アクション・レシート」（Issue #322）という 2 つの新機能提案の起票が主要なトピックとなった。また、認定プログラムのベータ立ち上げ戦略として、FAPI や OIDC の先行事例を参照した議論が行われた。

2. 公開された仕様・ドラフト改訂 ​

2 月中に新たなドラフト版の公開やパブリックレビュー開始は確認できなかった。主要 3 仕様（SSF 1.0、CAEP 1.0、RISC Profile 1.0）は 2025 年 9 月に Final 公開済みであり、引き続き実装・認定フェーズが中心である。

CAEP インターオペラビリティプロファイルは Final 化に向けた作業が進んでおり、2 月 17 日に PR #315（受信者要件の追加）がマージされた。このプロファイルは CAEP とは独立したドキュメントとして管理されている。

3. ミーティングと議論 ​

定例 WG コール（2026-02-03） ​

参加者（12 名）: SGNL、Jamf、Google、Okta 等の組織から参加

主要議題と決定事項:

ステータスエンドポイントの GET 専用化 ​

ステータスエンドポイントの操作に関する仕様整備が議論され、GET 専用サポートへの移行と POST 要件の廃止が決定された。Thomas Darimont が適合性テストへの反映を担当することになった。

HTTP ステータスコードの処理順序 ​

不正な形式のストリーム設定の処理順序が確立された：

  1. JSON 処理 → 不正な場合は 400
  2. 有効な JSON だが使用不可データの場合は 404

アクセストークン処理 ​

クライアント認証フロー（client credentials flow）をデフォルトサポートとすることが決定された。認可コードフロー（authorization code flow）ユーザーは、適合性テストにおいて動的なトークン取得なしでトークンを直接提示できるとされた。

新機能の候補として議論された項目 ​

  • ポイント・イン・タイム・シグナルステータス（Yair Sarig による提案、後に Issue #321 として正式起票）
  • テナントレベルのサインアウト要件

定例 WG コール（2026-02-10） ​

参加者（10 名）: Okta、Google、SailPoint、Omnissa、SGNL 等から参加

主要議題と決定事項:

CAEP 受信者テストの進捗 ​

Thomas Darimont は受信者テストの完成が 3 月以降になることを確認した。Jen Schreiber の PR が完成次第、Transmitter テストと Receiver テストの両セットを同時に完成させる計画となった。

認定プログラムのベータ立ち上げ戦略 ​

認定プログラムの立ち上げを議論するにあたり、FAPI WG・OIDC・Verifiable Credentials 認定プログラムの先行事例から教訓を得る方針が確認された。注目すべき点として、英国とブラジルにおける規制要件が FAPI 採用を推進した実績が紹介され、米国政府が RFP や CISA 文書（NIMBUS 2000）に SSF の義務付けを含める可能性についても言及された。

決定事項:

  • 3 月前に相互運用性プロファイルの未解決問題をクローズ（Atul 担当）
  • 「ベータ」フェーズの正式立ち上げを計画（初期採用者による自己認証を可能にする）

政策・標準への影響機会 ​

Aspen Institute（米国の著名シンクタンク）が発表したスキャム防止報告書が、共有シグナルや標準ベースのアプローチに言及せず「独占的イニシアチブ」のみを参照していた点が問題提起された。WG として米国立法プロセスへの影響機会として認識する必要があるとの声があがった。

アクション項目:

  • 共同議長向けのロードマップ要点を開発（Gail 担当）

定例 WG コール（2026-02-17） ​

主要議題と決定事項:

イベントメタデータ（Issue #320） ​

イベントへのオプショナルフィールド追加の可否について議論が行われた。Atul Tulshibagwale は「空白部分を埋めるのではなく、必須フィールドセットが必要」と相互運用性の懸念を強調し、追加フィールドはイベント固有であるべき（汎用的なメタデータフィールドは望ましくない）との合意に至った。デバイスコンプライアンスイベントのメタデータについては、Yair Sarig が別途提案を提出する予定となった。

ステータスイベント（Issue #321） ​

受信者が以前送信されたイベントの現在のステータスをオンデマンドでクエリできる機能について議論が行われた。CVS Health の Sean O'Dell から「セッション失効イベント後にユーザーのステータスを確認したかった」という具体的なユースケースが共有され、この機能追加を暫定的にサポートする合意が得られた。一方、Okta の Apoorva Deshpande はアイデンティティの複雑さが WG スコープの問題となる懸念をフラグとして挙げた。

アクション・レシート提案の方向性 ​

Mike Kiser（SailPoint）と Sean O'Dell（CVS Health）が Issue #322 として正式起票する「アクション・レシート」提案の概要が紹介された。送信者が要求したアクション（例: セッション失効）をレシーバーが完了したことを確認できる仕組みが現在の SSF に欠けている「盲点」として問題提起された。両者は IPSIE WG にも提案を提示する予定とされた。

CAEP インターオペラビリティプロファイル PR #315 ​

受信者要件 PR のマージが承認された。プロファイル全体の読みやすさに関する広範なレビューは後日に延期となった。

定例 WG コール（2026-02-24） ​

参加者（6 名）: SailPoint、OIDF、Omnissa、Crowdstrike、Okta から参加

主要議題と決定事項:

検証イベントトリガー方式 ​

受信者が送信者に好みの検証トリガー方法を伝える方法について議論が行われた。Apple の実装ではストリーム作成時に検証イベントが自動送信（送信者が開始）されるが、適合性テストは受信者が開始する検証要求を期待しており、両者が衝突していることが判明した。合意として、適合性テストは送信者起動・受信者起動の両アプローチを受け入れ、エラーを返さないこととする方針が確認された。

アクション・レシート設計（Issue #322） ​

Mike Kiser による提案の詳細が共有された。新しい受信者プッシュエンドポイントを設ける方式ではなく、受信者がエンドポイントを公開し、送信者が非同期的にポーリングする方式が検討されている。認証メカニズムについては仕様中での明確化が必要と認識された。

MDL / eKYC との統合 ​

eKYC のユースケースとして、金融機関が認証情報の変更通知を受け取るシナリオが検討された。認証情報が提示される理由に関するメタデータの取り扱いについて、eKYC WG との連携を深める必要性が確認された。

4. メーリングリストの主要スレッド ​

openid-specs-risc メーリングリストには 2026 年 2 月に該当するアーカイブが存在せず、同月に公開された投稿は確認できない。2026 年 2 月の WG の主要技術議論は定例コール（議事録が GitHub wiki に公開）と GitHub issue に集中していた。

5. GitHub 上の議論 ​

openid/sharedsignals#315 — Add Receiver requirements to CAEP Interop Profile ​

  • マージ日: 2026-02-17
  • 作成者: jischr、マージ者: iamseanodentity
  • 問題提起: CAEP インターオペラビリティプロファイルに受信者側の要件が欠けていた。ストリーム設定とステータス管理における受信者の具体的な義務が不明確な状態だった
  • 主要レビュアーの指摘: API 参照を一般的な表現（"provide stream configuration" 等）ではなく、SSF 仕様の具体的なセクションと API 呼び出しへの参照で置き換えるよう改善が求められた
  • 結果: tulshi、appsdesh、iamseanodentity の 3 名による承認を経てマージ

openid/sharedsignals#321 — Proposal for receiver getting point-in-time signal status ​

  • 作成日: 2026-02-04（Yair Sarig / Omnissa）
  • 問題提起: 現在の SSF フレームワークでは、受信者はシグナル状態の変更時のみ通知を受ける。デバイスコンプライアンス状態をリアルタイムで確認したい（例: ログインフローでのセキュリティチェック）というニーズに対応できていない
  • 提案内容: イベントベースの受動的メカニズムではなく、受信者がオンデマンドでステータスイベントを要求できる API の追加
  • 議論の軸: 2 月 17 日コールで「WG スコープ内か否か」が論点となり、暫定的なサポートで合意。Okta からはアイデンティティの複雑さに関する懸念が示された
  • 現状: オープン（継続審議中）

openid/sharedsignals#322 — Action Receipts in Shared Signals ​

  • 作成日: 2026-02-24（Sean O'Dell / CVS Health）
  • 問題提起: 送信者が要求したアクション（例: セッション失効）をレシーバーが実際に完了したことを確認する仕組みが SSF に存在しない。この「盲点」を埋めるための標準的な確認メカニズムが必要
  • 提案の対象スコープ: CAEP、RISC、SCIM イベントを含む
  • 設計方針の対立点: 新規の受信者プッシュエンドポイント方式 vs. 受信者がエンドポイントを公開して送信者が非同期ポーリングする方式
  • 現状: オープン（設計の詳細を継続検討中）

openid/sharedsignals#323 — Rust implementation for Shared Signals ​

  • 作成日: 2026-02-26（mjovanc）
  • 内容: ノルウェーの大手企業のバックエンドエンジニアによる Rust 言語での SSF 実装ライブラリ（sigshare）の紹介。IAM・セキュリティユースケースへの対応を目指しており、Rust コミュニティからの協力を募っている
  • 現状: オープン（コミュニティへの情報共有・サポート要請段階）

6. 関連イベント ​

  • FOSDEM 2026（2026-02-01 開催）: Thomas Darimont が「An Introduction to the OpenID Shared Signals Framework」と題した発表を行い、リアルタイムセッション失効・資格情報漏洩シグナル・Keycloak における SSF 実装を紹介した。実装者コミュニティへの SSF 普及という観点で 2 月の WG 活動の背景をなしている。発表内では Shared Signals Guide が実装者向けリソースとして紹介された。
  • RSA Conference 2026（4 月初旬予定）: 2 月 10 日コールでは、RSA Conference に向けた業界プレゼンスの強化についても言及があった。Microsoft の ITDR プラットフォームへの SSF 採用計画がその文脈で共有された。

7. 今後の予定 ​

2 月末時点（当時の視点）での予定事項：

  • 相互運用性プロファイルの未解決問題のクローズ（3 月前に完了予定、Atul 担当）
  • ベータ認定プログラムの正式立ち上げ（初期採用者による自己認証）
  • Thomas Darimont によるコンフォーマンステスト（受信者テスト）の完成（3 月中旬予定）
  • Yair Sarig によるデバイスコンプライアンスイベント・メタデータ提案の提出
  • Mike Kiser / Sean O'Dell によるアクション・レシート提案の仕様化・IPSIE WG への提示
  • 共同議長向けのロードマップ要点の整備（Gail 担当）

8. 参考情報源 ​