idbok

Appearance

OpenID Foundation IPSIE WG 活動レポート (2025 年 1 月) ​

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

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 月に正式に発足し、共同議長は Aaron Parecki (Okta) と Dick Hardt (Hellō)。

2025 年 1 月は WG 発足から 4 か月目 にあたる月で、年末年始の休止期間明けに最初の定例コール (1/7) を再開し、用語定義 (ipsie-terminology.md) と IPSIE レベル定義 (ipsie-levels.md) の枠組み を集中的に詰めた月にあたる。月内の議論は次の流れで推移した:

  • 1/7 コール: Issue #5「enterprise の定義」、Issue #24/#25「signals vs notifications」を整理。Authentication トラックを 3 段階 (A1/A2/A3) で組み立てるたたき台を提示
  • 1/14 コール: 用語系 PR (#33, #34, #35) を順次承認しつつ、Lifecycle Management のレベル数を「JIT」と「グループプロビジョニング」の 2 段階に絞るかが論点に
  • 1/21 コール: PR #37 をきっかけに「レベルは technical mechanism ではなく control objective で組み直すべき」と方向転換。年末 12 月の Gartner IAM Summit を interop デモのターゲットに据える方針を初共有
  • 1/28 コール: 「IdP / RP」呼称をやめ、enterprise と app を主体とし、両者の責務を別軸とした conformance table 構造に切り替える という、本月最大の方向転換に合意

この 1 月末の方向転換が、翌 2 月に Dean H. Saxe による PR #46 (Rotate IPSIE Level tables) として ipsie-levels.md に反映され、さらに 2/25 コールで JIT 除外と SL1〜SL3 / IL1〜IL3 が確定する流れの直接の起点となる。1 月時点では正式な Editor's Draft はまだ存在せず、WG の作業は openid/ipsie 親リポジトリ上の用語定義とレベル定義の編集 に集中していた。

月内の主な動き:

  • 定例コール 4 回（1/7, 1/14, 1/21, 1/28）。すべて毎週火曜 9:00 PT 開催で、参加者は 15〜19 名（議事録ベース）
  • openid/ipsie 親リポジトリで 新規 issue 3 件 (#39, #40, #43)、新規 PR 13 件 (#29〜#44 のうち 1 月起票分)、1 月内マージ 9 件 (#16, #17, #28, #30, #31, #32, #33, #34, #41)
  • 1/22 に Aaron Parecki が ML へ「Levels, provisioning, and entitlements」スレッドを起票し、PR #41 へのフィードバックを WG メンバーに要請
  • 1/29 に Dean H. Saxe の PR #41 "User/Group lifecycle management" がマージ。Lifecycle Management のレベルを「control objective」ベースで組み直す方向の最初の仕様化
  • 1/29 に Dick Hardt が PR #44 "Updated IPSIE level chart" をオープン。app / enterprise 別軸の新テーブル雛形を提案（マージは 2/3）
  • 1/15 に Okta Security Blog で Carmen Girardin (Manager, Security Communications) による Raising the Bar for our Industry with IPSIE が公開。Todd McKinnon (Okta CEO) のコメントを引用しつつ IPSIE を業界向けに紹介する、WG 結成後の中心的な広報投稿となる

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

2025 年 1 月時点で IPSIE WG から Final / Implementer's Draft / Editor's Draft として公開された仕様は存在しない。最初の OpenID Connect SL1 Profile Editor's Draft が aaronpk/ipsie-openid-sl1 に立ち上がるのは、本月末の方向転換と 2/25 の最終合意を経た 3 月 7 日 を待つことになる。

ただし、openid/ipsie 親リポジトリ上の ipsie-terminology.md および ipsie-levels.md の編集は本月も活発で、commits は およそ 35 件 が記録されている（マージコミット含む）。主要な編集の流れは次のとおり。

1/7 — 用語整理と Authentication トラックの粗組み ​

年末年始休止明けの 1/7 コールに合わせて、用語整理の PR が一斉にマージされた:

これにより ipsie-terminology.md と ipsie-v1-draft.md の骨格が整い、続く 1/14 コールでの用語系 PR レビューの土台となった。

1/13〜1/15 — Enterprise 定義の精緻化と MFA / Phishing-Resistant の追加 ​

1/13 に Dean H. Saxe が連続して 3 本の用語 PR をオープンした:

このうち PR #33 では、Aaron Parecki が「The enterprise is the 'resource owner' in the OAuth sense of the term, which in this case would be their data in the applications」と整理し、エンタープライズを OAuth の resource owner（エンドユーザではない） として位置付ける表現に統一された。これは IPSIE のスコープを「ユーザの個人データではなく、企業が制御するアプリ上のデータ」に明示的に絞り込む決定的なフレーミングとなる。

PR #34 では NIST SP 800-63B を参照する MFA 定義が組み込まれた。PR #35 では phishing-resistant authentication の用語が追加され、timcappalli からのレビューコメントを反映した上で aaronpk と ttripp の承認を得て 2/4 にマージされた。

1/17〜1/23 — OAuth/SAML 用語と tenant 用語の整備 ​

1/21〜1/29 — Levels テーブルの「control objective ベース」への組み直し ​

1 月の最大の仕様編集トピックがこれにあたる。1/21 コール（後述 §3）で「PR #37 が technical mechanism で組まれていて、control objective で組み直すべき」という方向転換が決まり、その合意を Dean H. Saxe が一連のコミットで実体化した:

  • 1/21: Refining levels based on controls, Lifecycle management updates
  • 1/22: Separated out entitlements, Update ipsie-levels.md
  • 1/27: New introduction
  • 1/29: Remove intro verbiage, IdP -> Identity Service, RP -> App, Updated terminology - identity service, application

これらが PR #41 "User/Group lifecycle management" として 1/29 にマージされた。PR #41 は (1) レベル定義を control objective（joiner / mover / leaver）ベースで組み直す、(2) Entitlements を IdP 管理可否で整理し直す、(3) IdP / RP 呼称を Identity Service / Application に置き換える という 3 つの構造変化を一度に持ち込んだ。なお PR コメントでは 2MarkMaguire から「JIT 時にアクセスレベルが指定されない場合、アプリは least privileges possible でアカウントを作成すべき」という提案が出され、aaronpk が SHOULD 表現での採用案を返したが、本 PR でマージされたファイルには未反映で、文言化は後続 PR に持ち越された。

最後の IdP -> Identity Service, RP -> App は 1/28 コール直後のコミットで、§3 で述べる「IdP/RP 呼称の放棄」決定の直接の仕様化に該当する。

なお 1/29 に Dick Hardt がさらに別の構造提案として PR #44 "Updated IPSIE level chart" をオープン（I'm just making things up as to what is at each level と本人が認める雛形提案）。Dean が「テーブル全体をこの形式に揃え直す」とコメントし、2/3 にマージされ、これが翌 2 月の PR #46 (Rotate IPSIE Level tables) の土台となった。

クローズされた PR ​

  • PR #29 "Changed verbiage for authN properties" (dhs-BI) — 2/4 にクローズ
  • PR #36 "Update ipsie-levels.md" (aaronpk, 1/14 起票) — 1/14 コール中の編集差分。pre-provisioning を async に置き換える趣旨だったが、列ヘッダ自体が後の編集で消えたため Aaron 自身が「もはや該当しない」と 2/4 にクローズ
  • PR #37 "Update ipsie-levels.md" (2MarkMaguire) — Lifecycle Management のレベル定義の対案。1/21 コールでの「technical mechanism ではなく control objective で組み直すべき」議論を受けて、Dean の PR #41 にスーパーシードされ 2/4 にクローズ

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

IPSIE WG の定例コールは毎週火曜 9:00 PT。1 月は 1/7, 1/14, 1/21, 1/28 の 4 回 開催された。すべての議事録は Aaron Parecki が ML へ転載しており、加えて GitHub Wiki にも 2025-01-07 2025-01-14 2025-01-21 2025-01-28 の各ページが存在する。

1/7 コール — 年明け再開、Authentication トラックの粗組み ​

1/8 付 ML 投稿 で Aaron Parecki が議事録を公開（18 名参加、Okta / Beyond Identity / Ping Identity / RSA / Microsoft / Zscaler 等が参加）。

主要議題と決定事項:

  • Issue #5「Enterprise の定義」: 「the enterprise is the resource owner rather than the end user」という整理を明示。これは IPSIE を OAuth の典型シナリオ（ユーザ＝resource owner）から意図的にずらす 定義変更であり、エンタープライズ SaaS におけるデータ所有関係の現実に合わせる動きである。Dean H. Saxe が次回までに定義文の精緻化を引き受け（後の PR #33 として実体化）
  • Issue #24 と #25「Notifications vs Signals」の統合: signal を統一用語として採用し、notification ベースの Issue #24 をクローズして #25 に集約。「signals は受信側に処理義務を負わせない（received without obligation to process）」という性質を意識的に区別する
  • Authentication トラックの 3 段階のたたき台: A1 / A2 / A3 を以下のように粗組み:
    • A1 (Baseline): SSO の基本メカニズムを標準化、IdP メタデータ通信を含む
    • A2: IdP と RP の間で MFA を negotiate
    • A3: 継続的認証とセッションライフサイクル管理
  • 論点:
    • MFA を A1 で要求するか、A2 から要求するか（規制要件との整合性）
    • Logout 要件を Authentication レベルから分離するか
    • IdP と RP が異なるレベルをサポートしている場合の互換性
    • can のような permissive 表現を MUST に統一する

最後の MUST 化は同日マージの PR #31 として直ちに仕様化された。コール全体としては 「実現可能な baseline を確立する」ことと「過度に bundling せずに段階を残す」ことのトレードオフ が通底するテーマだった。

1/14 コール — 用語 PR レビューと Lifecycle 段階数の論争 ​

1/16 付 ML 投稿 で Aaron Parecki が議事録を公開（19 名参加、Okta / RSA / Microsoft / Workday / Meta / HPE / SailPoint / Zscaler 等が参加）。

主要議題と決定事項:

  • PR #34 (MFA 用語): NIST 参照を加えた表現で合意、即日マージ
  • PR #35 (phishing-resistant authentication 用語): channel bonding に関するフィードバックを反映して継続
  • PR #33 (enterprise 定義): 当初「resource owner」という表現に違和感を覚える参加者がいたが、議論の結果「governance を中央集権的に行いたい組織」という表現に統一。1 つの提案として「an organization that seeks to implement enterprise-grade governance of its users」が紹介された。Dean がレビュー後にマージ
  • Lifecycle Management のレベル数論争: 「現在の複数レベルを JIT と グループプロビジョニング の 2 つに単純化すべきか」が論点に。セキュリティ側の懸念として、(1) admin レベルアカウントの自動生成を防ぐこと、(2) JIT をアカウント生成の唯一の手段とし、ダイレクトな email サインアップを禁止すること が挙がる。これに対し「lifecycle の段階を単純化しすぎると現場の運用が表現できない」との反論もあり、結論には至らず Mark Maguire が「望ましい挙動とセキュリティ制約を記述する PR を起草する」と引き受けた（後の PR #37 として実体化）

このコールでは、Aaron 自身が編集差分を PR #36 として提出したが、後続の構造変更（列ヘッダの削除）により「もはや該当しない」と 2/4 にクローズされている。

1/21 コール — Gartner IAM 12 月 interop 構想、control objective への転換 ​

1/21 付 ML 投稿 で Aaron Parecki が議事録を公開（17 名参加、Notetaker: Dean H. Saxe）。

参加者: Aaron Parecki (Okta), Kenn Chong (RSA), Sean Miller (RSA), Mark Maguire (Aujas Cybersecurity), Dick Hardt (Hellō), Dean H. Saxe (Beyond Identity), Filip Skokan (Okta), Frederico Valente (Workday), Karl McGuinness (Self), Shannon Roddy (Self/LBNL), Jon Bartlett (Zscaler), Danny Zollner (Microsoft), Ameya Hanamsagar (Meta), Tom Clancy (MITRE), Travis Tripp (HPE), Mike Jones (Self-Issued Consulting), Pamela Dingle (Microsoft)

主要議題と決定事項:

  • Gartner IAM Summit 2025 (12/8〜10, Grapevine, TX) での interop イベント構想: 「完全な仕様の網羅ではなく、機能のサブセットのデモを行う」「IdP 2 つ + RP 2 つ以上の参加を確保する」を目標として、Aaron と Dean がデモ準備を引き受けることに。Kenn Chong は「RSA のリーダーシップに参加可否を確認する」と回答。Aaron は「実イベントへのコミット締切のタイムライン」を別途整理することに。この 「年末 12 月の Gartner IAM での interop」 という目標は、後の 2/25 コールで WG 全体のスケジュールアンカーとして公式に位置付けられる
  • PR #37 のレビューと「control objective」への転換: 「現状のレベル定義は technical mechanism（JIT、グループプロビジョニング等）で組まれており、business security outcome で組まれていない」「The levels are valid use cases rather than relatively more/less secure（レベルは『より安全 / より安全でない』ではなく『有効なユースケース』を表す）」と参加者から指摘。レベルをユーザライフサイクル管理の control objective で組み直す方針へ転換:
    • Level 1: controlled joiner process (JIT provisioning)
    • Level 2: controlled leaver capabilities (deprovisioning) を Level 1 に追加
  • アカウントライフサイクルの複雑性:
    • セッション管理、デプロビジョニング、非 web access token の取り扱い
    • セキュリティ駆動のデプロビジョニング と コスト（ライセンス）駆動のデプロビジョニング の区別
    • TTL (time-to-live) を伴う ephemeral access
    • サイドチャネル（API トークン、GitHub に保存されたローカル鍵等）の扱い
    • 「ライセンスを scope の外に置く。app 固有の事象が多すぎる。セキュリティに焦点を絞る」（議事録 2025-01-21 より引用要約）

議事録要約（議事録 2025-01-21 より）: Dean が「レベル表を control objective 基準で構成し直し、PR #41 として提出する」「セッションライフサイクル管理の用語を control 表に追加する」を action item として引き受ける。Dean / Aaron は「デプロビジョニング機能の interop 要件」を明確化する

このコール直後の Dean のコミット連鎖（1/21〜1/29）が PR #41 として実を結ぶ。

1/22 ML スレッド — Levels, provisioning, and entitlements ​

1/22 に Aaron Parecki が Levels, provisioning, and entitlements を ML へ投稿。前日のコール議論を踏まえ、PR #41 へのフィードバックを WG メンバーに要請する内容で、「次回コール前にもっと多くの目を通したい。GitHub スレッドに参加するか、ML に直接返信してほしい」と呼びかけた。これは、コール参加者以外の WG メンバー（毎週火曜 PT 朝に出席できない参加者）に対し、非同期で PR レビューに参加するルートを意図的に確保する動きだった。

1/28 コール — IdP/RP 呼称の放棄、enterprise × app の責務別軸へ ​

1/30 付 ML 投稿 で Aaron Parecki が議事録を公開（15 名参加、Beyond Identity / Okta / Ping Identity / RSA / Hellō / Meta / Duende Software / Workday / Microsoft / Zscaler / HPE 等）。本月の方向性決定の頂点となった回。

主要議題と決定事項:

  • スコープの明確化: Aaron が「IPSIE は discrete なソフトウェアコンポーネント ではなく、アプリの properties とそれが何をサポートするか に焦点を当てる」と整理。プロトコル固有の実装ではなく、ロールとその interaction を定義する方向に視座を移す

  • 「IdP」呼称の放棄: エンタープライズが「IdP」と呼ばれる単一のソフトウェアではなく、認証・プロビジョニング・エンタイトルメントに対し 異なるツールの組み合わせ を使っているという現実認識が共有された。Shannon Roddy の発言が転換点として議事録に明記:

    "My IdP does JIT. I can also provide group info (entitlements). But I won't preprovision." — Shannon Roddy（議事録 2025-01-28 より）

    これを受けて、IdP / RP を enterprise / app（より厳密には Identity Service / Application）と呼び替える方向が合意された。IdP -> Identity Service, RP -> App の差分は Dean が同日中にコミットし、PR #41 マージ前に取り込まれた

  • Conformance vs. Maturity の整理: 「IPSIE のレベルは maturity progression（成熟度の段階）なのか、それとも interoperability conformance requirement（相互運用性適合要件）なのか」が議論に。Dean H. Saxe が「app と enterprise service の各々が、各レベルでサポートすべきものを別々に書く べき」と提案し、これが本月後半の方向性を決定づけた

主要次ステップ:

  • 「IdP/RP」中心の表現を enterprise / app の中立的な語彙に書き換える
  • レベル表を 両主体の義務を別個に示す 構造に再構成
  • 一方的に RP 中心だった表現を排除し、相互の要件として記述する
  • レベル表の大規模再構成に着手する前に、まず用語の置き換えを完了させる

議事録要約（議事録 2025-01-28 より）: 用語の方向転換が先、テーブル構造の rotate（responsibility 軸の分離）が次。後者は 2 月初の PR #46 として実体化する

この決定は本月内に Dean のコミットで部分的に仕様化され、続く 2 月の PR #46 (Rotate IPSIE Level tables) と PR #53 (Updated Identity Lifecycle levels) によって完全に取り込まれることになる。

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

openid-specs-ipsie メーリングリストは pipermail の 週次インデックス方式（親アーカイブ）で、2025 年 1 月の Week-of-Mon-20250106 / 20250113 / 20250120 / 20250127 の 4 週分に 計 7 通 が投稿された。本月の ML 投稿は コール agenda 通知・コール議事録・PR レビュー要請 が主体で、独立した技術討論スレッドはまだ形成されていない。WG 初期に共通する「議論はコールと GitHub 上で進める」運用パターンが既に確立されつつあった。

4.1 IPSIE WG Agenda 2025-01-07 — 2025-01-07 03:40 UTC 投稿 ​

  • 投稿者: Aaron Parecki (Okta)
  • 内容: 年明け最初のコール (1/7) の agenda 通知。GitHub Wiki に agenda と Zoom リンクが掲載されている旨を案内し、参加には IPR contribution agreement の提出が必要であることを念押し
  • 意義: 年末年始休止明けの WG 再開を ML 上で告知した投稿。1/14, 1/21, 1/28 の各コール agenda も Aaron から個別に Zoom リンクとともに発信される運用が定着していく

4.2 2025-01-07 IPSIE Meeting Minutes — 2025-01-08 16:24 UTC 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 1/7 コール議事録（18 名参加）。Issue #5 (enterprise 定義)、Issue #24/#25 (signals 統合)、Authentication トラック A1〜A3 の粗組み
  • 意義: WG として 「enterprise = resource owner」「signals は処理義務を伴わない」 という 2 つの基礎概念を ML 上で公式化した投稿

4.3 IPSIE WG Agenda 2025-01-14 — 2025-01-13 22:31 UTC 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 1/14 コール agenda 通知。GitHub Wiki への誘導と IPR 確認のリマインダ
  • 意義: 定常的な agenda 通知運用が 1 月時点で既に確立していることを示す

4.4 IPSIE Meeting Minutes 2025-01-14 — 2025-01-16 00:35 UTC 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 1/14 コール議事録（19 名参加）。PR #34 (MFA)、PR #35 (phishing-resistant)、PR #33 (enterprise) のレビュー結果、Lifecycle Management のレベル数を 2 段階に絞るかの論争
  • 意義: WG 内で「JIT 中心 vs グループプロビジョニング中心」の段階構造の論争が初めて議事録化された投稿。本月後半の control objective ベースへの転換の伏線

4.5 IPSIE Meeting Minutes 2025-01-21 — 2025-01-21 23:59 UTC 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 1/21 コール議事録（17 名参加、Notetaker: Dean H. Saxe）。Gartner IAM 12 月の interop 構想初提示、PR #37 を「control objective ベース」で組み直す方針への転換、Account Lifecycle の複雑性（セキュリティ vs ライセンス、TTL、サイドチャネル）の整理
  • 意義: 本月で最も内容が厚い議事録投稿。「12 月 Gartner IAM」が WG のスケジュールアンカーとして登場した最初の記録 であり、PR #41 起草の直接の動機を ML 上で公式化した投稿

4.6 Levels, provisioning, and entitlements — 2025-01-22 16:23 UTC 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 1/21 コール議事録を受けて起草中の PR #41 へのフィードバックを WG メンバーに要請。「次回コール前にもっと多くの目を通したい。GitHub スレッドに参加するか、ML に直接返信してほしい。方向性に賛成という表明だけでも歓迎」
  • 意義: 本月内で唯一の独立トピックスレッド。コール非参加メンバーを非同期で PR レビューに巻き込むための明示的な投稿で、WG が議論を多チャネル化する意図的な動きが見える。ただし ML 上での直接の返信は記録されておらず、議論は GitHub PR スレッドへ集約された

4.7 2025-01-28 IPSIE WG Meeting Minutes — 2025-01-30 16:24 UTC 投稿 ​

  • 投稿者: Aaron Parecki
  • 内容: 1/28 コール議事録（15 名参加）。スコープの明確化、IdP 呼称の放棄、Shannon Roddy の My IdP does JIT. I can also provide group info. But I won't preprovision. 発言、conformance vs maturity の整理、app / enterprise を主体とする責務別軸のテーブル構造への移行合意
  • 意義: 本月最大の方向転換を集約した議事録投稿。翌 2 月の PR #46 (Rotate IPSIE Level tables) の起点 となり、その後の WG の用語空間 (Identity Service / Application、SL / IL / En の 3 ディメンション) を支える決定を ML 上で公式化した

5. GitHub 上の議論 ​

openid/ipsie 親リポジトリで 2025-01-01〜2025-01-31 に起票された新規 issue は 3 件（#39, #40, #43）、新規 PR は 13 件（#29〜#44 のうち 1 月起票分、#29 / #30 / #31 / #32 / #33 / #34 / #35 / #36 / #37 / #38 / #41 / #42 / #44）、1 月内にマージされた PR は 9 件（#16, #17, #28, #30, #31, #32, #33, #34, #41）。本月の commit 数は およそ 35 件（マージコミット含む）。コメント密度の高い議論を以下に詳述する。

openid/ipsie#41 — User/Group lifecycle management ​

  • 起票: 2025-01-21（dhs-BI、1/21 コール直後に Action Item として起票）
  • マージ: 2025-01-29（aaronpk）
  • 問題提起: PR #37 への対案として、Lifecycle Management のレベル定義を technical mechanism（JIT、グループプロビジョニング等）ではなく、control objective（joiner / mover / leaver の制御） で組み直す
  • 主要な変更と議論:
    • Entitlements の再整理: 2MarkMaguire から「IdP がエンタイトルメント管理を一切できないアプリは IPSIE 適合と認めるべきではない」「E1 を排除し E2/E3 のみ残すべき」との指摘。aaronpk からは「entitlements/authorization を完全にスコープ外にする方向に傾いていた」との懸念表明があり、dhs-BI は「必要なら entitlements 部分は外す」と応答
    • JIT 時の least-privilege 提案: PR コメントで 2MarkMaguire が「If an access level is not specified when the account is created by the JIT process, the application must create the account with the least privileges possible」と提案し、aaronpk は MUST ではなく SHOULD 表現での採用案を返したが、本 PR でマージされたファイルには未反映で文言化は後続に持ち越された
    • IdP → Identity Service, RP → Application への呼称変更: 1/28 コール直後の Dean のコミットで同 PR 内に取り込まれた
  • 参加者: dhs-BI (author), aaronpk (merger), 2MarkMaguire (reviewer), deansaxe (contributor)
  • 意義: 本月最大の構造変化。Lifecycle Management のレベル設計を「技術メカニズム → 制御目的」へ転換し、同時に IPSIE の主体呼称を「IdP/RP → enterprise/app」に切り替えるという、2 つの本質的な決定を 1 つの PR にまとめて取り込んだ。2 月以降の ipsie-levels.md の構造は全てこの PR が引いた線の上に展開する

openid/ipsie#37 — Update ipsie-levels.md（クローズ） ​

  • 起票: 2025-01 中（2MarkMaguire、1/14 コールでの「PR を起草する」action を受けて）
  • クローズ: 2025-02-04（superseded by #41）
  • 議論:
    • dhs-BI のフィードバック: 「P3 をグループプロビジョニングからメタデータプロビジョニングに変えたのは意図が分からない。これらは等価な概念ではない」
    • aaronpk のガイダンス: 「レベル定義はプロトコル固有の言及を避けて書くべき。プロトコルの選択は仕様化の後段階で行う」
    • dhs-BI のスコープ問題提起: 「特定の要件が JIT プロビジョニングに属するのか、それとも別カテゴリか不明」「permission ルールは本質的に business rule であり、IPSIE が成文化すべきでない」
  • 状態: 1/29 に dhs-BI から「PR #41 がマージされた。この PR から取り込むべき要素はあるか」とコメント。2MarkMaguire は 2/4 に Levels updated by Dean's PR, closing this one. でクローズ
  • 意義: 本月の「control objective vs technical mechanism」論争の片側の主張を明示した PR。PR #41 にスーパーシードされたが、PR #37 で示された「permission ルールを成文化しない」「JIT を業務ルールから切り離す」といった整理は、後の WG での Entitlements トラックの境界設定議論に影響する

openid/ipsie#44 — Updated IPSIE level chart ​

  • 起票: 2025-01-29（dickhardt）
  • マージ: 2025-02-03（dhs-BI）
  • 問題提起: app / enterprise の責務を別軸とする新テーブル雛形をドキュメント冒頭に挿入。Dick 自身が I'm just making things up as to what is at each level（各レベルの中身は仮置き）と認める雛形
  • 議論:
    • dhs-BI (1/29): 「次回コール前にこの構造で他のテーブルも揃え直す」と即時に方針受け止め
    • dhs-BI (review, 1/29): 「要件は仮置きだが、まずマージしてから既存テーブルからの中身をこの形式で埋め直す」とアプローチを整理
    • dickhardt (1/29): 「reformat 対象のテーブルはこれ 1 つ」と確認
    • dhs-BI (final review, 2/3): aaronpk と同期した上で「マージして残りのテーブルを後続 PR で揃える」
  • 意義: 1/28 コールで合意した「app と enterprise の責務を別軸とする」構造を、Dick 自ら最初の 雛形 として提示した PR。仕様の中身ではなく 構造の合意形成 を狙った戦略的な動きで、翌 2 月の PR #46 (Rotate IPSIE Level tables) に直結する

openid/ipsie#33 — Tweaking the definition of 'enterprise' further ​

  • 起票: 2025-01-13（dhs-BI）
  • マージ: 2025-01-14（aaronpk）
  • 問題提起: enterprise 用語の輪郭を、IPSIE charter の範囲内でより明確に定義する
  • 議論:
    • aaronpk: 「The enterprise is the 'resource owner' in the OAuth sense of the term, which in this case would be their data in the applications」と OAuth 用語へ接続する整理を提示
    • ttripp: 用語ドキュメントに対するコメント提案
  • 意義: 「エンタープライズはユーザではなくアプリ上のデータの所有者である」という、IPSIE の射程を OAuth の consumer フロー（ユーザ＝resource owner）から意図的にずらす フレーミング上の決定打 となった PR

openid/ipsie#39 — Consider 'inactivity' in Identity Management requirements / levels ​

  • 起票: 2025-01-18（ameyah, Ameya Hanamsagar / Meta）
  • 問題提起: 「現状、一部のアプリは独自 API やネイティブ portal を通じて inactivity monitoring を提供するが、プラットフォーム横断の一貫性がない。アプリが アカウント × エンタイトルメントの組み合わせごとの last use タイムスタンプ を identity service に通知することで、組織は実際の利用パターンに基づいてアクセスをガバナンスできる」
  • 状態: 1 月内コメントなし、open のまま
  • 意義: Identity Lifecycle のレベル定義に inactivity ベースのガバナンス を組み込めるかという視点を WG に提起した issue。1 月時点では deferred 扱いだが、後の Identity Lifecycle トラックの拡張議論で参照される素地となる

openid/ipsie#40 — Discuss 'guest' accounts as a part of identity management ​

  • 起票: 2025-01-18（ameyah）
  • 問題提起: 「ゲストアカウント とは、エンタープライズテナントに排他的に作られたわけではないが、エンタープライズ ID から明示的に権限付与されてアプリ内のデータ / アーティファクトにアクセスできるアカウント」と定義。エンタープライズ環境で作成された共同編集ドキュメントへの個人アカウントからのアクセスを例として提示
  • 補足: Pamela Dingle が 1/14 コールで ephemeral アカウント（AWS デプロイメント等のサンドボックスアカウント）という追加カテゴリを提起していたことが本 issue に記録されている
  • 状態: 1 月内コメントなし、open のまま
  • 意義: Identity Lifecycle の射程外に置かれがちな「ゲスト」「ephemeral」アカウントを WG 議題化した issue。後の 2/26 の Issue #54 「Ephemeral Identities in IPSIE」につながる 問題意識の最初の表面化 に該当する

openid/ipsie#43 — Reframing of ILM section of IPSIE levels ​

  • 起票: 2025-01-24（sbroddy, Shannon Roddy / LBNL）
  • 問題提起: 「現状の Identity Lifecycle Management (ILM) セクションは、本質的に Identity Governance and Administration (IGA) を扱っているのではないか」と指摘。本来の ILM が扱うべき以下の事項が欠落していると主張:
    • ユーザの onboarding / offboarding 手続き
    • ユーザの法的氏名変更、メールアドレス変更
    • Affiliation / ロール遷移と、それらの RP への伝達
  • 加えて以下の相互運用課題も提起:
    • IdP → RP への user data 変更のシグナリング方式の標準化
    • 非静的なユーザ情報を扱う RP のガイドライン
    • 主識別子の戦略（email がそれを担えるか）
  • 状態: 1 月内コメントなし、open のまま
  • 意義: 1/28 コールでの「IdP/RP 呼称放棄」決定と同週に、ILM セクション全体のフレーミングに疑問を投げかけた issue。IPSIE が「ID の流動性（名前変更、属性変更）」をどう扱うかという、本月の議論からは抜け落ちていた論点を提起。後の WG での subject identifier 議論と接続する素地となる

6. 関連イベント ​

2025 年 1 月は IPSIE WG がカンファレンスで前面に出る月ではなく、WG 内部の用語・レベル定義作業に集中 した月だった。openid.net 上の独立した公式アナウンスは本月には記録されていないが、業界向け広報として次の動きがあった:

  • 2025-01-15 Raising the Bar for the Industry with IPSIE（Okta Security Blog）: Okta CEO Todd McKinnon 名義で IPSIE への業界支持を表明する投稿が公開された。IPSIE には 25 社 が参画していることが明示され、Okta / Microsoft / Ping Identity / Beyond Identity / Capital One / SGNL 等が共同で SSO・ライフサイクル管理・エンタイトルメント・リスクシグナル共有・セッション終了の標準化を進めると説明。Todd McKinnon は「the goal with IPSIE is to standardize identity security and help foster an open ecosystem」と発言し、ドラフト仕様の「early 2025」公開を目標として明示した
  • Gartner IAM Summit 2025 (12/8〜10, Grapevine, TX) の interop ターゲット設定（1/21 コール）: WG として 初めて公式に「interop デモのターゲット日」を設定 した瞬間。以降の WG 全体のスケジュール感はこのアンカー日付からの逆算となる

なお、1/21 コール議事録には IETF 122 (Bangkok, 3/15〜3/21) や IIW 40 (4/8〜4/10) への直接の言及はまだなく、これらは 3 月以降のコールで具体化される。

7. 今後の予定 ​

2025 年 1 月末時点で WG が 2 月以降に向けて確認していた予定:

  • IdP/RP 呼称放棄の即時実装: 1/28 コールで合意した enterprise / app（Identity Service / Application）への呼称切り替えを、PR #41 マージ後に残るドキュメント全域へ伝播させる。これは Dean が action item として引き受けた
  • app と enterprise の責務を別軸とするテーブル構造への移行: 1/28 コール合意 + Dick の PR #44 雛形をベースに、ipsie-levels.md のテーブル全体を「app 列 / enterprise 列を別軸として持つ」構造に rotate する。翌 2 月初頭の PR #46 として Dean が起草する想定
  • Lifecycle Management のレベル定義の精緻化: control objective（joiner / mover / leaver）ベースに切り替えた PR #41 をベースに、IL2 における JIT の扱いを巡る議論を継続。本月の段階では JIT 除外までは至っていないが、Lifecycle の段階数を絞る議論は既に始まっている
  • Authentication トラック (A1/A2/A3) の固め: 1/7 コールで提示された粗組みを、用語整備完了後に精緻化する
  • Entitlements の段階定義の継続検討: PR #41 で 3 段階 → 2 段階に縮約されたが、IdP が管理できないアプリ を IPSIE 適合外とするのか、別の compliance trade-off があるのかは継続検討
  • Identity Lifecycle の射程拡大検討: Issue #39 (inactivity)、Issue #40 (guest accounts)、Issue #43 (ILM vs IGA、名前変更 / 属性変更) の各論点は deferred 扱いで、本月末時点では明示的なオーナーは未定
  • Gartner IAM Summit 2025 (12 月) を interop デモの目標日に据える: 1/21 コールで初共有された目標。Aaron / Dean が demo 準備、Kenn Chong が RSA 内部の参加可否確認、Aaron が実イベントへのコミット締切タイムラインの整理を引き受ける

8. 参考情報源 ​

OpenID Foundation 公式 ​

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

GitHub ​

GitHub Wiki 議事録 ​

議事録補助リソース ​

業界広報 ​