idbok

Appearance

OpenID Foundation AuthZEN WG 活動レポート (2024年11月) ​

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

1. 概要 ​

AuthZEN Working Group（WG）は、アプリケーション内外における認可クエリ（PEP-PDP 通信）の標準 API 規格を策定する OpenID Foundation の WG である。Subject・Action・Resource・Context（SARC）の JSON ベース情報モデルを核に、Authorization API のドラフト策定と相互運用性デモを並行して進めている。2024 年 11 月時点の共同議長は Omri Gazitt（Aserto）、David Brossard（Axiomatics）、Gerry Gebel（Strata Identity）の 3 名で、定例コールは毎週火曜開催（隔週で 11:00 PT / 15:00 PT が交互）。

2024 年 11 月の AuthZEN WG は、WG 発足以来最大のマイルストーンである「Authorization API 1.0 Implementer's Draft 01」を OIDF メンバー投票で正式承認させた月 であった。承認は 2024-11-15、投票結果は 賛成 82・反対 2・棄権 22（合計 106 票、391 メンバー中 27%、定足数 20% を充足）。これによりベンダーは OIDF の IPR 保護下で安定的に AuthZEN を実装できる根拠を得た。同時に、月の後半には 「Implementer's Draft が承認された直後にどのように作業ブランチを命名・運用するか」 という versioning convention を巡る 13 通の連投スレッドが立ち上がり、Mike Jones（Self-Issued Consulting / 元 OIDF SAB）が「numbered drafts は monotonically increasing で immutable、minor version bump（1.1）には到達 Final 前は移行しない」という OIDF 慣行を改めて整理する場ともなった。

ML への 11 月分投稿数は 18 通（2024 年 11 月アーカイブ の 000221〜000238、2024-11-05 〜 2024-11-27）。GitHub openid/authzen リポジトリの 11 月活動は 新規 PR 3 件（PR #177、#178、dependabot #179）と新規 Issue ゼロで、議論の主舞台は ML と HackMD（Implementer's Draft 投票後の roadmap / Search API ドラフト）であった。

技術議論の主軸は次の 4 点であった:

  • Authorization API 1.0 Implementer's Draft 01 承認（2024-11-15）— 9 月初版（draft 00）公開、10 月 24 日 Notice of Vote 公告（45 日 review 期間終了）、11 月 7 日 〜 14 日投票、11 月 15 日 OIDF 公式アナウンス、という OIDF プロセスを完走
  • 2025 年最終仕様化を見据えた conformance test の検討開始（11-12 コール）— Final 1.0 を目指すならば適合性テストスイートが必要であり、Joseph Heenan に OIDF 側のリソース確認を要請する方針を決定
  • Search API / Partial Evaluation のドラフト初出（11-12 / 11-19 コール）— Vladi Berger（Kong）が partial evaluation の WIP ドラフトを起案。リクエスト形式は AuthZEN core からの派生で合意が取りやすかったが、レスポンス形式 が議論の焦点となり、SCIM の filter 構文（RFC 7644 §3.4.2.2）を参考にすべきかが俎上に
  • Implementer's Draft 直後の versioning convention 議論（11-25 〜 11-27、13 通連投）— Michael Schwartz（Gluu）が「AuthZEN 1.1 が公開された数分後にまた版が出る運用は、実装ベンダーの信頼を損なう」と問題提起。Mike Jones が OIDF 慣行（N.M-NN で N.M は Final まで不変、NN は immutable）を整理し、Omri Gazitt が当夜のうちに作業ブランチを 1.1-01 から 1.0-02 へ rename する PR #178 を投入してクローズ

なお、2024 年 11 月時点の AuthZEN は WG として最初の Implementer's Draft を出した直後 の局面であり、後の Search API（Draft 03）、Discovery エンドポイント、HTTP mapping extension（VNG 提案）、API Gateway Profile、Final 1.0 へと続く 2025 年の議題の 多くがこの月の roadmap 議論で初めて言及された 点で位置づけが大きい。

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

