idbok

Appearance

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

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

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 年 6 月時点の共同議長は Omri Gazitt（Aserto）、David Brossard（Axiomatics）、Gerry Gebel（Strata Identity）の 3 名で、定例コールは火曜開催（6 月から複数タイムゾーンを輪番でカバーする alternating times 運用に移行）。

2024 年 6 月の AuthZEN WG は、「Identiverse 2024（5/28-31、Las Vegas）の interop デモ成功を踏まえ、最初の Implementer's Draft 提出に向けて API spec を絞り込んだ月」 に位置付けられる。月初は Identiverse で議論された boxcarring（複数評価の一括処理）提案 のレビューが ML を占めたが、6 月 18 日にマージされた PR #113 で Search API と Boxcarring API を 1.0 spec からいったん除去し、シンプルな単一評価 API に集中する方針が確定。続く 6 月 25 日のコールでは Resource ID を mandatory にする設計判断が合意され（PR #117）、6 月 19 日には David Brossard が「consensus around the first implementer's draft」（ML #168）と宣言できる水準まで到達した。

openid-specs-authzen ML への 6 月分投稿数は 31 件（2024 年 6 月アーカイブ の 000148〜000178、6 月 1 日 〜 6 月 28 日）。GitHub openid/authzen リポジトリの 6 月活動は 新規 Issue 1 件（#116 "Comments on draft 1.0"）、新規 PR 7 件（うち spec 関連 4 件、依存更新 3 件）、main ブランチへの commit 18 件。なお 6 月 4 日の WG コールは Identiverse および EIC（6/4-7、Berlin）の重複により事前にキャンセルされ（ML #150）、定例は 6 月 11 日から再開されている。

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

  • Boxcarring 提案の徹底レビューと、いったん 1.0 から除外する判断 — Identiverse で「batted around」された boxcarring 提案を Omri Gazitt が HackMD ドキュメント化し（ML #148、6-01）、レスポンス形状（array vs keyed object）、後方互換性、エラー伝搬、DoS 防御、stop-on-error / stop-on-deny フラグなど 16 通の議論が交わされた。最終的に 6-12 commit ce7fbb5（PR #113）で Boxcarring と Search API を 1.0 spec から除去し、後続バージョンに送る判断が下された
  • Resource ID を mandatory にする設計合意（6-25 コール → 6-27 PR #117） — Alex Babeanu が ML #169 で Issue #116 を立て、「1.4.2 節で id が OPTIONAL だと、id 無し = search リクエストと解釈されないか？」と曖昧性を指摘。David Brossard が「Can Alice view record #123? という discrete な質問と Can Alice view records as a whole? という search 的な質問を分離すべき」と整理し、6-25 コールで resource id mandatory を合意。PR #117 が 6-27 起票・6-28 マージで反映
  • HTTP ステータスコード（401/403）と PDP の deny decision の区別を明文化（PR #118） — 4-06 起票の Issue #86（independentid）が「PDP API への 401/403 と、PEP が 200 + deny を受けて client に返す 403 は別物。spec で明確に区別すべき」と提起していた件を、Omri Gazitt が 6-27 PR #118 で解消
  • コールタイムの alternating times 運用開始と APAC 参加の確立 — David Brossard が ML #165（6-18）で「we're now using alternating times to accommodate everyone」と宣言し、6-18 コールを 3pm PT（APAC フレンドリー）で開催。同コールには「pretty good attendance」が得られ、後の APAC コールトラック確立の起点となった

