idbok

Appearance

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

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

1. 概要 ​

AuthZEN Working Group（WG）は、Policy Enforcement Point (PEP) と Policy Decision Point (PDP) の間の認可クエリを標準化する OpenID Foundation の WG である。Subject・Action・Resource・Context（SARC）の JSON ベース情報モデルを核に、Authorization API のドラフト策定と相互運用性デモを並行して進めている。2024 年 7 月時点の共同議長は Omri Gazitt（Aserto）、David Brossard（Axiomatics）、Gerry Gebel（Strata Identity）の 3 名で、定例コールは毎週火曜開催。

2024 年 7 月の AuthZEN WG は、「Authorization API を 1.0 系と 1.1 系の 2 トラックへ分岐させ、Implementer's Draft 候補となる 1.0 系のセクション整備と、boxcarred（バッチ評価）対応の 1.1 系新規創設を並行して進めた月」 であった。月初 7 月 3 日には Omri Gazitt が api/authorization-api-1_1.md を新規作成（commit 91a6174）し、同日中に「Access Evaluations（複数形）API」と boxcarring 仕様を 1.1 へ追記（commit 4f5c4b5、api/authorization-api-1_0.md の section header 整形 +38/-33 行、api/authorization-api-1_1.md +376/-68 行）。これは後の 8 月 14 日 Authorization API 1.0 - draft 00 公開、および 9 月 6 日 candidate Implementer's Draft 提出に直接連なる起点である。

openid-specs-authzen ML への 7 月分投稿数は 10 件（2024 年 7 月アーカイブ の 000179〜000188、7 月 3 日 〜 7 月 29 日）。GitHub openid/authzen リポジトリの 7 月活動は 新規 PR 2 件（PR #121 dependabot braces 3.0.2 → 3.0.3、PR #122 PlainID Support）、新規 Issue 0 件（7 月内に新規起票された Issue は確認できない。6 月以前に起票された #116 "Comments on draft 1.0"、#109 "Use JSON schema..."、#111 "Fix action names in interop scenario" などが継続中）、main ブランチへの commit 6 件（spec 改訂 2 件、PlainID interop 関連 3 件、dependabot 1 件）。

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

  • 1.0 / 1.1 仕様の分岐宣言（7-03 ML #179） — Omri Gazitt が「1.0 を最初の Implementer's Draft 提出に向けて固める。1.1 は fast follower として boxcarred requests に対応する Access Evaluations (plural) API を加える」と宣言し、https://openid.github.io/authzen/ で両 spec を併行公開。後の 8-14 draft 00 publish までのロードマップが 7 月初頭に確定した
  • Resource と Subject の構造的対称性をめぐるレビュー（7-03 〜 7-04 ML #180 〜 #182） — David Brossard が「Resource 定義は RFC 8259 を参照しているが、Subject 定義は同等の JSON 構造を持つにもかかわらず RFC 参照がない」と整合性を指摘。Omri Gazitt が「両者を symmetric にする意図だった」「今後のフィードバックは GitHub Issue で」と応答し、Brossard 自身が「Somehow I missed this paragraph. Never mind, all's well.」と既存記述で対称性が確保されていることを確認して収束
  • Todo interop シナリオの 1.0 適合化と dynamic resource の扱い（7-07 〜 7-08 ML #183 〜 #186） — Omri Gazitt が「Todo backend を 1.0 spec に揃える作業中に design issue を発見した」と問題提起（mandatory な resource id をどう扱うか）。Eve Maler は「dynamic resource への対応が必要、static URL/ID への依存は持続不可能」「Shared Signals Framework (SSF) を resource lifecycle 管理に活用できないか、ただし AuthZEN との結合は optional な profile に留めるべき」と原則論を提示。Alex Babeanu（3edges）は「graph ベース PDP では全 todo を表す単一 node を用意できるので、毎リクエスト同じ todo id を送る運用で十分」と実装側の最小コスト解を提案。Omri Gazitt は {"type": "todo_list", "id": "todo-list-1"} の singleton リソース + roles として admin/editor/evil_genius を扱う方向で集約し、Andres Aguiar（Okta）の OwnerID を context に載せる ReBAC 案も組み合わせた解へ収斂
  • IETF 120 OAuth WG での AuthZEN Profile of OAuth RAR 発表（7-22 開催、7-29 ML #188） — David Brossard が IETF 120（Vancouver、2024-07-20 〜 26）の OAuth WG セッションで「AuthZEN Profile of OAuth RAR」（15 分枠）と「ALFA 2.0 Authorization Policy Language」（15 分枠）の 2 件を発表。7-29 の ML 投稿で「RAR の期待と profile を完全に align させるためにはまだ作業が必要、追加の OAuth × AuthZEN 統合の機会もある」と次の論点を WG に共有した

