Skip to content

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

執筆日: 2026-04-20(2026年1月分の遡及執筆)

1. 概要

Shared Signals Working Group(以下 SSF WG)は、セキュリティシグナルをシステム間でリアルタイムに共有するための標準を策定するグループである。主要成果物である Shared Signals and Events Framework 1.0(SSF)、Continuous Access Evaluation Profile 1.0(CAEP)、RISC Profile 1.0 は 2025 年 9 月に Final 仕様として公開されており、2026 年 1 月は認定プログラム立ち上げに向けた集中的な準備作業が中心となった月であった。

1 月の主な動き:

  • SSF 1.0 Final Transmitter 適合性テストが demo.certification.openid.net で利用可能になり、テスト中のバグ修正も実施
  • Atul Tulshibagwale が 2026 年の最重要目標として認定プログラム第 1 版(certlaunchv1)の立ち上げを宣言し、GitHub ラベルで関連 issue を整理
  • ストリームステータスエンドポイントを認定スコープに含めるかどうかをめぐり、2 回のミーティングと複数の ML スレッドで活発な議論が展開
  • PR #313(CAEP インターオペラビリティプロファイルへのデバイスコンプライアンス変更)がマージ
  • 1 月最終週には、Phillip Hunt がストリームが無効状態のときの RFC 8936 ポーリングエンドポイントの挙動について技術的質問を提起

定例 WG コールは毎週火曜日(太平洋時間 10:00)に開催されているが、1 月 6 日分はキャンセルされており、1 月 13 日・20 日の 2 回が実施された。


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

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

ただし、適合性テストのインフラ整備という観点では重要な進展があった。1 月 5 日、OpenID Foundation の Thomas Darimont が SSF 1.0 Final Transmitter 適合性テストをデモ環境(demo.certification.openid.net)でリリースしたことを ML で告知した。テスト計画は「OpenID Shared Signals Framework 1.0 Final: Transmitter」として選択可能であり、本番環境への昇格は 3 つ以上の異なる Transmitter 実装者からの肯定的フィードバックを条件としている。テストリリース後まもなく、新メンバーの Nevzat Çırak が "Combined Acknowledge and Poll" テストケースで ACK データが送信されていないバグを発見し、Darimont が即日修正した。

CAEP インターオペラビリティプロファイルは現在も作業中であり、1 月は主に issue の起票とミーティングでの議論が中心であった。


3. ミーティングと議論

定例 WG コール(2026-01-06)

1 月 5 日付で Atul Tulshibagwale より「No call tomorrow」の告知が ML に投稿され、この週の定例コールはキャンセルされた。Mike Leszcz からも同旨のカレンダー通知が送られた。


定例 WG コール(2026-01-13)

Atul Tulshibagwale がコール後に議事メモを ML に投稿した。

主要議題: ストリームステータスエンドポイントの認定スコープ

最大の議題は「CAEP インターオペラビリティプロファイル(および認定テスト)にストリームステータスエンドポイント機能を含めるか」という論点であった。以下の 3 つの選択肢が提示された:

  1. ステータスエンドポイント機能をスコープから外す
  2. ステータス取得(読み取り)のみを含める
  3. ステータス取得と更新(読み書き)の両方を含める

参加者の意見は分かれた。ステータスエンドポイントは観測可能性とデバッグに不可欠だという意見がある一方、新規実装者にとって認定の障壁を高めるとの懸念も出た。「認定テストに含まれる機能は実装が進み、含まれない機能は採用が進まない」という実態を踏まえ、どの機能を必須要件として定めるかは戦略的な判断であるとの認識が共有された。

アクセストークン関連

Issue #308(認定チームからのアクセストークン関連の質問)の議論が行われた。Bearer トークンを認定スコープで許可するか、DPoP や mTLS などのセンダー拘束型トークンを要求するかについて意見交換がなされた。CISA 文書でのバウンドトークン推奨に言及する声もあったが、SSF 仕様がセキュリティプロトコルの詳細を過度に規定すべきかどうかという慎重論も出た。

認可コードフロー

