idbok

Appearance

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

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

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 年 4 月時点の共同議長は Omri Gazitt（Aserto CEO）と David Brossard（Axiomatics CTO）であり、定例コールは隔週で時間帯を入れ替えるハイブリッド運営に移行する転換点を迎えていた。

2024 年 4 月の AuthZEN WG は、「Identiverse 2024（5/28-31, Las Vegas）での初の公開 interop イベントへ向けて、仕様文書・interop スイート・実装側の準備を一気に立ち上げた月」 に位置付けられる。Omri Gazitt が起票・マージした PR #85（4-04 起票 → 4-09 マージ）によって 「Access Evaluation API（単一評価）」と「Access Evaluations API（複数評価／boxcarred）」を仕様上明確に分離 する重要なリファクタが入り、続く PR #88 でエンドポイントが /access/v1/evaluations から /access/v1/evaluation へと移行。4-15 月曜には Google Sunnyvale キャンパスで開催された OpenID Foundation Workshop で David Brossard と Omri Gazitt が WG アップデートを発表し、翌 4-16 火曜の定例コール直前（4-16〜18）には Mountain View で Internet Identity Workshop XXXVIII（IIW 38）が開催。Omri Gazitt が IIW 38 で AuthZEN interop セッションを主導した。月末の 4-30 コールでは David Brossard が 「OpenID AuthZEN - Boxcarring Requests」プレゼン（ML #136）を共有し、後の 5 月 PR #102 / 6 月 boxcarring 提案へと繋がる設計議論の出発点を作った。

openid-specs-authzen ML への 4 月分投稿数は 35 件（2024 年 4 月アーカイブ の 000104〜000138）。Identiverse 関連の社交イベント告知（Happy Hour / Pre-Interop）が多くを占めるが、技術議論として重要な (a) Eve Maler 起点の "layered-semantics interop/compliance" スレッド（#114〜#122、9 通）、(b) 月末の "Inconsistencies in the Interop payloads?" スレッド（#133, #138）、(c) 週次コール時間調整スレッド（#123〜#125 + 4-16 議事録 #126） の 3 本が議論の主軸を形成した。GitHub openid/authzen リポジトリの 4 月活動は 新規 PR 15 件（うち 4 月内マージ 14 件、1 件は close → 同等内容を別 PR で再投入、月跨ぎマージ 3 件を 4 月起票として含む）、新規 Issue 2 件（#86, #87）、main ブランチへの commit 35 件以上。

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

  • Access Evaluation API と Access Evaluations API の仕様上の分離（PR #85） — Omri Gazitt が 4-04 起票・4-09 マージ。Interop シナリオが暗黙的に使っていた「単一評価」と、仕様文書に既に書かれていた boxcarred 版「複数評価」を別の章として明文化し、エンドポイントを /access/v1/evaluation（単一） と /access/v1/evaluations（複数）に統一する大規模リファクタ
  • Context フィールドのレスポンス側追加と obligations / advice 議論の出発点（PR #90, ML #114〜#122） — Eve Maler（xmlgrrl）が HEART / FHIR の経験を踏まえて「PEP と PDP の layered semantics（capability negotiation, obligations, advice）」議論を起こし、Omri Gazitt が response 側に context フィールドを追加する PR で受け止め、4-16 コールで具体的な議論へ
  • 隔週 11am PT / 3pm PT への定例コール運用切替（ML #126） — David Brossard が SurveyMonkey で時間希望を調査（13 名回答、10 名が単一時間帯希望）、4-16 議事録で 「11am PT on even weeks and 3pm PT on odd weeks」 を採択。地理分散参加者（欧州・米西海岸）の双方をカバーするための運用変更
  • Identiverse 2024 Interop（5-28）に向けた準備加速 — 実装側では Aserto / Topaz・Cerbos・Kogito（PR #84）・SGNL（PR #95）の 4 実装が 4 月時点で interop conformant、加えて Hexa / Strata, Axiomatics, Permit.io, OPA が "in development"。Postman Collection 更新（ML #134）、Interop 招待状送付（ML #131、4-29 配信）、当初予定していた Happy Hour の一旦キャンセル（ML #130、4-23、後に 5 月 BrewDog で復活）

加えて月末 4-30 コール（ML #135 の Roland Baum の欠席連絡が同コール開催の傍証）では、David Brossard による 「OpenID AuthZEN - Boxcarring Requests」プレゼン共有（ML #136、4-30 17:59 UTC）と、現行 interop payloads の不整合（userID vs ownerID）の指摘（ML #133）・Omri Gazitt による「expediency 重視で意図的に統一していない」釈明（ML #138）が並行して走った。これらは翌月以降の Decisions API 仕様化試行（5 月 PR #102）、boxcarring HackMD ドキュメント正式提案（6 月 ML #148）、can_* 命名規約論争（5 月 Issue #111 〜 9 月以降の Gabriel Corona フィードバック）の直接の前段に当たる。

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