これらの議論を経て、6 月末時点で 1.0 spec は single evaluation API + mandatory resource id + HTTP error code 明文化 の体裁を整え、Gerry Gebel が OpenID リーダーシップと Implementer's Draft 提出に向けた liaison を進めるフェーズに入った（ML #172）。これが翌 7 月の 1.0 / 1.1 分岐宣言（ML #179、boxcarring を 1.1 として fast follower 化）に直結する。

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

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

  • URL（リポジトリ）: api/authorization-api-1_0.md（openid/authzen main ブランチ）
  • プレビュー: openid.github.io/authzen/ で GitHub Pages から自動レンダリング
  • 6 月内の主要改訂:
    • commit ce7fbb5（2024-06-12、ogazitt、PR #113）: Evaluations API と Search API を spec から除去、JSON 形式の全面再整理、subject ID を RFC 9493（Subject Identifiers for SET）準拠化（@tulshi の先行作業を基盤）、subject / object の type を mandatory 化、action の name を required 化、HTTPS binding を transports セクションへ統合、全 JSON example への解説追加、bullet list レンダリング修正、文法・スペル修正
    • commit c1dd00c（2024-06-18、ogazitt）: PR #113 のレビュー反映
    • commit 1f73450（2024-06-19、ogazitt）: small errata
    • commit 106a982（2024-06-19、tulshi、PR #115）: Omri Gazitt を primary author として明記
    • commit d44ee68（2024-06-27、ogazitt、PR #118）: HTTP 401/403 を PDP API への認可エラーとして明示し、PEP が deny decision を受けて返す 403 とは別物であることを spec 上で区別（Issue #86 解消）
    • commit 757b20c（2024-06-27、ogazitt、PR #117）: Resource id を OPTIONAL から REQUIRED へ変更
    • commit 71cf531（2024-06-27、ogazitt）: 上記に伴い JSON example を mandatory resource id 準拠に修正
  • 位置付け: OIDF への最初の Implementer's Draft 提出に向けた絞り込みフェーズ。6 月の作業で「single evaluation API のみを 1.0 のスコープとする」方針が確定し、Search / Boxcarring は将来バージョンへ送られた。後の 7-03 に Omri Gazitt が api/authorization-api-1_1.md を新設し、boxcarring を 1.1 spec の fast follower として再合流させる経路がこの月に準備された

Boxcarring 提案（HackMD ドラフト） ​

  • 形態: 公式 spec ではなく、HackMD 上の議論用ドキュメント（ML #148 で初回投稿）
  • 発端: Identiverse 2024（5/28-31）の現場ディスカッションを Omri Gazitt が文書化
  • 6 月内の改訂: 初版（array レスポンス）→ Alex Olivier の指摘を受けて keyed object 形式に変更 + エラーセクション追加（ML #153、6-06）→ 6-11 / 6-13 コールで stop-on-error / stop-on-deny フラグや capability negotiation の議論を経て段階的に整備
  • 6 月末の到達点: 6-25 コールで「Boxcarring の overall design に full consensus」と David Brossard が報告（ML #172）。ただしこの時点では 1.0 spec から除去された状態で、別ドキュメントとして温存。これが翌月 7-03 に Authorization API 1.1 として正式 spec 化される
  • 位置付け: AuthZEN コア仕様の boxcarring 拡張は 6 月に技術的合意は得られたが、1.0 implementer's draft の射程外として明示的に切り離された。WG が「最小限の最初のドラフトを早く出す」戦略を取った象徴

依存パッケージ更新（dependabot） ​

  • PR #114 ws 7.5.7 → 7.5.10 (/interop/authzen-todo-application)、6-18 マージ
  • PR #119 braces 3.0.2 → 3.0.3 (/interop/authzen-todo-application)、6-28 マージ
  • PR #120 ws 7.5.9 → 7.5.10 (/interop/authzen-interop-website)、6-28 マージ
  • 既存 PR #101 ejs 関連も 6-28 にマージ完了
  • いずれも interop デモ環境の脆弱性対応で、spec 本体には影響なし

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

AuthZEN WG は通常毎週火曜にコールを開催している。2024 年 6 月の暦上の火曜は 6 月 4 日・6 月 11 日・6 月 18 日・6 月 25 日 の 4 枠だが、6 月 4 日は Identiverse 2024（5/28-31、Las Vegas）および EIC 2024（6/4-7、Berlin）の重複によりキャンセルされた（ML #150、Omri Gazitt、6-03）。実質開催されたのは 6-11 / 6-18 / 6-25 の 3 回。

