idbok

Appearance

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

執筆日: 2026-04-28（遡及執筆）

1. 概要 ​

Shared Signals WG（旧称 RISC WG）は、ゼロトラスト・継続的アクセス評価のための非同期セキュリティイベント共有プロトコルを策定する OpenID Foundation のワーキンググループである。共同議長は Atul Tulshibagwale (SGNL)、Sean O'Dell (Disney)、Shayne Miel (Cisco) の 3 名体制。主要成果物は GitHub の openid/sharedsignals で管理されている以下 3 仕様である:

  • Shared Signals Framework (SSF): Transmitter（送信者）と Receiver（受信者）間の非同期通信 API 基盤
  • Continuous Access Evaluation Profile (CAEP): ゼロトラストにおけるアクセス状態変化通知プロファイル
  • Risk Incident Sharing and Coordination (RISC) Profile: クレデンシャル詰め込み・アカウント乗っ取り対策プロファイル

2025 年 7 月の Shared Signals WG は、6 月 11 日に開始された 60 日間のパブリックレビュー期間（〜2025-08-10）の真っ只中 にあり、Final 投票直前のドラフト整備に集中した月であった。月初の SSF 1.0-04 / CAEP 1.0-04 / RISC 1.0-02 を対象としたレビュー期間中に、TakahikoKawasaki らから多数の編集上の指摘が PR として寄せられ、それらが 6 月末から 7 月 1 日にかけて連続マージされた。

7 月の活動は大きく以下の 4 つの軸に整理できる:

  1. 公開レビュー期間中の編集修正取り込み: PR #277 / #278 / #280 が 7 月 1 日にマージされ、txn 値の文字列化、編集上の細かな誤りの修正、ライセンス文言の整備が完了
  2. GitHub 上で公開されるドラフトの「未確定であること」を明示する課題: Issue #284 が 7 月 8 日に jischr (Jen Schreiber) によって起票され、リポジトリ HTML ビルドへの「WIP」表記の追加方針が議論された
  3. 複雑な Subject マッチングのエッジケース問題: Issue #282 が 7 月 1 日に Vatsal Gupta (Apple) から起票され、IP アドレス・エイリアス・ネスト構造を持つ Subject の比較セマンティクスの曖昧さが浮上。v1 には間に合わせず v2 (vFuture) で対応する 方針が 7 月 22 日コールで合意された
  4. Final 投票プロセスへの移行と日程変更: 7 月 28 日に Notice of Vote が公示。当初予定では 8 月 11 日 〜 25 日の投票期間であったが、レビュー期間中に積み上がった非規範的修正を取り込んだ draft 5 / draft 3 を 7 月 30 日に再公開 したことに伴い、投票期間が 8 月 15 日 〜 8 月 29 日に 4 日後ろ倒し された。同時期に Authenticate 2025 (10 月 13-15 日, Carlsbad) における初の Interop Event 参加募集 が ML へ流れ、月末には 8 月 14 日の Extraordinary Call の招集も Mike Leszcz から発信された

定例コールは 7 月 1 日・8 日・22 日・29 日に開催され、7 月 15 日のコールは 定足数不足のため成立しなかった （Atul Tulshibagwale 名義で「No quorum: Today's weekly call did not take place」と ML に通知）。

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

2.1 公開レビュー期間（6/11〜8/10）の対象ドラフト ​

2025-06-11 公示の Public Review Period アナウンス で 60 日間の公開レビュー対象として指定されているドラフトは以下のとおり。7 月 1 日から 7 月 28 日までは このドラフトに対するレビューが進行中 という建付けであった。

仕様公開レビュー対象ドラフト
OpenID Shared Signals Framework1.0-04
OpenID Continuous Access Evaluation Profile1.0-04
OpenID RISC Profile of CAEP1.0-02

公示当初の投票予定は 8 月 11 日 〜 25 日 であった（Public Review Period アナウンス本文 より）。7 月 1 日と 7 月 22 日のコール議事録でも、この日程が読み上げられて確認されている。