Authorization API ドラフト（4 月時点の状態） ​

  • 形態: openid.net/specs/ 配下への正式 publish は 未実施。リポジトリ内 markdown（api/authorization-api.md 系列）+ GitHub Pages プレビューでのみ公開。8-14 の Implementer's Draft 00 publish にはまだ 4 ヶ月先行する初期段階
  • 4 月時点の主要編集作業:
    • PR #85 "updated spec to include a separate single-evaluation API description, and other cleanup"（ogazitt、2024-04-04 起票 → 2024-04-09 マージ、commit 8966f31）: 4 月最大の仕様変更 PR。3 つの主要変更を一括投入
      • JSON キーをすべて lowercase に統一（payload examples 全箇所）
      • 既存の「Access Evaluation API Request/Response」セクション群を 「Access Evaluations」（複数形）にリネーム → boxcarred / 複数評価版を意味する命名へ
      • 単一評価のための 「Access Evaluation API Request/Response」（単数形）セクションを新規追加 — これが interop シナリオで実際に使われていた API
      • JSON インデントを 2-space に統一
      • エンドポイント URL を /access/v1/evaluation（単一）と /access/v1/evaluations（複数）に整理
    • PR #88 "updated todo backend evaluation api to conform to new spec"（ogazitt、2024-04-09 起票・即日マージ、commit 376a4fe）: 上記 spec 変更を todo-backend 実装へ反映。エンドポイントを /access/v1/evaluations → /access/v1/evaluation に変更
    • PR #89 "Api/evaluation context"（ogazitt、2024-04-09 起票・即日 close、非マージ）: 同日に PR #90 として再投入されたため close。Netlify deploy review が pending だった形跡が残る
    • PR #90 "updated eval calls to include 'context' in response, and fixed CI"（ogazitt、2024-04-09 起票 → 2024-04-11 マージ、commit 1139587）: レスポンス側に context フィールドを追加し、既存の "reason object" を context 内に統合。CI publish 失敗も併せて修正。Alex Babeanu の「How would a PDP know what values to add in there?」という形式化を求める指摘に対し、Omri Gazitt は「まず仕組みだけ入れて、後で profiles を定義して capability negotiation を進める」と回答する設計判断を表明。後の 4-16 コールで Eve Maler の HEART / FHIR ベース提案を受ける土台がこの PR で整備された
    • PR #97 "Minor editorial changes"（adeinega、2024-04-19 起票、月跨ぎで 5-15 マージ）: 編集レベルの軽微修正。4 月内に commit 6187ac0（4-19）として最初の編集が main へ反映済み
  • 位置付け: 4 月は 「仕様文書を interop シナリオの実態に合わせる」整合作業の月。単一評価／複数評価の分離（PR #85）が仕様の構造を変える土台となり、context フィールド追加（PR #90）が次月以降の obligations / advice / capability negotiation 議論の入口となった

Interop シナリオ（Todo アプリ）— 仕様の事実上の reference ​

4 月時点で AuthZEN WG にとって、Todo アプリの interop シナリオは 「仕様の事実上のリファレンス実装」 として機能していた。仕様改訂と interop 整備が同期する運用が確立。

  • シナリオ定義ファイル: interop/authzen-interop-website/docs/scenarios/todo.md（authzen-interop.net 配下に published）
  • アクション命名: can_read_user, can_read_todos, can_create_todo, can_update_todo, can_delete_todo 等の can_* プレフィックス記法。5 月末に Cyril Dangerville（Thales、Issue #111）が違和感を表明する 1 ヶ月前段階
  • 4 月内の整合改善作業:
    • 4-03 PR #83（ogazitt）: directory.ts の roles 属性追加、"key" → "id" リネームで interop payload doc と整合
    • 4-04 PR #84（eazerad = Elie Azerad）: Kogito を PDP リストに追加。pdps.json 更新
    • 4-13 PR #94（ogazitt）: test スクリプトを AUTHZEN_PDP_API_KEY 環境変数に切替（SGNL の API key 認証対応）
    • 4-13 PR #95（ogazitt）: SGNL を interop results に追加（commit e96d4d4）
    • 4-14 PR #96（tulshi）: SGNL endpoint URL を https に修正
    • 4-30 PR #98, PR #99（davidjbrossard）: Axiomatics の endpoint 追加と results 追加 — 4-30 月末コール前後の起票、月跨ぎで 5-01 マージ
  • dependency 更新群（4-05 と 4-12）: express, webpack-dev-middleware, tar 等を dependabot 起点で順次更新（commit c267eff, d358377, 6a7498e, 2fee3af, e5c999b, 3d24771, 5d79581, fa26971, 259f21b, 6839fe4, fca9697, b777ef1, PR #91 Bump tar 6.1.15 → 6.2.1 等）。Identiverse interop に向けたセキュリティ・依存性メンテナンスの一環

4 月時点の interop conformant 実装 ​

