idbok

Appearance

OpenID Foundation IPSIE WG 活動レポート (2024 年 12 月) ​

執筆日: 2026 年 5 月 19 日（2024 年 12 月の活動を遡及してまとめたレポートです）

1. 概要 ​

OpenID Foundation の Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) WG は、エンタープライズにおける安全な ID 連携の実現を目的として、OpenID Connect・OAuth 2.0・SCIM・SAML・Shared Signals 等の既存仕様の 相互運用性プロファイル を策定する WG である。2024 年 10 月 15 日に Okta / OpenID Foundation / Ping Identity / Microsoft / SGNL / Beyond Identity / Capital One らの参画とともに正式に発足し、共同議長は Aaron Parecki (Okta) と Dick Hardt (Hellō) が務める。

2024 年 12 月は WG 発足から 3 か月目 にあたる月で、11 月にタスクフォース構想と「greenfield 新規アプリ向けの v1」というスコープ合意 (11/26 コール) を経た後、初めて ipsie-v1-draft.md 本体への具体的な機能要件追加と、ipsie-levels.md / ipsie-terminology.md という後続の主要文書の最初の枠組み が並走的に立ち上がった月にあたる。月内の議論は次の流れで推移した:

  • 12/3 コール: 11/26 で合意した「v1 = 新規アプリ向け」を踏まえ、ipsie-v1-draft.md の Framing 節を切り出し、B2B SaaS の文脈を拡張。Policy Engine の置き場所論争を経て「単一の policy engine を規定しない、プロトコル上を流れるデータに集中する」方向で合意。Pamela Dingle が用語節の必要性を Issue #12 として起票
  • 12/10 コール: PR を細かい issue 単位に分解する方針を Jen Schreiber が引き受け。Kenn Chong が「Level 1 = MFA / Level 2 = SSO + assurance / Level 3 = session + shared signals」の 3 段階レベル構造を提案。「ユーザはアプリへ直接ログインしない（shadow IT を防ぐ）」を IPSIE の前提として確認。Aaron が NIST AAL 表形式に倣ったレベル文書の初稿を引き受け
  • 12/16 (夜): Jen Schreiber (Workday) が Issue #19〜#25 を一気に 7 本起票し、ipsie-v1-draft.md の機能セクションを discussion-defining issue として分解
  • 12/17 コール (年内最終): Aaron が ipsie-levels.md 初稿 (PR #26) を提示。Dick Hardt の提案を受けて 「単一の直線的レベル」から「Authentication (A1/A2/A3) と Provisioning (P1/P2/P3) の 2 ベクター」へ転換。Travis Tripp が organization を、Tim Cappalli が workforce をそれぞれ用語候補として提示。must use vs must make available の議論で「IPSIE は 相互運用要件 を規定し、実装方法は規定しない」という性格付けに合意。2025 年中の interop イベント開催が初めて目標として議論された
  • 12/18〜31: WG コールは年末休止。ipsie-v1-draft.md のセクション分解 issue (#19〜#25) 上で非同期討議が継続。Jon Bartlett (Zscaler) と Dean H. Saxe (Beyond Identity) を中心に、自動認証時の MFA レート制限、位置情報シグナル、signals と notifications の意味的差分などが書き込まれた

月内の主な動き:

  • 定例コール 3 回（12/3, 12/10, 12/17）。すべて毎週火曜 9:00 PT 開催で、参加者は 13〜22 名（議事録ベース）。12/17 は 年内最終回
  • openid/ipsie 親リポジトリで 新規 issue 8 件 (#12, #19, #20, #21, #22, #23, #24, #25)、新規 PR 11 件 (#10, #11, #13, #14, #15, #16, #17, #18, #26, #27, #28)、12 月内マージ 7 件 (#10, #11, #13, #15, #18, #26, #27)。commits 約 24 件（マージコミット含む）
  • 12/17 に Aaron Parecki が ipsie-levels.md の初稿 (PR #26) と ipsie-terminology.md の初稿 (PR #18 のマージ → PR #27 でのコール中ライブ編集) を起ち上げ。翌 1 月以降の用語整備とレベル定義の出発点となる
  • 12/16 23:10〜23:20 UTC に Jen Schreiber が ipsie-v1-draft.md 内の主要セクションごとに Discuss/Define 系 issue 7 本 (#19〜#25) を起票。WG 議論の単位を「PR 単位」から「issue 単位」へ細分化する転換を実行に移した
  • 12/29 までの ML 投稿は 計 9 通（コール agenda 1 通・議事録 3 通・週次 GitHub digest 4 通・11/25 起点の継続スレッド 1 通）

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

2024 年 12 月時点で IPSIE WG から Final / Implementer's Draft / Editor's Draft として公開された仕様は存在しない。WG は発足 3 か月目で、作業の中心は openid/ipsie 親リポジトリ上の ipsie-v1-draft.md（11 月起ち上げ）と、本月新規に作られた ipsie-terminology.md および ipsie-levels.md の編集にあった。

12/3 — ipsie-v1-draft.md への機能要件群の追加 ​

11/26 コールで合意した「v1 = 新規 (greenfield) アプリ向け」というスコープを踏まえ、12/3 コール当日とその直前に 4 本の PR が提出され、即日 3 本がマージされた:

  • PR #10 "Add device signals to the IPSIE v1 Draft" (dhs-BI, 12/3 マージ) — 既存のユーザ中心シグナルに加え、デバイスシグナル（device posture / integrity）を Signals 節に追加
  • PR #11 "Added step-up / re-authentication request from RP to IdP" (dhs-BI, 12/3 マージ) — RP → IdP の step-up / re-authentication 要求を新規ユースケースとして追加。コール中の議論を受け、初稿の独立ユースケース 2 本を 1 つに集約してマージ
  • PR #13 "Framing section + B2B SaaS expansion" (timcappalli, 12/3 マージ) — 冒頭節を Framing ヘッダに改名し、B2B SaaS の文脈説明を拡張
  • PR #14 "Added initial draft of protocol selection" (dhs-BI, 12/5 起票) — 各ユースケースに対し最初のプロトコル候補を割り当てる試案。12/3 コールでの「プロトコルの『勝者』を宣言せず、選択肢を列挙する」方針との整合が問われ、本月内にはマージされなかった（後に 2025-08-19 のコール議論を経てクローズ）

12/5 には George Fletcher (Capital One) が PR #15 "Update ipsie-v1-draft.md based on discussion this week" をオープンし、12/3 コール議論を反映した要件群を追加。12/10 にマージされた。

12/10 — 用語整備の起点と「audience の三分割」 ​

12/10 コールで「PR を細かい issue に分解する」「Level 1 / 2 / 3 の段階構造を導入する」が方針として固まり、その直後の同日中に Aaron Parecki が PR #18 "first attempt at terminology from dec 10 discussion" を起票（Issue #12 への対応）。Dean H. Saxe が 12/13 に Merging this as a starting point for further work. のコメントとともにマージし、これが ipsie-terminology.md というファイル自体の起点 となった。

このコールでは、ドキュメントの想定読者を以下の 3 分類に整理する案も合意された:

  • IdP developers
  • RP developers
  • Security / compliance teams（コントロールを評価する側）

12/16 (夜) — 機能セクションの issue 化 ​

Jen Schreiber (Workday) が 23:10〜23:20 UTC の 10 分間に 7 本の issue を連続起票し、ipsie-v1-draft.md の主要機能セクションを 個別の Discuss/Define issue として分解した。Create section: 系と Discuss/Define: 系が混在するのは、まだ存在しない節と既に骨格のある節の双方を扱ったため:

なお元 Activity Summary では一部の番号タイトルが「Create section: User Authentication via Workforce IdP」等として表示されているが、現行 GitHub 上での正式タイトルは上記の Discuss/Define: 表記である（数件は起票後に修正された可能性が高い）。

12/17 — ipsie-levels.md の起点と Authentication / Provisioning 2 ベクター化 ​

12/17 コール当日とその直前に Aaron Parecki が 2 本の PR を起票:

  • PR #26 "first draft of IPSIE levels" (aaronpk, 12/17 マージ) — ipsie-levels.md の初稿。Aaron 自身が I tried to create levels where each incremental level adds new capabilities that benefit the customer. I intentionally focus on capabilities without mentioning specifications yet. と PR ボディに記述。コール中の議論を受けて、提出時点の直線的レベル定義を「Authentication 軸 (A1/A2/A3) と Provisioning 軸 (P1/P2/P3) の 2 ベクター」に分解する 2 つの commit (split levels into authentication and provisioning vectors, Updated the definition of enterprise company) が同日中に追加されてからマージされた
  • PR #27 "Update ipsie-terminology.md" (aaronpk, 12/17 マージ) — コール中ライブで ipsie-terminology.md の Enterprise 定義を編集（their organizational needs への言い回し統一、the organization → the enterprise）。ttripp から「組織の代理人としてのユーザ」「組織と enterprise の関係」を整理する追加用語の提案レビューがあり、Dean が「別 PR として切り出して欲しい」と返し、本 PR は LGTM でマージ

加えて、12/17 起票・本月内未マージの:

  • PR #28 "Add more terms to IPSIE Terminology" (ttripp, 12/17 起票, 2025-01-07 マージ) — PR #27 で派生した「組織代表ユーザ」周りの用語追加。年内最終回後の起票だったため、翌年 1/7 コール後にマージされた

12/17 マージ前に Dean H. Saxe (dhs-BI) が ipsie-terminology.md への「enterprise」定義改訂 (commit ac4b0ef8、Updated the definition of enterprise company) を PR を介さずに直接 main へコミット してしまうミスを犯し、Issue #12 上に I updated the definitions and committed to main without a PR. A mistake I won't make again. と自己訂正のコメントを残している。これを受けて Aaron が PR #27 を起こし、コール中ライブ編集として後追いで形式化した経緯。

月次マージ済み一覧 ​

12 月内にマージされた PR は #10, #11, #13, #15, #18, #26, #27 の 7 本（PR #28 は 12/17 起票だが翌 1 月マージ）。本月の commit 数は 約 24 件（マージコミットを含む）。

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

IPSIE WG の定例コールは毎週火曜 9:00 PT。12 月は 12/3, 12/10, 12/17 の 3 回 開催され、12/24 と 12/31 は年末休止。議事録は Aaron Parecki が ML へ転載しており、加えて GitHub Wiki にも 2024-12-03 2024-12-10 2024-12-17 の各ページが存在する。

12/3 コール — 「v1 = 新規アプリ向け」の具体化と Policy Engine 論争 ​

12/3 付 ML 投稿 で Aaron Parecki が議事録を公開（20 名参加）。

参加者: Aaron Parecki (Okta), Dick Hardt (Hellō), Dean H. Saxe (Beyond Identity), Tom Clancy (MITRE), Sean Miller (RSA), Kenn Chong (RSA), Shannon Roddy (Self), Frederico Valente (Workday), Erik Gomez (JGSW), Jon Bartlett (Zscaler), Shawn McGuire (Riot Games), Brian Soby (AppOmni), Jen Schreiber (Workday), Pamela Dingle (Microsoft), Nagesh Gummadivalli (Workday), Tim Cappalli (Okta), Filip Skokan (Okta), Apoorva Deshpande (Okta), George Fletcher (Capital One), Bjorn Hjelm (Yubico)

主要議題と決定事項:

  • PR レビューと用語節の必要性: pending PR をレビューする中で、B2B SaaS Developer / B2B SaaS Application 等の用語が未定義であるという認識が共有された。Pamela Dingle が Issue #12 "Need Definitions &/or a Terminology Section" を起票し、it seems clear that terms will change but we do need a place where our shared understanding is captured. と動議
  • Policy Engine の置き場所論争: Policy Engine を IdP 側に置くべきか、RP 側に置くべきか、両方を許すべきかが議論に。結論は 「単一の policy engine を規定しない（no single policy engine mandate）」「プロトコル上を流れるデータに集中し、特定アーキテクチャを処方しない」 に合意。これは IPSIE の射程を「アーキテクチャ規定」ではなく「インターフェース規定」に絞る重要なフレーミングとなった
  • workforce 用語: IPSIE のスコープを「workforce アプリケーション」に絞ることが提案され、workforce の定義（従業員・契約者を含む）を用語節に加えることに
  • Signals と Authentication の分離認識: Dean が「議論が繰り返しシグナルに戻ってくる。これらは伝統的な認証要素を超えたデータ交換を表す」と整理し、Signals が Authentication とは独立した節として扱われるべきという認識が共有された

Action items: ttripp / dhs-BI らに対し「既存節の拡張 PR と新規節の PR を分けて提出」「用語節の追加」「ユースケース見出し下にプロトコル / メカニズムを列挙する」が課された。WG 内コミュニケーション用に Slack の #wg-ipsie-feeds チャンネル が用意され、GitHub 通知の受信を希望するメンバーが参加するよう案内された。

12/10 コール — Level 1/2/3 の起ち上げと「ユーザはアプリへ直接ログインしない」前提の確認 ​

12/10 付 ML 投稿 で Aaron Parecki が議事録を公開（13 名参加）。

参加者: Aaron Parecki (Okta), Sean Miller (RSA), Kenn Chong (RSA), Karl McGuinness, Dick Hardt (Hellō), Frederico Valente (Workday), Anthony Giliberti (Capital One), Jon Bartlett (Zscaler), Travis Tripp (HPE), Victor Lu, Jen Schreiber (Workday), Tom Clancy (MITRE), Filip Skokan (Okta)

主要議題と決定事項:

  • PR を issue 単位に分解する方針: 既存 PR #15 / #16 などが大きすぎてレビューが追いつかないため、機能単位の issue に分解してから PR にする 方針が合意された。Jen Schreiber が分解を引き受け、これが 12/16 夜の Issue #19〜#25 の連続起票へ直結する
  • Kenn Chong による 3 段階レベル構造の提案: コンプライアンス階層として以下の枠組みが提示された:
    • Level 1: Access to resources must be protected with MFA、クレデンシャル recovery 機能を含む
    • Level 2: SSO とアプリ横断のクレーム / アシュアランス管理
    • Level 3: セッション管理と Shared Signals の実装
  • 基礎的前提の確認: Users do not login to applications directly（ユーザはアプリへ直接ログインしない）を IPSIE の前提として確認。これにより shadow IT account の発生を構造的に防ぐ。直接サインアップを禁止し、必ず IdP 経由とする
  • 想定読者の三分割: IdP developers / RP developers / Security & compliance teams（コントロール評価側）の 3 つに整理
  • エンタープライズ駆動の要件 vs ISV 実装側の懸念: 規制コンプライアンスと仕様コンプライアンスを分離する。「シグナルや認証要素ごとに maturity が違う」ことを階層構造で表現する

Action items: Aaron が NIST AAL 表に倣ったレベル文書の初稿を起こす（→ 12/17 の PR #26 として実体化）。Jen が機能ごとに GitHub issue を生成する（→ 12/16 の Issue #19〜#25 として実体化）。次回 (12/17) に再びレビューする。

12/17 コール — ipsie-levels.md 初稿、A/P 2 ベクター化、2025 年中の interop イベント構想 ​

12/17 付 ML 投稿 で Aaron Parecki が議事録を公開（17 名参加、Notetaker: Dean H. Saxe）。年内最終回。

参加者: Aaron Parecki (Okta), Dean H. Saxe (Beyond Identity), Erik Gomez (JGSW), Travis Tripp (HPE), Tom Clancy (MITRE), Brian Soby (AppOmni), Gennady Shulman, Shannon Roddy (Self/LBNL), Matt Topper (Uber Ether), Dick Hardt (Hellō), Victor Lu, Tim Cappalli (Okta), Kenn Chong (RSA), Mike Kiser (SailPoint), Jen Schreiber (Workday), Apoorva Deshpande (Okta), George Fletcher (Capital One)

主要議題と決定事項:

  • 用語: organization vs workforce vs enterprise: Travis Tripp が「主要クラウド (AWS, Azure, GitHub, Salesforce, GCP, Oracle) は organization を採用している」と挙げ、業界用語として organization を推奨。Tim Cappalli は workforce を推す立場を維持。最終的に 「完璧な定義は不要だが、将来の文書中で曖昧にならない明確さは必要」 と合意し、「the enterprise's IdP」のように文脈で補強する書き方を採用。Travis が業界用語の調査リストを作ることに

  • ipsie-levels.md 初稿の構造転換: Aaron が PR #26 で直線的なレベル定義を提示したが、Dick Hardt が 「Authentication と Provisioning を別の vector として分けるべき」 と提案。これを受けて Aaron が同日中に split levels into authentication and provisioning vectors の commit を追加し、レベル構造を:

    • Authentication vector: A1 / A2 / A3
    • Provisioning vector: P1 / P2 / P3

    の 2 軸へ転換してマージ。session 管理と authorization は 将来的に第 3 vector になり得る が、本月時点では deferred とされた。これが 1 月以降の「A1〜A3 トラックの精緻化」「Lifecycle Management トラックの起ち上げ」に直結する

  • MFA とプロトコル要件の関係: Aaron が「Level 1 では IdP が MFA を強制するだけなので プロトコルの相互運用性は不要。Level 2 になると RP - IdP 間の MFA negotiation が必要で、ここから相互運用要件が立ち上がる」と整理。これにより「IPSIE のレベルは段階的に相互運用責務を積み上げる」性格が定式化された

  • must use vs must make available: Tom Clancy が「全要件を必須にするのか、ベンダが選択的に実装できるのか」を提起。Aaron が 「IPSIE は相互運用要件を規定するもので、実装方法を規定しない。組織にコンプライアンス充足の柔軟性を残す」 と回答。これは IPSIE 全体の規範性レベルを決める重要な性格付け

  • 2025 年中の interop イベント目標: 「レベル定義が固まることを条件として、2025 年中に IPSIE interop イベントを開催する ことを暫定目標とする」が初めて議論された。場所・時期の具体化は次回以降に持ち越し（実際には 1/21 コールで「2025 年 12 月の Gartner IAM Summit」が候補として登場する）

議事録要約（議事録 2024-12-17 より）: Aaron がドキュメントの enterprise 定義を明確化する。PR #27 はコール中ライブ編集として提出済。年末休止に入り次回は 1/7

Aaron はこの回をもって「年内最終コール」と宣言し、12/24 と 12/31 をスキップ、次回開催を 2025-01-07 に設定した（12/17 ML agenda 投稿 でも明示）。

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

openid-specs-ipsie メーリングリストは pipermail の 週次インデックス方式（親アーカイブ）で、2024 年 12 月の Week-of-Mon-20241125 末尾 / 20241202 / 20241209 / 20241216 / 20241223 の各週分に 計 12 通（11/25 週末尾の 1 通を含む）が記録されている。

本月の ML 投稿はその大半が コール agenda 1 通 + 議事録 3 通 + 週次 GitHub digest 4 通 で占められ、独立した技術討論スレッドはまだ少ない。WG 初期に共通する「議論はコールと GitHub 上で進める」運用パターンが既に確立されつつあり、これは 11/25 起点の Dean H. Saxe による「Slack vs GitHub vs email」議論の帰結でもある（後述）。

4.1 GitHub vs. email vs. slack for IPSIE WG discussions — 2024-11-25 投稿（12 月の運用に直結するため記載） ​

  • 投稿者: Dean H. Saxe (Beyond Identity)
  • 内容: 「Slack は 3 つのチャネルの中で最も discoverability が低い」「Slack で実質的な議論が起きたら ML や GitHub にサマリを残してほしい」「GitHub と email が最も widely visible」と整理。明示的なルール化ではなく gentle guidance として提案
  • 意義: 本月以降、コール議事録 / agenda は ML へ、PR / Issue 議論は GitHub へ、雑談 / 通知のみ Slack #wg-ipsie-feeds というチャネル分担が定着する直接の起点

4.2 2024-11-26 Meeting Minutes — 2024-12-01〜02 週投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 11/26 コール議事録（22 名参加）。「v1 is for new applications」を主要決定として記録。SAML 移行シナリオを charter に含めるか、developer user story を GitHub 上で具体化するか、SAML コミュニティへの周知を Dean が引き受けるか、を action item として残す
  • 返信:
    • Dean Saxe: 「次回コール (12/3) で『チャーターへの PR は誰でも提出できる』ことを参加者に再周知してほしい」
    • George Fletcher: 「enterprise user story は既に文書化されているか？」「IPSIE の主要価値提案はエンタープライズによる ID システムコンポーネントの統合だ。実エンタープライズからの pain point を収集してそれを基に作業しているか？」と問いかけ
  • 意義: 「v1 = greenfield」というスコープを ML 上で公式化した投稿。さらに George の問いかけが「ユーザストーリーを誰がオーナーシップを持って整備するか」という運用課題を浮き彫りにし、これが 12/3 コールでの PR 分割方針と 12/10 の「issue 単位への分解」に間接的につながる

4.3 2024-12-03 Meeting Minutes — 2024-12-03 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 12/3 コール議事録（20 名参加）。Policy Engine 配置論争の結着（「単一 policy engine を規定しない」）、workforce 用語の検討開始、Issue #12 の起票報告、Slack #wg-ipsie-feeds チャンネル案内
  • 意義: 「IPSIE はアーキテクチャ規定ではなくインターフェース規定」 という性格を明文化した最初の ML 投稿。以降の WG の全議論はこの前提の上に組み上がる

4.4 2024-12-10 Meeting Minutes — 2024-12-10 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 12/10 コール議事録（13 名参加）。Kenn Chong の Level 1/2/3 提案、Users do not login to applications directly の前提確認、想定読者の三分割、Jen による issue 分解の引き受け、Aaron による NIST AAL 風レベル文書の引き受け
  • 意義: 「IPSIE Levels」という概念が ML 上に初めて公式化 された投稿。本月後半のすべての議論（issue 分解、PR #26、A/P 2 ベクター化）の枝分かれ点となる

4.5 IPSIE WG Agenda 2024-12-17 — 2024-12-17 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 12/17 コール agenda 通知。年内最終回 であること、次回は 1/7 に再開することを明記
  • 意義: WG が年末年始の休止を ML 上で公式化した投稿。以降 12/29 までは週次 GitHub digest のみが流れる

4.6 2024-12-17 Meeting Minutes — 2024-12-17 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 12/17 コール議事録（17 名参加、Notetaker: Dean H. Saxe）。organization vs workforce 用語論争、ipsie-levels.md 初稿の A/P 2 ベクター化、Level 1 における MFA とプロトコル相互運用の関係、must use vs must make available の規範性整理、2025 年中の interop イベント目標
  • 意義: 本月最大の構造変化を集約した議事録投稿。「直線的 Level → 2 ベクター」 と 「IPSIE は相互運用要件を規定するもので実装を規定しない」 という 2 つの方向性を一度に公式化

4.7 週次 GitHub digest 群 — 各週末 ​

  • 投稿者: Repository Activity Summary Bot
  • 該当週: 12/8, 12/15, 12/22, 12/29 の 4 通
  • 内容: 各週の openid/ipsie リポジトリの issue / PR / comment の差分要約
  • 意義: コール議事録だけでは把握しきれない非同期作業（特に 12/16 夜の Issue #19〜#25 連続起票、12/22 週の継続コメント、12/29 週の Dean による Issue #19 コメント）を ML 加入者に通知し続けたチャネル。コール非参加メンバーへの情報供給チャネルとして機能した

5. GitHub 上の議論 ​

openid/ipsie 親リポジトリで 2024-12-01〜2024-12-31 に起票された新規 issue は 8 件（#12, #19, #20, #21, #22, #23, #24, #25）、新規 PR は 11 件（#10, #11, #13, #14, #15, #16, #17, #18, #26, #27, #28）、12 月内にマージされた PR は 7 件（#10, #11, #13, #15, #18, #26, #27）。本月の commit 数は 約 24 件（マージコミット含む）。コメント密度の高い議論を以下に詳述する。

openid/ipsie#24 — Discuss/Define: Notifications ​

  • 起票: 2024-12-16 23:19 UTC（jischr）
  • 状態: クローズ（2025-01-10 に Aaron が内容を #25 へ移管）
  • 問題提起: ipsie-v1-draft.md の Receive Notifications of Revoked Tokens および Receive Notifications of Invalidated Sessions の 2 節を独立 issue 化
  • 主要な議論:
    • dhs-BI (12/17): 「なぜ #25 を含めなかったのか？ これらが notifications で、#25 が signals と区別される理由は？」
    • jischr (12/17): 「ipsie-v1-draft.md の節分けに従って分割しただけ。意味的 / 機能的に notifications と signals は違うのか自分も気になる」
    • aaronpk (12/17): 「これら 2 つは同じ概念だと思う。be notified when sessions have been invalidated と receive real-time signals about changes in account posture or integrity の両方とも、送信側が『これが起きた』と言うだけで、受信側の挙動への期待を伴わない。これは backchannel logout のように『コマンド』として明確な期待を持つものとは対照的だ」
    • dhs-BI (12/17): 「コール (12/17) で議論し、1 つにマージする方向で進めよう」
  • 続: 1/7 コール後に timcappalli が「notifications はユーザ中心の傾向がある。signals (#25) に寄せる」と整理、1/10 に aaronpk がコメント本体を #25 へ移管してクローズ
  • 意義: 「signals は受信側に処理義務を負わせない」「backchannel logout のような command とは区別する」 という IPSIE の概念上の重要な線引きが、本月内に明文化された場面。1 月以降の Signals トラックの基礎概念となる

openid/ipsie#19 — Discuss/Define: User Authentication via Workforce IdP ​

  • 起票: 2024-12-16 23:10 UTC（jischr）
  • 状態: open（5 コメント）
  • 問題提起: 「カスタマーの workforce IdP との federated relationship を介したユーザ認証のセットアップ」を定義する
  • 主要な議論（本月内）:
    • joninusa (Jon Bartlett, Zscaler, 12/17): 「MFA timeout / retry 設定の共有を含めるべき。自動認証 (automated authentications) で MFA が要求される場合、信頼済みソースからのアカウントロックアウトを防ぐためにリトライ上限を超えないようにすべき」「Location sharing（実 client IP の伝達）を加えるべき」と 2 件追記。NIST SP 800-63B のレート制限節、Zscaler / Fortinet のレートリミット参考リンクを提示
    • dhs-BI (12/17): 「automated authentications についてもう少し説明を。どんなユースケースが該当するか」
    • joninusa (12/17): 元コメントを更新して具体化
    • dhs-BI (12/23): 「私の見解では、ユーザは認証セレモニーに関与すべき (NIST SP 800-63B、multifactor cryptographic authenticator の activation secret 概念)。ただし silent / automated 認証のユースケースを収集して、それが IPSIE の in/out of scope かを判断すべきだ」
  • 意義: 本月内に 「サイレント / 自動認証を IPSIE の射程に含めるか」 という論点が明示的に持ち込まれた issue。後の Authentication トラック (A1〜A3) の境界画定議論で参照される。Dean の 12/23 コメントは年末休止中の唯一のメイン議論

openid/ipsie#25 — Define/Discuss: Signals ​

  • 起票: 2024-12-16 23:20 UTC（jischr）
  • 状態: open
  • 問題提起: アカウントポスチャ / 整合性に関するリアルタイムシグナル、デバイスポスチャ / 整合性に関するリアルタイムシグナル（device management サービス、EDR 等から）の受信
  • 主要な議論（本月内）:
    • joninusa (12/17): 「Location 変更通知（実 client IP 含む）を追加すべき」
    • dhs-BI (12/17): 「managed device では GPS 座標を含めても良い。ネットワーク / 物理ロケーションシグナルとして一般化できる」
  • 意義: Issue #24 と統合される前提で出発した issue。location / GPS シグナルの粒度議論が早い段階で起こり、1 月以降の Signals トラック設計の素地を作った

openid/ipsie#12 — Need Definitions &/or a Terminology Section ​

  • 起票: 2024-12-03 17:13 UTC（pamelatech, Pamela Dingle / Microsoft）
  • 状態: クローズ（1/10 に aaronpk が ipsie-terminology.md の存在を理由にクローズ）
  • 問題提起: B2B SaaS Developer B2B SaaS Application 等の用語が定義されていない。it seems clear that terms will change but we do need a place where our shared understanding is captured.
  • 主要な議論:
    • dhs-BI (12/17): 「用語を更新して PR なしで main に直接コミットしてしまった。これは二度とやらない。新版は ac4b0ef8。」と自己訂正（コミット ac4b0ef8 の author も Dean H. Saxe (Beyond Identity) であり、Updated the definition of enterprise company のメッセージで enterprise 定義の明確化を加えたもの）
  • 後続: 12/17 マージの PR #18 (ipsie-terminology.md 初稿) → PR #27 (コール中ライブ編集) → PR #28 (組織代表ユーザ用語の追加) のチェーンで対応された
  • 意義: ipsie-terminology.md というファイル自体を WG リポジトリ上に存在させる契機となった issue。IPSIE WG の用語整備プロセスの正式な起点

openid/ipsie#26 — first draft of IPSIE levels ​

  • 起票: 2024-12-17 00:10 UTC（aaronpk、12/17 コール直前）
  • マージ: 2024-12-17 18:48 UTC（dhs-BI、コール直後）
  • PR ボディ: I tried to create levels where each incremental level adds new capabilities that benefit the customer. I intentionally focus on capabilities without mentioning specifications yet. 高レベルの定義については confidence が低いことを明示
  • 主要な議論:
    • ttripp (12/17): 「SSO の JIT Provisioning は (1) User のみと (2) User / Group 両方の 2 つがある。1 は典型的、2 はもう一段の maturity」 とプロビジョニング成熟度の区別を提起
    • dhs-BI (12/17): 議論を反映した修正後に LGTM で承認
    • コミット履歴: 同 PR 内には初稿 first draft of ipsie levels. needs a lot more work! (aaronpk, 00:08) の後、Dean H. Saxe が main に直接行った Updated the definition of enterprise company (dhs-BI, 00:24) と、コール議論を受けた split levels into authentication and provisioning vectors (aaronpk, 18:26、コール直後) が含まれる
  • 意義: 本月最大の構造変化。ipsie-levels.md というファイル自体を立ち上げ、「Authentication 軸 (A1/A2/A3) × Provisioning 軸 (P1/P2/P3) の 2 ベクター構造」 を WG 公式の枠組みとして固定化した PR。1 月以降の A1〜A3 トラック精緻化、2 月の Lifecycle Management 構造改革、3 月の OpenID Connect SL1 Profile への分岐すべてが、この PR が引いた線の上に展開する

openid/ipsie#14 — Added initial draft of protocol selection（未マージ） ​

  • 起票: 2024-12-05 16:45 UTC（dhs-BI）
  • 状態: 2025-08-19 に aaronpk がクローズ（コール議論の結論として）
  • 問題提起: 各ユースケースに最初のプロトコル候補を割り当てる試案
  • 主要な議論: PR ボディに Sorry, something went wrong. とのみ記載され、12/3 コールでの「プロトコルの『勝者』を宣言せず、選択肢を列挙する」方針との整合が定まらないまま放置された。8/19 のコール議論を経てクローズ
  • 意義: 「プロトコル選択を仕様化するか / 列挙に留めるか」という IPSIE の規範性レベルに関する論点を、本月内に最初に提起した PR。本月中には決着せず、後に SL1 Profile が「特定プロトコルにバインドした profile」として独立した契機の遠因となる

openid/ipsie#3 — Task Forces（既存 issue 上の本月コメント） ​

  • 既存 issue（11/13 起票）に対し、12/3 に dhs-BI が 「v1 scope を確定するまで本 issue は open のまま保留。v1 scope が我々の near term work のタスクフォース構造を導いてくれることを期待する」 とコメント
  • 意義: 11 月に Dean が提示した「5 タスクフォース構造（SSO / Application authz / User sync / Signal sharing / End-user authN）」を本月の v1 = 新規アプリ向け 議論の進行に合わせて凍結する判断。本月以降は タスクフォースを正式分割せず、issue 単位での非同期議論で進める運用 が事実上確立した

6. 関連イベント ​

2024 年 12 月は IPSIE WG がカンファレンスで前面に出る月ではなく、WG 内部の v1 ドラフト整備に集中 した月だった。openid.net 上の独立した公式アナウンスは本月には記録されていない。

ただし、11 月の Okta による How the IPSIE Working Group is Reshaping Identity Security を起点として参加企業が拡大しつつあり、12/3 コールの参加組織には Okta / Hellō / Beyond Identity / MITRE / RSA / Workday / JGSW / Zscaler / Riot Games / AppOmni / Microsoft / Yubico / Capital One / HPE / SailPoint / Uber Ether 等が並び、初回 (10 月) の主要発起 7 社（Okta / OIDF / Ping Identity / Microsoft / SGNL / Beyond Identity / Capital One）から実質的に倍増している実態が確認できる。

12/17 コールで議論された 2025 年中の interop イベント開催 という目標は、本月時点では場所・時期が未確定だが、これが翌 1 月の「2025 年 12 月 Gartner IAM Summit (Grapevine, TX) を interop ターゲット日に据える」決定の伏線となる。

7. 今後の予定 ​

2024 年 12 月末時点（年内最終回 12/17 直後）で WG が 2025 年 1 月以降に向けて確認していた予定:

  • 次回コールは 2025-01-07: 12/24, 12/31 は休止。1/7 で年明け再開
  • Issue #19〜#25 の非同期議論を継続: Discuss/Define 系 7 本 + Issue #12 をベースに、機能セクションごとの議論をコール外で深める。Aaron / Dean が分散議論を集約する役割
  • ipsie-levels.md の精緻化: 12/17 にマージされた初稿の A1/A2/A3, P1/P2/P3 を、用語整備（PR #28 で起票済）と並行して具体化する
  • ipsie-terminology.md の充実: ttripp が PR #28 として用意した「組織代表ユーザ」「組織と enterprise の関係」用語を 1/7 以降にレビュー
  • session 管理 / authorization を第 3 vector にするか: 12/17 で deferred 扱いとなった論点。1 月以降のレベル定義精緻化の中で再検討
  • enterprise 定義の精緻化: 12/17 にコール中ライブ編集 (PR #27) で着手したが「OAuth resource owner として位置付けるか」の議論は持ち越し（実際には 1/14 マージの PR #33 として実体化）
  • silent / automated 認証の in/out of scope 判断: Dean が Issue #19 の 12/23 コメントで提起。1 月以降の Authentication トラック (A1〜A3) 設計議論の中で扱う
  • 2025 年中の interop イベント開催: 12/17 で初議論。場所と時期の具体化は次回以降（1/21 コールで Gartner IAM Summit 12 月案が登場）

8. 参考情報源 ​

OpenID Foundation 公式 ​

メーリングリスト（pipermail アーカイブ、週次インデックス） ​

GitHub ​

GitHub Wiki 議事録 ​

議事録補助リソース ​

関連参考（本月外） ​