idbok

Appearance

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

執筆日: 2026-05-20（2024 年 9 月分の遡及レポート）

1. 概要 ​

Shared Signals Working Group（以下 SSF WG、旧称 RISC WG）は、ゼロトラスト・継続的アクセス評価のための非同期セキュリティイベント共有プロトコルを策定する OpenID Foundation のワーキンググループである。共同議長は Atul Tulshibagwale (SGNL) と Tim Cappalli (Okta)。主要成果物は openid/sharedsignals で管理されている 3 仕様 (SSF / CAEP / RISC Profile) であり、2024 年 9 月時点では 2024-08-20 に承認されたばかりの Implementer's Drafts フェーズにあった。3 仕様すべてが Final 化されるのは 2025-09 であり、本月はその 1 年前にあたる。

9 月は 「Implementer's Draft 承認直後の最初の月」 にあたり、活動の主軸は以下の 3 点に整理できる:

  • Formal security analysis の WG 承認プロセス: 8/27 に Marcus Almgren (malmgren01DF、OIDF) が Issue #198 で WG 承認手続きを開始したセキュリティ分析報告 (2024-08-26_WP4.1b-Report.pdf) について、9/10 コールでは ID2 と ID3 の差分整理を待って承認を保留、9/24 コールで 正式承認して Issue クローズという 2 段階運用が実施された。さらに 9/24 同日、この security analysis 由来の指摘 2 件 (Issue #207 audience 検証の強化、Issue #208 poll endpoint の認可必須化) が FragLegs (Shayne Miel, Cisco) によって v1Final ラベル付きで起票された
  • Risk Level Change Event 設計をめぐる長時間議論 (Issue #200): 8/30 に Apoorva Deshpande (Okta、GitHub: appsdesh) が「risk-level-change という新 CAEP イベント (LOW / MEDIUM / HIGH の 3 値)」を提案。9/10 コールで「リスクは主観的すぎる」「RISC 仕様名との混同が起きる」「列挙すべきか抽象化すべきか」の対立軸が顕在化。9/10 ML 投稿 (001647) では 「以前 @FragLegs と @atultulshi が Session Established/Presented にリスク指標を入れる方向で議論しており、これを独立イベントに引き出す方向だった」 と、本 Issue が長期にわたる議論の延長線上にあることが記録された。月末時点で「CAEP に残す / RISC へ移さない」「メタデータベースの汎用イベント方針」が暫定合意となる
  • Subject Identifier 拡張議論 (Issue #201): Apoorva が 9/10 コール直後に「Session Established / Session Presented / Risk Level Change イベントで IP アドレスを送信したい」と起票。9 月後半に 「Complex Subject Member として追加するか / 新 Simple Subject Format ips を作るか / IANA Security Events Identifiers Formats registry を経由するか」 の 3 案が GitHub と ML で並走し、opaque フォーマットの正しい構造 ({"format": "opaque", "id": ...}) についての確認コメントまで投稿された。月内には合意に至らない

openid-specs-risc ML の 9 月人手投稿は 13 件程度（GitHub bot 通知を除く）で、Atul Tulshibagwale (議長) の議事録/コール調整 4 本、Mark Haine と Tom Sato による NIST SP 800-63-4 Draft 2 関連 2 本、Elizabeth Garber / Gail Hodges による OIDF Process Document / IPR Policy 改訂提案告知 2 本、Monty Wiseman の出席通知 1 本、Atul の Final security analysis レビュー依頼 1 本が中心。残りは GitHub bot による Issue/PR/コメント通知。

GitHub 側では Issue 7 件 (#200(8/30 起票だが議論は 9 月)、#201、#203、#204、#207、#208、#210) と PR 1 件 (#209) が新規起票され、Issue #198 のみが月内クローズされた。本月の main ブランチへの新規コミット (マージ) は確認できなかった。これは Implementer's Draft 承認直後で、編集はすべて WG レベルの議論フェーズに止まり、normative な PR が WG コール上で十分に審議されるのを待つ運営方針だったためと推察される。

定例 WG コールは 隔週運用 (火曜 10am PT / 1pm ET) で 9/10 と 9/24 の 2 回が開催された。9/10 朝には Atul が 「co-chair の出席を確認できない」 として開催可否を懸念する ML 投稿を行った (001648) が、結果的に Shayne Miel の進行で開催された。9/17 は隔週運用上の休会、9/3 のコールも議事録が確認できず実質開催されていない。

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

2024 年 9 月中に Final 仕様の新規公開、Implementer's Draft 投票通知、パブリックレビュー開始通知のいずれも確認できなかった。3 仕様 (SSF / CAEP / RISC Profile) はいずれも 2024-08-20 に承認された Implementer's Drafts のままである。

月内に main ブランチへマージされた PR は確認できなかった (9 月時点では normative な PR は未起票・未マージ)。月内に新規起票された主要な仕様議論 Issue / PR を以下に挙げる:

Issue/PRタイトルauthorcreated9 月末時点
#200New event to represent risk level changesappsdesh2024-08-30open。spec:CAEP (後日付与)
#201A list of IPs as a new subject member in SSFappsdesh2024-09-10open。enhancement, spec:SSF
#203Section 2.7.1 in the CAEP Interop spec is confusingtulshi2024-09-16open。spec:Interop, v1Final
#204CAEP Assurance Level needs more options and detailtulshi2024-09-18open。spec:CAEP, vFuture
#207Receivers should validate aud value in StreamConfiguration responseFragLegs2024-09-24open。spec:SSF, v1Final
#208Poll endpoint should require authorizationFragLegs2024-09-24open。spec:SSF, v1Final
#210Requirements for the test suiteFragLegs2024-09-24open
PR #209First iteration of Event Def Specjischr2024-09-24open。Issue #158 解決を狙う

Issue #200 は厳密には 8/30 起票だが、本格的な議論は 9/10 コール以降に起こったため本月のレポート対象とする。Issue #207 / #208 / #210 / PR #209 はいずれも 9/24 コール直後に集中起票された運営イベントで、特に Issue #207 / #208 は security analysis 報告書のレコメンデーションを Issue 化したもの。v1Final ラベルが付与されており、当時の WG が「これらを v1 Final 化前に解消する」ことを暗黙的に合意していたことがわかる。

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

9 月の WG 定例コールは 隔週開催 (火曜 10am PT / 1pm ET) で 9/10 と 9/24 の 2 回が開催された。9/17 は隔週運用上の休会。9/3 については Monty Wiseman の参加辞退通知 (001644) が残るのみで議事録は確認できない。9/10 については当日朝に Atul が **「co-chair の出席を確認できない」**ため開催が危ぶまれる旨を ML に投稿 (001648) したが、結果的に Shayne Miel の進行で開催された。

3.1 2024-09-10 定例 WG コール ​

参加者は 10 名: Shayne Miel (Cisco)、Marcus Almgren (OIDF)、Thomas Darimont (OIDF)、Rajvardhan Deshmukh (Cisco)、Stan Bounev (VeriClouds)、Swathi Kollavajjala (Cisco)、Apoorva Deshpande (Okta)、Tom Sato (VeriClouds)、Sean O'Dell (Disney)、Steve Venema (Microsoft) (議事録 HackMD 2024-09-10 より)。共同議長 Atul Tulshibagwale が欠席で、Shayne Miel が事実上の議事進行を担ったコール。主要議題は (1) Formal Security Analysis 報告書の承認、(2) Risk Level Change Event (Issue #200) 設計議論、の 2 点。

主要議論:

  • Formal Security Analysis 報告書の承認 (Issue #198): Marcus Almgren が 8/27 に Issue #198 で WG 承認プロセスを開始したセキュリティ分析報告書 (2024-08-26_WP4.1b-Report.pdf) について議論。**「ID2 と ID3 の間でどの指摘が解消され、どれが残り、どれが新規に提起されたかの差分が必要」**という意見で一致し、Shayne が ID2 と ID3 の比較ドキュメントを作成して次回コールに持ち越すことを決定。9/3 18:45 UTC に Atul が ML へ送った **「ID2 のレビューと ID3 のレビューを比較すべき。次回 WG ミーティングで Shayne にサマリ提示を依頼したい」**という事前依頼 (001646) と整合する運営

  • Risk Level Change Event (Issue #200) の設計議論: Apoorva Deshpande が 8/30 に提案した「risk-level-change という新 CAEP イベント」について、ベンダ間でリスクをどう統一的に伝達するかの議論。本コールで顕在化した対立軸:

    • 主観性の壁: 「異なる企業・システムで『リスク』の定義は大きく異なり、極めて主観的」 (議事録 2024-09-10 より) との指摘
    • 命名の混乱: **Stan Bounev が「RISC 仕様との名称混乱を避けるため、より明確な命名規則が必要」**と提起
    • 列挙 vs レジストリ: 特定のリスクイベント型を作るか、メタデータ付きで汎用化するか。**「15 以上のリスクタイプが考えられる」**との発言があり、列挙の困難さが浮上
    • メタデータアプローチ: **「Rx の視点からはメタデータが文脈付与に有効」**との提案
    • Subject 種別の区別: user / device / tenant のリスクレベルを区別すべきという提案

    最終的に 「リスクイベントは RISC ではなく CAEP に残す」「個別イベント多数ではなく、メタデータ付き汎用イベントを志向する」「最終レビュー前にスキーマ/辞書を先に整備する」 の 3 点で議論を収束させた

  • アクションアイテム:

    • Shayne: Formal Security Analysis の ID2 → ID3 差分を整理 (9/24 コール用)
    • Apoorva: SSF spec に新 subject type を追加 (Issue #201 として翌週起票)
    • TBD: RISC / CAEP 間の整合性レビュー
    • Jen Schreiber & Sean O'Dell: profile への JSON Schema 適用可能性を評価

本コール直後に Apoorva は Issue #200 上で「このイベントによりリスクレベル通知を多様な subject に対し汎用化できる。reason_admin で個別の合理性を補足可能」 とコメント (001650)。Sean O'Dell (iamseanodentity) と思われる発言者は「以前 @FragLegs と @atultulshi が Session Established / Presented にリスク指標を入れる方向で議論し、独立イベントへ引き出す方向だった」「会社 A と会社 B でリスクをどう分類するかの問題が残る」 と問題提起 (001647)。

3.2 2024-09-24 定例 WG コール ​

参加者は 10 名: Shayne Miel (Cisco)、Marcus Almgren (OIDF)、Thomas Darimont (OIDF)、Yair Sarig (Omnissa)、Apoorva Deshpande (Okta)、Rajvardhan Deshmukh (Cisco)、Swathi Kollavajjala (Cisco)、Jen Schreiber (Workday)、Stan Bounev (VeriClouds)、Tushar Raibhandare (Google) (議事録 HackMD 2024-09-24 より)。議題は (1) Formal Security Analysis の正式承認、(2) Test Suite の状況確認、(3) Event Stream Permanence の論点提起、(4) NIST SP 800-63-4 Draft 2 へのフィードバック調整、の 4 点。

主要議論:

  • Formal Security Analysis の正式承認: Shayne が ID2 → ID3 差分を整理して提示し、WG として正式承認。Issue #198 は当日中に 「The WG officially approved the formal analysis in the SSF WG meeting on September 24th. Closing issue.」 とコメントの上でクローズ (001665)。承認直後に **Swathi Kollavajjala が「Tx が aud claim を作る場合、Rx はイベントが正しいストリームから来たことをどう検証するか」**と提起。Yair Sarig が「それはまさに aud claim の役割。In this case how does the Rx verify that events are from the right stream? That's the job of the aud claim.」 と応答 (議事録 2024-09-24 より)。この audience 検証議論が同日 Issue #207 (Receivers should validate aud value in StreamConfiguration response) として FragLegs (Shayne) により正式 Issue 化された

  • Test Suite の状況: Shayne が Google Docs の interoperability requirements document を提示し、Tx / Rx 両側で実装相互運用性検証に必要な要件を列挙。Issue #210 (Requirements for the test suite) が作業追跡用に起票された。これは後日 (10 月) Thomas Darimont の OpenID Conformance Test Suite (SSFTT / SSFRT) 着手の伏線となる

  • Event Stream Permanence の論点提起: **Tushar Raibhandare (Google) が「ストリームは作成されたら永続的に存在するという現仕様の暗黙の前提は妥当か。Tx 側が無期限に消えた Rx 宛にイベントを送り続けるのは expensive ではないか」**と問題提起 (議事録 2024-09-24 より)。**Yair Sarig が「Verification event 要求を cadence で行う仕組みを optional として導入し、Rx 無反応時の自動 disable までの時間を含められるようにすべき」**と応答。**Apoorva Deshpande は「verification event だけでなく任意のエンドポイント呼び出しでもよい」**と補足、**Shayne Miel は「status エンドポイント等で動かせるのが無駄な送信を避けられて良い」**と賛同。本論点は月内に Issue 化されないが、10/8 に Atul が Issue #211 (Permanence of streams) として明文化し、12 月の PR #222 (Introduce inactivity_timeout) へとつながる

  • NIST SP 800-63-4 Draft 2 フィードバック調整: NIST のフィードバック期限が 10/7、OIDF 内部の集約期限が 9/27、ワークショップ開催が 9/19-20 と確認。SSF WG として §4.8 Shared Signaling と §3.1.2.1/3.1.2.2 の fraud event 関連を重点レビュー対象とすることを再確認

  • アクションアイテム:

    • Tushar: ストリーム expiration の optional な仕組みを明文化する PR を提出 (10/8 コール後の正式 Issue 化を経て、後日 PR へ)

9/24 コール終了同日に、Shayne (FragLegs) が security analysis 報告書のレコメンデーションを基に Issue #207 (audience 検証強化)、Issue #208 (poll endpoint 認可必須化)、Issue #210 (test suite 要件) の 3 件を、Jen Schreiber (jischr) が PR #209 (First iteration of Event Def Spec) を相次いで起票した。「コールで議論された論点が同日中に GitHub に正式化される」 という運営パターンがはっきり現れた日である。

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

openid-specs-risc ML のアーカイブは週次インデックス形式で提供されている。2024 年 9 月の状況:

アーカイブ週投稿数主な内容
Week-of-Mon-2024090229/3 コール出席辞退 (Monty Wiseman)、Final security analysis 比較依頼 (Atul Tulshibagwale 9/3)
Week-of-Mon-20240909139/3 コールキャンセル告知、9/10 議事録、NIST 800-63-4 レビュー呼びかけと返信、Issue #198/#200/#201 通知
Week-of-Mon-202409162Issue #203/#204 起票通知
Week-of-Mon-202409237Issue #207/#208/#210 起票、Issue #198 クローズ、OIDF Process Document / IPR Policy 改訂提案 (Elizabeth Garber / Gail Hodges)

人手による ML 投稿は概ね 8 本程度 (出席辞退、コールキャンセル告知、議事録、NIST 関連 2 本、Process/IPR 改訂提案 2 本、Final security analysis 比較依頼 1 本)、残りはすべて GitHub bot 通知。以下に技術的・運営的に重要な 4 スレッドを取り上げる。

4.1 Final security analysis - Atul Tulshibagwale, 2024-09-03 ​

Atul が Shayne に対して送ったレビュー依頼。Atul は 「After reviewing the report, I thought it would be good to compare their review of ID2 with their review of ID3」 と書き、「どの指摘が解消されたか、どれが残っているか、新たに発見された問題は何か」を次回 WG ミーティングで提示してほしいと依頼した。これは 9/10 コールでの 「ID2 → ID3 差分の整理を待って承認を保留する」決定と、9/24 コールでの 正式承認による Issue #198 クローズに直接つながる重要な事前調整である。Implementer's Draft 承認 (8/20) から 2 週間後に 外部監査結果を WG として正式に消化する プロセスが動いていることがわかる典型例。

4.2 NIST 800-63-4 draft review - Mark Haine, 2024-09-09 / Tom Sato 返信 2024-09-09 ​

Mark Haine が NIST SP 800-63-4 Draft 2 (csrc.nist.gov/pubs/sp/800/63/4/2pd) のレビューを SSF WG に呼びかけた投稿。「OpenID Foundation は NIST Comment Template を改変した Google Sheet で会員からの input を集約し、まとめて NIST へ提出する」運営方式を提示。SSF WG にとっての重点項目として:

  • 800-63A-4 §3.1.2.1 / §3.1.2.2: 「suspected and confirmed fraud events」の伝達に関する記述
  • 800-63C-4: fraud 関連の追加記述あり (詳細特定は保留)

スケジュールは 9/19-20 ワークショップ → 9/27 OIDF 内集約締切 → 10/7 NIST 提出締切。Tom Sato (VeriClouds) は同日返信で 「§4.8 Shared Signaling は RISC profile のスコープと一致する。これは industry の interop 活動と RISC profile 採用を加速する重要な進展」 と評価。「signals can communicate important changes in state between parties that would not be otherwise known」 という SSF の本質的価値が NIST ガイドラインに取り込まれていることを高く評価した。SSF WG にとって NIST SP 800-63-4 は 「政府ガイドラインに SSF/RISC が取り込まれる初めての本格的機会」 であり、9/24 コールでもフィードバック調整が再確認されている。

4.3 Proposed revisions to OpenID Process and IPR Policy - Elizabeth Garber / Gail Hodges 返信, 2024-09-26 ​

OIDF 全体ガバナンス文書改訂提案の正式告知。理事会で 2024-09-12 に全会一致承認、21 日間レビュー期間 (9/13-10/4) と 14 日間投票期間 (10/5-10/19) を経て会員投票へかけられる旨を伝える。SSF WG 固有の話ではないが、Final 化プロセスを定める Process Document の改訂が SSF v1 Final 化に向けた基礎ルールに影響するため、本 WG への配信が行われた。主要変更点:

  • Process Document:
    • 新規定義語 4 件: "Non-Core Decision"、"Core Decision"、"Quorum Requirement"、"Substantive Change"
    • "Specifications Council" の定義と membership 要件の更新
    • "Table 1 - Work Group Decision points" による意思決定枠組みの集約
    • WG 定足数の修正: 「Active Contributors の 20% または 20 Contributors のいずれか低い方」
    • §4.4 / §4.7 / §4.10 で会員投票が 理事会 supermajority 投票に置き換え
  • IPR Policy:
    • "Table 1: Overview of IPR applicability" の新設
    • 新規定義語 "Errata corrections" / "Work Group Draft"
    • 複数 artifact 種別を扱う著作権条項の再構成
    • licensing 説明段落の追加

10 月の SSF WG にも継続的に影響し、本提案は 10/19 に Approve 106 / Object 1 / Abstain 21 (投票参加率 34%、定足数 30% 超過) で承認される (10 月レポート §4.2 参照)。

4.4 Possibly no meeting today / Meeting notes - Atul Tulshibagwale, 2024-09-10 ​

Atul の 9/10 コールに関する 2 通連続投稿。先発 (9/10 朝、15:26 UTC) は 「I've been unable to confirm whether any of the co-chairs will be available to host the meeting today.」 と co-chair の出席確認が取れず当日コール開催が危ぶまれることを共有するもの。結果的に 9/10 のコールは Atul 欠席のまま開催され、Shayne Miel が事実上の議事進行を担うこととなった (議事録 §3.1 参照)。後発 (9/10 夕) は 9/10 コールの議事録 ML 共有版。

5. GitHub 上の議論 ​

openid/sharedsignals リポジトリの 2024 年 9 月の活動:

  • Issue 新規起票: 7 件 (#200 (8/30)、#201、#203、#204、#207、#208、#210)
  • Issue クローズ: 1 件 (#198 — 9/24 コールでの WG 正式承認に伴う)
  • PR 新規起票: 1 件 (#209)
  • PR マージ: 月内マージなし
  • main ブランチへの新規 commit: 9 月内コミットは確認できなかった (Implementer's Draft 承認直後の議論集約期)

以下に技術的・運営的に重要な 4 件の議論を取り上げる。

5.1 openid/sharedsignals#200 — New event to represent risk level changes ​

  • author: appsdesh (Apoorva Deshpande, Okta)
  • 起票: 2024-08-30
  • 9 月末時点: open

Apoorva が CAEP 拡張として「risk-level-change という新 SET イベントで、user / device / tenant の subject に対する risk level (LOW / MEDIUM / HIGH) の変化を Tx → Rx で伝達」する提案。required claims は current_level、optional に previous_level / ips (観測 IP 配列)。提案理由として 「malware 検出によるデバイスリスク変化」「ログイン失敗・パスワード漏洩によるユーザリスク変化」「DDoS によるテナントリスク変化」 の 3 シナリオが本文に列挙された。**「nonprescriptive nature」**を強調し、ポスチャ変化を通知するだけで具体的な remediation は強制しない設計。

9 月の議論 (ML スレッド・コール議事録):

  • 9/10 ML (001647): 既存議論との関係について 「We discussed this previously, @FragLegs and @atultulshi by adding in a risk indicator into session presented / session established CAEP Events and we discussed pulling this out into, possibly, its own event type.」 と過去経緯を提示。「what is the risk and how does company A classify it versus company B」 という社別差異の問題が指摘される
  • 9/10 ML (001650): Apoorva が 「This event helps make risk-level communication generic for various subjects, as noted in the examples. The risk aspect is going to be subjective, but it's still very prevalent in the industry.」 と返答し、reason_admin フィールドで個別 rationale を補足できると説明
  • 9/10 コール: 「主観性 vs 業界での普及」「列挙 vs メタデータ駆動」「RISC との命名混同」の 3 軸で 1 時間近く議論

9 月末時点では「CAEP に残す」「個別イベントを多数作らずメタデータベースで汎用化する」「スキーマ/辞書を先に整備してから profile を最終化する」の 3 点が暫定合意。後に 2025-02-11 にクローズされる長期 Issue となるが、本月にコア論点が出揃ったことが記録される。

5.2 openid/sharedsignals#201 — A list of IPs as a new subject member in SSF ​

  • author: appsdesh (Apoorva Deshpande, Okta)
  • 起票: 2024-09-10 (9/10 コール直後)
  • 9 月末時点: open。enhancement, spec:SSF, v1Final (ラベルは後日付与)

Apoorva が **「Session Established (CAEP) / Session Presented / Risk Level Change (新規提案) で IP アドレスを subject に含めたい」**と起票。@FragLegs (Shayne Miel) と @iamseanodentity (Sean O'Dell) をメンションして input を依頼。9/10 コールの拡張線で、IP アドレスを SSF の subject identifier 系として第一級に扱う提案。

9 月内の ML での議論 (001656 / 001658 / 001659) では以下の 3 案が並走した:

  • 案 A (Complex Subject Member): IP アドレスを Complex Subject の ips フィールドとして直接埋め込む。Apoorva の原案
  • 案 B (新 Simple Subject Format ips): { "format": "opaque", "ips": ["1.2.3.4", ...] } 形式の新 Simple Subject を導入し、Complex Subject の user フィールド内に nest できるようにする。コメンタは **「IP を新しい format type にすると IANA Security Events Identifiers Formats registry への登録が必要となり、SSF WG のスコープを越える」**と警告
  • 案 C (opaque フォーマットの構造修正): コメンタが「Apoorva の案 B 表記は誤り。opaque フォーマットの正しい構造は {"format": "opaque", "id": ...} であり、ips フィールドではなく id フィールドを使う」と訂正。さらに **「SSF spec には既に jwt_id と saml_assertion_id という 2 つの Simple Subject Format がある。IP リスト用の 3 つ目の format を加える形がよい」**と整理

9 月末時点では合意に至らず、後日 (2026-01-07 マージの PR #313 など) で間接的に device compliance 文脈で再整理されることになる。「Simple Subject vs Complex Subject Member の設計選択」 という SSF の identifier model の根幹に触れる議論として記録される。

5.3 openid/sharedsignals#207 / #208 — Formal Security Analysis 由来の v1Final ブロッカー ​

  • author: FragLegs (Shayne Miel, Cisco)
  • 起票: 2024-09-24
  • 9 月末時点: いずれも open、spec:SSF, v1Final

9/24 コールでの formal security analysis 正式承認を受けて、Shayne が同日中に 2 件の Issue を起票:

  • #207 (Receivers should validate aud value in StreamConfiguration response): **「現仕様では Receiver は RFC 7519 に従い SET の audience を検証する義務があるが、StreamConfiguration response の audience 値を検証する要件は明文化されていない。実装者は実際にはこの値を SET 検証のために使用しているはず」**と問題提起。Tx 側で正しい aud を埋めても、Rx 側で StreamConfiguration を受け取った段階で aud を検証していなければ、Rx が誤ったストリームから SET を受け取った場合に検出できないという脆弱性パターン。9/24 コールの Swathi / Yair の議論 (§3.2 参照) を Issue 化したもの。後に PR #246 で解決される

  • #208 (Poll endpoint should require authorization): **「poll endpoint の URL が秘密である必要は現仕様で要求されていない。つまり SET は任意の party から要求できる状態にある。SET 機密性が必要なユースケースでは poll endpoint で認可を強制すべき」**と問題提起。SET の機密性に関する基礎的なセキュリティ強化要求

両 Issue は 「Implementer's Draft 承認直後に外部監査結果をフィードバックループに乗せる」プロセスの直接の成果物として記録される。v1Final ラベルが付けられ、両 Issue とも v1 Final 化前に必ず解消すべきブロッカーとして位置付けられた。

5.4 openid/sharedsignals PR #209 — First iteration of Event Def Spec ​

  • author: jischr (Jen Schreiber, Workday)
  • 起票: 2024-09-24
  • 9 月末時点: open

Jen が Issue #158 (Machine readable event schema) を解決するために起票した PR。9/24 コールでの **「最終レビュー前にスキーマ/辞書を先に整備する」**方針 (9/10 コールでの暫定合意に由来) を受けて、Jen が初期版 Event Definition Spec を提示。

9 月内の本 PR 本体への議論は限定的だが、PR 本文では **「Event 型登録の要件: 作者は OpenID Foundation contributing member であること」「Schema は publicly accessible でなければならず、document へ resolve すること」**といった registry governance ルールが提案された。本 PR は 10 月以降に Atul / Tim Cappalli らとの間で **「event の collection (例: session security) を新スキーマモデルで第一級に扱うか / interop profile に押し出すか」**の設計哲学対立 (10 月レポート §5.4 参照) を引き起こすことになる。

6. 関連イベント ​

6.1 NIST SP 800-63-4 Draft 2 Workshops (2024-09-19 / 09-20) ​

NIST が Digital Identity Guidelines 800-63-4 の Draft 2 (csrc.nist.gov/pubs/sp/800/63/4/2pd) を公開し、フィードバック収集のため 9/19-20 の 2 日間 workshop を開催。OpenID Foundation は NIST Comment Template を改変した Google Sheet を用意し、会員からの input を集約して 10/7 NIST 提出期限に間に合わせる運営を実施した。SSF WG にとっての重点項目は (a) 800-63A-4 §3.1.2.1 / §3.1.2.2 の suspected and confirmed fraud events 伝達、(b) §4.8 Shared Signaling (RISC profile のスコープと一致)、(c) 800-63C-4 の fraud 関連記述、の 3 領域。**「政府ガイドラインに SSF/RISC が取り込まれる初めての本格的機会」**として WG が組織的に対応した。OIDF 内部の集約締切は 9/27、9/24 コールでも再確認された。

6.2 OIDF Process Document / IPR Policy 改訂提案 (2024-09-12 理事会承認 / 09-13 レビュー開始) ​

OIDF 全体ガバナンス文書改訂提案が 9/12 理事会で全会一致承認され、9/13 から 21 日間の会員レビュー期間が始まった。**「Final 化プロセスを定める Process Document の改訂が SSF v1 Final 化に向けた基礎ルールに影響する」**ため、SSF WG にとっても重要なガバナンスイベント。詳細は §4.3 参照。

6.3 Implementer's Draft 公開からの月次インパクト ​

2024-08-20 に承認された SSF / CAEP / RISC Profile の 3 Implementer's Drafts は、本月 (承認後 2-6 週目) において:

  • 業界実装側からの大規模なフィードバック PR の起票はまだ起こっていない (main ブランチへのコミットが 9 月内ゼロであることがそれを示す)
  • 代わりに security analysis (外部監査) からの組織的レコメンデーション処理が中心: Issue #198 の WG 承認、#207 / #208 への分解、v1Final ラベル運用の開始
  • NIST SP 800-63-4 Draft 2 公開と重なり、政府ガイドラインへの SSF/RISC 取り込み議論が同時並行

10 月以降の Permanence of streams (Issue #211)、Verification 400 response (Issue #214)、Event Def Spec PR #209 のレビュー深化、SSF Conformance Test Suite 着手 (Issue #210) は、いずれも本月 9 月の議論を素地としている。

7. 今後の予定 (2024 年 9 月末時点の視点) ​

9 月末時点 (当時の視点) で予定されていた次月以降の動き:

  • 次回 WG コール (10/8): 隔週運用で 10/8 が次回。Issue #200 (Risk Level Change)、#201 (IP subject member)、#203 (CAEP Interop §2.7.1)、#204 (CAEP Assurance Level)、#207 (audience 検証)、#208 (poll endpoint 認可)、#210 (test suite 要件)、PR #209 (Event Def Spec) の v1Final 候補仕分けが主要議題となる見込み
  • Event Stream Permanence の Issue 化: 9/24 コールで Tushar が提起した論点を正式 Issue 化し、PR を準備するアクションが Tushar に割り当てられている
  • NIST SP 800-63-4 Draft 2 フィードバック: 9/27 OIDF 内集約締切、10/7 NIST 提出締切に向けて、SSF WG メンバーは Shared Signaling (§4.8) と fraud event (§3.1.2.1 / §3.1.2.2) を中心にコメント投稿
  • PR #209 (Event Def Spec) のレビュー深化: 9/24 起票のため、10 月の隔週コール 2 回で本格的なレビューが入る
  • OIDF Process Document / IPR Policy 投票: 10/5-10/19 が会員投票期間。可決されれば SSF v1 Final 化プロセスに影響
  • v1Final ラベル運用の本格化: 9/24 に Shayne が起票した Issue #207 / #208 から v1Final ラベルが本格運用開始。v1 Final 候補仕様を WG レベルで明示的に追跡する運営パターンが定着し始める

10 月以降には Dallas Interop (Gartner IAM Summit、12/9-11) に向けたテスト整備、v1Final 候補 Issue の集中処理、Event Def Spec の設計哲学対立の決着が大きなテーマとなる (詳細は 10 月レポート参照)。

8. 参考情報源 ​

議事録 ​

メーリングリスト ​

GitHub ​

公式・関連情報 ​