4-15 OIDF Workshop で David Brossard / Omri Gazitt が発表した内容（OIDF Workshop 2024-04-15 配布資料）によれば:

  • Conformant（4 実装）: Aserto Topaz, Cerbos, Kogito, SGNL
  • In development（3 実装以上）: Axiomatics, Permit.io, OPA
  • その他関与表明: Hexa (Strata)、3Edges（Alex Babeanu が ML #112 で「Will likely be ready by May」と発言）

Kogito（Apache Kogito、KIE/Drools 系列のルールエンジン）は eazerad（Elie Azerad）が PR #84 で追加。SGNL は ogazitt が PR #95 で結果を追加し、tulshi が URL 修正を担当する 2 名体制での investigation。これら 4 実装は 5 月の Identiverse Interop に向けた基礎メンバーとして機能した（ただし最終的に 5 月の OIDF アナウンスに名を連ねた 9 ベンダーには Kogito の名は含まれず、代わりに 3Edges, Permit.io, Rock Solid Knowledge, Thales が加わる結果となった）。

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

AuthZEN WG は隔週火曜（米国時間）にコールを開催している。2024 年 4 月の暦上の火曜は 4 月 2 日・9 日・16 日・23 日・30 日 の 5 枠。HackMD @oidf-wg-authzen チームスペースの公開状況は限定的で、4-16 コール議事録のみが ML #126 で外部リンク（https://hackmd.io/8OQVOCrbRt6g6_cFuPbO6A?view）として共有された。その他のコールの個別議事録は外部からは確認できないが、ML 投稿・GitHub 活動・OIDF Workshop プレゼンの内容から開催と議論の存在は再構成できる。

4 月 2 日（火）定例コール — 推定 ​

  • 公開議事録: 確認できない
  • コール存在の根拠: 翌 4-03 に ogazitt が PR #83 で directory.ts の roles 属性と key/id リネームを投入。コール直後の整合作業と推測される
  • 想定議題: Identiverse interop に向けた仕様文書と interop ペイロードの不整合の整理着手。同週末（4-04）に PR #85（spec の単一評価／複数評価分離）が起票されることから、本コールで方針が合意されたと推測

4 月 9 日（火）定例コール — 推定: 仕様リファクタの集中マージ ​

  • 公開議事録: 確認できない
  • コール存在の根拠と当日活動: 同日に PR #85（spec の単一評価分離、+大規模リファクタ）と PR #88（todo-backend を新 spec に conform）が立て続けにマージ、加えて PR #89 → PR #90（response 側 context フィールド追加）の起票が同日。「コール中に方針合意し、当日中に PR を merge する」典型的な高速リズム が観察される
  • 欠席連絡（ML 上）:
    • ML #112（Alex Babeanu、3edges、2024-04-09 16:57 UTC）: 「I won't be on the call today...」。事前に書面で提出した議論ポイント:
      • 「AS <--> PDP possible interface in addition to the PEP <--> PDP」 — Authorization Server を PEP と見做すかの設計問題
      • 「Should the PDP return values like scopes?」 — PDP が scope を返す設計
      • RAR (Rich Authorization Requests) との関係 — RAR を leverage / extend するか
      • 「3Edges will likely be ready by May」 — interop 参加表明
    • ML #113（Jason Garbis、Numberline Security、2024-04-09 17:36 UTC）: 「I can't attend today's meeting due to a scheduling conflict with another recurring commitment」。Identiverse での合流を期待
  • 想定議題: PR #85 のレビュー結果合意、context フィールド導入の方針、Babeanu / Garbis 不在のため一部議論は持ち越し

4 月 15 日（月）OpenID Foundation Workshop（特別イベント、定例コールではない） ​

  • 開催形態: OpenID Foundation の四半期 Workshop。Hybrid（in-person + remote）
  • 物理ロケーション: Google, 242 Humboldt Ct, Humboldt 1, Sunnyvale, CA 94089
  • 日時: 2024-04-15 月曜、12:30 〜 16:00 PT
  • AuthZEN セッション: 12:50 〜 13:05 PT（15 分枠）、登壇者は David Brossard と Omri Gazitt の共同議長コンビ（OIDF Workshop registration page）
  • 共有された内容（OIDF_Workshop-at-Google_2024-04-15.pdf より）:
    • Prior Art Document: XACML, ALFA, Cedar, Topaz, OAuth の比較分析
    • PEP-PDP API draft の現状報告
    • AuthZEN Interop Scenarios（Todo アプリ）の紹介
    • 4 実装 conformant（Aserto Topaz, Cerbos, Kogito, SGNL）、3 実装以上が in development（Axiomatics, Permit.io, OPA）
    • Next steps: Identiverse 2024（5/28-31）と EIC 2024（6/4-7）での AuthZEN パネル + interop イベント
  • 意義:
    • OIDF コミュニティ全体に対して AuthZEN の進捗を初めて体系的に発表した場
    • WG 結成（2023-12）から約 4 ヶ月での「4 実装 conformant」という事実が OIDF Executive Director Gail Hodges および他 WG 議長層に共有された