2.2 7 月 1 日の編集修正連続マージ — PR #277 / #278 / #280 ​

7 月 1 日には、TakahikoKawasaki と Atul Tulshibagwale (tulshi) の手による以下の 3 PR が立て続けにマージされ、レビュー期間中に発見された編集上の誤りが本流ブランチへ取り込まれた。

  • PR #277: Changed examples to show txn value is a string (tulshi → 7/1 マージ): Issue #273 への対応として、SSF 仕様内の txn クレーム例の値を整数表記から文字列表記へ修正。レビュー過程で FragLegs (Shayne Miel) が「CAEP 仕様にも 13 箇所同種の問題がある」と指摘したが、別 PR (#279) で対応中であることを共有して承認。最終的に iamseanodentity (Sean O'Dell) がマージ。
  • PR #278: Fixes issue #274 - editorial issues in the SSF spec under public review (TakahikoKawasaki → 7/1 マージ): SSF 仕様の編集上の問題への対応。2 コミットめでは spec_version フィールド未指定時のデフォルトを 1_0-ID1 とする後方互換性確保のための注記が追加された。FragLegs / jischr / tulshi の 3 名がレビュー、tulshi がマージ。
  • PR #280: Fixes issue #276 - editorial issues in the RISC spec under public review (TakahikoKawasaki → 7/1 マージ): RISC 仕様の編集上の修正（例示メールアドレスの一貫化、引用符表記の統一、JSON URL の整形）。tulshi 承認・FragLegs 承認後マージ。

これらは Issue #275 (CAEP)、Issue #276 (RISC) で TakahikoKawasaki が事前にまとめた編集レビュー指摘群への対応であり、Issue #275 は前月末に PR #279 (6/30 マージ) で、Issue #276 は本月の PR #280 で解消された。RFC 8417 の要件（event_timestamp は秒単位、trusted_network は boolean、txn は文字列）に仕様例を揃え直す作業が、レビュー期間中の数週間で集中的に消化された格好である。

2.3 PR #283 — Session Presented / Session Established CAEP イベントの説明改訂 ​

7 月 1 日に iamseanodentity が起票した PR #283: For Issue 281 - Clarification on Session Presented and Session Established CAEP events は、Issue #281 (2025-06-24 起票) を起点とする。Issue #281 では「Session Presented と Session Established の使い分けに関する記述を、より簡潔で明瞭にすべき」との要望が示されており、PR #283 はこれに応えて該当節 (Section 4) の表現を改訂し、Section 5 を整理する内容となっている。本 PR は 7 月内には承認に至らず、ラベル spec:CAEP 付与のまま 継続案件として 7 月末時点で open であった（最終マージは年末）。

2.4 Notice of Vote 公示 (2025-07-28) — 投票日程の 4 日後ろ倒し ​

2025-07-28 付の Notice of Vote が OIDF Board Secretary の Marie Jordan 名義で公示された。投票期間は 2025 年 8 月 15 日 (月) 〜 8 月 29 日 (金) の 14 日間 であり、6 月 11 日のレビュー開始時に告知されていた 8 月 11 日 〜 25 日から 4 日間後ろ倒しされた 形となった。

この日程変更の背景は、Public Review Period アナウンスの末尾追記にも反映されている。同アナウンスは Updated Drafts (July 30) として、レビューフィードバックを取り込んだ改訂版（SSF draft 05 / CAEP draft 05 / RISC draft 03）が 7 月 30 日に公開されたことを記しており、投票対象がこれら新ドラフトに切り替わったために投票期間も合わせてシフトされたと読める。

Atul Tulshibagwale は同 Notice を Voting notice として ML へ転送し、メンバーへ周知した。

なお、この投票対象ドラフトの番号体系（SSF / CAEP は 1_0-04 → 1_0-05、RISC は 1_0-02 → 1_0-03 への統一連番化）が、後の 8 月 5 日コールで Apoorva Deshpande から「より高いバージョン番号を維持するという決定を取り下げるのか」と問い質されることになる。7 月時点ではまだ顕在化していないが、伏線として記録しておく。

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