Authorization API 1.0 - Implementer's Draft 01（2024-11-15 承認・WG 史上初の正式承認版） ​

  • 正式名称: Authorization API 1.0 - draft 01
  • URL: authorization-api-1_0-01.html
  • 編集者（spec 本体記載）: Omri Gazitt（Aserto）、David Brossard（Axiomatics）、Atul Tulshibagwale（SGNL）
  • コントリビューター: Marc Jordan（SGNL）、Erik Gustavson（SGNL）、Alex Babeanu（3Edges）
  • 承認プロセス:
    • 9 月: draft 00 公開（document date 2024-09-06）
    • 10 月 24 日: Notice of Vote 公告（OIDF Secretary Marie Jordan 名義）。45 日 review 期間終了
    • 10 月 31 日: 早期投票開始
    • 11 月 7 日 〜 11 月 14 日 12:00 PT: 公式投票期間
    • 11 月 15 日: 承認アナウンス 公開（賛成 82・反対 2・棄権 22、定足数 20% を充足）
  • 位置づけ: Implementer's Draft は OIDF の IPR 保護下で実装者が参照可能な安定版仕様。これにより、12 月の Gartner IAM Grapevine デモ参加ベンダー（Aserto、Axiomatics、Cerbos、Permit.io、EmpowerID、SGNL、WSO2、Topaz 他）が公式仕様 URL を実装根拠として引用できる状態が確立した
  • 仕様内容: PEP-PDP 間通信のトランスポート非依存 API、Subject / Action / Resource / Context（SARC）情報モデル、Access Evaluation エンドポイント（単数形）、JSON ペイロード、HTTPS バインディング、TLS 必須、エラーハンドリング、セキュリティ考慮事項

11 月内に仕様リポジトリへマージされた PR ​

openid/authzen リポジトリで 11 月内にマージされた PR は以下の 2 件のみ（dependabot を除く）:

  • PR #177 - Added unique resource IDs per owner（aaguiarz〔Andres Aguiar / Auth0 / Okta、OpenFGA 推進担当〕起票、2024-11-15 16:22 UTC 起票・2024-11-15 17:14 UTC マージ）
    • interop の decision*.json テストフィクスチャで、同一 todo ID が複数オーナー（morty / rick / summer / beth / jerry）に共有されており、ReBAC 系 PDP の評価意図と整合していなかった点を修正
    • オーナーごとに 7240d0db-8ff0-41ec-98b2-34a096273b91 〜 ...b95 のように末尾を分けた一意 ID を採番
    • PR 本文の問題提起: 「This implies that the same Todo item is owned by different users, which is probably not intended.」「In addition of making it more correct, it simplifies the implementation in ReBAC systems, as they can store the { user:x, owner, todo:y } relation in the database instead of obtaining it from the context.」
    • Implementer's Draft 01 承認当日にマージ された点が象徴的で、ReBAC 系（Auth0 / OpenFGA、Aserto / Topaz、Permit.io）の interop 品質を承認直後に底上げする狙い
  • PR #178 - created api spec version 1_0_02 and fixed bullet formatting（ogazitt 起票・マージ、2024-11-27 23:01 UTC 起票・23:03 UTC マージ、api/1.0.2 ブランチ）
    • api/authorization-api-1_0_02.md（899 行）を新規作成し、Implementer's Draft 01 を出発点とする次期作業ファイルを確立
    • .github/workflows/jekyll-gh-pages.yml を 1.0.02 もビルド対象に追加
    • ML スレッド「New versions」の合意を即座にコードへ反映 した PR。スレッドで議論された 1.1-01 → 1.0-02 への rename を当夜のうちにリポジトリへ適用

11 月内に作成された dependabot PR ​

  • PR #179 - Bump cross-spawn from 7.0.3 to 7.0.6 in /interop/authzen-interop-website（dependabot 起票 2024-11-27、merge は 2025-02-25）— interop website の依存更新

11 月内の新規 Issue ​

11 月中に新規作成された Issue は 確認できなかった。Implementer's Draft 直前という時期柄、議論は ML 側に集中していた。

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

AuthZEN WG は毎週火曜にコールを開催している。2024 年 11 月の定例コールは 11 月 5 日・11 月 12 日・11 月 19 日・11 月 26 日 の 4 回。隔週で 11:00 PT と 15:00 PT が交互に入れ替わる構成で、11 月 5 日コールでは「Europe に配慮し、隔週 3pm PT 枠を 1pm PT に前倒しする」決定が議事化された。議事録はすべて ML（pipermail）に投稿され、HackMD @oidf-wg-authzen にも蓄積される。