なお 7 月の特徴として、ML スレッドは すべて 7 月前半（7-03 〜 7-08）と 7 月末（7-29）の 2 つの塊 に集中している点が挙げられる。7 月中旬（7-09 〜 7-22）は ML 上の公開発言が乏しい一方、GitHub では Vladi Berger（PlainID）が PR #122 を 7-10 に起票し、7-22 に commit ea1e109 で PlainID 用の interop 結果ファイル（interop/authzen-interop-website/docs/results/plainid.md、55 行）を追加するなど、interop 参加実装拡大が静かに進行していた。これは後の 8 月時点で「13 実装規模」と Omri Gazitt が発言できるようになる準備期間に相当する。

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

Authorization API 1.0（7 月時点の状態） ​

  • URL（リポジトリ）: api/authorization-api-1_0.md（openid/authzen main ブランチ）
  • プレビュー: openid.github.io/authzen/ で GitHub Pages から自動レンダリング
  • 7 月内の改訂: commit 4f5c4b5（2024-07-03、ogazitt）で section header 階層の整形（H2 → H3 への降格、複数形 "Subjects" → 単数 "Subject" 等の用語統一）。差分は +38/-33 行
  • 位置付け: OIDF への最初の Implementer's Draft 提出に向けて固めていく対象。7 月の段階ではまだ openid.net/specs/ 配下に publish された URL を持たず、リポジトリ内 markdown / GitHub Pages プレビューでの版管理段階。後の 8-14 に draft 00 として initial publish される

Authorization API 1.1（2024-07-03 新規作成） ​

  • URL（リポジトリ）: api/authorization-api-1_1.md（openid/authzen main ブランチ）
  • プレビュー: openid.github.io/authzen/authorization-api-1_1
  • 7 月内の改訂:
    • commit 91a6174（2024-07-03、ogazitt）: api/authorization-api-1_1.md を新規作成（+592 行）。.github/workflows/jekyll-gh-pages.yml を更新して 1.1 用に RFC XML → HTML 変換ステップを追加し、GitHub Pages に両仕様を並行公開できるようにした
    • commit 4f5c4b5（2024-07-03、ogazitt）: boxcarring セクションを 1.1 に追記。api/authorization-api-1_1.md は +376/-68 行（同 commit で 1.0 の section header も整形）
  • 新機能の核: Access Evaluations (plural) API — 単一の Access Evaluation API を拡張する形で、複数の Subject / Action / Resource / Context 組を一括で評価する boxcarred request 形式を導入。7 月時点では「evaluations を map（オブジェクト）として扱う」設計が初版に含まれていたが、これは 8-20 コール以降に「array へ戻す」案として再評価されることになる
  • 位置付け: Omri Gazitt が 7-03 ML #179 で「The second is meant to be a fast follower and adds support for boxcarred requests.」と表明した通り、1.0 の後を追走する WG ドラフト

7 月内の interop 実装拡大 ​

  • PlainID PDP の追加準備: Vladi Berger（PlainID）が PR #122 "Add PlainID Support" を 2024-07-10 に起票（マージは 2024-08-06）。4 commits 構成（うち 2 件は main からの merge）、レビュアは ogazitt が承認
  • PlainID interop 結果ファイルの追加: commit ea1e109（2024-07-22、Vladi Berger）で interop/authzen-interop-website/docs/results/plainid.md を +55 行で追加。テスト全件 pass の結果を初投入（ユーザー一覧取得、todo 管理、削除等の permission チェック）
  • 意義: 5 月に WG が公表した interop イベント（AuthZEN Work Group Announces Authorization Interop Results、2024-05-29 OIDF アナウンス）の延長として、参加 PDP 実装が継続的に増えていた時期。PlainID は 7 月時点で実質的な追加組 に位置付けられる

7 月内のその他 PR ​

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