Shared Signals WG は通常、火曜日 1pm-2pm EDT (10am-11am PDT) に定例コールを開催している。2025 年 7 月の開催状況は以下のとおり:

日付種別状態
2025-07-01 (火)定例開催。8 名参加。バージョン番号付与方式と中間ドラフトの公開方法を議論
2025-07-08 (火)定例開催。12 名参加。Issue #284 (WIP 表記)、PR #283 (CAEP セッションイベント) 議論
2025-07-15 (火)定例定足数不足で成立せず。Atul Tulshibagwale と John Marchesini の 2 名のみ参加
2025-07-22 (火)定例開催。6 名参加。Issue #282 (複雑な Subject マッチング) を v2 行き決定
2025-07-29 (火)定例開催。6 名参加。Authenticate Interop と認定テストの進捗共有

3.1 2025-07-01 定例コール (HackMD 議事録より) ​

参加者: Atul Tulshibagwale (SGNL)、Mike Kiser (SailPoint)、Sean O'Dell (Disney)、John Marchesini (Jamf)、Vatsal Gupta (Apple)、Shayne Miel (Cisco)、Jay Baskar (Radiant Logic)、Yair Sarig (Omnissa)。

主要議論:

  • 公開レビュー期間中に起票された Issue のレビュー: レビュー開始以降に上がった Issue 群を一覧で確認。投票スケジュールは「レビュー期間終了 8 月 10 日 (日)、投票期間 8 月 11 日 (月) 〜 8 月 25 日 (月)」と読み上げで確認された（議事録 2025-07-01 より）。

  • 中間ドラフトのバージョン番号付与方式: 公開レビュー期間中に GitHub Pages 上で見える「現在進行中のドラフト」と、OIDF が公式に承認・publish した Implementer's Draft / Final ドラフトとの 混乱を防ぐ方法 が議題となった。Atul は「反復版に sub-version 番号を付与すれば実装内容を追跡できる」と提案したのに対し、Shayne は次のように懸念を表明:

    "Unless we have an automated way of adding version numbers (in whichever form), it will be a nightmare to merge."

    自動化なしに番号を手動管理する負担を避けるため、「作業中のバージョンは識別しない」という方針で Shayne と Jen Schreiber の合意が成立。Jen はこの代替案として「Working Group Draft であることをドキュメント冒頭ヘッダで明示する追加作業」を Issue 化することを引き受けた（現仕様の Final 化以降に着手）。

  • GitHub 上の HTML レンダリングの位置づけ: 「実装者ドラフトと反復版が GitHub 上で並行公開されており、混乱が生じている」との指摘が共有された。これは Issue #284 (§3.2) の伏線である。

3.2 2025-07-08 定例コール (HackMD 議事録より) ​

参加者: Atul Tulshibagwale (SGNL)、Vatsal Gupta (Apple)、Shayne Miel (Cisco)、George Fletcher (Practical Identity)、Robert Gallagher (Mastercard)、John Marchesini (Jamf)、Apoorva Deshpande (Okta)、Stan Bounev (Blue Label)、Yair Sarig (Omnissa)、Martin Gallo (Independent)、Jen Schreiber (Workday)、Sean O'Dell (Disney)。