4 月 16 日（火）定例コール — 議事録公開済 ​

ML #126 "Notes from today's call"（David Brossard、2024-04-16 20:00 UTC）で議事録 HackMD ノート（8OQVOCrbRt6g6_cFuPbO6A）が公開された 4 月唯一の公式記録があるコール。

  • 参加者（14 名）: gerryatstrata, Allan Foster, davidbrossard, Roland Baum, Granville Schmidt, Jeff Broberg, Eve Maler, Jason Garbis, Joshua Roberts, Eric Hoffman, Jamie Lin, Elie Azerad, Daniel Katzman, Mickey Martin
  • Omri Gazitt 欠席理由: ML #124（2024-04-16 17:51 UTC）で 「I won't make it today (at IIW, doing a session on AuthZEN interop!)」 と通知。同週 IIW 38（Mountain View）での AuthZEN 単独セッション登壇のため

4-16 コールの主要議題と決定事項 ​

  1. 週次コール時間の決定

    • SurveyMonkey 調査結果: 13 名回答、10 名が単一時間帯希望
    • 決定: 「11am PT on even weeks and 3pm PT on odd weeks」（隔週で時間帯を alternating）
    • 背景: 米西海岸（PT）と欧州（CET/CEST）の双方をカバーする運用の試行

  2. OIDF Workshop（4-15）の readout

    • 「interop 進捗で positive な反応」とポジティブな報告
    • 他 WG（特に Connect, FAPI, Shared Signals）との連携機会

  3. Omri の仕様アップデート（IIW のため deferred）

    • PR #85 / #88 / #90 で 4-09 〜 4-11 にマージ済みの単一評価分離・context フィールド追加の解説は Omri 不在のため次週送り

  4. Eve Maler による obligations / advice 議論（議事録 2024-04-16 より）

    • HEART と FHIR フレームワークを参照しつつ、「obligations と advice をどう機能させるか」の枠組み提案
    • 主な tension: 「double requests を避けつつ、必要な authorization augmentation を可能にする」 バランス
    • Eve Maler 提案: 「a discovery / .well-known endpoint」 が OAuth インフラと同様に必要ではないか
    • データフィルタリング（例: 「US-based clients only」）に obligation を使うのは 「framework の誤用」 の可能性、という慎重論
    • 4-04 〜 4-11 のスレッド（ML #114〜#122）で展開された capability negotiation 議論の対面での継続

  5. アクションアイテム:

    • obligation / advice 実装のゴール formalization
    • obligation response format の仕様書化
    • .well-known endpoint の標準定義の検討
    • default PEP implementation の検討

4 月 23 日（火）定例コール — 推定 ​

  • 公開議事録: 確認できない
  • コール存在の根拠: 同日 20:52 UTC に David Brossard が AuthZEN Happy Hour（5-27 予定）のキャンセル通知（ML #130）を ML へ配信。コール後の運用アクションと推測。なお後に 5 月 BrewDog 集合（5-27 ML #143）として復活する
  • 想定議題: Identiverse interop の参加実装最終確認、obligations / advice の前回継続議論

4 月 30 日（火）定例コール — 推定: Boxcarring プレゼンと payload 整合 ​

  • 公開議事録: 確認できない（議事録は未公開と推測）
  • コール存在の根拠:
    • ML #135（Roland Baum、2024-04-30 17:43 UTC）: 「Unfortunately I can't attend the call today due to vacation and limited connectivity.」 — 当日コールが存在することの直接の傍証
    • ML #137（Elie Azerad、2024-04-30 18:02 UTC）: 「The link doesn't appear to start the meeting this week. I see 'the host has another meeting in progress.'」 — Zoom 接続に問題が発生した記録（つまりコール自体は実施された）
    • ML #136（David Brossard、2024-04-30 17:59 UTC）: コール開始時刻付近に 「Background for today's discussion on boxcarring / multiple requests」 として Google Slides「OpenID AuthZEN - Boxcarring Requests」を ML へ共有
  • 主要議題:
    1. Boxcarring（複数評価リクエスト）プレゼン: David Brossard が主導。「同一 HTTP リクエスト内で複数の認可判定を batch する」アプローチを設計議論。後の 5 月 PR #102（Decisions API 仕様化試行）と 6 月 ML #148（Omri Gazitt の HackMD boxcarring 提案）に直結
    2. Interop payloads の不整合議論: 開始前の ML #133（David Brossard、2024-04-30 16:31 UTC）で「userID と ownerID の使い分けは意図的か？」と問題提起。Omri Gazitt は ML #138（2024-04-30 23:31 UTC）で 「The GET /users/{id} uses the PID (extracted out of the sub claim in the JWT)... I didn't have time to investigate how to create custom PIDs and just used what we had for expediency」 と「expediency 優先で意図的に不統一」 と回答。pragmatism vs consistency の典型的なトレードオフ判断
    3. Postman Collection の更新着手: ML #134（David Brossard、2024-04-30 17:24 UTC）: 「I have started refreshing the AuthZEN Postman Collection to align with the interop test suite Omri created」 と告知
    4. Identiverse Interop 招待状送付: ML #131（David Brossard、2024-04-29 17:42 UTC）: 「Invitation: OpenID AuthZEN Interop @ Tue May 28, 2024 8am - 3:30pm (PDT)」 を ARIA West Convention Center / Copperleaf 8 + Google Meet remote のハイブリッド開催として配信（場所と時間枠が初めて確定）

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

