idbok

Appearance

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

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

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ō)。スコープは SSO・ユーザライフサイクル管理・エンタイトルメント・リスクシグナル共有・ログアウト・トークン失効の 6 分野で、それぞれをセキュリティレベル（SL1〜SL3）と相互運用レベル（IL1〜IL3）に分けたプロファイル群として整理する方針が共有されている。

2025 年 2 月は WG 発足から 4 か月目、レベル定義 (ipsie-levels.md) の枠組みを集中的に詰めた月 にあたる。1/28 コールで合意された「IdP / RP 中心の用語から enterprise / app ベースの記述、および app と enterprise の責務を別軸に分けた conformance table 構造への切り替え」を受け、2 月は (1) 新テーブル構造のリポジトリへの反映、(2) Session Lifecycle (SL) ・ Identity Lifecycle (IL) ・ Entitlements (En) の 3 ディメンションの精緻化、(3) エンタイトルメント管理を IPSIE が扱える対象か（あるいは AuthZEN WG に委ねるか）の論争、(4) JIT (Just-In-Time) プロビジョニングを Identity Lifecycle のスコープから外す合意、という流れで議論が展開した。

この月の議論成果は、3 月に Aaron が aaronpk/ipsie-openid-sl1 上で立ち上げる OpenID Connect IPSIE SL1 Profile (Editor's Draft) 初版 の基盤となる。とくに 2/25 コールで成立した「SL1/SL2/SL3 と IL1/IL2/IL3 の各 3 レベル定義」「JIT を Identity Lifecycle から除外」「年末 12 月の Gartner IAM での interop デモを WG ゴールに据える」という意思決定群は、その後の WG の方向性を決定づけた重要な合意である。

月内の主な動き:

  • 定例コール 4 回（2/4, 2/11, 2/18, 2/25）。すべて毎週火曜 9:00 PT 開催で、参加者は 13〜21 名（議事録ベース）
  • 2/3 に Dean H. Saxe が PR #46 "Rotate IPSIE Level tables" を提出、2/4 にマージ。1/28 コール合意の新テーブル構造（app と enterprise の責務を別軸）を ipsie-levels.md に反映
  • 2/11 に Aaron Parecki が Issue #51 "Entitlement Management - Real World Examples" を起票。16 コメントに及ぶ集中議論を 2/12〜2/17 にかけて誘発し、本月最大の論点となった
  • 2/26 に Dick Hardt の PR #53 "Updated Identity Lifecycle levels" がマージ。JIT を Identity Lifecycle のスコープから除外し、IL1〜IL3 を user/group/role の create/update/delete に集約する 2/25 コール合意を仕様化
  • 2/26 に Dean H. Saxe が Issue #54 "Ephemeral Identities in IPSIE" を起票。JIT 除外決定で扱いが宙に浮いた「セッション寿命と同じだけ生きる短命アイデンティティ」をどう位置付けるかを WG 議題化
  • 2 月時点では 正式なプロファイルドラフトは未存在。WG の作業は openid/ipsie 親リポジトリの ipsie-levels.md（レベル定義ドキュメント）の編集に集中

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

2 月時点では IPSIE WG から Final / Implementer's Draft / Editor's Draft として公開された仕様は存在しない。WG はまだ「レベル定義 (ipsie-levels.md) を固める」段階にあり、最初の OpenID Connect SL1 プロファイル Editor's Draft が立ち上がるのは翌 3 月 7 日の Aaron Parecki のコミット投入を待つ。

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

2/3〜2/4 — 新テーブル構造への切り替え（PR #46） ​

2/3 21:21 UTC に Dean H. Saxe が PR #46 "Rotate IPSIE Level tables" をオープン。本文では「テーブル構造を回転（rotate）させ、それに合わせて長い説明文も整列させた」と説明したうえで、2 つの未解決点をレビュアに問いかけている:

Two open questions:

  1. Should JIT be permitted at IL2? It conflicts with pre-provisioning/deprovisioning.
  2. Is the E1 guidance too weak? Should we remove it or change "MAY" to "MUST" for both applications and identity services?

これらの問いは、後の 2/4 / 2/11 / 2/25 コールの議論を直接駆動する論点となる。Aaron Parecki は 2/3 のコメントで「JIT は許容すべき。ユーザが pre-provisioning タスクの完了前にログインする可能性がある」と応答し、Dick Hardt はさらに「JIT を IL2 で許容するかは app / enterprise 個別ポリシーの問題」と整理した。

PR #46 は 2/4 中に Aaron がマージ。同じ 2/4 コール後に Aaron 自身が以下の追従 PR を提出している:

その他、1 月から続いていた用語追加 PR (#35, #38, #42, #44) も 2/4 に一斉マージされ、本月前半に WG 全体としての用語整理が一気に進んだ。

2/20〜2/26 — Identity Lifecycle の単純化（PR #53） ​

2/20 に Dick Hardt が PR #53 "Updated Identity Lifecycle levels" をオープン。コミットメッセージで以下の 3 点を明示している:

  • standardized on singular of Application and Identity Service（単数形に統一）
  • simplified IL levels（IL レベルの単純化）
  • removed JIT as a provisioning mechanism since it is not a life cycle（JIT をプロビジョニング機構として除外、lifecycle ではない）

途中 2/25 コール後に Add in JIT to IL1 description（IL1 説明文中に JIT 言及を残す）コミットが追加され、2/26 に Dean が LGTM レビュー、Aaron がマージ。これは 2/25 コール（後述 §3）で成立した「JIT を Identity Lifecycle のスコープから明示的に外し、IL は user/group/role の CRUD に集中する」合意の仕様化である。

なお、Aaron が 2/19 にオープンした PR #52 "updates from the Feb 18 meeting" は同じ目的を持っていたが、Dick の PR #53 にスーパーシードされて 3/3 にクローズされた（Aaron のコメント This has been replaced by #53）。

1 月末からの累積編集の到達点 ​

2 月末時点の ipsie-levels.md は、次の 3 ディメンションを app / enterprise の責務を別軸とした表形式 で記述する構造に整理された:

  1. Session Lifecycle (SL1/SL2/SL3): SSO の確立・継続・終了に関する要件。SL1 = baseline SSO、SL2 = 強化された認証コンテキストとセッション管理、SL3 = IdP-RP 間の state change シグナル授受
  2. Identity Lifecycle (IL1/IL2/IL3): ユーザ・グループ・ロールの作成・更新・削除に関する要件。JIT は明示的に除外
  3. Entitlements (En): アプリケーションのパーミッションを IdP がどう管理するかの要件。本月の議論で「IPSIE がどこまで踏み込むか」が最大の論争点となった（後述）

これらは 3 月の OpenID Connect SL1 Profile Editor's Draft 初版が依拠する基盤定義となる。

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

IPSIE WG の定例コールは毎週火曜 9:00 PT。2 月は 2/4, 2/11, 2/18, 2/25 の 4 回 開催された。すべての議事録は Aaron Parecki が ML に転載しており、ML 投稿から議論を再構成できる。

2/4 コール — 新テーブル構造の反映と Session Termination の射程 ​

2/6 付 ML 投稿 で Aaron Parecki が議事録を公開（19 名参加、Notetaker: Mark Maguire）。

主要議題と決定事項:

  • 3 ディメンションのテーブル構造の確認: 1/28 コールで合意した「Session Lifecycle / Identity Lifecycle / Entitlements の 3 独立カテゴリ × app と enterprise の責務を別軸」という新構造を、PR #46 として ipsie-levels.md に反映することを確認
  • SL2 における must vs may の用語論争: Session Level 2 のアプリ側要件を必須 (must) と任意 (may) のどちらで規定するかが論点に。Kenn Chong (RSA) が「セキュリティ要件はより厳格に保つべき」と must を支持。Aaron が「規制要件の柔軟性を rely on するべきケースもある」と反論したが、最終的に must 表現を維持 することで合意
  • Session Termination の定義の確定: 「Session termination はユーザの全トークンを失効させ、すべての場所からログアウトさせること」と定義。管理者が手動でログアウトを発動するケースと、Shared Signals 経由でイベントが流れるケースの両方をカバーする
  • SL3 の posture/state changes: 「posture changes」を「state changes」と用語変更し、user 状態と device 状態の両方を含めることに合意。SL3 は state change を receive することを要求するが、特定のアクション（即時失効など）は要求しない（責任は RP 側のポリシーに委ねる）
  • Global logout problem: あるアプリでのログアウトが他のアプリにカスケードする global logout の扱いは結論に至らず、GitHub での議論に持ち越し

このコールの直後、George Fletcher が Issue #47 "Session termination 'requirements'" を起票（モバイルアプリが offline_access scope でリフレッシュトークンを発行している場合、それらは「サインインセッション」と紐付かないため、Session Termination 時の扱いを明確化する必要がある）。Mark Maguire は Issue #50 "Terminating User Sessions - Complications with PAM" を起票し、「IdP がセッション終了を発動しても、PAM (Privileged Access Management) 経由でチェックアウトされた共有アカウント認証情報による既存セッションは残存し続ける」という具体的なギャップを提起した。

2/11 コール — Identity Lifecycle と Entitlements を分けるか ​

2/11 付 ML 投稿 で Aaron Parecki が議事録を公開（21 名参加、Notetaker: Dean H. Saxe）。Authorization (Entitlements) 領域の取り扱いが本月最大の論点として浮上した回。

主要議論:

  • Chair / Editor の役割分担: 冒頭で Dick Hardt が「IETF のように chair と editor を独立した人物にすべきではないか。これまでのコールは co-chairs / editors が支配的だった」と問題提起。Aaron は「OIDF では chair と editor を兼任するのが標準慣行」と応答、Dean は「追加のエディタを受け入れることに前向き」と表明
  • Identity Lifecycle と Entitlements を別トラックにするか: Dick Hardt が「groups は本質的に user の attribute なので、Identity Lifecycle と Entitlements を分ける必要はなく、ひとつのディメンションに統合できる」と主張。Aaron は「分離することで各トラックが独立に成長できる」と反論、Travis Tripp は「グループはユーザに先行して存在しうる（user-less な状態でも作れる）」と Aaron 側の整理を補強
  • Authorization の現実の多様性: Russell Allen が自社の authorization モデルを共有: 「我々が authZ を制御するリソースの集合、リソースごとに CRUD パーミッションを持つ、マルチテナント境界あり」「我々のモデルは典型的ではなく社内管理されている」と述べ、Aaron は「相互運用には、identity service がエンタイトルメントをアプリへどう exposes するかを定義する必要がある」と問題の核心を整理。Pam Dingle (Microsoft) は「identity service にアプリが何を求めるかから出発し、既知のセキュリティリスクを攻撃する観点で議論しよう」と提案
  • 「現実例の収集を先行させる」決定: 詳細な Authorization 議論は一旦保留し、まず「異なるツールで authorization がどう管理されているか」のドキュメントを集めることに合意。Aaron が直後に Issue #51 を起票

議事録要約（議事録 2025-02-11 より）: Authorization (Entitlements) の議論は、参加者の組織ごとに implementation が全く異なるため、定義を先行させると合意が得られない。まず real-world examples を集めて共通項を見出すアプローチに切り替える。詳細な Entitlements 仕様化は Identity Lifecycle / Session Levels の確定後に取り組む

2/18 コール — Entitlements の議論深化と「アプリがロールを exposes する」モデル ​

2/19 付 ML 投稿 で Aaron Parecki が議事録を公開（19 名参加、Notetaker: Mark Maguire）。Issue #51 への 1 週間分のコメントを踏まえ、コール上で Entitlements の方向性を詰めた回。

主要議論:

  • AuthZEN への依存の是非: Karl McGuinness は「この段階で IPSIE が AuthZEN への dependency を持つことには慎重になりたい (would be nervous for IPSIE to take an AuthZen dependency in this time)」と発言。AuthZEN WG は同時期に活発だったが、まだ仕様が確立されていない段階での依存にリスクがあるとの指摘。Mike Kiser (SailPoint) も「zero standing privilege は近い将来には viable ではない、5 年程度のタイムラインで考えるべき」と現実感を共有
  • 「Groups」用語の擁護と批判: Dick Hardt が「Microsoft と Google は groups という用語を使っている。エンタープライズに浸透している用語を使う方が普及に有利」と主張。これに対し Karl McGuinness は「groups だけでは authorization context が欠落する。アプリが自身の permission モデルを exposes するアプローチが必要」と反論
  • コア要件の合意形成: 議論を経て、次の原則について緩やかな合意が形成された:
    • IdP が access の付与・削除を管理する
    • アプリは自身の roles / permissions を identity service に exposes する
    • identity attributes はアプリ横断で一貫してマッピングされる
    • 失効が各システムで成功したことを verify する
  • 「アプリ→ロール exposes→IdP がロールを user の attribute として割り当て」モデルの提示: Russell Allen は「このアプローチなら、アプリは domain model を進化させても role contract を破らずに済む」と述べ、変更容易性の観点でこのモデルを支持
  • Long-tail SaaS への適用容易性: 「Comprehensive な解決策をエンタープライズ向けに作るより、多数のアプリに対するインクリメンタルな改善を優先する」（Mark Maguire ほか）。David Lee は「既存ワークフローを最適化するのでなく、より secure な方法に切り替える」と発言

議事録要約（議事録 2025-02-18 より）: Entitlements に関しては「アプリが自身の permission モデルを exposes し、IdP がそれを user の attribute として割り当てる」モデルが基本方向。AuthZEN への明示的な依存は当面避け、エンタイトルメントの中核は IPSIE 内で扱う方針。ただし詳細な仕様化は Session / Identity Lifecycle の確定後

2/25 コール — JIT を Identity Lifecycle から除外、3 レベル × 2 ディメンション確定 ​

3/3 付 ML 投稿 で Aaron Parecki が議事録を公開（13 名参加、OSW の準備で公開が 1 週間遅れた旨を冒頭で説明）。本月の意思決定の頂点となった回。

参加者: Aaron Parecki (Okta), Dean H. Saxe (Beyond Identity), Travis Tripp (HPE), Hannah Sutor (GitLab), Dick Hardt (Hellō), Mike Kiser (SailPoint), Frederico Valente (Workday), Shannon Roddy, Nagesh Gummadivalli (Workday), Russell Allen, Gennady Shulman, Wesley Dunnington (Ping), Ameya Hanamsagar (Meta)

主要決定:

  • JIT (Just-In-Time) プロビジョニングを Identity Lifecycle のスコープから除外: 焦点は「SSO 起点で作られる JIT ユーザに lifecycle 管理が付随しないことが本質的問題」。Travis Tripp の発言が JIT 除外の根拠として議事録に明記されている:

    "JIT is not managing the lifecycle - you created an immortal entity." — Travis Tripp（議事録 2025-02-25 より）

    Aaron は「JIT が発生した場合でも、IL1 は IdP が以後そのアイデンティティを管理下に置くことを要求する」と整理し、Dean は「JIT 自体を定義する必要はないが、lifecycle が JIT で作られたユーザを管理できることを定義する必要がある」と述べた。最終的に 「JIT を IL のメカニズムから除外し、IL は user / group / role の create / update / delete に集中する」「ただし、JIT で作られたユーザは IL によって完全に管理されることを要求する」 という構造に合意。これは PR #53（2/26 マージ）として直ちに仕様化される

  • 3 レベル × 2 ディメンションの確定: Session Lifecycle (SL1/SL2/SL3) と Identity Lifecycle (IL1/IL2/IL3) の各 3 レベル定義が確定。Entitlements (En) は本月の議論を経て一旦後置きとなり、後の WG 進行で別途扱う方針

  • 作業順序の決定: 「SL1 と IL1 のプロトコル定義から先に着手する」「年末 12 月の Gartner IAM Summit を interop デモのターゲット日に据える」「下位レベルの定義を完了してから IL2/SL2 の定義に進む」というシーケンシャルな進行方針が明示された。この「12 月 Gartner IAM での interop」というスケジュールアンカーが、以降の WG 全体の逆算スケジュールの基準点となる

  • JIT race condition の認識: Travis Tripp の「provisioning in the background can take longer than the timeline for a user to SSO into a system, creating a race condition」という発言（後の 3 月の議事録転載で明示的に記録）が JIT 除外の理由として共有された

議事録要約（議事録 2025-02-25 より）: SL1〜SL3 と IL1〜IL3 のレベル定義が確定。JIT は Identity Lifecycle のスコープから除外され、IL は user / group / role の CRUD に集中する整理に。次月以降は SL1 / IL1 から先にプロトコル定義に着手し、12 月の Gartner IAM での interop を WG 全体のゴールに据える

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

openid-specs-ipsie メーリングリストは pipermail の週次インデックス方式（親アーカイブ）。2 月の投稿は 議事録通知と週次 GitHub digest が大半 を占め、独立した技術討論スレッドは形成されなかった。これは IPSIE WG の「議論は定例コールと GitHub Issue 上で完結させ、ML は議事録通知と digest の場とする」運用パターンが本月時点で既に確立していたことを示している。

4.1 2025-02-04 IPSIE WG Meeting Minutes — 2025-02-06 19:51 UTC 投稿 ​

  • 発端: Aaron Parecki が 2/4 コール議事録を ML へ転載（Notetaker: Mark Maguire、19 名参加）
  • 内容: 3 ディメンション × app/enterprise 別軸の新テーブル構造の確認、SL2 の must 維持、Session Termination の定義確定、SL3 の state change シグナル受信要件、Global logout 問題の GitHub 議論への持ち越し
  • 意義: 1 月末の用語整理 → 2 月初の新テーブル構造反映という流れを ML 上で公式化した投稿。本月以降の WG 議論の出発点

4.2 2025-02-11 Meeting Minutes — 2025-02-11 23:27 UTC 投稿 ​

  • 発端: Aaron Parecki が 2/11 コール議事録を ML へ転載（Notetaker: Dean H. Saxe、21 名参加）
  • 内容: chair / editor 役割分担の議論、Identity Lifecycle と Entitlements を分けるか統合するかの論争、Authorization の現実の多様性（Russell Allen の社内モデル提示、Pam Dingle の「アプリ起点アプローチ」提案）、Issue #51 起票宣言
  • 意義: Entitlements 領域に IPSIE がどこまで踏み込むかの 議論軸が ML 上で初めて明示 された投稿。「現実例の収集を先行させる」アプローチが Issue #51 として翌週から実体化する

4.3 2025-02-18 Meeting Minutes — 2025-02-19 00:07 UTC 投稿 ​

  • 発端: Aaron Parecki が 2/18 コール議事録を ML へ転載（Notetaker: Mark Maguire、19 名参加）
  • 内容: AuthZEN への依存可否の議論、Mike Kiser の「zero standing privilege は 5 年タイムライン」発言、「Groups」用語の擁護と批判、「アプリが自身の permission モデルを exposes する」モデルの合意形成
  • 意義: Entitlements を Authorization の汎用フレームワーク（AuthZEN）に丸投げするのではなく、「アプリ→IdP に roles を exposes する」モデルを IPSIE 自身が定義する 方針が議事録化された投稿

4.4 2025-02-25 IPSIE WG Meeting Minutes（3/3 投稿） — 2025-03-03 21:12 UTC 投稿 ​

  • 発端: Aaron Parecki が、OSW (OAuth Security Workshop) 準備のため公開が 1 週間遅れた 2/25 コール議事録を 3/3 に ML へ転載
  • 内容: JIT を Identity Lifecycle から除外する合意、Travis Tripp の you created an immortal entity 発言、SL1〜SL3 / IL1〜IL3 の確定、SL1 / IL1 からの作業着手、年末 Gartner IAM での interop ゴール設定
  • 意義: 本月最大の意思決定を集約した投稿。3 月以降の OpenID Connect SL1 Profile Editor's Draft 初版立ち上げの直接の起点 となる議事録。投稿が翌月 3/3 にずれ込んだが、内容は完全に 2 月の WG 合意

4.5 週次 GitHub digest（自動配信） ​

openid-activity at aaronpk.com Bot が日曜配信する週次 digest が 4 本配信されている:

これらの digest は、WG 議論の実体が コール議事録と GitHub 上に集中 していることの裏返しでもある。

5. GitHub 上の議論 ​

openid/ipsie 親リポジトリで 2025-02-01〜2025-02-28 に起票された新規 issue は 4 件（#47, #50, #51, #54）、新規 PR は 6 件（#45, #46, #48, #49, #52, #53）、2 月内にマージされた PR は 8 件（#35, #38, #42, #44, #46, #48, #49 が 2/3〜2/4 に一斉マージ、#53 が 2/26 マージ）。コミットは 19 件。コメント密度の高い議論を以下に詳述する。

openid/ipsie#51 — Entitlement Management - Real World Examples ​

  • 起票: 2025-02-11（aaronpk、2/11 コール直後の決定により起票）
  • 問題提起: Entitlement Management の現実の実装パターンを WG メンバーから集め、共通項を見出して仕様化の起点とする。Aaron の投稿:「Please provide details on integrations you manage」
  • 主要参加者の主張（コメント順）:
    • Mark Maguire (2MarkMaguire) (2/11 19:25 UTC): エンタイトルメントを「アプリのパーミッション」、ロールを「エンタイトルメントの束（抽象化のため）」と定義。「エンタープライズアプリの 60% が AD/SCIM/API でアクセス管理、20% が JDBC、20% がレガシーなフラットファイル方式」と現実分布を提示。「IPSIE はアプリが集中エンタイトルメント管理のためのインタフェースを提供することを要求すべき。カスタムコネクタを毎回作らせるべきでない」
    • Dean H. Saxe (dhs-BI) (2/11 23:20 UTC): 「zero standing privilege モデル（パーミッションが runtime データから動的に導出され、静的エンタイトルメントが存在しない）を IPSIE はどう扱うのか」と問題提起。「AuthZEN との交差点はどこか。RBAC ではなく ABAC / PBAC / ReBAC を使うモデル、あるいは AWS IAM のように複数モデルが共存するシステムはどうするか」
    • baboulebou (2/12 01:51 UTC): 「エンタイトルメントと authorization は一般に外部の特化システムで管理する方が良い。AuthZEN PDP 経由の外部 authorization が、内部エンタイトルメント API を exposes するより優れる」とアーキテクチャ的主張
    • Aaron Parecki (2/12 02:14 UTC): 「SaaS アプリとエンタープライズ IdP 間で AuthZEN を実装している現実の例があれば共有してほしい」と具体例を要求
    • baboulebou (2/12 02:32 UTC): OAuth Step-Up Authentication (RFC 9470) と AuthZEN を統合するユースケースを提示。「ロールや内部エンタイトルメントを必要とせず、集中ポリシー管理で認証強度を動的に上げる」例
    • Mark Maguire (2/12 03:10 UTC): 「zero standing privilege は SOX や金融コンプライアンス要件と衝突する。銀行は『どのアカウントがどのシステムに、どの時点でアクセス権を持っていたか』を集中ロケーションで監査可能な形で保持することを要求される」と反論
    • baboulebou (2/12 03:29 UTC): 「決定論的な PDP と集中ポリシーは、数百のアプリにエンタイトルメントを分散させるより監査トレールを改善する」と再反論
    • baboulebou (2/12 14:58 UTC): 「エンタープライズには複数の authorization パターンが共存する必要があるかもしれない。off-the-shelf ソフトウェアには provisioning、社内システムには PEP/PDP アプローチ」と統合論を提示
    • Russell Allen (Russell-Allen) (2/15 00:35 UTC): 自社の多テナントプラットフォーム（OIDC フェデレーション + 社内 authorization サービス）の実装を共有。「AuthZEN の PDP とリソースサーバの結合度、リクエストごとの PDP コールの性能と鮮度（freshness）に懸念がある」
    • baboulebou (2/15 02:07 UTC): ReBAC、OPA Rego、CEDAR など複数の authorization モデルに言及。「AuthZEN WG で『partial searches』機能の開発が進んでいる」
    • Russell Allen (2/16 16:55 UTC): 「PDP が boolean response でなく、PEP に condensed policy sets を返す方式を好む。リクエストあたり複数 authorization decision があり、race condition を避けたい」
    • baboulebou (2/16 17:54 UTC): Russell-Allen を AuthZEN WG セッションに招待
    • Russell Allen (2/16 18:23 UTC): SCIM ベースのエンタイトルメント統合を managed system 向けに使う実例を共有。「静的マッピングだと expressiveness の限界がある」
    • Russell Allen (2/16 19:33 UTC): VPN、ターミナルアプリ等を経由する複数層 authorization の複雑性を提起。「異なる trust model 間での composability が課題」
    • simon-canning-octopus (2/16 22:17 UTC): Grammarly (SAML/SCIM でシンプルなロール) と Octopus Deploy (Space/Project/Environment scoped な細粒度 RBAC) を対比。「domain-centric な細粒度は IdP でモデル化困難」
    • baboulebou (2/17 00:22 UTC): 「COTS プラットフォームは AuthZEN をネイティブにサポートできる。エンタープライズは社内ソフトウェアを PDP アプローチで管理」と統合論で締めくくり
  • 状態: 2 月末時点で open（コメント数 16）。3 月以降も新規コメントなく、議論は 2/18 コールで「アプリが自身のロールを exposes する」モデルへの一旦の集約として消化された
  • 意義: 本月最大の議論。zero standing privilege vs. 静的エンタイトルメント、AuthZEN への依存可否、PDP の性能/鮮度、エンタイトルメントの集中 vs. 分散、SOX 準拠要件、複数モデルの共存性、といった Authorization 標準化の主要論点が一気に洗い出された。これらは以降の IPSIE の Entitlements トラックが取り組むべき問題リストの基礎となる

openid/ipsie#47 — Session termination "requirements" ​

  • 起票: 2025-02-04（gffletch、George Fletcher、2/4 コール直後）
  • 問題提起: モバイルアプリは offline_access scope でリフレッシュトークンを要求するが、これらのトークンは通常「サインインセッション」と紐付かない。Session Termination 時の扱いを明確化する必要がある
  • 主要参加者の主張:
    • Dean H. Saxe (dhs-BI) (2/4 20:41 UTC): 「SLx レベルのガイダンスに追記すべき。ipsie-levels.md の descriptive text に統合する PR を歓迎」
    • Brock Allen (brockallen, Duende) (2/5 14:32 UTC): 実装観点の問い。「Identity Service はモバイル/ネイティブアプリにどう通知するのか。push notification インフラを前提とするのか？」
    • Aaron Parecki (2/5 14:43 UTC): 「OIDC Back-Channel Logout 仕様を参照すべき。標準 OIDC のもとでは offline_access scope の refresh token は revoke されないままでよいが、IPSIE の session termination では明示的に revoke されなければならない」
    • Brock Allen (2/6 13:00 UTC): 「Identity Service レベルでの refresh token revoke は技術的に可能。ただし モバイル/ネイティブアプリ側に残存するアクセストークン が懸念」
  • 状態: 4 コメントで議論が一旦止まり、open のまま 3 月以降に持ち越し。SL1 ドラフトの構造が固まる中で session termination の細部は別 issue (#66 SSF Events as Directives, 3/28 起票) に発展していく
  • 意義: モバイルアプリにおける offline_access の扱いという、エンタープライズ SSO で見過ごされがちな実装ギャップを早期に issue 化した事例。Brock Allen の指摘「モバイル側に残存するアクセストークン」は、後の Session Termination 仕様で SSF (Shared Signals Framework) と組み合わせる議論の素地となる

openid/ipsie#50 — Terminating User Sessions - Complications with PAM ​

  • 起票: 2025-02-04（2MarkMaguire、Mark Maguire / Aujas Cybersecurity）
  • 問題提起: 「管理者は個人アカウントではなく、PAM (Privileged Access Management) ワークフロー経由でチェックアウトされた共有特権アカウント認証情報を使うことが多い。IdP が全セッション終了を発動しても、PAM 内でチェックアウト中の共有アカウントによる既存セッションは残存し続け、unauthorized access リスクを生む」
  • 提案: PAM アプリ向けの dedicated recommendations section をガイドラインに追加。「PAM ソリューションが RP として session termination を受信した際に、チェックアウト中のパスワードを自動的にローテートまたは無効化することを要求する」
  • 状態: 2 月内コメントなし、open のまま。後の WG 議論で PAM 固有のシナリオは Entitlements トラックや SSF トラックと交差する形で扱われる
  • 意義: エンタープライズ ID セキュリティの「現場の手触り」を持つ Mark Maguire ならではの PAM 特有のセッション失効ギャップ を WG に提起した事例。RP 側の責務範囲を仕様としてどう書き分けるかという以降の議論に直接寄与

openid/ipsie#54 — Ephemeral Identities in IPSIE ​

  • 起票: 2025-02-26（dhs-BI、Dean H. Saxe、2/25 コール直後）
  • 問題提起: 2/25 コールで JIT を Identity Lifecycle のスコープから除外する合意が成立したが、「JIT-like provisioning で SSO イベント時に作成され、ユーザのセッション長だけ存続する 短命アイデンティティ (ephemeral identities)」をどう扱うかが宙に浮いた。「ユースケースとデータを WG に持ち寄ってほしい。今後の議論の対象」
  • ラベル: sl1, deferred, FAL2（後付け）
  • アサイン: Dean H. Saxe
  • 状態: 2 月内コメントなし、open のまま deferred 扱いに
  • 意義: JIT 除外の 裏面 を即座に issue 化した事例。Identity Lifecycle に乗らないが現実の SSO シナリオで頻出する短命アイデンティティを、後の SL1 / FAL2 議論の文脈で扱う前提を明示

openid/ipsie#45 — Identity CRUD Implementation Concepts ​

  • 起票: 2025-02-03（paucorre、Pau Corredor）
  • 内容: 用語ドキュメントに Identity CRUD Implementation Concepts を追記
  • 議論経過:
    • paucorre (2/3): PR 提出
    • Aaron Parecki (2/4): レビュー、outdated マーク
    • Dean H. Saxe (dhs-BI) (2/4): 「言語は良くて有用。ただし、これは IETF SCIM WG の最近の作業由来で SCIM 向きの方向性を持っている」
    • paucorre (2/4): 「SCIM への参照は protocol-agnostic に保つために削除済み。特定段落のリファイン支援を要請」
    • dhs-BI (2/4): 「小さな懸念はあるが、合意があればマージしてよい」
    • Dean H. Saxe (deansaxe) (2/9): 議論を反映したアップデートをコミット
    • dhs-BI (2/9): 「lgtm after the updates」
    • dhs-BI (2/25): 「lgtm - マージ前に upcoming call で議論しよう」
  • 状態: 2 月末時点で open（最終的に 3 月にも持ち越され、本月内ではマージされず）
  • 意義: SCIM WG の最新議論を IPSIE の用語に取り込む試みと、それを protocol-agnostic に保つ慎重さのバランスが議論された事例

PR の状況サマリ ​

2 月内にマージされた PR:

2 月末時点で open のまま残った PR:

6. 関連イベント ​

2025 年 2 月は、IPSIE WG が外部イベントで前面に出る月ではなく、WG 内部の仕様作業に集中 した月であった。openid.net 上に IPSIE 関連の独立した公式アナウンスや、IPSIE WG メンバーによる大規模カンファレンス登壇は本月には記録されていない。

ただし、本月の WG 活動は次の外部要因の影響下にあった:

  • OSW (OAuth Security Workshop) 出席: 2/25 コールの議事録公開が 1 週間遅れた理由として、Aaron が冒頭で「OAuth Security Workshop で参加者と議論していて多忙だった」と説明。OSW は OAuth/OIDC 関連の研究者・実装者が集う非公式技術ワークショップで、本年は 2 月末〜3 月初に開催されたとみられる
  • 翌月 3/5 の IDSA × OIDF ウェビナー準備: 翌 3 月 5 日に Identity Defined Security Alliance (IDSA) 主催で開催される「Securing the Future of Identity with IPSIE – A New Industry Standard」ウェビナー（300 名超登録）の準備が 2 月後半に進められたと推察される（直接の ML 言及はないが、3 月の WG コール後の openid.net アナウンスから逆算）
  • 年末 12 月 Gartner IAM Summit を WG のゴール日に据える決定（2/25 コール）: WG として 初めて公式に「interop デモのターゲット日」を設定 した瞬間。以降の WG スケジュールはこのアンカー日から逆算される運用が定着する

なお、2/25 コール議事録には IETF 122 (Bangkok, 3/15〜3/21) や IIW 40 (4/8〜4/10) への言及はまだ含まれていない。これらのイベントとの定例コールのスケジュール調整は、翌 3 月のコールで具体化される。

7. 今後の予定 ​

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

  • 3/4 コール — SL1 / IL1 のプロトコル定義開始: 2/25 で確定したレベル定義に基づき、SL1 と IL1 から先にプロトコル仕様の編集に着手する方針が共有済み。これは翌月 3/7 の Aaron Parecki による OpenID Connect IPSIE SL1 Profile Editor's Draft 初版 の aaronpk/ipsie-openid-sl1 投入として実現する
  • SAML SL1 の起草担当者の選定: 2/25 コールで OIDC SL1 を Aaron、SAML SL1 を別担当者（後の 3/27 の Matt Topper による PR #65 として実現）に分担する流れが暗黙に形成されていた
  • Identity Lifecycle ドキュメントの安定化: PR #53 のマージ (2/26) で IL の基本構造が確定。3 月以降は IL の詳細要件（特に SCIM 関連）の議論を深める
  • Entitlements トラックの一旦保留: Issue #51 で集まった現実例を参照しつつ、Entitlements の仕様化は SL/IL の進捗を見て後置きに
  • Ephemeral Identities の deferred 議論: Issue #54 として Dean がアサインを引き受け、SL1 / FAL2 の議論文脈で別途扱う
  • 年末 12 月 Gartner IAM Summit での interop デモ: WG 全体のゴール日として 2/25 で初めて公式設定された。以降の WG スケジュールは本日付からの逆算で動く

8. 参考情報源 ​

OpenID Foundation 公式 ​

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

GitHub ​

GitHub Wiki 議事録 ​

  • IPSIE WG Wiki トップ — 議事録インデックス（74 件、2024-10 以降）
  • 2 月の各コール議事録は ML 投稿（上記）でも完全に追跡可能

議事録補助リソース ​