主要議論:

  • Issue #284: GitHub 上で公開されている仕様が Final ではないことの明示: 7 月 1 日コールで持ち越された「ドラフト識別」議題を Issue として正式起票したのが、本日朝の Jen Schreiber による Issue #284: Editorial: Signify that Github hosted Specs are not final である。コール内で議論の対象となった具体的な提案は:

    • GitHub Pages 上の HTML タイトル末尾に "WIP" (Work In Progress) サフィックス を付与
    • draft 4 へ向けて作業中であれば 1.0 - draft 4 WIP、draft 4 が投票入りして次サイクルが始まったら 1.0 WIP へ切り替え
    • README の表ヘッダにも「WIP specifications」と明記し、公式ドラフトへのリンクも併記

    Issue 本文には「正式な Implementer's Draft として publish する準備が整った時点で WIP を外す」という運用方針が示されている。Apoorva Deshpande は「The HTML is useful」と発言し、HTML レンダリング自体の価値は高い ことを支持しつつ、識別用ラベルが必要との立場を表明した（議事録 2025-07-08 より）。複数の WG が中間ドラフトに sequential number を付ける方法を採っている一方で、チェックイン戦略については OIDF 横断的なガイドラインが存在しない ことを George Fletcher が指摘。

    "no OIDF recommendation" — George Fletcher (議事録 2025-07-08 より)

    WG としては「中間版 HTML をリポジトリにチェックインしない」という消極的合意に着地した。

  • PR #283 (CAEP Session Presented / Session Established 例示の改訂): Sean O'Dell が起票した PR #283 の議論。原則として「規範的な記述には IdP のような特定エンティティ概念を導入しない」「追加の説明は非規範的サブセクションへ配置する」方針で合意。George Fletcher からは、Receiver が session request を受け取る場合と、アプリケーションが新規セッションを生成する場合とでは挙動の意味合いが異なる、という設計レベルの論点提起があった。

3.3 2025-07-15 定例コール (定足数不足) ​

参加者: Atul Tulshibagwale (SGNL)、John Marchesini (Jamf) の 2 名のみ。

議題として Authenticate 2025 (Carlsbad, CA, 10/13-15) における暫定的な相互運用性テストが軽く話題に上ったものの、定足数不足のため正式な議事は行われずに散会 となった (議事録 2025-07-15: "Meeting adjourned due to lack of quorum")。

Atul Tulshibagwale は同日 17:07 UTC に No quorum: Today's weekly call did not take place を ML へ投稿し、コール不成立を WG メンバー全員に周知した。

3.4 2025-07-22 定例コール (HackMD 議事録より) ​

参加者: Atul Tulshibagwale (SGNL)、Shayne Miel (Cisco)、Robert Gallagher (Mastercard)、John Marchesini (Jamf)、Apoorva Deshpande (Okta)、Sean O'Dell (Disney)。

主要議論:

  • レビュー・投票日程の確認: レビュー期間 8 月 10 日 (日) 終了、投票期間 8 月 11 日 (月) 〜 8 月 25 日 (月) という当初日程が再度確認された。Notice of Vote 発行 (7/28) 直前の最後の日程確認 となった。

  • Authenticate 2025 Interop: 10 月 13-15 日 Carlsbad で開催される Authenticate 2025 における SSF Interop Event の準備状況が共有された。

  • Issue #282: 複雑な Subject マッチングのエッジケース: 本コール最大の論点。Vatsal Gupta が 7 月 1 日に起票した Issue #282: Provide Guidance and Examples for Edge Cases in Complex Subject Matching は、SSF 仕様 8.1.3.1 節の「2 つの subject はすべてのフィールドが undefined または identical の場合に match する」という記述に潜む曖昧さを問題化したものである。Issue 本文では以下の 2 シナリオが具体的に提示されていた:

    • ネストされた複雑な Subject: ユーザオブジェクトに role フィールドが含まれる側と含まれない側を比較するとき、match と判定すべきか
    • マルチ値フィールド (IP アドレス配列など): 異なる個数の値を含む配列同士の比較ロジックが未規定

    コール中の議論で Shayne Miel は次のような懸念を表明:

    "2 subjects match if they are identical is strong language" (議事録 2025-07-22 より)

    この「strong language」(強い断定)は、IP アドレス subject や aliases subject を実装する際に、RFC 9493 が「正確なエイリアス match」をどう定義するかについて何も規定していない という現実とぶつかる。同じく Atul の 7/22 ML 投稿: Call notes, and an important call out では、「複数 IP / 複数 aliases を持つ subject に対して subset を渡したときの取り扱いが未定義であり、実装間で矛盾するロジックを生む可能性がある」と整理されている。

    Apoorva Deshpande は「v1 では後方互換性を保証できないことを投票者に伝えるべき」と発言。v1 では正規範的な仕様変更を入れず投票を進め、明確化作業は v2 (vFuture) で実施する方針が WG として合意された。Shayne は Mike Jones との連絡担当として、v2 における実装ガイダンス提供方針を共有することを引き受けた。

    Issue #282 の GitHub 上のコメントでも、「array 値同士の比較は ANY match セマンティクス にすべきではないか」(transmitter 側 subject の aliases のいずれかが receiver 側登録 aliases と重なれば match と扱う) という具体的提案が出ているが、これは「major normative change」であり v2 へ繰越すべきとの結論で整合する。