2024 年 11 月 5 日（火）定例コール — コール時刻調整・投票週前夜 ​

  • 背景投稿: Changing the time of our call on every other Tuesday（David Brossard、2024-11-05）
  • 応答: #222（Omri Gazitt、2024-11-06）— Elizabeth（OIDF スタッフ）を web 更新のため追加
  • 決定事項:
    • 隔週 3pm PT のコールを 1pm PT（10pm CET / 8am AEST） に移動し、Europe からの参加を容易化
    • もう一方の隔週コールは現行時刻を維持
    • 公式投票期間（11 月 7 日 〜 14 日）直前のタイミングで、投票呼びかけと早期投票（10 月 31 日開始）の状況確認も行われたと推察される
  • 意義: WG として欧州コミュニティ（Axiomatics、Cerbos、Permit.io、後の VNG / Trimpe 等）の継続参加を仕組みとして確保。後の 12 月 Trimpe 加入や 2025 年 1 月の API GW Profile 議論につながる前提整備

2024 年 11 月 12 日（火）定例コール — Implementer's Draft 投票週・2025 年計画着手 ​

  • 議事録: Notes from today's call（David Brossard、2024-11-12）
  • 派生応答: #224（Christopher Hendrix、Cornell、2024-11-13）
  • 主要議題:
    • OIDF 2025 計画: 「meeting agenda と notes を ML に publish する運用をより徹底すべき」（議事録 2024-11-12 より要約）。WG 全体に対する OIDF 側からの publication ガバナンス強化要請を受けた
    • Final 仕様タイムライン: 「2025 年に Final Spec を狙うかどうかを WG として決める必要がある」と確認。もし狙う場合は conformance test suite が必須要件 となるため、Joseph Heenan（OIDF Certification 担当）に必要リソースをリクエストする方針を決定
    • Discovery & Routing: 「ルーティング（PEP がどの PDP に問い合わせるか）は仕様スコープ外」と合意（実装者の裁量に委ねる）。Discovery エンドポイント は「サポート機能を識別するためのもの」（binary requests/responses、boxcarring〔バルク評価〕、search の各機能フラグ）と位置づけ、ただし「boxcarring / binary / search の実際のユースケースをもっと理解する必要がある」と未消化論点を残す
    • Search API: Vladi Berger（Kong）が partial evaluation の draft を作成済みであることを共有。次回までに既存 search documentation を読み込んで議論する宿題を出す
    • Outreach 戦略: PEP ベンダー / フレームワーク向けの outreach 対象一覧を populate する必要を確認。David Brossard が Gartner と接触を開始したと報告
    • versioning に関する重要な決定: 後の ML 「New versions」スレッドで Omri Gazitt が引用したとおり、「作業ブランチを 'AuthZEN 1.1 01' から正式名 'AuthZEN 1.0.02' へ rename する」合意がこの 11 月 12 日コールで取られた（Omri Gazitt の発言、2024-11-25）
  • Christopher Hendrix の論点提示（議事録への返信 #224、Cornell、コール欠席）:
    • Search API 議論の参考として ucast プロジェクト (github.com/stalniy/ucast) を紹介
    • ucast は「統一的な conditions の AST と、各方言や DB パッケージへのアダプタを持つ標準化試行」と説明
    • Vladi のドラフトが論理合成（function composition）と serialization の uniform 化を狙う方向と論点が一致する外部参照例として提示

