Skip to content

OpenID Foundation AB/Connect WG 活動レポート (2024年11月)

執筆日: 2026-05-19(2024 年 11 月の活動を遡及してまとめたレポートです)

1. 概要

AB/Connect Working Group(AB/Connect WG)は、OpenID Connect 仕様群および OpenID Federation 系仕様を策定する OpenID Foundation 最古参の WG である。2024 年 11 月時点の共同議長は Michael B. Jones、Nat Sakimura、John Bradley の 3 名。議事録は ML 公開アーカイブには独立した HTML としては残らず、議事録担当者が Draft Meeting Notes を ML に投稿する運用が定着している。

2024 年 11 月は IETF 121(Dublin、11 月 2 〜 8 日)の影響でコール本数こそ少なかったものの、**OpenID Federation 周辺の GitHub 議論が一気に活性化した「Federation コミュニティ拡大の月」**となった。具体的な動きは以下のとおりである。

  • 月初(10 月 24 日)に OpenID Federation 1.0 draft 40(Fourth Implementer's Draft 候補相当の更新)が公開された直後の月であり、本月内に GitHub 上で openid/federation リポジトリへの Issue/PR が爆発的に増加した。新規 Issue は #130 〜 #149、新規 PR マージは 16 件と、本 WG の GitHub 活動としては 2024 年内で最も活発な月のひとつとなった
  • 11 月 30 日に AB/Connect WG が 3 つの新規仕様を採択: OpenID Federation Extended Subordinate Listing、OpenID Federation Wallet Architectures、OpenID Connect Relying Party Metadata Choices。Mike Jones は 11 月 30 日付の self-issued.info 投稿でこれを公表し、新規 active contributor として Michael Fraser と Łukasz Jaromin を明示的にクレジットした(Giuseppe De Marco は「emerged as a leader in the space」として継続貢献者と位置付けて言及)
  • OpenID Connect Relying Party Metadata Choices 1.0 draft 01 が 11 月 25 日に公開され、Filip Skokan・Joseph Heenan からのフィードバックを反映して「multi-valued パラメータは request 専用、response では用いない」点を明文化した
  • OpenID4VP 3rd Implementer's Draft のパブリックレビューが 11 月 1 日に開始(45 日間、12 月 16 日まで)。Digital Credentials Query Language の導入、transaction data メカニズム、client_id_scheme の prefix 方式への置換等を含む大型更新であり、AB/Connect WG コールでも継続的な議題となった
  • AuthZEN Authorization API 1.0 Implementer's Draft が 11 月 7 〜 14 日の投票で承認(賛成 82 / 反対 2 / 棄権 22、11 月 15 日公表)。AB/Connect WG 直接の成果物ではないが、関連 ML での周知が継続された
  • Native SSO for Mobile Apps では「ID Token 依存を縮小すべきか」「authorize endpoint は本当に必要か」という根本的な設計論が ML 上で噴出。George Fletcher、Vladimir Dzhuvinov、Brian Campbell、Brock Allen が連続投稿で論戦を展開し、翌 12 月の PR #744(draft 7 への土台)につながる議論が形成された

ML 投稿は 010498010514 の 17 通と Connect WG としては静かだが、その内訳は **「Federation 採択告知 + Native SSO 設計論 + OpenID4VP 投票呼びかけ」**に集中している。なお 2024 年 11 月時点では、OpenID Provider Commands はまだ AB/Connect WG への寄稿として提示されておらず(提示は 2025 年 1 月 15 日)、Federation 1.1 / Federation for OpenID Connect 1.1 への分割路線(2026 年)も当然まだ着手前である。前月 10 月 29 〜 31 日に開催された IIW 39(Mountain View、Computer History Museum) での議論を背景として、Federation Wallet 周辺の関心が WG 内部で高まりつつあるタイミングでもあった。

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

OpenID Connect Relying Party Metadata Choices 1.0 - draft 01 公開(11 月 25 日)

Michael Jones が 11 月 25 日 01:48 UTC(ML #010506)で draft 01 の公開を告知。前版(draft 00、10 月公開)からの主要な変更点は次のとおり。

  • multi-valued パラメータの適用範囲を明確化: registration request parameter としてのみ使用し、registration response parameter としては使用しない旨を明文化(Joseph Heenan、Filip Skokan からのフィードバックを反映)

本仕様は OpenID Connect Dynamic Client Registration 1.0 の拡張として、RP が metadata parameter に対して「単一値ではなく許容値集合」を申告できるようにするもの。OpenID Federation の Automatic Registration では「OP からの登録レスポンスを介して OP の選択を RP に伝える」経路が存在しないため、RP 側が許容値集合を予め申告しておく仕組みが特に重要となる。Michael Jones は 11 月 21 日付(ML #010504)で関連 PR の存在を通知しており、本投稿はそのレビューを経たマージ後の正式 publish 告知である。

GitHub 側では openid/rp-metadata-choices リポジトリの PR #1 として 11 月 20 日に「Multi-valued parameters are for requests and not responses」がマージされている。

OpenID4VP 3rd Implementer's Draft パブリックレビュー開始(11 月 1 日)

OpenID Foundation の公的告知 として 11 月 1 日に発出。45 日間(〜 12 月 16 日)のパブリックレビュー期間が設定された。本版の主な更新点:

  • Digital Credentials Query Language の導入: 既存の Presentation Exchange に代わる選択肢として
  • transaction data メカニズムの新設: ユーザー認証と authorization の binding を実現
  • client_id_scheme パラメータの廃止と prefix 方式への置換: client identifier scheme の安全性向上のため

仕様自体は DCP WG 所管だが、Implementer's Draft の投票運用および ML 周知は引き続き AB/Connect 側で行われている。レビュー期間中の 12 月 2 日付で draft 23 が editorial フィードバックを反映して公開され、12 月 17 〜 24 日の正式投票・12 月 24 日承認(Approve 91 / Object 3 / Abstain 19)へと進む。

OpenID Federation 1.0 - 月内の規範改訂は本体 publish なし、GitHub での PR 大量マージ

OpenID Federation 1.0 本体の新規ドラフト publish(draft 40 → 41)は本月内には行われず、翌 12 月 4 日の draft 41 公開を待つ。ただし openid/federation GitHub リポジトリでは月内に 16 件の PR がマージされており、これらが翌月の draft 41 の本体となる。主要な月内マージ PR は §5 で詳述するが、概観としては次の領域を整理する月であった。

  • Trust Anchor / Trust Chain 周辺の用語整理(PR #131 起因の議論、後の draft 41 PR #154 起点となる議論を本月内に形成)
  • Trust Mark validation のドキュメント拡充(PR #125、Issue #153 への対応)
  • Federation Entity Keys と metadata の関係の明文化(PR #141、Issue #140 への対応)
  • Request Object 使用の説明明確化(PR #142、Issue #139 への対応)
  • Error codes の追加・整理(PR #145、Issue #136 への対応)

AuthZEN Authorization API 1.0 Implementer's Draft 承認(11 月 7 〜 14 日投票、11 月 15 日公表)

AuthZEN WG 主管の Authorization API 1.0 Implementer's Draft が、AB/Connect 外の成果物として 11 月 15 日に 承認公表された。投票結果は Approve 82 / Object 2 / Abstain 22(投票総数 106、391 名中 27%)。AB/Connect WG コール内で個別議題となった記録は確認できないが、Implementer's Draft の投票運用フローを WG 横断的に共有している事務局アナウンスの一環として把握される。

3. ミーティングと議論

AB/Connect WG は当時、毎週月曜の Atlantic Spec Call と隔週火曜の Pacific コールを基本運用としていた(12 月 16 日からの新運用刷新は翌月の動き)。11 月は IETF 121 の影響で Pacific 側が冒頭から中止となり、Atlantic 側の 11 月 18 日・25 日の 2 回が中核となった。

開催日種別状態議事録/告知
11 月 5 日(火)Pacific コール中止(IETF 121 のため)ML #010498(Nat Sakimura、2024-11-04)
11 月 18 日(月)Atlantic Spec Call開催議事録 ML #010499(Michael Jones 投稿、2024-11-19)
11 月 25 日(月)Atlantic Spec Call開催議事録 ML #010505(Michael Jones 投稿、2024-11-26)

11 月 18 日 Atlantic Spec Call

参加者は議事録に列挙されている 7 名: George Fletcher、Nat Sakimura、Mike Jones、Brian Campbell、David Waite、Tom Jones、Aaron Parecki(議事録 ML #010499)。

主要議題:

  • Native SSO for Mobile Apps の方向性議論: PR レビューを通じて、open issues 8 件のうち 3 件が PR で解消される見込みであることが確認された。Brian Campbell が「Native SSO を best practice として推進することに対する懸念」を改めて提起したのに対し、Mike Jones は **「Okta、Yahoo、Vladimir(Connect2id)が既に実装している」**と既存実装の存在を強調。George Fletcher も「ドキュメント化に価値がある」と支持し、publish することで追加の実装要望が出てくる可能性も議論された
  • モバイル系の追加作業: MODRNA WG の現状活動が不明な中、追加のモバイル関連イニシアチブの可能性が話題に挙がったが結論には至らず
  • GitHub リポジトリ運用: WG 配下の GitHub リポジトリが 4 つになったことを確認。federation-wallet リポジトリには open issues が 14 件あり、Mike Jones が Issue #39(「Authorized Credential within OpenID4VP metadata using Duckle」)のレビューを担当することに。Nat Sakimura は WG リポジトリ一覧の更新の必要性を指摘
  • OpenID4VP: Foundation 全体での Implementer's Draft レビューが進行中。Tom Jones が「verifiable presentations における user consent」について問題提起。Mike Jones は「actionable なフィードバックにするため formal issue を立てるべき」と応答

11 月 25 日 Atlantic Spec Call

参加者は議事録に列挙されている 5 名: Nat Sakimura、Mike Jones、Aaron Parecki、Tim Cappalli、Tom Jones(議事録 ML #010505)。

主要議題:

  • AI ノートテイカー bot のポリシー: Mike Jones がコール参加申請してきた複数の AI ベースのノートテイキング bot を rejecting したことを報告。「Foundation 全体としての bot 参加ポリシーは存在しない」状態であり、「録画なしの confidential discussion の余地を残すため」拒絶を選択したと説明。Tom Jones は別途、Otter AI bot がカレンダーアクセス権限から自動的にミーティング招待に「参加者」として追加された事案に困惑を示し、「この種の AI 自動参加は近い将来全員にとって本格的な問題になる」と警鐘を鳴らした(ML #010507
  • OpenID Connect RP Metadata Choices: multi-valued パラメータが request 専用であることを確認。Mike Jones がコール後に Filip と Joseph のフィードバックを反映してマージ・publish する予定を表明
  • Native SSO: マージ済み PR 742 が Issues #2167、#2166、#2164 を解消したことを報告。実装者が ID Token state management ではなく device secret を使っているという観測が共有され、George Fletcher が「コミュニティに対してこのアプローチへの input を募る」方針を提示
  • OpenID Federation 関連 PR: 2 件の PR が approve され、マージ間近に: ①「federation entity keys が metadata に現れてはならない」点の明確化(PR #141)、②「Request Object 使用を authorization endpoint と PAR endpoint の両方で説明」(PR #142)。また open issues として「client authentication method discovery の困難」(Issue #147)と「trust chain selection に起因する metadata conflict 処理」(Issue #148)の 2 件が継続議論対象として共有された
  • OpenID4VP consent concern: Tom Jones が「verifiable presentations が holder の informed consent に関する ACM Ethics ガイドラインの最小要件を満たしているか」という問題提起を継続。Mike Jones は引き続き GitHub issue 経由での議論を促した

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

openid-specs-ab ML の 2024 年 11 月アーカイブには 17 通の本体投稿が収録されている。技術討議の中心となった主要スレッドは以下のとおり。

OpenID Connect Working Group Meeting Notes (2024-11-18) - 2024-11-19 投稿(Michael Jones)

11 月 18 日 Atlantic Spec Call の Draft Meeting Notes。Native SSO の publish 是非、federation-wallet リポジトリの状況、OpenID4VP の Implementer's Draft レビュー進捗が記録されている。本スレッドはその後、Vladimir Dzhuvinov(ML #010501、11 月 19 日)、Brian Campbell(ML #010500、11 月 19 日)、George Fletcher(ML #010508、11 月 27 日)、Vladimir Dzhuvinov(ML #010514、11 月 27 日)が連続的に返信を寄せ、当月最大の技術討議スレッドへ発展した。

主要論点:

  • Brian Campbell: 2022 年 9 月の自身の push-back を再掲し、Native SSO を best practice として進めることへの skepticism を改めて表明
  • Vladimir Dzhuvinov(11/19): 「device_secret トークンに ID Token の内容を全て含めれば(さらに追加情報も)、ID Token は冗長になる」と整理。実装者観点での具体的指摘
  • George Fletcher(11/27): 「ID Token への依存を縮小もしくは排除する方向で spec を更新する案」を提示し、implementer 各位の input を募集
  • Vladimir Dzhuvinov(11/27): George の提案を強く支持し、ID Token 排除のメリットを列挙: ①client・IdP の実装簡素化、②client がデバイスキーチェーンに保持するのは不透明な device secret のみで済む、③IdP 側は token 有効期限・audience・hash・pairwise subject の復号・update 時のマッチング等の検証を省略可能、④ID Token を authorization 目的で token endpoint に signed JWT として送信する際、個人情報がサーバーログに残るリスクの回避。「仕様は consistently & conceptually simple、easy to implement、surrounding specs と整合的であるべき」という設計哲学も改めて強調

The OID4VP is not ready for implementation - 2024-11-19 投稿(Tom Jones)

Tom Jones が OpenID4VP の implementation readiness を厳しく批判するスレッド。「The document is not compliant with most existing laws nor with the ACM Ethics document with respect to holder's informed consent」と主張し、詳細は OpenID4VP リポジトリの Issue #333 に記載と誘導。Joseph Heenan(Authlete)が即日返信(ML #010503、11 月 19 日)で「issue を立ててくれて感謝。既にいくつか応答が付いているので、議論は issue で継続しましょう」と GitHub への議論集約を提案。

本論点はその後 11 月 25 日コールでも Tom Jones が再提起しており、OpenID4VP の 3rd Implementer's Draft レビュー期間と並行して継続される consent デザインに関する原則的問題提起となった。

Contributing OpenID Connect Relying Party Metadata Choices 1.0 spec to the working group - 2024-11-21 投稿(Michael Jones)

RP Metadata Choices 1.0 仕様の AB/Connect WG への寄稿確定に関する update。「multi-valued パラメータについてのフィードバックスレッドを反映する PR」の存在を周知。直前の議論で Joseph Heenan が「multi-valued パラメータは request 専用、response 不用」と整理した内容を、正式な仕様改訂として吸収する流れを確認するスレッド。

openid-connect-rp-metadata-choices-1_0-01 - 2024-11-25 投稿(Michael Jones)

draft 01 の公開告知。前述のフィードバック反映が完了したことの宣言。本仕様は当月内に AB/Connect WG が正式に Working Group ドラフトとして採択した 3 仕様のひとつとなり、月末の Mike Jones blog 投稿で全体像が共有される。

Spec Call Notes 25-Nov-24 - 2024-11-26 投稿(Michael Jones)

11 月 25 日 Atlantic Spec Call の Draft Meeting Notes。AI bot rejection、Native SSO の device secret 重視議論、Federation の 2 PR approve、Federation の 2 open issues 共有、Tom Jones による OpenID4VP consent 問題の継続提起が記録される。

Tom Jones の返信(ML #010507、11 月 26 日)は AI ノートテイカー(Otter AI)が自身のカレンダーアクセス権限を悪用してミーティング招待に「参加者」として割り込んだ事例を共有し、「organization 全体で AI 参加問題への意識を持つべき」と警鐘を鳴らす内容。WG 運用上の現実的懸念として記録される。

Is authorize endpoint required in 'SSO for Mobile'? - 2024-11-27 開始(Brock Allen)

George Fletcher の Native SSO 更新提案(ML #010508)を受けて、Brock Allen が新スレッドを立てて深掘りした 5 通の連続スレッド(#010509#010510#010511#010512#010513)。

論点の流れ:

  • Brock Allen(11/27 14:12 UTC): 「spec の価値が token endpoint からの結果にあるなら、authorize endpoint を経由しない代替経路(OAuth 2.0 for First-Party Applications 等)で device_secret を取得し、Native SSO で別 client / 別デバイスへログインできないか」と問題提起
  • George Fletcher(11/27 15:08 UTC): 「device_sso scope を指定すれば、OAuth 2.0 for First-Party Applications で token endpoint から device_secret を返せる」と肯定的に回答。一方「spec が First-Party Applications フレームワークより先行して書かれた経緯があり、early implementer に breaking change が出る可能性」も指摘
  • Brock Allen(11/27 15:49 UTC): 「専用 grant type を新設すれば、汎用 token-exchange との混同を避けられるのではないか」と追加提案
  • George Fletcher(11/27 16:43 UTC): 「専用 grant type を使うと、モバイルアプリが access token・refresh token を取得する同じ呼び出しで device_secret を取得できなくなる(多段呼び出しになる)」と実用面の制約を指摘
  • Brock Allen(11/27 19:52 UTC): 「なぜ別 grant type が access token・refresh token を同時に返せないのか」と再質問

この一連の議論は、George Fletcher が翌 12 月 31 日に提出する PR #744(Native SSO draft 7 の土台)に向けて、grant type 選択・device_secret 取得経路・First-Party Applications との統合という 3 つの設計軸を明確化した重要な前哨戦である。

Canceled event with note: AB/Connect WG (Pacific) @ Tue 2024-11-05 - 2024-11-04 投稿(Nat Sakimura)

Pacific コールの月初中止告知。理由は **「IETF 121 のため」**と明示。IETF 121(11 月 2 〜 8 日、Dublin、Convention Centre Dublin、Cisco ホスト、現地参加 982 名・オンライン参加 501 名)が AB/Connect WG メンバーの多くの旅程と重なっていたことが背景。

5. GitHub 上の議論

2024 年 11 月の AB/Connect 周辺 GitHub 議論は、ほぼ openid/federation リポジトリに集中している。OpenID Connect Core 本体および Native SSO は依然として Bitbucket Issue Tracker(bitbucket.org/openid/connect)で管理されていた。

openid/federation - 月内に起票された主要 Issue(抜粋)

Issueタイトル起票者起票日コメント数状態
#147Client cannot know what client authentication method a server has registered it forjogu2024-11-2124closed
#136Resolve Endpoint Error Responsezachmann2024-11-0810closed
#148Guidance / Strategies on how to deal with conflicting metadata due to trust chain selectionzachmann2024-11-223closed
#131Inconsistent Trust Anchor parameter namesvdzhuvinov2024-11-064closed
#137Resolve Response and subject's federation jwkszachmann2024-11-084closed
#135Proposal to limit leaf entity participation across federationscicnavi2024-11-073closed
#134Proposal for different entity metadata for different trust anchorscicnavi2024-11-073closed
#133Non-viable outcome for metadata check in automatic registrationcicnavi2024-11-073closed
#140metadata.federation_entity.jwks equal to federation entity keys?zachmann2024-11-152closed
#139PAR with the optional trust_chain parameter?vdzhuvinov2024-11-142closed

openid/federation - 月内マージ PR

PRタイトル著者マージ日
#119Describe why and how to not support request_uriselfissued11 月 4 日
#117Restore trust mark status iat query parameterselfissued11 月 4 日
#118Restrict aud values to Entity Identifier of recipientselfissued11 月 4 日
#121Define application/explicit-registration-response+jwt media typeselfissued11 月 4 日
#122Require kid in Signed JWK Set JWTsselfissued11 月 4 日
#124Remove remark about trust mark delegation revocationselfissued11 月 4 日
#125Clarify Trust Mark validationselfissued11 月 6 日
#126Informatively say that two OP metadata parameters can be usedselfissued11 月 6 日
#128Make Seconds Since the Epoch language consistentselfissued11 月 6 日
#141Federation Entity Keys MUST NOT appear in metadataselfissued11 月 26 日
#142Clarify description of using request objectsselfissued11 月 26 日
#144Move Trust Mark issuers and owners into terminologysurfnet-niels11 月 27 日
#146fix: labels in figurepeppelinux11 月 29 日
#145Define additional error codesselfissued11 月 30 日
#149token_endpoint_auth_method with Automatic Registrationselfissued11 月 30 日
#152fix: resolve metadata seq diag missing charpeppelinux11 月 30 日

これらは翌 12 月 4 日の draft 41 本体に取り込まれる editorial・normative 改訂群である。

openid/federation#147 - Client cannot know what client authentication method a server has registered it for

24 コメントを集めた当月最大の議論。jogu(Joseph Heenan)が 11 月 21 日に起票。問題提起の核心は次のとおり。

  • Federation の Automatic Registration では、client・server 双方が複数の client authentication method(private_key_jwtmTLS 等)をサポートする場合、server がどの method で client を登録したかを client 側が知る手段がない
  • 多くの実装では server は登録時に 単一の method を選んで割り当てるのが通例だが、その情報を client にフィードバックする経路がないため、client は 50% の確率で誤った method を token endpoint で使ってしまう
  • 提案: authorization endpoint での Automatic Registration を廃止し、PAR(Pushed Authorization Requests)を必須化する。これにより PAR 段階で authentication method を確立でき、server が確定した method で client を登録できる

11 月中の主要論争(selfissued vs jogu):

  • selfissued(11/27): 「両 method が動作するなら client の選択に依存しないはず。本当に問題なのか?」と疑問提起
  • jogu(11/27): 「server は登録時に単一 method を割り当てるのが通例。明示的な spec 言語か PAR 必須化のいずれかで曖昧性を解消すべき」
  • selfissued(11/28): 「Automatic Registration は persistent な server レコードを必要としない。全 method は client keys に裏付けられているため、選択は重要でないはず」
  • jogu(11/28): 「実装の現実を無視している。spec 言語の明確化か PAR 必須化が必要」

本論点は 12 月以降も継続討議となり、2025 年 9 月 3 日にようやくクローズされる長期 issue となった。最終的に PR #232 で対処されるが、12 月段階では peppelinux・vdzhuvinov・MichaelFraser1999・rohe・SECtim と複数のエディタを巻き込んで「PAR 必須化の是非」「OAuth 全体の問題か Federation 固有の問題か」を巡る論争が続いた。当月時点ではまだ着地点が見えていない状態である。

openid/federation#136 - Resolve Endpoint Error Response

zachmann(Gabriel Zachmann)が 11 月 8 日起票。resolve endpoint がサポートする error response の標準化を提起する内容。「resolver が限定的なフェデレーション範囲で動作するとき、複数の resolver に問い合わせる階層的フェデレーションでは、エラーの区別が運用上重要」と主張。

主な議論の流れ:

  • selfissued(11/8): 「具体的にどんな error condition を signal すべきか提案してほしい」と要請
  • zachmann(11/15): invalid_trust_anchor/invalid_anchor(404)、invalid_sub(404)、invalid_trust_chain(404)、invalid_metadata/metadata_policy_error(400)の 4 種を提案
  • peppelinux(11/15): 「invalid_trust_anchorinvalid_sub は fetch endpoint 用、後者 2 つは resolve response 用と分けるべき」と整理。PR 提出を申し出
  • selfissued(11/19): 既存の missing_trust_anchortrust_chain_validation_failed との重複を指摘。汎用形に置換すべきか問題提起。Section 8.9 と 12.1.3 の error codes を統一する方針を提案
  • zachmann(11/20): 「missing_trust_anchor(chain 解決で anchor が見つからない場合)と invalid_trust_anchor(client が送った anchor が reject された場合)は区別すべき」と整理
  • peppelinux(11/21): 改訂案として trust_chain_validation_failedmetadata_resolution_failedmetadata_not_foundtrust_anchor_unknownsubject_not_found の 5 種を提案
  • selfissued(11/27): PR #145 として two-set の error codes を統合した更新を community レビューに供する

これらの議論が PR #145(11 月 30 日マージ)として一旦着地。

openid/federation#148 - Guidance / Strategies on conflicting metadata due to trust chain selection

zachmann が 11 月 22 日起票。RP と OP が 異なる trust chain を選択した結果、resulting metadata が衝突する場合のガイダンスを求める内容。zachmann の提案は「RP・OP の双方が複数 trust chain を評価すべき。最初の有効な chain で停止せず、衝突発生時に他の chain も試すべき」「RP は OP 視点で自身の metadata を resolve したうえで request を送るべき」。

論争:

  • @Razumain(11/26): 「プロトコル層でこれを解決すべきではない。各検証者が trust anchor を選び、衝突は RP metadata の調整やフェデレーションポリシーの調整等、プロトコル外で対処すべき。仕様の役割は『bad federation setup を防ぐこと』ではない。検証アルゴリズムに過度な複雑性を導入することになる」と強く反対
  • peppelinux(11/26): 関連する Issue #86 の参照を提示
  • selfissued(11/28): @Razumain の立場に共鳴を表明。「アルゴリズム負担が大きすぎる」とし、ただし「@Razumain の提案する内容を implementation guidance として仕様に含めるべきか」は今後の論点として留保

本 issue は最終的に Razumain・selfissued の見解(プロトコル外対処)が優勢となり、後にクローズされる。

openid/federation#131 - Inconsistent Trust Anchor parameter names

Vladimir Dzhuvinov が 11 月 6 日起票。resolve request では anchor、explicit client registration response では trust_anchor_id と一貫性のない命名が混在している問題を指摘。

論点:

  • zachmann(11/6): 「resolve endpoint は anchor ではなく trust_anchor を使うべき」
  • selfissued(11/30): 「もう 1 つの不整合: Subordinate Listing request は entity_type、Resolve request は type。Resolve 側を entity_type に揃えるべき」と追加指摘
  • selfissued(11/30): 「claim 名も trust_anchor_id から trust_anchor へ統一すべき」
  • peppelinux(11/30): 「resolve endpoint は古いバージョンの命名を引きずったもの。trust_anchor への統一に賛成」

この議論が 12 月 4 日にマージされる PR #154(「Use consistent parameter and claim names」)の起点となり、Federation draft 41 における anchortrust_anchor および typeentity_type の正規化に直接つながった。

openid/federation-wallet#43 - Introduce entity_id_alternative_names Parameter for OpenID Federation

15 コメントを集めた federation-wallet リポジトリの主要 issue。peppelinux(Giuseppe De Marco)が 11 月 11 日起票。「OpenID Federation の Entity Configuration に optional な entity_id_alternative_names パラメータ(string 配列)を追加し、HTTPS URL 以外の unique identifier(EBSI 等の DID を含む)を登録可能にする」提案。

論点(11 月分のみ抜粋):

  • tweeddalex(11/11): 「DID ベースのエコシステム(EBSI、Swiss eID 等)を OIDF フレームワークにマッピング可能にする」と強く支持
  • selfissued(11/19): 「alternative ID 所有者が federation entity も実際にコントロールしていることをどう reverse proof するのか?」と security 懸念
  • peppelinux(11/19): 「Entity Configuration の既存の cryptographic material を使って、distributed ledger 上の trust evaluation で alternative identifier binding を verify する」案
  • selfissued(11/19): 「公開鍵のコピーだけでは control を証明できない。具体的にどんな signature が alternate ID 所有者の制御を示すのか?」と反論
  • peppelinux(11/19): 「alternative proof は federation の scope 外。仕様はパラメータを導入するだけで、verification は他仕様に委ねるべき」「entity は自身が publish する alternative identifier・trust mechanism の選択責任を負う」

Federation × Wallet × DID 連携の根本的な設計論となり、Wallet Architectures 仕様の方向性に大きな影響を与える前哨戦となった。

openid/connect リポジトリの状況

openid/connect GitHub リポジトリは当時 issue/PR 運用に使われておらず、月内に新規 issue/PR は確認できない。OpenID Connect Core 本体や Native SSO の改訂は Bitbucket Issue Tracker(bitbucket.org/openid/connect)上で管理されていた。

6. 関連イベント

IETF 121 Dublin(11 月 2 〜 8 日)

IETF 121 が 11 月 2 〜 8 日に Dublin の Convention Centre Dublin で開催(Cisco ホスト、現地参加 982 名・オンライン参加 501 名)。OAuth WG セッションは 11 月 4 日・5 日・7 日に開催され、Aaron Parecki は 自身の blog で参加予定 WG を整理した。AB/Connect WG メンバーの多くがこのイベントに参加していたため、11 月 5 日の Pacific コールはキャンセルとなった(ML #010498)。

WIMSE(Workload Identity in Multi-cloud and Service Environments)WG では OAuth・JWT・SPIFFE を組み合わせた workload identity の議論が進み、AB/Connect WG メンバーが OAuth 周辺の動向を Federation 議論にフィードバックする経路となった。

AuthZEN Authorization API 1.0 Implementer's Draft 投票(11 月 7 〜 14 日)

AuthZEN WG 主管の投票が 11 月 7 〜 14 日に実施され、11 月 15 日に Implementer's Draft として承認公表。AB/Connect WG 直接の成果物ではないが、OIDF 内の他 WG の Implementer's Draft 投票運用の実例として ML 周知が継続された。

OpenID4VP 3rd Implementer's Draft パブリックレビュー期間(11 月 1 日 〜 12 月 16 日)

公的告知 が 11 月 1 日に発出。45 日間のレビュー期間が AB/Connect WG コール内でも継続議題となり、Tom Jones による consent design への問題提起(11 月 18 日・25 日コール)が形成された。

Mike Jones による「Three New Specs Enhancing OpenID Federation and New Contributors」公表(11 月 30 日)

Mike Jones の self-issued.info で 11 月 30 日、AB/Connect WG が以下の 3 仕様を採択したことを公表:

  1. OpenID Federation Extended Subordinate Listing - 大規模 entity 数を持つフェデレーションで「単一リクエストで複数 entity statement と関連詳細を取得可能にする」拡張
  2. OpenID Federation Wallet Architectures - 「wallet エコシステムのセキュリティと相互運用性を高めるための OpenID Federation 1.0 の使用方法」を定義し、「大規模デプロイメントでのセキュアな metadata 交換とポリシー適用」を促進
  3. OpenID Connect Relying Party Metadata Choices - RP が metadata パラメータの「サポート値集合」を表現可能にする拡張。Automatic Registration(registration response がない)特に有用

新規 active contributor として Michael FraserŁukasz Jaromin が明示的にクレジットされ、Federation コミュニティの世代交代と拡大を象徴する月末となった。Giuseppe De Marco については「emerged as a leader in the space」として継続貢献者の中で位置付けられ、Roland Hedberg、John Bradley、Mike Jones 自身と並ぶ Federation コミュニティのリーダー層として言及されている。Mike Jones は「これらの仕様が新たな active contributor を本作業に呼び込んでいる」点を強調し enthusiasm を表明している。

7. 今後の予定(2024 年 11 月末時点の視点)

  • OpenID Federation 1.0 規範改訂: 月末段階で openid/federation 上に積み上がった 12 件のマージ済み PR と継続議論中の Issue #131・#136・#147・#148 をもとに、次版 draft(後の draft 41)を 12 月初頭に publish する見込み。anchortrust_anchortypeentity_type の正規化、resolve endpoint への複数 Trust Anchor 許容、error codes の整理、Federation Topologies 章新設などが目玉となる予定
  • OpenID Federation Wallet Architectures: 11 月 30 日に正式採択。Issue #43(entity_id_alternative_names)に代表される DID/EBSI 連携議論を中心に、wallet ecosystem への Federation 適用が継続課題
  • OpenID Federation Extended Subordinate Listing: 11 月 30 日に正式採択。早期段階の draft をベースに、ページネーション機構と subordinate statement 構造の整理が続く(後の 12 月 19 日 draft 01 公開へ)
  • OpenID Connect Relying Party Metadata Choices: draft 01 公開済み。Automatic Registration との接続を中心に継続レビュー
  • OpenID4VP 3rd Implementer's Draft: パブリックレビュー期間(〜 12 月 16 日)終了後、12 月 17 〜 24 日に投票実施予定。Tom Jones が提起した consent 問題への対応も並行
  • Native SSO for Mobile Apps: George Fletcher による「ID Token 依存縮小」「authorize endpoint 必須化見直し」「grant type 再設計」の 3 軸での検討が継続。年内に PR を提出する見込み(実際には 12 月 31 日 PR #744 提出)
  • WG コール運用: 当月時点では Atlantic 週次・Pacific 隔週の従来運用を維持。12 月以降の運用刷新(EU フレンドリー化)はまだ議題に上がっていない
  • OpenID Provider Commands: 当月時点では未提示。Dick Hardt と Karl McGuinness による寄稿提示は 2025 年 1 月 15 日

8. 参考情報源

Connect WG コール議事録

Native SSO 関連 ML スレッド

RP Metadata Choices 関連 ML スレッド

GitHub Issues / PRs(11 月内)

仕様ドキュメント

公式アナウンス・関連記事