3.5 2025-07-29 定例コール (HackMD 議事録より) ​

参加者: Atul Tulshibagwale (SGNL)、John Marchesini (Jamf)、Thomas Darimont (OpenID Foundation)、Wade Ellery (Radiant Logic)、Vatsal Gupta (Apple)、Martin Gallo (Independent)。

主要議論:

  • Authenticate 2025 Interop Event の進捗: 「Final 仕様に対する初の相互運用性テストイベント として位置付ける」「10 月の Interop Event までに認定 (certification) ステータスの取得を目指す」という方針が共有された。Atul は次のように発言:

    "Would like to work towards getting a certification status by the interoperability event in October" (議事録 2025-07-29 より)

  • 認定テストの状態: Thomas Darimont から「年初以降のテスト本体に変更はなく、仕様との手動 diff でも軽微な相違しか見つからなかった」と報告。現状のテストは Transmitter のみカバーしており、Receiver 側テストはまだ draft 段階。Thomas 自身は 8 月が休暇 + OID4VC 業務優先のため、9 月から本格的にテスト開発時間を確保する スケジュール感が共有された。

  • 実装者参加の必要性: 「テスト開発・実施には実装者からの支援が必要」との呼びかけ。これは 7 月 31 日に発信される Authenticate Interop Call for Participation (§4.3) と直接連動する。

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

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

