idbok

Appearance

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

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

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 年 3 月は WG 発足から約 5 か月、レベル定義（SL1/SL2/SL3、IL1/IL2/IL3）の枠組み合意が直前の 2/25 コールで成立した直後 にあたる。月初の 3/4 コールでは「最初のプロトコル仕様を SL1 / IL1 に絞って書き始める」方針と「年末 12 月の Gartner IAM での interop デモを WG 全体のゴールに据える」スケジュール感が共有された。これを受けて 3 月 7 日に Aaron Parecki が OpenID Connect IPSIE SL1 Profile の Editor's Draft 初版 を aaronpk/ipsie-openid-sl1 リポジトリに投入し、ML へ周知。これに先立つ 3 月 5 日には Identity Defined Security Alliance (IDSA) 主催で IPSIE を題材にしたウェビナーが開催され、登録者 300 名超を集めて IPSIE の存在を業界に広く周知する月にもなった。

月内の主な動き:

  • 定例コール 3 回（3/4, 3/11, 3/25）。3/18 は IETF 122 (3/15〜21, Bangkok) と重なるためスキップを 3/4 コールで事前決定。同様に 4/8 コールも IIW 40 (4/8〜10) と重なるためスキップが 3/25 コールで決定された
  • 3/7、Aaron Parecki が OpenID Connect IPSIE SL1 Profile (Editor's Draft) 初版 を aaronpk/ipsie-openid-sl1 に push し ML へ周知。FAPI のスタイルに倣った Internet-Draft 形式
  • 3/5、Aaron / Dean / George / Gail と Jeff Reich (IDSA) によるウェビナー「Securing the Future of Identity with IPSIE – A New Industry Standard」開催（告知記事）。登録者 300 名超
  • SL1 Editor's Draft 初版に対し、openid/ipsie 親リポジトリで SL1 関連 4 件（#60, #61, #62, #63）+ SL1 ドラフトフィードバック 1 件（#64）、SL2 関連 1 件（#59、PAR の扱い）、SL3 関連 2 件（#56, #58）、SSF/directives 関連 1 件（#66）の合計 9 件の新規 issue が起票され、いずれも実質的な議論を伴った
  • 3/27、Matt Topper (UberEther) が SAML SL1 Profile の初版 PR (#65) を提出。Aaron の OIDC SL1 をベースに NIST SP 800-63 Rev 4 の文言にマッピングする方針
  • 3/25 コールで「SL1 では IdP は public client を MUST support」「アクセストークンは SL1 では限定的扱い」という方向性に集約。これは翌 4 月の Call for Adoption / draft-00 公開へ直結する重要な意思決定

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

3 月時点では IPSIE WG から Final / Implementer's Draft として公開された仕様はない。WG はまだ「最初の Editor's Draft を書き始める」段階である。一方、3 月内に編集面で大きな進展が 2 つあった。

openid/ipsie 親リポジトリ — ipsie-levels.md の整合性修正 ​

3/3 に、2/25 コールでの合意（Identity Lifecycle トラックから Just-in-Time プロビジョニングを削除し、レベル定義を「create/update/delete of users, groups and roles」に集約する整理）を反映する PR #55 "updates for consistency" が Aaron Parecki から提出され、同日 Dean H. Saxe によりマージされた。コミット履歴は以下の 3 件:

  • e70f40d updates for consistency (2025-03-03)
  • 880ae38 changes from dean's comments (2025-03-03)
  • 09575b0 Merge pull request #55 from aaronpk/feb-25-edits (2025-03-03)

openid/ipsie 親リポジトリへの 3 月内コミットは上記 3 件のみであり、以降の議論成果は aaronpk/ipsie-openid-sl1 側に集中する。

aaronpk/ipsie-openid-sl1 — OpenID Connect IPSIE SL1 Profile (Editor's Draft) の立ち上げ ​

3 月最大の編集作業は、Aaron Parecki が個人リポジトリ aaronpk/ipsie-openid-sl1 上で SL1 OIDC プロファイルの Editor's Draft 初版を立ち上げたことである。3/7 に集中して 19 コミットが投入され、martinthomson/i-d-template を用いた Internet-Draft 形式（IETF kramdown）で初版が形成された。代表的なコミット履歴:

  • b3d7b44 Initial commit (2025-03-07 16:57 UTC)
  • 7be83a2 rename draft to set up (17:01)
  • ea870d2 Setup repository for draft-openid-ipsie-sl1-profile using https://github.com/martinthomson/i-d-template (17:03)
  • 36eec29 add some requirements (17:36)
  • c11ad4b add some more reqs (18:00)
  • 3c905a6 more requirements (19:34)
  • 00f6753 update intro / 409c079 add back middle (19:49〜19:51)

Aaron は同日 20:28 UTC に ML へ Initial draft of OpenID Connect IPSIE SL1 Profile を投稿し、レビュー先として 2 つの URL を案内した:

  • 編集中の HTML レンダリング: https://drafts.aaronpk.com/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html
  • ソース: https://github.com/aaronpk/ipsie-openid-sl1

Aaron は本投稿の中で、ドラフトの構成方針について「FAPI のフォーマットに倣い、開発者向けの解説よりも要件検証を優先する簡潔な記述スタイルを採用した」と説明したうえで、編集者が答えを持たないオープンクエスチョンとして 2 点を明示している:

  1. PAR (Pushed Authorization Requests) を MUST にするか: FAPI は baseline security profile で PAR を必須としているが、IPSIE が同等の要件を持つかは未確定（→ Issue #59 として正式に追跡）
  2. RP のセッションライフタイムを伝達するクレームをどう設計するか: SAML の SessionNotOnOrAfter 属性に相当する仕組みが OIDC には未定義（→ Issue #60 として正式に追跡）

このタイミングで、過去の 2 月コールで議論されてきた論点が一気に正式 issue 化された。3/6〜3/11 にかけて起票された #56, #58, #59, #60, #61, #62, #63 はいずれもこの Editor's Draft 初版を起点とした「SL1 ドラフトに対する具体的なフィードバック」群である（§5 で詳述）。

関連: SAML SL1 Profile の最初の試案 — PR #65 ​

3/27 に Matt Topper (UberEther) が openid/ipsie 親リポジトリへ PR #65 "Create draft-saml-ipsie-sl1-profile.md" を提出。本文の説明は短く、Initial cut from Aaron's OpenID Connect SL1 profile with a more explicit approach and mapping to the upcoming 800-63 Rev 4 verbiage. Definitely not complete, but at least something to start from. とあるとおり、Aaron の OIDC SL1 をベースに NIST SP 800-63 Rev 4 の文言 へマッピングする初版である。3 月内ではマージされず、open のまま 4 月以降の SAML 議論の参照点として残った。

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

IPSIE WG の定例コールは毎週火曜 9:00 PT。3 月は 3/4, 3/11, 3/25 の 3 回開催（3/18 は IETF 122 と重複のためスキップ）。議事録は github.com/openid/ipsie/wiki 配下の各日付ページに記録されているが、3 月時点ではこれと並行して 議事録の本文を ML にも転載する運用 が採られており、ML 投稿から各コールの論点を再構成できる。

3/4 コール — SL1/IL1 への絞り込みと年末 interop ゴールの設定 ​

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

主要議題と決定事項:

  • 最初のプロトコル作業を SL1 / IL1 に絞る: 全レベルに同時着手するのではなく、まず最低レベル（SL1 = SSO、IL1 = ライフサイクル管理の最低限）に集中して仕様化を進める方針を確認
  • 公開プロセスの所要期間の共有: WG last call から最終承認までは「voting と OIDF レビュー期間を含めておよそ 10 週間」かかるとの目安を共有。年末 12 月の Gartner IAM Summit (12 月開催) を interop デモのターゲット に据え、そこから逆算してドラフト公開時期を見積もる
  • shared signals を「imperative command」と扱うか「informational notification」と扱うかの議論: ある参加者が「OpenID Back Channel Logout は SecEvent を imperative command として用いている」と先例を提示。この論点は後に Issue #66 (SSF Events as Directives?) として 3/28 に正式起票される
  • 次回以降の作業分担: Aaron が OIDC SL1 ドラフトの起草を引き受け（→ 3/7 に実現）、Pam が SAML SL1 ドラフトの起草を引き受ける（後者は最終的に 3/27 Matt Topper の PR #65 として実現）
  • 3/18 コールは IETF 122 (Bangkok) のためキャンセル

3/11 コール — Editor's Draft レビューと OIDC SL1 の脅威モデル ​

3/11 付 ML 投稿 で Dean H. Saxe が議事録を公開（16 名参加、Apple・Okta・Cisco・Yubico・Workday 等が代表的に参加）。

Dean は冒頭で 「3/18 はバンコクの IETF 122 のためコールなし。期間中は非同期での協調を推奨」 とアナウンス。レビュー対象として以下の 3 リソースが共有された:

  • OpenID SL1 Editor's Draft: https://drafts.aaronpk.com/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html
  • SL1 ラベル付き GitHub issues: https://github.com/openid/ipsie/labels/sl1
  • OpenID Slack 招待リンク（招待 URL 公開、WG のリアルタイム議論用）

主要議論:

  • 「SL1 は最強のセキュリティ基盤（FAPI2）を要求すべきか、より参入しやすい public client フローを許すべきか」（Karl McGuinness）。Karl は SAML の世界では事実上 public client であることを引き合いに、SL1 で confidential client を必須化することへの懸念を提起
  • Filip Skokan の反論: 「FAPI では attacker model が要件を駆動している。SL1 でアクセストークンを発行しないのであれば、public client は SL1 の脅威モデルとして整合するのか」を問い、要件の根拠を脅威モデルから組み立てるべきと指摘

この議論は同日のうちに Issue #61 (Confidential Client を MUST にするか) のコメント欄で書面化され、3 月後半の SL1 設計の中核論点となっていく。

3/25 コール — SL1 の方向性が「public client + AT は UserInfo 限定」に集約 ​

3/28 付 ML 投稿 で Dean H. Saxe が議事録を公開（17 名参加、Okta・Workday・Zscaler・GitLab 等）。本月最大の意思決定の場となった。

Dean は事前に 3/25 22:43 UTC のアジェンダ投稿 で議題を共有していた:

  • 反トラスト方針・コントリビューター契約のリマインド
  • Slack コミュニティの案内
  • スケジュール更新（4/8 はキャンセル）
  • IETF SCIM WG での「IL1」プロファイル提案の状況共有
  • OpenID SL1 仕様の未解決 5 項目（tenancy / session lifetime / confidential client / access token / PAR）のレビュー
  • SAML SL1 の議論
  • AOB

コール本体での主要決定:

  • 「SL1 では IdP は public client を MUST support」で集約: 3/11 から続いた論点が、Issue #61 のコメント蓄積と本コールでの議論を経て方向性合意に至った。同時に「confidential client を要求するのは SL2 以上」「access token は SL1 では限定的扱い（UserInfo 取得のみ）」と整理された
  • SCIM IL1 と IETF SCIM WG との関係整理: Dean が SCIM WG への IPSIE 紹介メール（後述）を ML 経由でフォワード共有し、IPSIE WG として「既存仕様のホームがある場合は新規仕様を作らない」原則を再確認
  • OIDC のセッションライフタイム伝達は AB/Connect に移管: Issue #60 (SessionNotOnOrAfter 相当のクレーム) について、Aaron が「IPSIE 内でポリシー判断を行うのではなく、IdP と RP の間でポリシー実行を可能にすることに留めるべき」と整理。Issue #62 (テナンシー) と合わせて AB/Connect WG での OIDC Enterprise Extensions 提案として進める方針が固まり、Dick Hardt が引き受ける
  • 「directives」議論の整理: Issue #60 を一旦クローズし、「IdP から RP への directives」をより一般的に扱う新規 issue を立てることで合意（→ 3/28 に Dean が Issue #66 "SSF Events as Directives?" として起票）
  • 4/8 コールは IIW 40 と重なるためキャンセル

議事録要約（議事録 2025-03-25 より）: SL1 プロファイルが confidential client / access token の要否について 5 つの未解決項目を抱える状態から、「IdP MUST support public client、AT は SL2 以上、SCIM 統合と SAML SL1 は並行で検討」という方向性合意に到達。デプロイ容易性とセキュリティ要件のバランスを取った判断であり、4 月の Call for Adoption に向けた素地が整った

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

openid-specs-ipsie メーリングリストは pipermail の週次インデックス方式（親アーカイブ）。3 月の投稿は議事録通知・アジェンダ投稿・週次 GitHub digest が大半を占め、議論は同期コールと GitHub Issue 上で展開される運用が確立している。技術的に独立したスレッドは多くないが、以下のスレッドが本月の活動を理解する上で中心的である。

4.1 Initial draft of OpenID Connect IPSIE SL1 Profile — 2025-03-07 20:28 UTC ​

  • 発端: Aaron Parecki (Okta) が、aaronpk/ipsie-openid-sl1 への初版投入を ML へ周知。同投稿は IPR プロセスに従って HTML 添付（仕様本体）と Foundation 提出を兼ねる
  • 内容: ドラフト構成が FAPI ライクであること、SL1 要件のうち ID トークン関連が反映されていること、未解決 2 項目（PAR / SessionNotOnOrAfter 相当のクレーム）を明示
  • 意義: IPSIE WG として初めての「実体ある OIDC プロファイルドラフト」が公開された瞬間。これ以降、ML・コール・GitHub のすべての議論が本ドラフトを基準点として進行する

4.2 IPSIE WG Meeting Minutes (2/25 議事録、3/3 投稿) — 2025-03-03 21:12 UTC ​

  • 発端: Aaron Parecki が、OSW 出席のため公開が遅れた 2/25 コール議事録を ML へ転載
  • 内容: SL1/SL2/SL3 と IL1/IL2/IL3 のレベル定義の初期合意、Identity Lifecycle からの JIT プロビジョニング除外（「IL は user/group/role の CRUD に集中」）の決定が記載
  • 意義: 本月の SL1 起草作業が立脚するレベル枠組みを ML 上で公式化した投稿。Travis Tripp の Provisioning in the background can take longer than the timeline for a user to SSO into a system, creating a race condition という発言が JIT 除外の根拠として明示的に記録されている

4.3 2025-03-04 Meeting Minutes — 2025-03-06 投稿 ​

  • 発端: Aaron Parecki が 3/4 コール議事録を投稿（17 名参加）
  • 内容: SL1/IL1 への集中、年末 Gartner IAM での interop ゴール、shared signals の imperative/informational 議論、Aaron と Pam の起草分担
  • 意義: 「年末 12 月 interop」というスケジュールアンカーが ML 上で明文化された最初のスレッド。以降の WG 全体の逆算スケジュールはここを起点としている

4.4 IPSIE Meeting Notes - March 11, 2025 — 2025-03-11 21:47 UTC ​

  • 発端: Dean H. Saxe が 3/11 コール議事録を投稿
  • 内容: 3/18 IETF 122 によるスキップ告知、Editor's Draft レビュー、Karl と Filip の confidential client / 脅威モデル議論
  • 意義: SL1 設計を「FAPI ベース」か「より緩い public client 許容」かに分岐させる論点が ML 上で初めて議事録化された

4.5 Fwd: OpenID Foundation IPSIE WG (SCIM WG へのフォワード) — 2025-03-25 02:57 UTC ​

  • 発端: Dean H. Saxe が IETF SCIM WG に対して送付した IPSIE 紹介メールを openid-specs-ipsie ML にフォワード共有
  • 内容: IPSIE WG は「自然なホームが既にある仕様の新規作成・更新は行わない」原則を強調。SCIM プロファイルは SCIM WG と協調する意図を表明。IPSIE Levels ドキュメントへのリンク、Charter、Contribution Agreement、OpenID Calendar への参照
  • 意義: IPSIE WG が自身のスコープ境界を外部 SDO へ明示的に通知した最初の公式コミュニケーション。同じく 4 月以降の AB/Connect WG への持ち込み（Issue #60, #62）の原則も、ここで述べられた「既存ホームのある仕様はそこで進める」方針の延長線上にある

4.6 Agenda for March 25 — 2025-03-25 02:43 UTC ​

  • 発端: Dean H. Saxe が 3/25 コールのアジェンダを事前共有
  • 内容: SL1 仕様の未解決 5 項目（tenancy / session lifetime / confidential client / access token / PAR）をレビュー対象として明示。SL1 ラベル付き Issue #59〜#63 へのリンクを列挙
  • 意義: 「SL1 の未解決 5 項目」というフレーミングが ML 上で明示された投稿。この 5 項目は 3/25 コールでの方向性合意 → 4 月の Call for Adoption へと一気に解消されていく

4.7 週次 GitHub digest ​

openid-activity at aaronpk.com Bot が日曜配信する自動 digest が 4 本（3/2, 3/9, 3/16, 3/23, 3/30）配信。本月の起票・コメント活動が時系列で記録されている

5. GitHub 上の議論 ​

openid/ipsie 親リポジトリで 3/1〜3/31 に起票された新規 issue は 9 件（#56, #58, #59, #60, #61, #62, #63, #64, #66）、PR は 3 件（#55 マージ済 / #57 オープン / #65 オープン）。コメント密度の高い 5 件を以下に詳述する。

openid/ipsie#59 — SL2 - to PAR or not to PAR? ​

  • 起票: 2025-03-07（aaronpk、SL1 Editor's Draft 初版投入と同時）
  • 問題提起: FAPI は baseline で PAR を必須化しているが、IPSIE が同じ要件を採るかは未確定。エンタープライズ SSO 実装での PAR 採用は限定的
  • 主要参加者の主張:
    • Karl McGuinness (3/7): 「FAPI は RAR 等で authz request にパラメータを渡す強い必要があるが、IPSIE が同じ立場かは不明。enterprise SSO で PAR は今は使われていない。脅威モデルを精査するまで PAR 必須化は遅らせるべき」
    • Joseph Heenan (jogu, FAPI 編集者) (3/10): 「もし PAR を必須化すれば、IPSIE SL1 は実質的に FAPI2 + private_key_jwt + DPoP + 少しの追加要件 のプロファイルに見える。FAPI2 のサポートが棚から既にあるベンダーが多く、formal analysis 済み、複数のエコシステムが FAPI2 採択を表明している。PAR は authz request の改ざんを防ぐ単純な仕様で、divergence するコストは high」
    • Karl (3/10): 「#61 (Confidential Client) と密接に関連する。SL1 で confidential client + private_key_jwt + DPoP を要求するなら FAPI2 を再利用するのが筋。逆に SSO 専用（追加 scope なし）に絞るなら新規プロファイルが必要で、その場合は formal analysis を別途行う必要がある」
    • Brock Allen (Duende, 3/10): 「ASP.NET OIDC client が PAR をサポートしている（Duende が PR を出した）。PAR は PKCE と同じくらい一般化していく」
    • Maciej Machulak (Macke) (3/10): 「『誰も PAR をサポートしていない』を前提に議論するのは雑。Directly Supports / Customizable / Near-term roadmap / Long-term roadmap / No plan、の 5 段階で実際の vendor サポート状況を定量化すべき」
  • 状態: 3 月内には結論に至らず open。後の 4/1 コールで「SL1 では PAR を要求する明確な理由がない」として SL2 以降に持ち越しが確定する

openid/ipsie#60 — SL1 - how to let IdP dictate RP session lifetime in OpenID Connect ​

  • 起票: 2025-03-07（aaronpk）
  • 問題提起: SAML の SessionNotOnOrAfter 属性に相当する仕組みが OIDC には存在しない。IdP が RP のセッション上限を伝達する方法を IPSIE 拡張として定義するか、AB/Connect WG で扱うべきか
  • 主要参加者の主張:
    • Karl McGuinness (3/7): max session lifetime に留まらず、より一般的な policy directive (idle vs max lifetime / transient vs persistent / online-only vs offline / device-bound 要求 / MFA TTL 等) が必要になるかもしれない。一般化するなら AB WG で extension として扱うのが筋
    • Dick Hardt (3/10): 「IPSIE は最大セッション寿命を規定するのか？」と本質的問いを投げかけ
    • Aaron Parecki (3/10): 「IPSIE 内でポリシー判断を行うのではなく、IdP と RP の間でポリシー実行を可能にすることに留めるべき」 と原則を明示
    • Dean H. Saxe (3/11): 「directives は richer な集合になりうる。AB に居場所があるか議論したい」
    • Dean (3/25): 3/25 コールにかけて、本 issue をクローズして directive を扱う新規 issue を立てることを提案
    • Dick Hardt (3/27): 「コール議論に従い、#62 (テナンシー) と同じワークストリームに統合する」
  • 意義: 「IPSIE は WHO が WHAT をすべきかをポリシー的に規定するのではなく、IdP/RP 間のポリシー実行メカニズムだけを定義する」という設計原則が Aaron の発言として明確化された。これは以降の IPSIE 仕様全体に通底する原則となる

openid/ipsie#61 — SL1 - Is Confidential Client a MUST in OpenID Connect IPSIE SL1 Profile? ​

  • 起票: 2025-03-07（mcguinness）
  • 問題提起: Aaron の初版は FAPI に倣って confidential client を要求。しかし多くのエンタープライズ SSO は ID トークンのクレームだけを使い、アクセストークン (UserInfo) や refresh token を必要としない。PKCE + HTTPS リダイレクト + 登録済オリジン + DNS/PKI といった緩和条件で public client を許容できないか
  • 主要参加者の主張:
    • Aaron Parecki (3/7): 「public client を許容する主な懸念は、enterprise SSO で 同意画面がないため、credentials なしだと app impersonation が見えない形で発生しうること。public client 許容のセキュリティ properties 喪失を thorough に分析したい。OSW での議論からも、こうした問題は最初の見た目ほど単純ではないと学んでいる」
    • Aaron (3/7): Okta Integration Network が public client を一切許容しない事実を data point として共有
    • Karl McGuinness (3/7): 「SAML SSO というエンタープライズの ゴールドスタンダード は事実上 public client。+1 で thorough な分析を支持するが、SAML にない overhead を追加するなら良い根拠が必要」
    • Aaron (3/7): 「OIN のケースは RP が Okta API への access token も必要としていたから。ISV は custom OIDC 登録も使える」「相互運用の観点では、IPSIE OIDC client は 常に credentials を持つか、まったく持たないか のどちらかにすべき。app が IdP ごとに credentials の要否を調べる必要がある状況は避けたい」
    • Karl (3/7): 「level ごとに必須要件を変えるのはあり得る。SL1 から SL2 に上がる際に credentials 管理が追加される設計は、WG コール向きのトピック」
  • 状態: 3/25 コールで「SL1 では IdP は public client を MUST support」の方向性合意に到達。3/28 に Dean が「confidential client は SL1 では required ではないという合意に近づいている」とコメントし、4/28 に正式クローズ
  • 意義: 本月の SL1 設計を方向付けた最重要 issue。Aaron の「all or nothing」の相互運用原則（IdP ごとに credentials 要件が異なる状況を許さない）は IPSIE の interop 哲学を象徴する発言

openid/ipsie#63 — SL1 - are access tokens part of SL1? ​

  • 起票: 2025-03-11（dickhardt、3/11 コール直後）
  • 問題提起: SL1 でアクセストークンを発行する必要があるか。実質的に UserInfo 呼び出しの一度きりにしか使われない
  • 主要参加者の主張:
    • Dick Hardt (3/12): 「一晩考えた結論として、SL1 にアクセストークンは含めるべきでない」
    • Brock Allen (3/13): 「『含めない』とは、まったく禁止するのか、必須にしないのか。implicit grant のみ使うという意味か？」
    • Dick (3/13): 「implicit は禁止、authorization_code のみ。OIDC は OAuth 2.0 上に成立しており、OAuth 2.0 は token endpoint からの成功応答に access_token を要求するため、access_token が MUST と誤解されてきた。IPSIE は UserInfo を非サポートとし access_token を返さないと規定するのが理想だが、breaking change なので、IPSIE は access_token に対して silent、ID トークンが返ること、RP はユーザ識別に ID トークンのみを使うこと、を要求する妥協案でも良い」
    • Karl McGuinness (3/13): 「+1 で authorization_code + PKCE （OAuth 2.1 / Security BCP ベース）を SL1 唯一のフローとする。offline_access 非サポート（refresh token なし）、scope は openid 必須 + profile/email/address/phone のみ。UserInfo の access_token 寿命は ID トークンと同じに束ねる。これによりバックチャネルでクレーム取得は可能だが、AT が SSO 範囲外で使われない」
    • Brock Allen (3/13): 「scope は『その 5 個だけ』か『最低限その 5 個』か？ enterprise では custom scope の利用が多い」
    • Karl (3/13): 「vendor 固有 scope で UserInfo 外の保護リソースを要求し始めた瞬間に FAPI2 のように見えてくる。これが #59 #61 の議論」
    • Dick (3/13): 「Karl の提案に整合する。5 分は AT/ID トークンとして長い。code と同じく 60 秒にしては？ identity 関連 scope は許容、access 用途の scope は不可」
    • Brock Allen (3/13): 「resource server endpoint ではなく、claim を ID トークン/UserInfo に追加リクエストする目的の custom scope についての話。+1」
    • Karl (3/13): 「identity 関連 scope なら問題ない。UserInfo の境界線をどこに引くかが論点」
    • Dean (3/24): 「合意形成中だが、Aaron の初版 SL1 ドラフトに対する PR を誰か書いてくれないか」
    • Dean (3/28): 「3/25 コールに従い、confidential client は SL1 では不要、access token も SL1 では利用しない という合意に近づいている」
  • 状態: 4/28 にクローズ。Karl の「UserInfo の AT 寿命を ID トークンと束ねる」提案は draft-00 の構造（AT は存在するが UserInfo 専用に用途限定）の原型となる
  • 意義: 3 月の SL1 設計を最も具体的に詰めた issue。8 件のコメントで「authorization_code + PKCE、refresh token なし、scope は identity 関連のみ、AT は UserInfo 専用」という SL1 の輪郭が決定的に形成された

openid/ipsie#62 — SL1 - tenancy in third-party initiated login ​

  • 起票: 2025-03-10（dickhardt）
  • 問題提起: Multi-tenant OP は非標準の domain_hint パラメータでテナント指定するのが一般的。Third-party initiated login と authorization request の両方でこれを標準化するべき。Multi-tenant client が tenant ごとに別 client_id を持つ場合、client_id パラメータも third-party initiated login に追加すべき
  • 主要参加者の主張:
    • Dean H. Saxe (3/11): 「3/11 コールに従い、この作業は Connect WG に移すべき」
    • Dick Hardt (3/11): コール後の補足。domain_hint / client_id パラメータの仕様化、および OpenID Provider Commands draft に既存の tenant クレーム・session_lifetime も同じドキュメントに含める可能性
    • Dean (3/12): 「AB Connect WG への移管合意を受けてクローズする」「AB Connect WG ML 上のスレッド: openid-specs-ab 2025-March/010661」（Mike Jones、Nat Sakimura、Brian Campbell に CC）
    • Dick Hardt (3/12): 「クローズすると追跡しにくい。Connect 側で作業開始するまで open のままにしては？」
    • Dean (3/24): 「Dick の要望に応じて reopen し、Dick をアサインして AB Connect 側の進捗を追跡してもらう」
    • Dick Hardt (3/27): 「#60 も同じワークストリームに linking」
  • 意義: IPSIE WG が自身のスコープ境界を運用面でも明示し、関連仕様の議論を他 WG にプッシュする手続きを初めて実行した事例。クローズ → reopen のやり取りは、IPSIE 内に「追跡用 issue」を残す運用判断として注目に値する

補足: 3 月中に起票・議論された他の issue ​

  • openid/ipsie#56 — SL3 and optional processing of shared state (gffletch, 3/4): SL2 のステップアップ認証は session を baseline に戻す手段が必要。session-downgrade event を仕様化すべき
  • openid/ipsie#58 — SL3 and requiring state changes from App to IdP (mcguinness, 3/6): SL3 で RP が user/session/device state 変化を IdP に通知する要件は曖昧。特に device state は browser-based SSO では識別子が流れず、interoperable な device ID は managed device 限定で identity protocol スコープ外
  • openid/ipsie#64 — SL1 - Draft Feedback (2MarkMaguire, 3/17): (1) ID トークンクレームを IdP 側に MUST で要求しているが RP の検証義務が抜けている、(2) DNSSEC は MUST だが普及率を考えると採用阻害要因にならないか。Dean は 3/24 に「DNSSEC は SHOULD で書かれているので据え置き。ID トークン検証要件は確かに足りていない、追加方向で」と応答
  • openid/ipsie#66 — SSF Events as Directives? (dhs-BI, 3/28): #60 の議論を受けて起票。SSF (Shared Signals Framework) 経由のイベントを directive として扱う構成を提案。@tulshi (3/30) と @iamseanodentity (Sean、3/30) が好意的反応、Sean は「action receipts」という未公開の議論概念を共有。@FragLegs (3/31) は具体的な JWT 構造案として actions フィールドを events と並列に置く案を提示

PR の状況 ​

  • #55 updates for consistency (aaronpk, 3/3 起票・即マージ): 2/25 コール合意の ipsie-levels.md 反映
  • #57 remove MFA as a requirement (frumioj, 3/5): 「Multi-factor は 2 因子超を含意し、phishing 耐性とは別概念」。Dean (3/5) は「アイデアには賛成だが、PR としては phishing 耐性方法すべてが MFA なわけでもなく、MFA すべてが phishing 耐性なわけでもない。一貫した用語整理が必要で、single knowledge factor より良いもの を prescribe する方向にすべき」と応答し、3 月内マージなし
  • #65 Create draft-saml-ipsie-sl1-profile.md (topperge, 3/27): Aaron の OIDC SL1 をベースに NIST SP 800-63 Rev 4 にマッピングした SAML SL1 初版。3 月内マージなし、4 月以降の SAML 議論の参照点として残存

6. 関連イベント ​

3/5 IDSA 主催ウェビナー「Securing the Future of Identity with IPSIE – A New Industry Standard」 ​

3 月最大の対外イベント。Identity Defined Security Alliance (IDSA) 主催で IPSIE WG を業界に紹介するオンライン webinar が 3/5 (9:00 PT / 12:00 ET) に開催された。OpenID Foundation のアナウンス記事 Webinar about IPSIE secures more than 300 registrations（3/7 公開）は、登録者が 300 名超 に達したことを伝えており、IPSIE が業界の高い関心を集めていることを示している。

パネリスト:

  • Jeff Reich (Executive Director, IDSA)
  • Dean H. Saxe (Principal Engineer, Office of the CTO, Beyond Identity)
  • Aaron Parecki (Director of Identity Standards, Okta)
  • Gail Hodges (Executive Director, OpenID Foundation)
  • George Fletcher (Identity Standards Architect, OpenID Foundation)

録画は BrightTalk でオンデマンド公開された。

ウェビナーのアブストラクトでは、断片化したエンタープライズ ID セキュリティの現状と、IPSIE が「technology stack 全体の可視性」を提供することで SaaS ベンダーとエンタープライズの双方にとっての統一基準となることが訴求されている。SaaS ベンダーとエンタープライズの双方に「IPSIE 形成に参加してほしい」と呼びかける位置付け。

IETF 122 (Bangkok, 3/15〜3/21) ​

直接 IPSIE WG セッションが設定されたわけではないが、IPSIE WG 定例コール (3/18) はこのイベントとの重複を理由にスキップされた（3/4 コール議事録および 3/11 ML 投稿で告知）。IETF 122 の SCIM WG では「IL1」プロファイルの議論動向が共有され、IPSIE 側からは 3/25 コールで状況がレビューされた。Dean は 3/25 にこれを受けて IETF SCIM WG への IPSIE 紹介メール（§4.5）をフォワード共有している。

Slack コミュニティの開設・案内強化 ​

3/11 と 3/25 の両方で、Dean が https://join.slack.com/t/oidf/shared_invite/zt-30zg9louv-3HgJEwIL7vB3uWv2KEbLtw 経由の OpenID Slack 招待リンクを ML 上で繰り返し案内している。これにより 3 月後半には Issue #66 のコメントでも Dean が「Slack 上の議論を要約」(https://oidf.slack.com/archives/C02Q0762E83/p1743199121972539) として GitHub に転載する運用が始まり、IPSIE WG の議論チャネルが「定例コール + GitHub + Slack」の 3 本柱に拡大 している。

7. 今後の予定 ​

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

  • 4/1 コール — SL1 ドラフトの最終詰めと Call for Adoption 投入: 3/25 コールでの方向性合意（public client / AT は UserInfo 限定 / PAR を SL1 から外す）を draft に反映後、Call for Adoption へ
  • 4/8 コールはスキップ: IIW 40 (Computer History Museum, Mountain View, 4/8〜10) と重なるため。3/25 コールで決定済
  • OpenID Connect SL1 Profile の Call for Adoption: 4 月初旬に Dean が ML 上で開始する予定。2 週間の Call で WG 公式 draft への昇格を狙う
  • SAML SL1 (PR #65) のレビュー継続: Matt Topper による SAML 初版を起点に、SAML 側でも SL1 同等のセキュリティアウトカムを達成する道筋を 4 月以降に議論
  • Issue #60 / #62 の AB/Connect WG への持ち込み: Dick Hardt が OIDC Enterprise Extensions として AB Connect 側で extension 提案を進める。openid-specs-ab ML スレッド (2025-March/010661) を起点に作業継続
  • Issue #66 (SSF Events as Directives) の議論深化: SSF 派生として directive 設計を進める。action receipts 概念を含む議論が Slack でも進行中
  • 年末 Gartner IAM での interop デモ: 3/4 コールで再確認された年末ゴール。4 月以降は逆算スケジュールに沿って SL1・IL1 のドラフト固めへ
  • IETF SCIM WG との連携: Dean が IETF SCIM WG に紹介済み。SCIM プロファイル領域では SCIM WG をホームとし、IPSIE は profile 層を担当する役割分担

8. 参考情報源 ​

OpenID Foundation 公式 ​

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

GitHub ​

GitHub Wiki 議事録 ​

議事録補助リソース ​

関連外部 ​