議事録は HackMD 上の @oidf-wg-authzen チームスペースで管理されており、ML には個別の議事録投稿ではなく週次サマリが流れる運用。

6 月 4 日（火）コール — キャンセル ​

  • キャンセル理由: Identiverse および EIC への参加者集中
  • アナウンス: ML #150（Omri Gazitt、2024-06-03）「our next AuthZEN WG meeting will be June 11, on account of Identiverse and EIC」「5-21 のミーティングで決定済み」
  • 代替活動: ML 上で boxcarring 提案のレビューを継続。HackMD ドキュメントへの直接コメントも受付

6 月 11 日（火）コール — Boxcarring レビュー再開 ​

  • 議題の中心: Identiverse / EIC を挟んだ後の boxcarring 提案レビュー
  • 議事録の独立投稿: ML 上に明示的な議事録投稿は確認できない
  • 読み取れる議論内容（前後の ML 投稿および同日 commit からの再構成）:
    • 6-11 当日に Roland Baum（ML #156、18:28 UTC）が「main request と evaluations 内の context に異なる時刻が指定された場合の優先関係」を具体例（time: 2024-05-31 vs 2024-06-01）付きで質問
    • Omri Gazitt が同日 19:11 UTC（ML #157）に 「main request は default、evaluations 内の値が個別に override する」 という precedence ルールを明文化して回答
    • これが boxcarring の参考実装意味論（main request as defaults + per-evaluation overrides）として固まる起点

6 月 18 日（火）コール — 1.0 spec 大幅 refactor のレビュー、APAC コール初回 ​

  • アジェンダ通知: ML #164（David Brossard、6-18 05:37 UTC）「Omri has taken the time to update the spec and create a new pull request (#113)」「The main change is the focus on single request/response for this first draft as previously discussed」「Please read the PR and updates before the call tomorrow so we can discuss the changes」
  • タイムスロット: 通常の北米朝枠ではなく 3pm PT へ変更。ML #165（David Brossard、6-18 06:24 UTC）「Just a reminder we're now using alternating times to accommodate everyone. Tomorrow's meeting will be at 3pm PT.」と全員に再通知
  • 結果: 同日夜に David Brossard が ML #168（6-19 20:37 UTC）で「we had a pretty good attendance which comforts our decision to split calls」「we've reached consensus around the first implementer's draft」「huge thanks to Omri and Atul」と勝報を投稿。ML 内に GitHub markdown と GitHub Pages 公開版 のリンクを共有し、「GH issues or simply via the mailing list でフィードバックを」と呼びかけ
  • 意義:
    • AuthZEN がタイムゾーン分散運用に正式移行した日。後の 2024-07-29 ML #188 で David Brossard が「3pm PT / midnight CET / 8am AEST」の APAC コールを呼びかける運用はこの 6-18 が起点
    • 1.0 implementer's draft の 章構成および scope（single evaluation API）が確定した日