openid-specs-authzen ML（2024 年 4 月アーカイブ）の 4 月総投稿数は 35 件（000104〜000138）。Identiverse 関連の社交イベント告知が大半を占めるが、技術設計に関わる議論として重要なスレッドを以下 4 本選定する。

4.1 An example framework for layered-semantics interop/compliance — 2024-04-10 開始（Eve Maler 起点、9 通） ​

4 月の最も技術的に重要なスレッド。Eve Maler（xmlgrrl、ForgeRock 元 CTO で HEART WG 創設者） が 4-10 22:20 UTC に問題提起、Omri Gazitt・Alex Babeanu・Jeff Broberg らと 9 通で展開。

  • #114（eve@xmlgrrl.com、2024-04-10 22:20 UTC）: HEART での switchable layered semantics（base spec / 第三者 / 組み合わせのいずれからも提供されうる機能集合）の経験を共有。HEART は FHIR API 構造を resource type / scope へマップし、sens/ETH（substance abuse data の confidentiality scope）や break-the-glass scope を prescriptive に扱う。重要要件として 「A resource server that is capable of filtering information MUST advertise this capability through the use of these scopes」 を引用。アクセストークンに confidentiality marker が欠ける場合、サーバーはクライアント側に access 無しと仮定して filter 適用すべき、と。AuthZEN への提案: 「PDP が PEP へ context block を送る仕組みを定義し、(1) PDP の課す obligations（break-the-glass 等）、(2) PEP の advice/obligation 受入能力の pre-declaration、(3) PDP と PEP の動的ネゴシエーション、の 3 シナリオをカバーすべき」
  • #115（Omri Gazitt、Aserto、2024-04-10 23:04 UTC）: 肯定的に応答。「we (now) have context in both the request and response payloads, we should have the mechanism to achieve PEP-PDP capability negotiation」（PR #90 が同週 mergeしたばかり）。ネゴシエーションシナリオを 2 つ提示:
    • PEP が context 内に capability を表明し、非対応 PDP を reject
    • PDP が必要 capability を識別し、欠落 request を deny
  • #119（Alex Babeanu、3edges、2024-04-11 06:37 UTC）: 批判的意見。「I fail to see how this will help if we don't formalize this context block in the response. How would a PDP know what key/value pairs to add in there? Is this supposed to be implementation-specific?」 — context block の構造を形式化しないと PDP がレスポンス context にどの key/value を入れるか分からない、という interop 維持上の本質的な懸念。実装ごとに勝手に書くなら interop の意味を失う
  • #122（eve@xmlgrrl.com、2024-04-11 17:50 UTC）: Omri が PR へのリンクを提供してくれたことに感謝。「we can iterate on both the framework and any standardized elements while staying open to use cases from contributors」 と段階的合意の方針に同意
  • 意義:
    • HEART / FHIR の経験（資源カテゴリ別の sensitivity scope、break-the-glass）が AuthZEN obligations / advice 設計の出発点として参照された記録。AuthZEN は XACML と異なり HEART の延長として obligations を再設計しようとしていた
    • Alex Babeanu の 「形式化なしの mechanism は interop の助けにならない」 批判は、PR #90 の Omri の「まず mechanism、後で profiles」段階的アプローチとの間で緊張関係を生む。この緊張は 5 月の Identiverse 後、6 月の boxcarring 議論で「1.0 spec を single evaluation に絞り、複雑な機能は profiles へ」（PR #113）方針として一つの解を得る
    • 4-16 コール議事録での Eve Maler の .well-known endpoint 提案、obligation response format 標準化検討、default PEP implementation のアクションアイテムへ繋がる

4.2 Weekly call time options — 2024-04-16 開始（David Brossard 起点、3 通） ​

  • #123（David Brossard、2024-04-16 03:33 UTC）: SurveyMonkey で時間希望調査を実施。「Please take 30 seconds to complete the survey re. the time options for our weekly call」（survey URL: https://www.surveymonkey.com/r/226W6FM）
  • #124（Omri Gazitt、Aserto、2024-04-16 17:51 UTC）: 「I won't make it today (at IIW, doing a session on AuthZEN interop!)」 — Omri が IIW 38 で AuthZEN interop 単独セッションを実施する事実を公開
  • #125（David Brossard、2024-04-16 17:57 UTC）: 了解の応答
  • 結果: 同日 4-16 コールで 「11am PT on even weeks and 3pm PT on odd weeks」 が採択（議事録 #126 より）。13 名回答中 10 名が単一時間帯を希望したものの、結局 alternating 案が選ばれた点が興味深い（地理分散参加者への配慮が優先された結果）
  • 意義: WG が 「米西海岸固定」から「欧州との分散ハイブリッド」へ運用を切り替えた転換点。後の 6-18 ML #165 で David Brossard が改めて宣言する alternating times to accommodate everyone 運用の根拠がここで形成された