2024 年 11 月 19 日（火）定例コール — Search API レスポンス形式と IPSIE との関係 ​

  • 議事録: Notes from today's call（David Brossard、2024-11-19 23:59 UTC）
  • 参加者: Victor Lu、Alex Babeanu、David Brossard、Vladi Berger、Phillip M.、Roblox からの新規参加者
  • 主要議題:
    • Search API / Partial Evaluation: 「リクエスト形式は AuthZEN core からの派生として相対的なコンセンサスが取れている」一方で「レスポンス形式の合意が難航」（議事録 2024-11-19 より要約）。Vladi の提案と既存の競合提案の 2 案が併存
    • SCIM filter 構文の参照可能性: 「SCIM の search query language（RFC 7644 §3.4.2.2）を採用すべきか」が議題化。既存ソリューションが配下ポリシーフレームワーク（典型は XACML）の表現を反映しがちな現状を踏まえ、ニュートラルな業界既存標準を活用する選択肢として議論
    • 想定ユースケース: ランタイム data filtering、access reviews、entitlement generation の 3 領域を主要ユースケースとして列挙
    • IPSIE WG との関係: 「OpenID Foundation 新規エンタープライズ認可イニシアチブ IPSIE に AuthZEN / ABAC のコンセプトを統合する可能性」を議論（IPSIE WG は 2024 年 10 月に kickoff された direct neighbor WG）
    • アクションアイテム: Vladi が AuthZEN evaluate フレームワークに揃えてプロポーザル例を改訂。IPSIE 統合は別途調整
  • 意義: Search API のレスポンス形式が WG 内最大の技術論点であることが明確化された回。後の 2025 年に Draft 03 として結実する Search API の議論起点

2024 年 11 月 26 日（火）定例コール — KubeCon 報告・2025 ロードマップ初出 ​

  • 議事録: Notes from 2024-11-26 AuthZEN call（Omri Gazitt、2024-11-27 16:21 UTC）
  • 主要議題:
    • KubeCon NA 2024（Salt Lake City、2024-11-12 〜 15）報告: Omri Gazitt が「Your Cheat Code for API Authorization」（CNCF Co-located Events NA 2024 schedule、11 月 12 日 1:30pm MST、Salt Palace Level 1 | 151 G）でセッションを実施。参加者 200 名超 と報告し、search 機能および認可ソリューション全般への強い関心を確認
    • プロセス & ツール: HackMD の代替ツール検討、コール時刻の追加調整、現行 HackMD 利用における IP rights enforcement の懸念に言及。Mike L（Mike Leszcz / OIDF スタッフ）に HackMD usage と IPR の整理を依頼する方針を決定
    • 2025 年ロードマップ初出: 「Implementer's Draft 01（Evaluation）→ Draft 02（Evaluations + Discovery）→ Draft 03（Search）へ進める道筋」を明示的に議論。Final 仕様投票のタイムラインも検討対象に
    • Search API: Vladi が list と predicate capabilities に関するプロポーザルを提示
    • Outreach 戦略: industry adoption に注力し、design patterns documentation を継続整備する方針を再確認。「Industry profiles（API Gateway / GraphQL / Kubernetes 等）は WG 内部ではなく外部グループ発信が望ましい」とのスタンスを共有
    • Certification 認証: Final 仕様ステータスを目指すうえで OIDF certification への engage が必要、と確認
  • アクションアイテム: co-chair が outstanding な OIDF プロセス論点を確認してから WG 全体に再提示
  • 意義: KubeCon での 200 名超セッションが Implementer's Draft 承認直後の外部反応として記録された回。後の 12 月 17 日 Grapevine 報告でも比較対象として参照される

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

openid-specs-authzen ML（2024 年 11 月アーカイブ）の 11 月総投稿数は 18 件（000221〜000238）。技術議論を含む主要スレッドは以下の 3 本。

4.1 Changing the time of our call on every other Tuesday — 2024-11-05 開始（David Brossard、2 通スレッド） ​

  • 発端（#221）: David Brossard が、隔週で 3pm PT に設定されていた火曜コールを「Europe に配慮して」1pm PT（10pm CET / 8am AEST）へ前倒しする決定を共有
  • 応答（#222、Omri Gazitt、2024-11-06）: WG サイトの更新を依頼するため、Elizabeth（OIDF スタッフ）を thread に追加
  • 意義: 一見事務的ながら、欧州コミュニティ（Axiomatics、Cerbos、Permit.io、後の VNG）が後の Search API / API Gateway Profile / HTTP mapping extension 議論の主要担い手となる流れの 入り口 にあたる時刻調整

4.2 Notes from today's call (2024-11-12) → ucast 紹介 — 2024-11-12 開始（David Brossard、2 通スレッド） ​

  • 発端（#223）: 11 月 12 日コール議事録投稿。Final 仕様 / conformance test、Discovery & Routing スコープ、Search / Partial Evaluation、Outreach 戦略を網羅
  • 応答（#224、Christopher Hendrix、Cornell、2024-11-13）: コール欠席を詫びつつ、Search API 議論の参照として ucast プロジェクト（github.com/stalniy/ucast）を紹介。「統一的な conditions の AST と、各方言や DB パッケージへのアダプタを持つ標準化試行」と特徴づけ
  • 意義: Search API のレスポンス形式議論にコミュニティから外部の正規化試行例（ucast）が引かれた最初の例。後の Vladi 提案の serialization 統一方針および SCIM filter 構文検討と並ぶ参照軸として位置づけられる