認可コードフローについては、エンタープライズ採用において大手テクノロジー企業が使用していることを踏まえ、維持が必要との確認がなされた。


定例 WG コール(2026-01-20)

Mike Kiser(SailPoint)が議事メモを ML に投稿した。

参加者: Yair Sarig(Omnissa)、Google Workspace(Tushar Raibhandare)、SailPoint(Mike Kiser)等から参加

議題 1: デバイスメタデータのシグナルへの追加

Issue #320 の起票につながった議論として、デバイス情報をシグナルに含める方法が検討された。サブジェクト識別子(sub_id)に埋め込む案とペイロード内に含める案が比較され、デバイスのコンプライアンスシグナルに OS タイプやシリアル番号などの追加コンテキストを付与するユースケースを踏まえ、イベントペイロード内に標準的な位置とフォーマットを定義する方向でコンセンサスが形成された。Yair Sarig がこの議論の結果として Issue #320 を起票した。

議題 2: ストリームステータス更新の認定要件化

1 月 13 日の議論の続きとして、ストリームの一時停止(pause/unpause)機能との関係が焦点となった。

「verification doesn't return status」(検証イベントはステータスを返さない)

という指摘のもと、ステータスチェックを認定要件とすべきかどうかが再度議論された。Mike Kiser の議事メモによれば、必須の相互運用性要件とオプション機能を明確に区別することが合意された。

Google Workspace の Tushar Raibhandare は、翌日の ML 投稿でコールを受けての見解を整理している(後述)。

議題 3: 意思決定プロセスの加速

一部の参加者から意思決定の速度を上げたいという要望が出た。アクション項目として Mike Kiser が eKYC/ウォレット分野の Juliana Cafik の取り組みを調査することとなった。

(議事録 2026-01-20 より)


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

SSF 1.0 Final Transmitter Conformance Tests available on demo.certification.openid.net - 2026-01-05 開始

Thomas Darimont(OpenID Foundation)が SSF 1.0 Final Transmitter 適合性テストのデモ環境リリースを告知したスレッド。テスト計画の作成方法、ドキュメントへのリンク、バグ報告先(GitLab の SSF ラベル)が案内された。テストリリース後、Nevzat Çırak が "Combined Acknowledge and Poll" テストケースで ACK データが送信されないバグを発見し、Darimont が修正対応した。本番昇格の条件として「3 つ以上の異なる Transmitter 実装者からの肯定的フィードバック」が設定されている。

Certification launch prep - 2026-01-12 開始

Atul Tulshibagwale(SGNL、CTO)が 2026 年の最重要目標として SSF/CAEP Transmitter の認定プログラム(certlaunchv1)立ち上げを宣言したスレッド。GitHub に certlaunchv1 ラベルを作成し、認定第 1 版のリリース前に解決すべき issue(当時 3 件 + PR 1 件)を整理した。コミュニティに対して追加 issue へのラベル付けと翌日(1 月 13 日)のコールでの議論参加を呼びかけた。

Call notes(2026-01-13) - 2026-01-13 開始

Atul Tulshibagwale が 1 月 13 日のコール後に投稿した議事メモスレッド。ストリームステータスエンドポイントの認定スコープ(3 択の議論)、アクセストークンの最大ライフタイム指定、認可コードフローの維持という主要 3 議題について ML 上での追加意見を求めた。

Call notes(2026-01-20) - 2026-01-20 開始

Tushar Raibhandare(Google Workspace)が 1 月 20 日のコールを受けて Google の立場を表明したスレッド。ストリームステータスエンドポイントについて「読み取り + 一時停止がサポートされている場合に限り更新も含める」ことを推奨した。根拠として、ストリームが一時停止された場合の唯一の復旧手段はステータス更新エンドポイントであること、ステータス更新なしでは受信者が削除・再作成などの回避策を実装する必要が生じることを挙げた。また、認定要件への採否が実装の普及率に直結するという「実装圧力」の観点も示した。

What happens to RFC8936 polling endpoints when stream status not enabled - 2026-01-29 開始