4.3 Inconsistencies in the Interop payloads? — 2024-04-30 開始（David Brossard 起点、2 通） ​

月末コール直前の payload 整合議論。

  • #133（David Brossard、2024-04-30 16:31 UTC）: 3 つのリファレンス先（authzen-interop.net の todo シナリオ、HackMD note gNZBRoTfRgWh_PNM0y2wDA、GitHub の decisions.json）で userID と ownerID が混在していると指摘。「Is that intentional? It would make more sense to always use owner since it's the grammatical purpose of the attribute in the resource category.」 と一貫性提案
  • #138（Omri Gazitt、Aserto、2024-04-30 23:31 UTC）: 意図的な不統一であることを表明。「The GET /users/{id} uses the PID (extracted out of the sub claim in the JWT)」でログインユーザーのプロフィール画像を取得し、それ以外のユーザーは todo オーナーの識別便宜のため email で取得する設計。「I didn't have time to investigate how to create custom PIDs and just used what we had for expediency」。実装が機能している以上、フィールド名統一を後回しにする pragmatic な判断
  • 意義:
    • interop 仕様の妥協点が明示的に ML に記録された貴重な一例。「最良の設計」と「Identiverse interop の deadline」の間で後者が勝った典型ケース
    • 後の 5-27 Issue #111（Cyril Dangerville の can_* 命名簡素化提案）も同じ構造の議論として再燃する。AuthZEN の interop scenario は 「動くことを優先した暫定設計」 の性格を月をまたいで引きずる

4.4 AuthZEN Pre-Interop Happy Hour — 2024-04-04 開始（David Brossard 起点、9 通 + 後続） ​

技術議論ではないが、WG メンバー間の対面ネットワーキング形成の記録 として重要なスレッド。

  • #104（David Brossard、2024-04-04 19:13 UTC）: 「For those of us attending Identiverse and the AuthZEN interop, are you interested in meeting up for drinks on the Monday night? If so, we could all meet up in an outdoor bar like the Paris or Brewdog. Thoughts?」
  • 応答（#105〜#111）: Alex Babeanu, Omri Gazitt, Derek Small, Elie Azerad, Roland Baum, Tariq Shaikh, David Hyland から好意的応答。「Count me in」 など
  • #128（David Brossard、2024-04-19）: 「I just sent a placeholder for the Happy Hour. Last year a bunch of us went to BrewDog's rooftop. Let's go there again.」 — BrewDog Las Vegas 確定
  • #130（David Brossard、2024-04-23 20:52 UTC）: Happy Hour 一旦キャンセル通知（German subject "Abgesagt"）。後に 5-27 ML #143 で 15 名分テーブル予約として復活する
  • 意義: 後の 5 月 Identiverse 期間中に 9 ベンダーが結集する物理的基盤がこの 4 月時点で 「Paris or BrewDog?」 という選択肢提示から始まっていたことの記録

5. GitHub 上の議論 ​

openid/authzen リポジトリの 2024 年 4 月活動: 新規 PR 15 件（4 月内マージ 13 件、close 1 件 = PR #89、月跨ぎマージ 1 件 = PR #97、4-30 起票で 5-01 マージ 2 件 = PR #98 / PR #99）、新規 Issue 2 件（#86, #87）、main ブランチへの commit 35 件以上。

4 月の特徴は 「仕様文書 × interop スイートの整合を取り続ける Omri Gazitt 主導の高頻度コミット」 と 「IIW / OIDF Workshop / Identiverse 準備に向けた小回りの利く修正の連続」 の 2 軸である。

5.1 PR #85 "updated spec to include a separate single-evaluation API description, and other cleanup"（ogazitt、2024-04-04 起票 → 2024-04-09 マージ） ​

4 月最大の仕様変更 PR。

  • 背景: interop シナリオが実際に使っていた「単一評価」API と、既存仕様文書に書かれていた boxcarred 「複数評価」API が混在しており、interop と spec の対応関係が不明瞭だった
  • 主要変更:
    • JSON キーを全 example で lowercase に統一
    • 「Access Evaluation API Request/Response」セクションを 「Access Evaluations」（複数形）にリネーム → boxcarred 版を意味する命名へ
    • 新しい 「Access Evaluation API Request/Response」（単数形）セクションを追加 — interop scenario で使う非 boxcarred 単一評価版
    • JSON インデントを 2-space に統一
    • エンドポイントを /access/v1/evaluation と /access/v1/evaluations に整理
  • 議論: davidjbrossard が 4-09 に approve。技術的論争は少なく、interop の実態に spec を合わせる方向で合意
  • 意義:
    • AuthZEN 仕様の 2 つの API ファミリー（single evaluation / multi evaluation）の構造が初めて明示的に分離された記録
    • 後の 5 月 PR #102（multi-decision を Decisions API として cleanup する試行、close）→ 6 月 PR #113（multi 系列を 1.0 から除去）の長期方針議論の 原点