4.3 New versions — 2024-11-25 開始（Michael Schwartz 起点、13 通連投） ​

11 月 25 日 〜 27 日にかけて連投された versioning convention を巡る論争スレッド。Implementer's Draft 01 承認から 10 日後、リポジトリ上に「AuthZEN 1.1」と思しき作業ブランチが見え始めたことを起点に、OIDF 全体の慣行確認まで及んだ。

  • 発端（#226、Michael Schwartz、Gluu、2024-11-25 17:03 UTC）: 「Specs that keep releasing new versions are not worth implementing.」と直接的に問題提起。1.1 が前版公開直後に現れる運用は、実装ベンダーが安定したターゲットを得られず、結果として広範な採用が阻害される と主張
  • 応答（#227、Julio Auto De Medeiros、Bloomberg、2024-11-25 20:37 UTC）: 技術的事実関係を整理。「1.1 doesn't modify the 1.0 API in any way」— 1.1 は 1.0 API を改変せず、Evaluations（複数形）用の新規エンドポイントを追加する非破壊変更である、と説明
  • Schwartz の反論（#228、2024-11-25 21:36 UTC）: 「Then I don't understand why it's called 1.1???」— 非破壊なら 1.1 にする必然性がなく、独立仕様にするか「Authzen-Core 1.0」のように別名にすべきと反論
  • Omri Gazitt の整理（#229、2024-11-25 22:19 UTC）: 「AuthZEN 1.1 was always an informal draft name. We actually discussed this very issue on the Nov 12 AuthZEN call, and agreed to rename the 'AuthZEN 1.1 01' draft to the more formal name of AuthZEN 1.0.02.」と説明。11-12 コールで既に rename 合意済みであり、将来版は PDP がサポートエンドポイントを広告する discovery メカニズムも備える計画と表明
  • Alex Babeanu の支持（#230、3edges、2024-11-26 15:22 UTC）: 「everything before the implementer's draft was just a work in progress」と発言し、ID1 の安定性を優先して discovery 等の新機能は次サイクルに送る方針を支持
  • Omri Gazitt の補強（#231、2024-11-26 15:54 UTC）: 「The decision mechanism will come in for ID2. ID1 is immutable.」と簡潔に確認
  • Schwartz の再反論（#232、2024-11-26 16:34 UTC）: 「Specs that keep releasing new versions are not worth implementing. If you want a whole bunch of developers to implement APIs and software using your standard, you can't keep changing it every week.」— 主張を改めて強調
  • Schwartz の補足（#233、2024-11-26 20:26 UTC）: 主張の論拠を 3 点に整理。(1) OpenID Connect Core 1.0 + errata set 2 は 2014 年以来不変であり、安定版の存在こそが成功要因、(2) Gluu / Jans では認可エンドポイント URL を client にハードコードせず、PDP metadata（discovery）こそが新機能追加時の鍵となる、(3) 標準化 WG はベンダー拡張（vendor extensibility）の余地を制度として設計すべきで、Gluu 自身も custom discovery metadata を追加するスタイルを採用している
  • Michael Jones の OIDF 慣行整理（#234、Self-Issued Consulting、2024-11-27 00:20 UTC）: 「Spec versions are of the form N.M – typically 1.0, until such time as 1.0 becomes Final and therefore immutable.」「All published numbered drafts are immutable.」「All the AuthZen specs should be using version number 1.0 until Final, but regularly publish numbered drafts until that goal is reached.」— OpenID Federation を範例として引用（draft 39 / 40 が同一の 1.0 を維持しつつ更新されている例）
  • Omri Gazitt の合意（#235、2024-11-27 00:47 UTC）: 「The next implementers draft will be https://openid.net/specs/authorization-api-1_0-02.html, and so on.」と URL レベルまで含めて確認。「spec compact なため、evaluations と search を minor version bump せずに収容できる」とコメント
  • Mike Jones の追加コメント（#237、2024-11-27 17:33 UTC）: 「The working group should be publishing new numbered drafts to openid.net/specs/ with each significant coherent set of updates to the spec.」— numbered drafts と Implementer's Drafts は区別される こと（OpenID Federation は 40 numbered drafts 中わずか 4 つが Implementer's Drafts）を例示
  • Omri Gazitt のクローズ（#238、2024-11-27 19:46 UTC）: 「Thanks Mike, it's helpful to know that even drafts that aren't ID's can have stable URLs on openid.net/specs.」と感謝表明でスレッドを締める
  • 議論決着への具体的アクション: 同日 23:01 UTC、Omri Gazitt が PR #178 を起票・即マージし、作業ファイル api/authorization-api-1_0_02.md（899 行）を新規作成。スレッドの合意を 同夜のうちにリポジトリへ反映 した
  • 意義: AuthZEN WG が最初の Implementer's Draft を承認させた直後に直面する 「ID 後の作業ブランチ命名」というガバナンス問題 に対し、Mike Jones が OIDF 慣行を整理して合意に導いた事例。同時に、Schwartz の「安定性こそ採用の前提条件」という主張は WG 内に強い印象を残し、後の 12 月 Discovery 議論（Schwartz による access_evaluation_v1_endpoint 共有）にも直接つながる伏線となった