6 月 25 日（火）コール — Resource ID mandatory 化合意、Boxcarring の overall consensus ​

  • 議事録: David Brossard が 6-27 ML #172 として詳細サマリを投稿（"This week's meeting notes"）
  • アジェンダ（議事録より）:
    • Authenticate conference の進捗 — David と Alex Olivier が talk 提出済み、authZ workshop 開催の可能性
    • Draft spec process check — ドラフトへの feedback レビュー
    • Resource ID type mandatory 化の議論
    • Decentralized ID ユースケースと subject ID 解決
    • Boxcar proposal レビュー（時間があれば）
  • 決定事項 1: Resource ID mandatory — 「This aligns better to the spirit of the API which is to ask discrete Yes/No questions (Can Alice view document #123?) rather than what would be perceived as a search query」(議事録 2024-06-25 より)。Patrick P. が「Can a user drink beer? のような年齢のみで判断するシナリオ」を anonymous DID ケースとして提起し、DID world では subject ID に DID 参照を載せる方向が共有された
  • 決定事項 2: Boxcarring overall design に consensus — エラーハンドリングと stopping behavior の議論に集中し、「Policy Decision Point 実装は内部リクエスト上限と sanity check を強制すべき」「safeguards と DoS prevention の specifications を加える」方向で合意
  • 決定事項 3: Gerry が OIDF リーダーシップと連携 — Gerry Gebel が implementer's draft を spec status へ進めるための調整を進行中。「Björn from OpenID confirmed he will coordinate with Elizabeth Garner regarding site updates」(議事録より)
  • 目標タイムライン: 「interoperability を IIW（10 月）または Authenticate conference（10 月）までに達成する」 との目標を明示

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

openid-specs-authzen ML（2024 年 6 月アーカイブ）の 6 月総投稿数は 31 件（000148〜000178）で、AuthZEN WG 発足初期において最も活発な月のひとつ。技術議論として実質的な意味を持つスレッドは以下の 4 本。

4.1 Boxcarring proposal — 2024-06-01 開始（Omri Gazitt 起点、計 16 通） ​

6 月最大の議論スレッド。Identiverse でのオフライン議論を ML へ正式化したもの。

  • #148（Omri Gazitt、2024-06-01 01:20 UTC）: 「I wrote up the boxcarring proposal that we batted around during Identiverse」と HackMD ドキュメントへの誘導。既存の single-decision evaluation API との後方互換性を保ちつつ、複数評価用の plural endpoint へ接続できる設計を提案
  • #149（Omri Gazitt、2024-06-03）: Andrew Clymer から事前にもらっていた capability negotiation 観点のフィードバックを反映。「Policy discovery is one such scenario」と、後の discovery エンドポイント議論の伏線
  • #151（Alex Olivier、Cerbos、2024-06-03）: 「array レスポンスは入力と同じ長さ・順序が保証されるはずだが spec で明示すべき」「むしろ resource id や action 等で keyed object にすればクライアント側の処理が簡素化される（SDK が自動化できる）」 と具体的改善提案
  • #152（Granville Schmidt、2024-06-03）: Olivier 案に賛同しつつ「コメントは HackMD ドキュメント直書きと ML どちらが望ましいか」と運用方針を質問
  • #153（Omri Gazitt、2024-06-06）: フィードバックを反映し HackMD を更新（array → keyed object に変更、errors セクション新設）。「Tuesday の meeting で議論する」と次のステップを示唆
  • #154（Steven Venema、2024-06-09）: 後方互換性シナリオを具体化。「PEP が boxcarring 対応 + PDP がレガシーの場合、PDP は evaluations キーを未知として無視し、main request 部分のみを単一評価として処理してしまう。逆方向（PEP レガシー + PDP boxcarring 対応）は問題なし」。代替案として /access/v1/authorizations vs /access/v1/authorization のエンドポイント分離を提案
  • #155（Omri Gazitt、2024-06-09）: 「at this stage, we don't need to worry about that kind of back-compat, since we haven't yet a first implementer's draft」と、現フェーズでの後方互換性議論をデフォルメ。capability negotiation の必要性は認めつつも先送り
  • #156（Roland Baum、Umbrella Associates、2024-06-11）: main request と evaluations 配列の値の競合を具体例で問題提起。「main request の context に time: 2024-05-31、evaluations 内に time: 2024-06-01 がある場合の解釈は？」「evaluations 要素は完全な subject-action-resource-context tuple として独立させるべきでは」と設計指摘
  • #157（Omri Gazitt、2024-06-11）: 「main request は defaults、evaluations 内の値が個別に override」 という precedence を明示。Baum の例では eval-1 は 2024-06-01、eval-2 / eval-3 は default の 2024-05-31 を継承
  • #158（Alex Babeanu、3edges、2024-06-13）: 4 つの未解決点を整理。(1) 専用エンドポイント /access/v1/authorizations を spec で定義するか、(2) エラーステータスとエラーメッセージの標準化（トランザクション失敗 vs 個別失敗）、(3) intro でユースケース例を示すべき、(4) overall は good
  • #159（Eve Maler、2024-06-13）: 「all vs any セマンティクスを安易に追加すると、項目とレスポンスの順序付け・対応関係の複雑性が増す」「real-world のユースケースで substantiate してから決めるべき」と原則的警告
  • #160（Omri Gazitt、2024-06-13）: Babeanu と Maler のすべての論点に網羅的に応答。「現ドラフトでは single / multi-request の評価 API を別エンドポイントに分離している」「エラーは framework 段階のため詳細仕様は持たない、main spec の HTTPS binding が 400/401/403/500 のみ規定」「各 evaluation は independent なので独立した decision を返す（all/any 不要）」「UI state 評価が主要ユースケースとして複数の参加者から挙がっており、既存製品が multi-request をサポートしている」
  • #161（Alex Babeanu、2024-06-13）: all/any 議論の代替として、evaluations オブジェクトのトップレベルに stopOnError（default false）と stopOnDeny（default false）の 2 フラグを置く提案。caller の裁量で early-exit を制御
  • #162（Alex Babeanu、2024-06-13）: DoS 防御の必要性を別投稿で強調。「GraphQL 等は query cost analysis を実装している。spec で boxcarred requests の上限を標準化するか、最低限 security guidance を加えるべき」
  • #163（Andrew Clymer、Rock Solid Knowledge、2024-06-14）: SCIM の service provider configuration エンドポイントを参考案として提示。「wire protocol が固まったら、利用可能な機能と上限値を露出するエンドポイントを spec が定義する形が良いのでは」
  • 論点の集約:
    • レスポンス形状: array → keyed object（合意）
    • precedence: main = defaults、evaluations = overrides（合意）
    • エラー伝搬: stop-on-error / stop-on-deny フラグ案（採用方向）
    • DoS 防御: PDP 実装に上限強制を求める security guidance を spec に追加（採用方向）
    • 後方互換性: 1.0 implementer's draft 前なので不問
    • ただし 1.0 spec への直接組み込みは見送り、別 spec として温存 — 6-12 commit ce7fbb5 で 1.0 から Boxcarring API を除去
  • 意義: AuthZEN WG が 「最小限の単一評価 API で 1.0 を出し、boxcarring は別ドラフトに分離する」 という戦略的判断を下したスレッド。技術的議論自体は決裂したわけではなく、むしろ 6-25 コールで overall consensus に達したが、リリーススコープから外したことが翌 7 月の 1.0 / 1.1 分岐を準備した

4.2 Comment on latest draft — 2024-06-20 開始（Alex Babeanu 起点、3 通、Issue #116 参照） ​

PR #113 マージ後の最新 spec に対する最初の本格レビュー。後の 6-25 コール決定（resource id mandatory）に直結。

  • #169（Alex Babeanu、2024-06-20）: Issue #116 を立てたことを ML に告知。「a (little) can of worms?」と論点の発掘を表現
  • #170（David Brossard、2024-06-20）: 設計意図を整理。「Can Alice view record #123? と Can Alice view records as a whole? の 2 種のクエリを区別したい」「resource identifier 無しのリクエストは search 操作に近いが、別エンドポイントとして将来 API セクションで扱う」
  • #171（Omri Gazitt、2024-06-20）: 「Great question. I also replied in the issue.」と簡潔に同調。Issue 側で詳細議論
  • 意義:
    • 「discrete authorization query」 と 「search-like query」 を AuthZEN が明確に分離する設計哲学を ML 上で初めて明文化
    • 後の 1.0 では search を完全に除外し、Authorization API 1.0 = discrete only、Search API は別 spec として将来仕様化する経路がここで決定

4.3 This week's meeting notes — 2024-06-27 開始（David Brossard 起点、3 通） ​

6-25 コールの公式議事録および decentralized ID ユースケースの掘り下げ。

  • #172（David Brossard、2024-06-27）: §3 で詳述した 6-25 コール議事録本体
  • #174（Alex Babeanu、2024-06-27）: Patrick P. の anonymous DID シナリオに対する補強。「W3C Verifiable Credentials Data Model v2.0 では、privacy 配慮のため credential が id プロパティを省略できる。credentialSubject プロパティ自体は必須だが、その内部の identifier は必須ではない」。2 つのアプローチを提示: (a) id 無しの VC は AuthZEN の射程外（年齢確認等は issuer 検証で十分、PDP 不要）、(b) generic placeholder subject を許容して "anyone with this VC" を扱う。「this is really an edge case where a PDP wouldn't really be required. I'd vote to scope it out for now」 と AuthZen v2 への先送りを推奨
  • #175（Omri Gazitt、2024-06-28）: Alex の判断に同意。「in the DID world as I understand it, the decision has typically already been made by the authentication system」 と認証層で既に判定済みであるという DID の運用実態を補強。v2 への先送りを支持
  • 意義:
    • AuthZEN 1.0 が W3C VC の anonymous credential を明示的にスコープ外とした合意の記録
    • 後の DCP WG (Digital Credentials Protocols) や OpenID for Verifiable Presentations との境界線をここで設定

4.4 Authorization Use Case — 2024-06-27 開始（Kelly Sauke 起点、4 通） ​

外部ユーザーからの実装ユースケース問い合わせ。WG の設計哲学を整理する機会となった。

  • #173（kelly@sauke.net、2024-06-27）: 3 つの設計前提を提示: (1) フロントエンドは認可判定をしない、(2) UI は UX のための pre-authorization のみ可、(3) microservice は実装詳細を露出しない。複合的に: orchestration microservice が複数の enterprise policy をラップする場合に standard interrogation endpoint をどう設計するかを質問。/access/v1/evaluation を AuthZen contract 準拠で露出 vs HTTP OPTIONS vs 専用 UI ポリシー、を選択肢として提示
  • #176（David Brossard、2024-06-28）: 3 つの原則すべてに賛同（OWASP C5/C7 への言及）。orchestration ケースには 2 案を提示: (a) UI 専用と業務専用のポリシーを分離する、(b) 業務ポリシーのみを使い、AuthZEN の evaluation endpoint または Search API で UI が利用可能な機能を判定する。「(b) のほうがクリーンだが開発者負担は大きい。とはいえベストプラクティスとして推奨」
  • #177（Omri Gazitt、2024-06-28）: OPA を用いた具体実装例を提示。「allowed で backend enforcement、visible/enabled で UI hint を同じポリシーから返す」。DELETE エンドポイントに対する ABAC 例（user が Operations 部門で IT Manager の title を持つ場合）を JSON で示し、「filtering（ユーザーがアクセス可能なリソース一覧の取得）は forthcoming AuthZEN search API を使う」と Search API の将来導入を明言
  • #178（Alex Babeanu、2024-06-28）: 粒度の整理。「coarse-grained UI access（pre-authorization）はビジネスユーザー / アプリ管理者が著者」「fine-grained microservice policy は開発者 / マイクロサービス担当者が著者」「両者をつなぐマッピングが必要、PDP は AuthZen 呼び出しに対する blackbox として両方を解決する」
  • 意義:
    • PDP の責任範囲 = backend authorization + UI hint という設計哲学を WG が明文化した記録
    • 「Search API は将来仕様」と Omri Gazitt が ML 上で明言した最初期の記録。後の /access/v1/evaluations (boxcarring) および Search API の独立仕様化の道筋を提供
    • AuthZEN が PDP-as-blackbox 哲学を採用したことを 3 共同議長クラスの参加者で確認

5. GitHub 上の議論 ​

openid/authzen リポジトリの 2024 年 6 月活動: 新規 Issue 1 件（#116）、新規 PR 7 件（spec 関連 #113 / #115 / #117 / #118、依存更新 #114 / #119 / #120）、main ブランチへの commit 18 件。

Issue 起票数が ML 議論量に比して少ない（1 件のみ）のは、WG が依然として 「議論は ML、決定は PR」 の運用モードにあったことを示す。GitHub Issue ベースの議論文化が定着するのは Implementer's Draft 公開後の 8 月以降（Issue #123 等）。

5.1 PR #113 "refactor API spec to remove search and boxcarred apis and cleanup"（ogazitt、2024-06-12 起票 → 2024-06-19 マージ） ​

6 月最大の spec 変更。1.0 implementer's draft の scope を確定。

  • PR 内容（PR description より）:
    • Evaluations API および Search API を spec から除去
    • JSON 形式の全面再整理
    • subject ID を RFC 9493（Subject Identifiers for SET）に整合（@tulshi の先行作業を基盤）
    • subject および object の type フィールドを mandatory 化
    • action の name フィールドを required 化（事前合意済み）
    • HTTPS binding ドキュメントを transports セクションへ統合
    • 全 JSON example に解説アノテーションを追加
    • bullet point レンダリング修正
    • 文法・スペル修正
  • ファイル変更: 主に api/authorization-api-1_0.md（大規模 refactor）
  • レビュー:
    • @davidjbrossard（6-18）: 複数ラウンドのレビューと inline コメント
    • @tulshi（6-18）: レビュー、6-19 に承認
    • @ogazitt: 6-19 commit c1dd00c でフィードバック反映
  • 意義:
    • AuthZEN 1.0 spec の scope を「single evaluation API のみ」に確定した PR
    • Search と Boxcarring を 1.0 から切り離す戦略的判断
    • RFC 9493 準拠の subject identifier フォーマットを採用し、Shared Signals Framework との将来的な互換性を担保

5.2 PR #117 "make resource id mandatory"（ogazitt、2024-06-27 起票 → 2024-06-28 マージ） ​

Issue #116 を解消する spec 修正。

  • PR 内容: 6-25 コールの WG 決定（resource id mandatory）を反映。api/authorization-api-1_0.md 内で Resource id フィールドを OPTIONAL → REQUIRED へ変更。関連ドキュメント更新と全 example の修正
  • レビュー: davidjbrossard（6-27）「Ok, approving」と承認
  • 関連 commit: 757b20c（mandatory 化本体）と 71cf531（example 修正）の 2 commit 構成
  • 意義:
    • AuthZEN 1.0 が「discrete Yes/No question」専用 API として固まった象徴
    • 後の Search API（resource id を持たないクエリ）の独立仕様化の前提条件
    • 翌 7 月の Todo interop 議論（ML #183 〜 #186）で「mandatory resource id をどう dynamic resource に適用するか」が再燃する伏線

5.3 PR #118 "clarify https error codes vs deny decisions"（ogazitt、2024-06-27 起票 → 2024-06-27 マージ） ​

Issue #86（independentid、2024-04-06 起票）を解消。

  • Issue #86 の論点: spec が 401 Unauthorized / 403 Forbidden を単に列挙するのみで、(a) PDP API への HTTP client 認可エラー、(b) PEP が PDP から 200+deny を受けて返す HTTP 403、の区別が不明瞭だった
  • PR 内容: spec 内で 「HTTP ステータスコードは PDP API への HTTP client の認可状態を表す」「PEP が client に 403 を返すのは PDP からの 200 + deny decision に基づく場合が典型」 と明示
  • レビュー: davidjbrossard が当日中にマージ
  • 意義:
    • PDP-as-API と PEP-as-API の責任境界を spec で初めて明文化
    • Implementer's Draft 提出前の最終的な曖昧性除去作業のひとつ

5.4 PR #115 "making Omri the primary author"（tulshi、2024-06-19 起票 → 2024-06-19 マージ） ​

著者順の整理。Atul Tulshibagwale（tulshi）が Omri Gazitt を primary author として明記する変更。実質的な spec 変更ではないが、Implementer's Draft 提出に向けた書誌情報整備の一環。

5.5 Issue #116 "Comments on draft 1.0"（baboulebou、2024-06-20 起票 → 2024-06-28 close） ​

6 月唯一の新規 Issue。

  • 論点: 1.4.2 節 Resources で id を OPTIONAL とすると、id 無しのリクエストが search 操作と解釈されてしまう。1.0 では id を mandatory にすべき
  • 解決: 6-25 コール合意 → PR #117 マージで close
  • 意義: WG が ML 議論で提起された設計疑問を即座に Issue → PR → spec 反映へ繋いだ模範ケース。ML → Issue → PR → spec 改訂のサイクルタイムが 1 週間以内に収まる WG の機動力を示す

5.6 依存更新 PR（#114 / #119 / #120） ​

  • PR #114 ws 7.5.7 → 7.5.10（dependabot[bot]、6-18 マージ、/interop/authzen-todo-application）
  • PR #119 braces 3.0.2 → 3.0.3（dependabot[bot]、6-28 マージ、/interop/authzen-todo-application）— GHSA-grv7-fg5c-xmjg 対応
  • PR #120 ws 7.5.9 → 7.5.10（dependabot[bot]、6-28 マージ、/interop/authzen-interop-website）
  • spec 本体への影響はなし、interop デモ環境の脆弱性追従

6. 関連イベント ​

Identiverse 2024（Las Vegas、2024-05-28 〜 31）— 6 月議論の起点 ​

6 月 1 日の ML #148 で Omri Gazitt が「the boxcarring proposal that we batted around during Identiverse」と書いている通り、boxcarring 提案は Identiverse 2024 の現地ディスカッションで形成されたアイデアを ML に持ち込んだもの。AuthZEN WG はすでに 5-29 OIDF アナウンス「AuthZEN Work Group Announces Authorization Interop Results」で Identiverse 当日の interop 結果を公表しており、その勢いを 6 月の spec 確定作業に直接接続した形となる。

EIC 2024（Berlin、2024-06-04 〜 07） ​

ヨーロッパの主要 IAM カンファレンス。AuthZEN WG コール 6-04 がキャンセルされた直接の理由のひとつ（ML #150）。AuthZEN メンバーの David Brossard（Axiomatics）、Omri Gazitt（Aserto）らが現地参加。具体的セッション内容は 6 月 ML 上では明示的に報告されていない。

Authenticate 2024（10 月）への提出準備 ​

6-25 コール議事録（ML #172）で David Brossard が 「David had a talk accepted」「Alex Olivier also submitted a talk」「Potentially open to having an authZ workshop」 と報告。10 月 Authenticate での発表と authZ workshop 開催が 6 月時点で具体化していた。

IIW（10 月想定） ​

6-25 コール議事録の「aim to achieve interoperability by IIW or the Authenticate conference」（議事録 2024-06-25 より）が示す通り、IIW XXXIX（2024 年 10 月開催想定）を interop マイルストーンに据えていた。

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

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

  • 1.0 Implementer's Draft の OIDF 提出に向けた最終調整: Gerry Gebel が OpenID リーダーシップと liaison 中。Björn は OIDF サイト更新を Elizabeth Garner と調整予定（実際には 8-14 公開へ繋がる）
  • Boxcarring の別 spec への切り出し: 6-25 コールで overall consensus に達した boxcarring を、1.0 とは別の spec として継続。具体的には翌 7-03 に api/authorization-api-1_1.md として新規作成される（本レポート対象外、2024 年 7 月レポート を参照）
  • Search API の将来仕様化: 6 月の議論で「forthcoming AuthZEN search APIs」（ML #177）と Omri Gazitt が明言。具体的タイムラインは未定だが、UI filtering ユースケースを含めて将来別 spec として進める方向
  • DoS 防御と stop-on-error / stop-on-deny フラグ: boxcarring spec 化時に取り込む方向で議論決着
  • alternating times 運用の継続: 北米時間 + APAC フレンドリー時間の輪番化。後の 7 月 / 8 月へ継承
  • interop 実装の継続拡大: 5-29 アナウンスで報告された interop 参加 PDP（Aserto、Axiomatics、Cerbos、SGNL 等）に加え、後の PlainID（7-10 PR #122）等の追加実装を Authenticate 2024 までに整備
  • W3C VC anonymous credentials の v2 送り: AuthZEN 1.0 では明示的にスコープ外。AuthZen v2 で再検討
  • Authenticate 2024（10 月）での発表 / authZ workshop: David Brossard と Alex Olivier の talk 採択済み

8. 参考情報源 ​