AuthZEN WG は毎週火曜にコールを開催している。2024 年 7 月の定例コールは 7 月 2 日・7 月 9 日・7 月 16 日・7 月 23 日・7 月 30 日 の 5 枠が暦上想定される。ML への投稿および GitHub wiki 上の Meeting Notes ページ構造（2026 年時点で確認できる範囲では年次ページに 7 月分の直接リンクは確認できず、当時の議事録は ML 投稿 ＋ 別ホストの HackMD ノートに分散していた可能性が高い）から、7-02 と 7-09 コールについては議事録投稿が ML に存在することを確認できる。

7 月 2 日（火）定例コール — 1.0 / 1.1 spec 分岐の決定 ​

  • 議事録（直接投稿は確認できない）: ML 上に 7-02 コール議事録の独立投稿は確認できず。ただし、Omri Gazitt が翌 7-03 03:47 UTC（北米火曜夕方相当）に投稿した ML #179 で 「As discussed on the AuthZEN call today, I've updated the 1.0 spec and created a new 1.1 spec that adds the Access Evaluations (plural) API.」 と回顧されており、7-02 コールにおいて以下が決定されていたことが読み取れる:
    • 1.0 を Implementer's Draft 候補として固める方針
    • 1.1 を fast follower として新設し、boxcarred requests（複数評価のバッチ送信）対応の Access Evaluations API を追加
    • 両 spec を openid.github.io/authzen/ で並行公開
  • 同日参照リソース: David Brossard が 7-09 の準備として ML #187 で「Past meeting notes are available at the OpenID AuthZEN wiki」「Notes from last week's session: HackMD document dated July 2, 2024」と HackMD への参照を案内している。すなわち 7-02 のフル議事録は HackMD 上で WG メンバー向けに共有され、ML には summary のみが投稿される運用だった

7 月 9 日（火）定例コール — Todo interop の dynamic resource 設計議論 ​

  • アジェンダ通知: ML #187 "Meeting notes from last week's call and prep notes for today's call"（David Brossard、2024-07-09）
  • 時刻: 11am PT / 8pm CEDT
  • 議題の中心: 「Omri's email re. the demo use case sent on Sunday」 = §4.3 で詳述する ML #183 〜 #186 のスレッドで提起された「1.0 で id を mandatory にする際に、Todo interop シナリオで動的に増減するリソースをどうモデル化するか」という設計課題
  • 参照資料:
    • 先週分（7-02）の議事録: HackMD ノート（2024-07-02 付け）
    • 今週分（7-09）の議事録: HackMD ノート（2024-07-09 付け、参加者は自分の名前を記入してから議論に参加する運用）
  • 読み取れる議論内容（事前 ML スレッドからの再構成）:
    • 動的リソースを per-instance ID 付きで送る案 vs singleton + role モデル案 の対立軸
    • Alex Babeanu（3edges）の「graph PDP では todo 全体を 1 node で表現できる」「3edges が初回 interop でも採用した実装パターン」
    • Eve Maler の「SSF を resource lifecycle 管理に使うが、AuthZEN core に依存させない optional profile に留める」
    • Omri Gazitt の集約案: {"type": "todo_list", "id": "todo-list-1"} の singleton 化と roles（admin / editor / evil_genius） 構造を採用し、permission payload としては can_read_todos / can_create_todos を扱う
  • 意義: 結論として 「1.0 では singleton todo_list を採用し、dynamic resource 管理は将来仕様（1.1 系または別 profile）に任せる」 という落とし所が 7-09 コール周辺で形成された。これは後の 8 月の can_* 命名議論（Issue #123、johakoch、2024-08-07）および 9 月の Joseph Heenan / Gabriel Corona による review 期間フィードバックへと連鎖する

7 月 16 日 / 7 月 23 日 / 7 月 30 日 コール — 公開記録は確認できず ​

  • 公開議事録: ML 上に独立した議事録投稿は確認できない。GitHub wiki の Meeting Notes ページ系列は 2026 年時点で確認できる範囲では 2026 年以降のものが中心で、2024 年 7 月分の wiki ページは確認できない
  • 想定される議論内容（GitHub commit 履歴と 7-29 ML 投稿からの逆算）:
    • 7-16: 7-09 コールで合意された singleton todo_list 構造の実装着手期。Omri Gazitt が backend 改修中
    • 7-23: PlainID interop 結果が前日 7-22 に commit された直後。新規 PDP 追加の確認と review が議題に上った可能性
    • 7-30: IETF 120 の OAuth WG 報告が中心議題。David Brossard が翌日 7-29 22:37 UTC（北米火曜午後相当）に投稿した ML #188 で「Last week at IETF...」と回顧し、追加コール（3pm PT / midnight CET / 8am AEST、Asia-Pacific フレンドリーな時間帯）を呼びかけている
  • 記述上の制約: HackMD @oidf-wg-authzen チームスペースは外部からはログイン画面が表示され、公開された個別ノートへのリンクが索引から辿れないため、7 月後半 3 コールの内容は ML 上の言及から推定する以外の手段がない

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