アーカイブ週投稿数主な内容
Week-of-Mon-2025063086/30 の Issue クローズ通知群、7/1 Call notes、Issue #276 クローズ
Week-of-Mon-2025070747/8 Issue #284 起票通知、Issue #284 への WIP 提案コメント往復、7/8 Call notes
Week-of-Mon-2025071427/15 No quorum 通知、Issue #282 への ANY match 提案コメント
Week-of-Mon-2025072117/22 Call notes (important call out: Issue #282 を v1 では未対応とする方針)
Week-of-Mon-2025072847/28 Voting notice 転送、7/29 Call notes、Authenticate Interop 参加募集、8/14 Extraordinary Call の招集

7 月の ML はノイズ（GitHub bot 通知）を除けば 「定例コール議事録の共有」+「重要トピックを WG 全体へ周知するための投稿」 の組み合わせが基本構造で、議論そのものは GitHub Issue / PR とコールに集中している。

4.1 Call notes, and an important call out - Atul Tulshibagwale, 2025-07-22 開始 ​

7 月 22 日コール議事録の共有と、「important call out」として Issue #282 の扱いを WG 全体へ周知 することを目的とした投稿。Atul はメール本文で以下の論点を整理:

  • 問題の所在: SSF 仕様は「(simple) subject は exactly identical なら match する」と記述するが、(a) 複数 IP アドレスを保持する subject に対し subset を渡した場合の挙動、(b) 複数 aliases を保持する subject に対し subset を渡した場合の挙動 — これら 2 シナリオでセマンティクスが未定義
  • 判断: WG はこのレビュー期間中に投票プロセスを 60 日間延長して規範的変更を入れることはせず、投票を予定通り進める。ただし投票者には「将来的に互換性のある変更が入る可能性がある」と通知すべき
  • 理由: RFC 9493 が「正確なエイリアス match」を規定しておらず、SSF 単独で結論できる問題ではない。v2 で実装ガイダンスとともに整備する

このスレッドは投稿後に応答 0 件で完結したが、ML 上の周知とコール議事録の参照可能化が役割であり、WG 内の合意を文書として ML アーカイブに残す ことに意義があった。

4.2 Voting notice - Atul Tulshibagwale, 2025-07-28 開始 ​

OIDF 事務局からの Notice of Vote の ML 転送。本文は Marie Jordan (OIDF Board Secretary) 名義の公式アナウンスへのリンクが中心で、投票期間として 8 月 11 日 〜 8 月 25 日 が提示された (※ 後に 8/15-8/29 へ修正)。Atul は「the following post from the OpenID Foundation」と前置きし、詳細は OIDF サイトを参照するよう案内している。

4.3 Call for participation: Interoperability event at Authenticate - Atul Tulshibagwale, 2025-07-31 開始 ​

Authenticate 2025 (Carlsbad, CA, 10 月 13-15 日) における OpenID Shared Signals Foundation 仕様の最初の相互運用性テストイベント への参加募集。Atul は本文で「参加者は仕様の Final 版に対応した実装をテスト・デモンストレーションできる」と説明し、参加意思は atul at sgnl.ai への直接メールで表明するよう呼びかけた。「Looking forward to another great interoperability event!」という結びは、過去の SSF Interop Event 成功を踏まえた呼びかけである。

4.4 Invitation: OpenID Shared Signals Working Group Extraordinary Call - Mike Leszcz, 2025-08-01 招集 ​

OIDF Operations Director の Mike Leszcz から、2025 年 8 月 14 日 (木) 1pm-2pm ET の Extraordinary Call (臨時コール) の招集メール。本文には次のように目的が明記されている:

  • 目的: 公開レビュー期間中に行われた Three Shared Signals Final Specifications への更新内容について、合意決定 (consensus decision) を行う
  • 参考: Public Review Period のアナウンスページ
  • 参加: optional (任意)

これは OIDF プロセス上、「最終公開レビュー後に行われた non-normative 変更について、合意形成のための会議が必要」というルールに従った正規プロセス起動の第一歩であった (7 月時点では「8 月の最初の議事として何が必要になるか」の枠組みが固まったところまで)。

4.5 Issue #284 周辺の ML 通知群と WIP 表記論 ​

7 月 8 日に Issue #284 が起票されると、bot 通知に続いて 同 Issue 上のコメントが 2 件 ML へ流れた (001958、001959)。

  • 1 通目のコメント (TakahikoKawasaki と推測): 「version string は開発ターゲットを反映すべき。draft 4 へ向けて作業中なら 1.0 - draft 4 WIP、draft 4 が投票入りして次サイクルに移ったら 1.0 WIP」と具体的な命名規則を提案
  • 2 通目のコメント: 「+1」と支持を示し、追加で「README の表ヘッダに WIP specifications と明示」「公開済みドラフトへのリンクを README に併記」の 2 点を提案

このやり取りは Issue 本文・コール議事録 (§3.2) と整合し、「中間版 HTML はチェックインしない」「タイトルとリポジトリ表記でドラフト性を明示する」 方向の WG 内合意を形成する材料となった。

5. GitHub 上の議論 ​

openid/sharedsignals リポジトリの 2025 年 7 月の活動:

  • Issue 新規起票: 2 件 (#282, #284)
  • PR 新規起票: 2 件 (#283, #286)
  • PR マージ: 3 件 (#277, #278, #280 — いずれも 7/1)

7 月の Issue / PR はすべて 「公開レビュー期間中の指摘を投票対象ドラフトに反映する」 という枠組みの中にある。Issue は v1 で対応するか v2 へ繰越すかの判断対象として WG コールへ持ち込まれ、PR はレビュー指摘の反映と Final 投票用ドラフト作成（PR #286 — 7 月末起票・8 月 1 日マージ）に絞られた。

5.1 openid/sharedsignals#282 — Provide Guidance and Examples for Edge Cases in Complex Subject Matching ​

  • author: vatsalgupta (Vatsal Gupta, Apple)
  • 起票: 2025-07-01
  • ラベル: vFuture
  • assignee: FragLegs
  • 状態: open

7 月の最重要設計議論。SSF 仕様 8.1.3.1 節の subject matching ルール「all fields are undefined or identical で match」が、ネスト構造を持つ複雑な subject や、IP アドレス・aliases などの マルチ値フィールド に対してどう振る舞うべきかが未定義である、という問題提起。本文中で提示されたシナリオは以下:

  • シナリオ 1 (ネスト構造): ユーザオブジェクトのうち一方のみが role フィールドを持つ場合に match と判定すべきかが不明
  • シナリオ 2 (配列フィールド): IP アドレスを 3 つ持つ subject と 1 つ持つ subject の比較ロジックが規定されていない

GitHub 上のコメントでは、「event の値が receiver が登録した array のいずれかと match すれば送信すべき」という ANY match セマンティクス案 が示された一方、これは「major normative change」であるため v2 へ繰り越しが適切との同意が得られている。

Issue は 7 月 22 日コール (§3.4) で正式に議論され、v1 投票への反映は見送り、v2 (vFuture) で実装ガイダンス付きで整備する 方針が確定した。Atul の 7/22 ML 投稿（§4.1）でこの決定が WG 全体へ周知された。

5.2 openid/sharedsignals#284 — Editorial: Signify that Github hosted Specs are not final ​

  • author: jischr (Jen Schreiber, Workday)
  • 起票: 2025-07-08
  • ラベル: wg-process
  • 状態: open

GitHub Pages 上で公開されている SSF / CAEP / RISC ドラフトが「まだ公式には Implementer's Draft として publish されていない作業中ドキュメント」であることを、明示的にラベル付けすべきという提案。具体提案として「version 番号末尾に WIP サフィックスを付加し、Implementer's Draft publish 時に外す」を示している。

7 月 1 日コールでの「中間ドラフト識別問題」議論 (§3.1) を踏まえて Jen Schreiber が起票したもので、コメントには「1.0 - draft 4 WIP → 投票入り後 1.0 WIP」という具体的命名規則と、README の表ヘッダ更新・公式ドラフトへのリンク追記が提案された (§4.5)。George Fletcher が指摘するとおり「OIDF 横断的にこの種の WIP 表記ガイドラインは存在しない」(議事録 2025-07-08 より) ため、Shared Signals WG 内での運用ルールとして整備する位置付けとなっている。

5.3 openid/sharedsignals#283 — For Issue 281 - Clarification on Session Presented and Session Established CAEP events ​

  • author: iamseanodentity (Sean O'Dell, Disney)
  • 起票: 2025-07-01
  • ラベル: spec:CAEP (12 月に付与)
  • 状態: 7 月末時点で open

Issue #281 (2025-06-24 起票) — 「Session Presented と Session Established の用法を簡潔・明瞭にすべき」 — への対応 PR。CAEP 仕様 Section 4 の表現を改訂し、Section 5 を整理する内容。Sean O'Dell は説明として「Session Presented については receiver 側のユースケースより IdP 側の prescriptive example を残し、追加 bullet point は作らないことを選んだ」と PR 本文で書いている。

7 月 8 日コール (§3.2) で議論され、「規範的記述では IdP のような特定エンティティを導入しない」「追加説明は非規範的サブセクションに置く」という方針が共有された。これに基づく改訂作業は 7 月内には完了せず、継続案件として 7 月末時点で open のまま投票プロセスへ移行した。

5.4 openid/sharedsignals#286 — Prepare specs for CAEP draft 5, RISC draft 3, and SSF draft 5 ​

  • author: FragLegs (Shayne Miel, Cisco)
  • 起票: 2025 年 7 月末 (マージは 8/1)
  • 状態: 7 月時点で open (8/1 マージ)

Final 投票対象となる draft 05 / draft 05 / draft 03 を作成するための準備 PR。FragLegs は PR 本文で次のように起票理由を述べている:

"We want this round of implementer's draft to become the final v1. We have added a few non-normative changes during the review period for draft 4 (typo fixes and examples) that we would like to have included in that v1."

つまり、draft 4 のレビュー期間中に蓄積された non-normative 修正を v1 Final へ持ち込む ためのドラフト切り替え作業である。Mike Jones の助言として「投票プロセスを最初からやり直すのではなく、既存投票枠の中で draft 5 を publish できる」という precedent (前例) が引かれている。

主な変更点:

  • 自動バリデーション通過のための公開日付修正
  • ビルドシステムへの make all / make propose 便宜コマンド追加
  • ライセンス文言を OIDF 標準形式へ揃える
  • 必要なセキュリティ考慮事項節を該当仕様にコピー

レビューでは tulshi が承認した一方、appsdesh (Apoorva Deshpande) は バージョン番号を逓減させる方針 (実装者ドラフト系列の 04 から Final 投票用ドラフトを 05 へ振り直すが、当初提案では 04 → 05 ではなく低い番号への切り替えが検討されていた) について懸念を表明。最終的に iamseanodentity (Sean O'Dell) が承認・マージした。

この PR の内容そのものは 8 月 1 日付のマージだが、起票は 7 月末 で、7 月 30 日の draft 05 / 03 公開（投票期間が 8/15-8/29 へ後ろ倒しされた要因）と直接連動している。

6. 関連イベント ​

6.1 Authenticate 2025 Interop Event 参加募集 (7/31 ML 発信) ​

10 月 13-15 日 Carlsbad での Authenticate 2025 で開催予定の Shared Signals Interop Event について、Final 仕様に対する最初の相互運用性テストイベント として位置付けられた (§4.3)。7 月 29 日コール (§3.5) では「10 月までに認定ステータス取得を目指す」方針が共有され、これを実現するために Thomas Darimont の認定テスト整備（9 月から本格化予定）と実装者の参加表明収集が並行して進む構図となった。

6.2 OIDF プロセスに沿った Extraordinary Call の招集 (8/1 ML 発信) ​

OIDF プロセスは「最終公開レビュー後に行われた non-normative 変更について合意形成プロセスを要求する」という規定を持つ。7 月 30 日に draft 05 / 03 を再公開したことに伴い、これらの変更について WG 内で合意を取る必要が生じ、Mike Leszcz は 8 月 14 日 1pm ET の Extraordinary Call をカレンダー招集として ML へ送付した (§4.4)。これは 8 月の活動の重要な前提となる。

7. 今後の予定（2025 年 7 月末時点の視点） ​

  • Final 投票期間 (8/15 〜 8/29): 当初予定 8/11-8/25 から 4 日間後ろ倒し。SSF draft 05 / CAEP draft 05 / RISC draft 03 が投票対象
  • 8 月 14 日 Extraordinary Call: 公開レビュー期間後の non-normative 変更に対する合意形成
  • PR #283 (Session Presented / Established 改訂) の継続審議: CAEP 仕様の Section 4 改訂作業を 8 月以降も継続
  • Issue #282 (複雑な Subject マッチング) の v2 行き: v1 では既存仕様文言のまま投票し、明確化は v2 で実施
  • Issue #284 (WIP 表記) の運用整備: Final 化以降、Jen Schreiber が中間ドラフト識別の運用ルールを整備
  • Authenticate 2025 Interop Event (10/13-15) 準備本格化: Final 仕様準拠 Transmitter / Receiver の参加実装募集
  • SSF Conformance Test の整備: Thomas Darimont が 9 月以降に集中投入し、10 月 Interop に間に合わせる目標
  • Receiver テスト整備の遅れ: 7/29 時点で Receiver 側テストはまだ draft 段階。実装者支援が求められている

7 月時点の Shared Signals WG は、「公開レビュー期間中の編集修正を消化しつつ、v1 で対応すべき論点と v2 へ繰り越す論点を仕分け、Notice of Vote 公示へ繋ぐ」 という地道な工程管理が活動の中心であった。新規仕様作業よりプロセス遵守と実装者向けレビュー対応が比重を占めた、Final 直前らしい 1 か月であった。

8. 参考情報源 ​