5. GitHub 上の議論 ​

openid/authzen リポジトリの 2024 年 11 月活動: 新規 PR 3 件（うち 11 月マージ 2 件、dependabot 1 件）、新規 Issue ゼロ。コメント数は全般に少なく、議論の主舞台は ML と HackMD（roadmap、Search API ドラフト、versioning）であった。

5.1 openid/authzen#177 — Added unique resource IDs per owner（aaguiarz、2024-11-15 起票・マージ） ​

  • 作成者・マージ者: aaguiarz（Andres Aguiar / Auth0 / Okta、OpenFGA 推進担当）が起票、Omri Gazitt がマージ

  • 起票・マージ: 2024-11-15 16:22 UTC 起票・17:14 UTC マージ（Implementer's Draft 01 承認当日）

  • 問題提起: interop の decision*.json テストフィクスチャで、同一 todo ID が複数オーナー（morty / rick / summer / beth / jerry）で共有 されていた点を指摘。PR 本文の引用例:

    json
    {
  "request": {
    "subject": { "type": "user", "id": "Ci...EBWxvY2Fs" },
    "action": { "name": "can_update_todo" },
    "resource": {
      "type": "todo",
      "id": "7240d0db-8ff0-41ec-98b2-34a096273b9f",
      "properties": { "ownerID": "jerry@the-smiths.com" }
    }
  },
  "expected": false
}

    「This implies that the same Todo item is owned by different users, which is probably not intended.」（PR #177 本文）

  • 解決: オーナーごとに末尾 1 桁を分けた一意 ID を採番（...b91 〜 ...b95、それぞれ morty / rick / summer / beth / jerry に対応）

  • ReBAC 視点の追加価値: 「In addition of making it more correct, it simplifies the implementation in ReBAC systems, as they can store the { user:x, owner, todo:y } relation in the database instead of obtaining it from the context.」（PR #177 本文）— context から都度抽出するのではなく、関係を DB に格納できるようになる

  • 意義: Implementer's Draft 01 承認直後に ReBAC 系 PDP（Auth0 OpenFGA / Aserto Topaz / Permit.io）の interop 品質を底上げ する PR。後の 12 月の Gartner Grapevine デモにおける ReBAC ベンダー interop 表示の前提整備にあたる

5.2 openid/authzen#178 — created api spec version 1_0_02 and fixed bullet formatting（ogazitt、2024-11-27 起票・マージ） ​

  • 作成・マージ: Omri Gazitt、2024-11-27 23:01 UTC 起票・23:03 UTC マージ（ML スレッド「New versions」#238 のクローズ投稿から約 3 時間後）
  • ブランチ: api/1.0.2
  • 変更内容（2 ファイル、+914 / -1）:
    • api/authorization-api-1_0_02.md（899 行新規作成）— Implementer's Draft 01 を起点とする次期作業ファイル
    • .github/workflows/jekyll-gh-pages.yml（+15 / -1）— 1.0.02 ビルドを CI 対象に追加
  • 意義: 「New versions」スレッドの合意（1.1-01 → 1.0-02 への rename、numbered drafts は immutable で URL も stable）を 当夜のうちにリポジトリへ反映 した PR。Mike Jones が示した OIDF 慣行が、議論レベルから具体的なファイル構造の確立へと展開した瞬間。後の 1_0-02 〜 1_0-04 シリーズ、最終的な Final 1.0 へと至る発展系列の起点