openid-specs-authzen ML（2024 年 7 月アーカイブ）の 7 月総投稿数は 10 件（000179〜000188）。技術議論として実質的な意味を持つスレッドは以下の 3 本。

4.1 Candidate spec for Implementer's Draft (1.0), and draft of boxcarred requests (1.1) — 2024-07-03 開始（Omri Gazitt → David Brossard、4 通） ​

7 月の方向性を確定した中核スレッド。

  • #179（Omri Gazitt、2024-07-03 03:47 UTC）: 「As discussed on the AuthZEN call today, I've updated the 1.0 spec and created a new 1.1 spec that adds the Access Evaluations (plural) API.」と 7-02 コールでの合意を ML 全体に共有。リンク先は https://openid.github.io/authzen/（1.0）と https://openid.github.io/authzen/authorization-api-1_1#name-access-evaluations-api（1.1 の boxcarring 節）。「The first spec (1.0) is what we are working towards making our first Implementer's Draft. The second is meant to be a fast follower and adds support for boxcarred requests.」「Please open issues in GitHub for any comments or questions on either.」と次の作業フローを規定
  • #180（David Brossard、2024-07-03 21:12 UTC）: 構造的レビュー。Resource 定義が RFC 8259 を参照しているのに対し、Subject 定義は同じく JSON object でありながら RFC 参照がない非対称性を指摘。Brossard は Resource 節の現行記述を引用し、「Subject も同等の clarity が必要では」と問題提起
  • #181（Omri Gazitt、2024-07-03 21:46 UTC）: 「I was intending on making them symmetric.」と意図を表明し、現行 spec 中の Subject 定義（「a JSON object that contains any number of key-value pair attributes」+ 必須 type / id）を引用して、対称性は既に確保されていると応答。「フィードバックは GitHub Issue で追跡したい」と作業フローを再確認
  • #182（David Brossard、2024-07-04 03:53 UTC）: 「Somehow I missed this paragraph. Never mind, all's well.」と、自身が見落としていた既存記述で対称性が成立していることを確認して論点クローズ
  • 意義:
    • 7-02 コールの合意を ML へ公示し、7 月の作業を spec 単位で方向付けた基盤投稿
    • WG 議長間で 「ML での議論は GitHub Issue へ集約する」 運用ルールを明文化し、9 月以降に Joseph Heenan / Gabriel Corona らが大量の Issue を立てる素地を作った
    • 共同議長同士でも spec の細部レビューを ML で行い、見落としを率直に認める文化が確立していることを示す

4.2 Evolving the Todo interop scenario to be compliant with AuthZEN 1.0 — 2024-07-07 開始（Omri Gazitt → Eve Maler → Alex Babeanu → Omri Gazitt、4 通） ​