5.2 PR #90 "updated eval calls to include 'context' in response, and fixed CI"（ogazitt、2024-04-09 起票 → 2024-04-11 マージ） ​

レスポンス側 context フィールドの導入。

  • 3 つの変更:
    • /evaluation と /evaluations API のレスポンス記述に context フィールドを追加
    • 既存の "reason object" spec を新しい context 構造内に統合
    • GitHub Pages の spec publish CI 失敗を修正
  • 参加者: ogazitt, baboulebou (Alex Babeanu), tulshi, davidjbrossard, independentid（5 名）
  • 重要な議論:
    • Alex Babeanu: 「How would a PDP know what values to add in there?」 — 形式化の必要性を改めて提起
    • Omri Gazitt: 「まず mechanism を入れて、後で profiles で specific capability negotiations を定義する」 — 段階的合意アプローチを表明
    • 「consistent HTTP request/header representation in context が policy condition を書きやすくし、policy と application の過度な結合を防ぐ」という pragmatic な利点も指摘
  • 意義:
    • context フィールドが request 側だけでなく response 側にも双方向化された記録
    • これにより 4-10 〜 4-11 の Eve Maler 主導 ML スレッド（§4.1）が「すでに mechanism は入っている。問題は profile を誰がどう作るか」という次のフェーズへ移行する土台が整った
    • "reason object" を context 内に統合したことで、後の月で reason / decision rationale を context として表現する設計が固まる

5.3 Issue #86 "Clarify Unauthorized / Forbidden Response"（independentid = Phil Hunt、2024-04-06 起票、2024-06-27 close） ​

HTTP status code 周りの仕様明確化要求。

  • 問題提起: 仕様において PDP API の HTTP ステータスと 認可判定結果の区別が曖昧
    • 401 Unauthorized: PDP 自体を呼び出す client の認証失敗を示すべき
    • 403 Forbidden: PEP が PDP の deny 判定（PDP から 200 OK で返ってきた中の decision: false）を受けて返すもの。PDP が直接 403 を返すケースとは異なる
  • 解決: 6-27 close、PR #118（6 月の HTTPS binding 整備の一環）でドキュメント明確化
  • 意義: AuthZEN の API が HTTP transport の上に乗る にあたっての semantic gap を初めて指摘した記録。PDP API は「認可判定の HTTP semantics」と「API 呼出側の認証 semantics」を二層で扱う必要があり、これは後の OAuth 2.0 binding 議論と関連

5.4 Issue #87 "Spec build is broken"（tulshi、2024-04-09 起票、2024-05-01 close） ​

GitHub Pages の spec build が壊れたという報告。

  • 問題: 直近のマージ（PR #85 系統）後に GitHub Pages の自動 build workflow が失敗。spec publish パイプラインの破損
  • 解決: 5-15 commit 6187ac0（adeinega の editorial、PR #97）および 5-15 PR #104（GitHub Pages 用 Jekyll workflow 拡張）で本格対応。PR #85 の大規模リファクタが内部 link を壊した影響と推測
  • 意義: 仕様文書を「コードベースとして CI で扱う」AuthZEN 流の運用が、4 月の高頻度マージで初めて綻びを見せた瞬間。5 月の PR #104 で本格的な GitHub Pages publish 基盤が整備される契機となった

5.5 interop 整備の小規模 PR 群（4-03 〜 4-30） ​

仕様本体への影響は小さいが、interop の運用基盤を支える PR 群。

  • PR #83 "Added missing roles attributes to directory.ts and minor cleanup"（ogazitt、2024-04-03）: directory.ts に roles 属性追加、"key" → "id" リネーム。tulshi がレビュー approve
  • PR #84 "Update pdps.json"（eazerad = Elie Azerad、2024-04-04 起票・即日マージ）: Kogito を PDPs リストに追加 — 4 月時点で 4 番目の conformant 実装として
  • PR #91 "Bump tar from 6.1.15 to 6.2.1"（dependabot、2024-04-12 マージ）: セキュリティ更新
  • PR #92 "clarified delete policy"（tulshi、2024-04-12 マージ）: interop scenario の delete アクションの説明明確化
  • PR #93 "fixed server start instructions"（ogazitt、2024-04-12 マージ）: README の起動手順修正
  • PR #94 "updated test script to use AUTHZEN_PDP_API_KEY"（ogazitt、2024-04-13 マージ）: SGNL の API key 認証対応のための環境変数化
  • PR #95 "added sgnl to results"（ogazitt、2024-04-13 起票・即日マージ）: SGNL を interop results に追加 — 4 番目の conformant 実装の登録
  • PR #96 "fixed SGNL URL to be https"（tulshi、2024-04-14 マージ）: SGNL endpoint URL の https 修正
  • PR #97 "Minor editorial changes"（adeinega、2024-04-19 起票、月跨ぎ 5-15 マージ）: 編集レベル軽微修正。adeinega は AuthZEN spec 文書のエディトリアル領域での後の重要 contributor となる
  • PR #98 / PR #99（davidjbrossard、2024-04-30 起票、5-01 マージ）: Axiomatics endpoint 追加と Axiomatics PDP results 追加 — 5 月 1 日マージのため commit SHA 5185db9, 3afd869 は 4-30 ベース。5 番目の conformant 実装が月跨ぎで登場