Phillip Hunt が SSF 1.0 Final と RFC 8936 プロファイルに関する技術的疑問を提起したスレッド。ストリームが disabled または suspended のとき、ポーリングエンドポイントはどのような応答を返すべきか(イベントなし / 接続エラー / HTTP 403 / 503 / 400)を質問した。また SSF クライアントがストリーム無効時にステータスエンドポイントを参照すべきか、ステータスエンドポイント自体がサスペンド中も機能するかについても問い、SSF クライアントのリトライアルゴリズム設計における実装上の課題を背景として示した。


5. GitHub 上の議論

openid/sharedsignals#313 - Device compliance changes in the CAEP interop profile

1 月 7 日にマージされた PR。openid-caep-interoperability-profile-1_0.md にデバイスコンプライアンス変更をサポートユースケースとして追加した(issue #311 のクローズ)。appsdesh(Contributor)による変更で、2025 年 12 月から review が進んでおり、tulshi(Atul Tulshibagwale)の承認および jischr のレビューコメント対応を経て derrumbe(January 7: "Looks good to me.")の承認後にマージされた。

openid/sharedsignals#317 - How to check if a SSF Transmitter supports multiple streams per receiver

Thomas Darimont が 1 月 7 日に起票した issue。SSF 仕様ではトランスミッターが複数ストリームをサポートしない場合は HTTP 409 を返すと規定されているが、OIDF 適合性テストは 201 と 409 の両方を受け入れるよう更新されているという齟齬を指摘した。問題の本質は「CAEP インターオペラビリティ対応のトランスミッターが複数ストリームをサポートするかどうかをレシーバーが事前に判断できない」点にある(トランスミッターメタデータに当該情報がないため、ストリーム作成を試みてはじめて判明する)。CAEP インターオペラビリティプロファイルが "MAY support" という緩い表現を使っているが十分かどうか、または単一ストリームのみを必須化すべきかが問われている。

openid/sharedsignals#318 - Status endpoint requirements for CAEP interop profile

1 月 8 日に Thomas Darimont が certlaunchv1 ラベル付きで起票した issue。CAEP インターオペラビリティプロファイルにおけるステータスエンドポイントの要件を体系的に議論するための場として設けられた。1 月 13 日・20 日のコールで集中的に議論され、Google Workspace による読み取り+条件付き更新の推奨が示されるなど、認定スコープ設計の中心的 issue となった。

openid/sharedsignals#316 - How to express compound subject identifier such as that of OpenID Connect?

OpenID Connect 仕様の共同著者である Nat Sakimura が 1 月 5 日に起票した issue。SSF 仕様には複合サブジェクト識別子(OpenID Connect のような複合的な識別子構造)についての記述がないと指摘し、WG として推奨する対処方針を問うた。複数の解決策が想定されるが、仕様の方向性を明確にすることが目的である。

openid/sharedsignals#319 - Clarify status code usage for malformed stream configurations

certlaunchv1 ラベル付きで 1 月 8 日に Thomas Darimont が起票。SSF 仕様では不正なリクエストボディの解析失敗に対して HTTP 400 を返すよう定めているが、適合性テスト中に一部実装が 404 を返すケースが確認された。バリデーションチェックの順序の違いから生じる挙動の差異であり、仕様またはCAEP インターオペラビリティ仕様への明確化追記が必要かどうかを問うている。


6. 関連イベント

1 月中に SSF WG に直接関連する OpenID Summit や IIW 等の主要カンファレンスは開催されていない。


7. 今後の予定

1 月末時点での当面の優先事項:

  • certlaunchv1 issue の解消: Issue #308(アクセストークン)、#317(複数ストリーム)、#318(ステータスエンドポイント要件)、#319(ステータスコード)の決着
  • CAEP インターオペラビリティプロファイルの完成: Jen Schreiber の PR(受信者要件)の完成を目指す
  • 適合性テストの本番昇格: 3 実装者以上からの肯定的フィードバック収集後に demo から production へ移行
  • ストリームステータスエンドポイントの認定スコープ確定: 2 月のコールで最終的な方向性を決定予定

8. 参考情報源