7 月の最大の設計議論スレッド。dynamic resource の扱いをめぐる原則論 vs 実装最小コスト論の対立。

  • #183（Omri Gazitt、2024-07-07 21:51 UTC）: 前週コール後の進捗報告として 2 件を完了報告:
    1. 「/access/v1/evaluations セクションを含む AuthZEN 1.1 spec を作成し、main にマージ・publish した」
    2. 「Todo backend を AuthZEN 1.0 spec に合わせて更新中、特に mandatory な resource ID フィールドの扱いについて」
    • その上で「a significant design issue that I believe is worth discussing on Tuesday's call」と問題提起し、背景資料 HackMD への参照を提示
  • #184（Eve Maler、2024-07-08 00:09 UTC）: 「翌週のコールは欠席するが事前 feedback を残す」前置きで原則論を提示。
    • 「Dynamic resources need to be catered for. A reliance on too-static resource URLs or IDs will not be sustainable for a lot of APIs needing protection.」
    • SSF（Shared Signals Framework）を lifecycle 管理に使う案に好意的反応を示しつつ、「lightweight and asynchronous from the tasks of policy decision making」「AuthZEN との結合は optional な SSF profile に留め、AuthZEN core 側が SSF に深く依存しないこと」と境界を明示
  • #185（Alex Babeanu、2024-07-08 17:12 UTC）: 実装側からの最小コスト解を提案。
    • 「send the same todo ID to the PDP on every request」
    • 「Graph-based system can just use 1 single Node representing all possible TODOs」「policy-as-code 実装も singular identifier を単に無視できる」
    • 「定数 todo1 を使い、現行の TodoApp node identifier を置き換える」案
    • 「3edges が初回 interop で採用した実装パターン」と前例を提示
  • #186（Omri Gazitt、2024-07-08 20:01 UTC）: Alex と Andres Aguiar（Okta、ReBAC 観点で OwnerID を context に載せる別案を提示していた）への謝辞とともに集約案を提示:
    • 「todo_list を type/singleton としてモデル化し、admin / evil_genius / editor の roles を relationships として扱う」
    • resource context の例: {"type": "todo_list", "id": "todo-list-1"}
    • permission payload の例: can_read_todos, can_create_todos
  • 論点の対立軸と落とし所:
    • 原則論側（Eve Maler）: dynamic resource を一級概念として spec で扱うべき。lifecycle 管理は SSF profile として分離
    • 実装最小コスト側（Alex Babeanu）: singleton で十分、PDP 実装の負担を増やさない
    • 集約案（Omri Gazitt）: singleton todo_list + roles 構造を 1.0 で採用、dynamic resource lifecycle は将来仕様に持ち越し
  • 意義: 7 月 9 日コールの中心議題となり、後の 1.0 仕様で採用される type + id mandatory + singleton resource パターン の起源。同時に、Eve Maler の SSF プロファイル案は AuthZEN と Shared Signals WG の連携可能性を示す初期言及として記録される（実際の AuthZEN-SSF プロファイル化は本レポート対象外の後期作業）

4.3 Last week at IETF... — 2024-07-29 開始（David Brossard、単発） ​

IETF 120（Vancouver、2024-07-20 〜 26）の OAuth WG セッションで David Brossard が AuthZEN を OAuth コミュニティへ売り込んだ報告。

  • 発端: IETF 120 OAuth WG セッション（金曜枠）で Brossard が以下の 2 件を発表
    • AuthZEN Profile of OAuth RAR（15 分）: OAuth Rich Authorization Requests（RFC 9396）の authorization_details 構造に AuthZEN の SARC モデルをどう載せるかの profile 提案
    • ALFA 2.0 Authorization Policy Language（15 分）: AuthZEN とは別軸だが認可ポリシー記述言語の進展
  • 本文: 動画リンク（OAuth WG の IETF 録画）を共有し、「There's more work to be done to fully align the profile with RAR expectations and there are additional opportunities」と次の課題を表明
  • 関連: Eve Maler が主導した Identity Information Workshop（IIW）でのセッションも参照され、共有 Google ドキュメントを案内
  • コール調整: Brossard は本投稿で 3pm PT / midnight CET / 8am AEST の追加コール開催を呼びかけ。Asia-Pacific からの参加者向けの時間帯
  • 意義:
    • AuthZEN が OIDF 内部の議論を超えて IETF OAuth WG コミュニティに正式露出した最初期の記録
    • 後の 2024-09-10 コール議事録（ML #194）で「IETF 120 からのフィードバックとして OAuth RAR と AuthZEN profile の整合性に乖離がある」「AuthZEN Search API のための統合ポイントとして OAuth grant management API を探索」と言及される議論の起点
    • WG が地理的に分散したメンバーシップに配慮し、Asia-Pacific 向けコール開催を試行した点も特筆

5. GitHub 上の議論 ​

openid/authzen リポジトリの 2024 年 7 月活動: 新規 PR 2 件（いずれも 8 月マージ）、新規 Issue 0 件、main ブランチへの commit 6 件。Issue 起票数ゼロは、Omri Gazitt が 7-03 ML #179 で「Please open issues in GitHub for any comments or questions」と呼びかけたにもかかわらず、7 月時点では ML スレッドでの議論が中心で GitHub Issue への移行は緩慢だったことを示す。GitHub Issue が活発化するのは spec が openid.net/specs/ に publish される 8 月以降であり、その意味で 7 月は 「ML 中心のコミュニケーション期」 の最終月に位置付けられる。