6. 関連イベント ​

OpenID Foundation Workshop at Google（Sunnyvale、2024-04-15） ​

  • 形態: Hybrid（in-person at Google Sunnyvale, Humboldt 1 + remote）
  • 時間: 12:30 〜 16:00 PT
  • AuthZEN 枠: 12:50 〜 13:05 PT（15 分）、David Brossard と Omri Gazitt 共同登壇
  • 共有内容（PDF 資料）:
    • Prior Art Document（XACML, ALFA, Cedar, Topaz, OAuth の比較）
    • PEP-PDP API ドラフト現状
    • Todo interop シナリオ
    • 4 conformant 実装: Aserto Topaz, Cerbos, Kogito, SGNL
    • 3+ in-development: Axiomatics, Permit.io, OPA
    • Next steps: Identiverse 2024 + EIC 2024 での AuthZEN パネル / interop
  • 意義: OIDF コミュニティ全体（Connect, FAPI, MODRNA, DCP, Shared Signals, eKYC-IDA 等の他 WG メンバー）に AuthZEN の進捗を体系的に発信した最初の機会

Internet Identity Workshop XXXVIII (IIW 38)（Mountain View、2024-04-16 〜 18） ​

  • 会場: Computer History Museum, Mountain View, CA
  • AuthZEN セッション: Omri Gazitt（Aserto）が単独で AuthZEN interop デモを実施（4-16 火曜、4-16 ML #124 で「doing a session on AuthZEN interop!」と明言）
  • セッション内容（Aserto IIW 38 retrospective より）:
    • WG goals
    • 「going from inception to an implementer's draft, an interop scenario, and four interoperable implementations (and counting!)」 — WG 結成（2023-12）から約 4 ヶ月での実績共有
    • interop シナリオの live demo
    • 「execute quickly to achieve concrete results」というレッスン共有
  • IIW 38 全体のテーマ: Verifiable Credentials と Authorization の 2 つが大きな話題。AuthZEN は後者の中核的存在として認知された

4 月時点では未開催だが計画されていたイベント ​

  • Identiverse 2024（5-28 〜 5-31, Las Vegas / ARIA）: AuthZEN Interop の正式開催が 4-29 ML #131 で告知（Copperleaf 8 ルーム、8am 〜 3:30pm PDT）
  • EIC 2024（6-04 〜 6-07, Berlin）: 4-15 OIDF Workshop の next steps で AuthZEN パネル / interop の予告

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

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

  • 5 月の隔週コール運用本格化: 「11am PT on even weeks and 3pm PT on odd weeks」 での alternating call の実行段階
  • Boxcarring Requests 設計議論の継続: 4-30 コール（David Brossard のプレゼン共有）で起点を作り、5 月以降に正式仕様化を試みる流れ（実際には 5 月 PR #102 として multi-decision を Decisions API 章として cleanup する試行、これは close。6 月に Omri Gazitt の HackMD 提案 ML #148 として正式提案へ）
  • Identiverse 2024 Interop（5-28）への準備加速: 残り 4 週間で in-development 3 実装（Axiomatics, Permit.io, OPA）+ Hexa の interop 完成を目指す。実際には 5 月内に Axiomatics, Topaz, Hexa/OPA, Thales AuthZForce, 3Edges, Rock Solid Knowledge, Permit.io が次々と結果ファイルを投入し、9 ベンダーが完走する成果へ
  • AuthZEN Happy Hour の再調整: 4-23 一旦キャンセルされた Happy Hour を 5 月以降に再設定する流れ（5-27 BrewDog 15 名分テーブル予約として復活）
  • obligations / advice / capability negotiation の仕様化検討継続: 4-16 コール議事録のアクションアイテム（obligation response format 標準化、.well-known endpoint 定義、default PEP implementation）を 5 月以降のコールで取り組む方針
  • Postman Collection の更新完了: 4-30 着手の Postman Collection 整備を 5 月の Identiverse interop 前までに完成

8. 参考情報源 ​