5.3 openid/authzen#179 — Bump cross-spawn from 7.0.3 to 7.0.6 in /interop/authzen-interop-website（dependabot、2024-11-27 起票） ​

  • 作成者: dependabot[bot]
  • 起票・マージ: 2024-11-27 起票、2025-02-25 マージ
  • 内容: interop website の依存パッケージ cross-spawn のセキュリティアップデート
  • 意義: 議論上の意義は小さいが、interop website が継続的に dependabot で保守されている状態を示す

6. 関連イベント ​

KubeCon + CloudNativeCon North America 2024（Salt Lake City、2024-11-12 〜 15） ​

  • 登壇: Omri Gazitt が「Your Cheat Code for API Authorization」を 11 月 12 日 1:30pm MST に Salt Palace Level 1 | 151 G で発表（CNCF Co-located Events NA 2024 schedule）
  • WG 内報告（11-26 コール議事録より）: 参加者 200 名超 と報告。search 機能および認可ソリューション全般への強い関心を確認
  • 位置づけ: AuthZEN Implementer's Draft 01 の公式承認（11-15）と完全に同週内のクラウドネイティブコミュニティ向け露出。Aserto を含むベンダーが製品レベルで AuthZEN 対応をアピールできる初の機会

Authorization API 1.0 Implementer's Draft 01 承認（2024-11-15） ​

  • OIDF 公式アナウンス: AuthZEN Authorization API 1.0 Implementer's Draft Approved（Marie Jordan / OIDF Secretary 署名）
  • 投票結果: 賛成 82・反対 2・棄権 22（合計 106 票、391 メンバー中 27%、定足数 20% 充足）
  • 位置づけ: WG 発足以来最大のマイルストーン。後の Gartner Grapevine 2024（12 月）、Gartner London 2025（3 月）の interop demonstration、および各ベンダー製品の AuthZEN 対応の正式根拠

7. 今後の予定（2024 年 11 月末時点の視点） ​

11 月末時点で WG が想定していた次月以降の動き:

  • 2025 年 H1 ロードマップの具体化: Implementer's Draft 02（Evaluations + Discovery）→ Draft 03（Search API）→ Final 1.0 という大筋を 12 月以降のコールで詳細化
  • Evaluations API（複数形バルク評価）の仕様明文化: 11-12 コールで「Discovery で広告すべき機能」として位置づけられた boxcarring の実装・ユースケースを 12 月以降に整理
  • Search API / Partial Evaluation のレスポンス形式: Vladi Berger のドラフトを WG 全体でレビュー。SCIM filter 構文（RFC 7644）参照可能性および ucast 等の外部正規化試行を比較しつつ、合意可能なレスポンス形式を 12 月以降に確定
  • Conformance test suite: Final 1.0 を狙う場合に必須となるテストスイートについて、Joseph Heenan（OIDF Certification）にリソース確認
  • Discovery エンドポイント設計: ID2 で導入予定。PDP がサポートエンドポイントを広告するメカニズムを、Schwartz の主張（vendor extensibility 担保）も踏まえて設計
  • 次期作業ファイル authorization-api-1_0_02.md: PR #178 で 899 行の枠を確保済み。12 月以降の編集の場として活用
  • Gartner IAM Summit Grapevine 2024（12 月 9 〜 11 日）対外プレゼンテーション: 共同議長 Omri Gazitt と David Brossard による初の Gartner 登壇を準備
  • IPSIE WG との連携: AuthZEN / ABAC コンセプトを enterprise 認可標準として IPSIE 側に組み込めるかの調整を、11-19 コールでの議論を起点として継続
  • HackMD 代替および IPR 整理: Mike Leszcz（OIDF）に依頼した HackMD usage と IPR enforcement の整理を待って、必要に応じてツール移行を検討

8. 参考情報源 ​