5.1 1.1 spec の新規作成 commit 91a6174（2024-07-03、ogazitt） ​

main への直接 commit（PR を介さず）。

  • 変更内容:
    • api/authorization-api-1_1.md を +592 行で新規作成
    • .github/workflows/jekyll-gh-pages.yml を更新し、1.1 用に RFC XML → HTML 変換ステップを追加。GitHub Pages 上で index.html（1.0）と authorization-api-1_1.html の両方を自動生成できるよう CI を拡張
  • 意義:
    • AuthZEN 仕様が単一ドラフトから複数バージョン並行管理体制へ移行した日
    • 後の 9-14 PR #144 で導入される authorization-api-1_1_01.md（1.1-01 作業ドラフト）の祖先にあたるファイル名は、この 7-03 commit に由来
    • CI を spec バージョン別に拡張する設計判断は、9 月以降の Implementer's Draft 切り出し（1_0_01.md）と 1.1-01 並行運用の前提条件を提供

5.2 1.0 section header 整形と 1.1 への boxcarring 追記 commit 4f5c4b5（2024-07-03、ogazitt） ​

同じく main への直接 commit。

  • 変更内容:
    • api/authorization-api-1_0.md を +38/-33 行で改訂: section header 階層を H2 → H3 へ降格、複数形 / 単数形の用語統一（"Subjects" → "Subject"、"Resources" → "Resource"）、Access Evaluation API 節の introductory content 追加
    • api/authorization-api-1_1.md を +376/-68 行で改訂: boxcarring（Access Evaluations、複数形）の本文を追加、Access Evaluation API への cross-reference を整備
  • 意義:
    • 1.0 の section 構造を Implementer's Draft 候補としてレンダリング可能な水準に整えた作業。後の 8-14 draft 00 publish に向けた章構成の確定
    • 1.1 の boxcarring セクションがこの commit で初めて実体を伴った形で投入され、7-09 コールでの dynamic resource 議論と並行して、技術的核（複数評価の一括処理）が固まり始めた

5.3 PR #122 "Add PlainID Support"（vladiber、2024-07-10 起票 → 2024-08-06 マージ） ​

interop 実装拡大の起点となった 7 月の唯一の機能 PR。

  • PR 内容: PlainID PDP を interop website / backend に統合
  • 構成: 4 commits（うち 2 件は main からの merge）。実体は interop/authzen-todo-backend への PlainID 用 evaluator 統合および interop/authzen-interop-website/docs/results/plainid.md の追加
  • 議論: Netlify bot の deploy preview 通知と ogazitt の approval のみで、実質的な review コメントは少数。これは PlainID 側がローカルで動作確認を済ませた上で PR を投げる運用が定着していたことを示唆
  • 7 月内の派生作業: commit ea1e109（2024-07-22、Vladi Berger）で PlainID interop 結果ファイル interop/authzen-interop-website/docs/results/plainid.md を +55 行で追加。テスト全件 pass の結果（ユーザー一覧取得、todo 管理、削除等の permission チェック）を初投入
  • 意義: 8 月の Authenticate 2024 interop 準備フェーズにおける PDP 多様性確保の一翼。7 月時点で PlainID が新規参加 PDP として確実に組み込まれた ことが、後の「13 実装規模」表明（9-17 ML #196）の構成要素を形成

5.4 PR #121 dependabot braces 3.0.2 → 3.0.3（dependabot[bot]、2024-07-03 起票 → 2024-08-13 マージ） ​

interop/authzen-interop-website の braces パッケージ脆弱性対応。GHSA-grv7-fg5c-xmjg（Uncontrolled resource consumption）への対処。7 月内には未マージで 8-13 にマージ。

5.5 継続中の Issue: #116 / #109 / #111（6 月以前起票） ​

7 月内に新規 Issue は起票されなかったが、6 月以前から open のままだった主要 Issue は引き続き未解決:

  • #116 "Comments on draft 1.0"（baboulebou、2024-06-20 起票）: 1.4.2 節 Resources で id を optional にする意味（omitted ID = search operation か）を問い、「1.0 では id を mandatory にすべき」と提案。7 月の Todo interop 議論（singleton todo_list 採用）と直接連動する論点。この提案が 7-09 コール周辺で実質的に採用される形で issue は後日 close される
  • #109 "Use JSON schema to describe request/response payloads"（cdanger、2024-05-27 起票）: request/response の payload を JSON Schema で記述すべきという提案。後の 8-20 / 9-03 コールで「json-schema / gRPC 互換のペイロード構造に作り直す」議論として再浮上する遠因。7 月時点では公開議論なし
  • #111 "Fix action names in interop scenario"（cdanger、2024-05-27 起票）: can_read_user のような can_* 命名を「cumbersome and not really appropriate」と批判し、read_user / read_todos / create_todo への simplification を提案。8-07 起票の Issue #123（johakoch）と 9-23 起票の Issue #154（randomstuff / Gabriel Corona）が同じ論点を再提起する 系譜の出発点。7 月時点では具体的なアクションなし

6. 関連イベント ​

IETF 120（Vancouver、2024-07-20 〜 26）OAuth WG セッション ​

  • 発表者: David Brossard（Axiomatics、AuthZEN WG 共同議長）
  • 発表 1: AuthZEN Profile of OAuth RAR（15 分） — OAuth Rich Authorization Requests（RFC 9396）の authorization_details 構造に AuthZEN の SARC（Subject / Action / Resource / Context）モデルを載せる profile 案
  • 発表 2: ALFA 2.0 Authorization Policy Language（15 分） — 認可ポリシー記述言語（XACML 系譜）のアップデート
  • 報告: ML #188（David Brossard、2024-07-29）
  • 意義:
    • AuthZEN が OIDF 内部から IETF OAuth WG コミュニティへ拡張された最初期の記録
    • 後の 9 月コールで「OAuth RAR と AuthZEN profile の整合性に乖離がある」「OAuth grant management API を AuthZEN Search API の統合ポイントとして探索」という議論の起点

Identity Information Workshop（IIW）セッション ​

  • 言及: ML #188 で David Brossard が「back in October」に Eve Maler が主導した IIW セッションを参照し、ノートへのリンクを案内
  • 共有資料: ML #188 から参照可能なノートリンク（公開リンクは pipermail 本文非取得のため詳細未確認）
  • 意義: WG メンバーの Eve Maler が IIW で AuthZEN 関連のディスカッションを主導していたことが記録されている。「back in October」という表現から、2023 年 10 月開催の IIW XXXVII を指していると推定される

7 月時点で予告された対外イベント（明示なし） ​

7 月の ML / commit からは、後の月で頻出する Authenticate 2024（10 月）/ IIW XXXIX（10 月）/ KubeCon（11 月）/ Gartner IAM Summit（12 月）等への明示的言及は確認できない。これらの言及が顕在化するのは 8-06 コール議事録（ML #189）以降であり、7 月時点では IETF 120 への参加実績と次の Asia-Pacific 向けコール開催が直近の関心事だったことが特徴。

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

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

  • 1.0 spec を Implementer's Draft 候補水準まで仕上げる: Security Considerations / IANA Considerations / Notices などの章を追加し、OIDF 標準仕様としての体裁を整える（実際にはこれが 8 月前半の集中作業となる）
  • 1.0 の OIDF Board への提出: 7 月末時点では正確な期日は未公示。後の 8-06 コール（ML #189）で「8 月 14 日水曜までに提出」と明確化される
  • 1.1 boxcarring の継続開発: Todo interop の dynamic resource 設計議論（7-09 コール）で確立した singleton todo_list 構造を 1.1 にも反映し、boxcarred Access Evaluations API の使用例を整備
  • PlainID PDP マージと interop 結果ファイル整備: PR #122 のマージ完了（実際は 8-06）と、PlainID を含む全 PDP の interop 結果を website に反映
  • IETF OAuth WG との継続対話: AuthZEN Profile of OAuth RAR を完成形に近付ける作業。Asia-Pacific 向け追加コールを通じてグローバル参加を強化
  • GitHub Issue ベースの議論文化への移行: ML #179 で Omri Gazitt が呼びかけた通り、技術論点の追跡を Issue へ集約する（実際の Issue 起票活性化は 8 月以降）
  • 継続中 Issue の解消: #116（resource id mandatory 化）、#109（JSON Schema 化）、#111（can_* 命名 simplification）への正式な対応方針

8. 参考情報源 ​