idbok

Appearance

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

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

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 年 8 月時点の共同議長は Omri Gazitt（Aserto）、David Brossard（Axiomatics）、Gerry Gebel（Strata Identity）の 3 名で、定例コールは毎週火曜開催。

2024 年 8 月の AuthZEN WG は、「Implementer's Draft 提出に向けた最終追い込みの月」 であった。月の中盤 8 月 14 日には Authorization API 1.0 - draft 00 が編集者（Omri Gazitt / David Brossard / Atul Tulshibagwale）の連名で document date 2024-08-14 として公開され、これがそのまま 9 月 6 日にマージされる candidate Implementer's Draft（draft 01）の直前版となる。同月の作業は、(1) 1.0 仕様本体の Security Considerations / IANA Considerations / Notices / 非規定参照 など仕様文書としての体裁を最終整備する作業、(2) 1.1 系列で boxcarring（複数認可リクエストのバッチ評価） をどう作るかという設計議論、(3) interop website / backend を draft 00 ペイロードに追従させる更新作業 — の 3 軸で進んだ。

openid-specs-authzen ML への 8 月分投稿数は 4 件（2024 年 8 月アーカイブ の 000189〜000192、8 月 6 日 〜 8 月 21 日）。開催回数の少なさ（月後半は 8 月 27 日コール中止（休暇・旅行））に対応する静かさだが、Implementer's Draft 提出計画とロードマップ表明という意味で 8 月全体を方向付ける投稿が含まれる。GitHub openid/authzen リポジトリの 8 月活動は 新規 PR 17 件（うち 8 月内マージ 12 件、8 月内 close 1 件、dependabot 起票 3 件は 9 月マージへ持ち越し、PR #131 Boxcarring は 8 月末時点で未マージのまま継続）、新規 Issue 1 件（johakoch から 1 件、can_* プレフィックス除去提案）。8 月 14 日前後に集中する PR の波が draft 00 publish に同期しており、書誌情報・履歴節・通知節などフォーマル仕様としての要件を一気に揃えた様子が読み取れる。

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

  • draft 00 publish と OIDF への Implementer's Draft 提出計画（8-06 コール） — Omri Gazitt が「セキュリティ章とノート章が完了した」「8 月 14 日水曜までに OIDF Board へ提出する」「10 月の Authenticate 2024 までに Implementer's Draft として批准されることが目標」と表明。実際に 8 月 14 日に draft 00 が openid.net/specs/authorization-api-1_0-00.html として公開された
  • 1.1-01 への boxcarring 機能搭載をめぐる設計議論（PR #131） — Alex Olivier（Cerbos）から spec-1.0 と spec-1.1 を別フォルダに分けて boxcarring を 1.1 で実装する PR が提案され、レビュアの Omri Gazitt との間で「フロントエンドは 2 つに分ける必要があるか、バックエンドは additive route で共通化できるか」が議論。バックエンドは統合、フロントエンドはバージョン別 で落ち着いた後、PR 自体は 9 月の構造改革（PR #156）に統合する形で 9-26 に close
  • Security Considerations / IANA Considerations の 1.0 → 1.1 同期（PR #127 / #126） — David Brossard が 1.0 で整備した Security 章を 1.1 へコピーして両仕様の整合を確保。TBS だった項目を Communication Integrity / Policy Confidentiality / Trust / Availability & Denial of Service の 4 節として具体化し、IANA Considerations は「新規 IANA 登録は不要」へ確定
  • 8 月 20 日コールでのペイロード構造へのフィードバック（その後 9-03 アジェンダで再浮上） — 後の 9-03 アジェンダ通知（ML #193）で「Aug 20 discussion でのフィードバックを受け、ペイロード構造を json-schema / gRPC など型付きプログラミングモデル互換へ作り直す提案を HackMD で共有する」と回顧された通り、8 月 20 日コールで Omri Gazitt が提示した draft 00 のペイロード設計について WG 内から強い見直し要請が出ていた。この時点では draft 00 publish 直後だったため変更は次版（draft 01）に持ち越されることになる

なお 8 月 13 日には David Brossard から「Shared Signals WG の複数ドラフトが投票にかかっている、レビューと投票を」という OIDF クロス WG リマインダ（ML #190、poll 334）も投稿されており、AuthZEN メンバーが OIDF 全体の Standards Track プロセスに参加する慣行が確立しつつあった点も記録しておく。

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

Authorization API 1.0 - draft 00（2024-08-14 publish） ​

  • 正式名称: Authorization API 1.0 - draft 00
  • URL: authorization-api-1_0-00.html
  • document date: 2024-08-14
  • 編集者: Omri Gazitt（Aserto）、David Brossard（Axiomatics）、Atul Tulshibagwale（SGNL）
  • status: Standards Track（draft 00 / Initial version）
  • Document History: -00 初版（同節記載は "Initial version" のみ）
  • 意義: AuthZEN WG が 2023 年 11 月の発足から約 9 ヶ月で初めて openid.net/specs/ 配下に公開仕様 URL を獲得した版。9 月 6 日にリポジトリ内で revision 01 (candidate implementers draft) PR #142 がマージされる前段として、編集体制と章構成の確定を意味する

8 月内の主要な仕様 PR（仕様本体への影響度順） ​

openid/authzen リポジトリで 8 月内にマージされた仕様本体関連 PR の中で、特に draft 00 publish に直結したもの。

PR #125 - Update authorization-api-1_0.md（ggebel、2024-08-07 マージ） ​

  • 変更内容: authorization-api-1_0.md 末尾に Appendix A. Notices を追加。OIDF 標準仕様としての通知節を整備
  • 経緯: ggebel（Gerry Gebel）が初版コミット、ogazitt が「fixed notices section」で整形修正、davidjbrossard の承認を経てマージ

PR #126 / #127 - Security Considerations の整備と 1.0 → 1.1 同期（davidjbrossard、2024-08-07 〜 2024-08-12 マージ） ​

  • PR #126 "Updates to the security considerations"（2024-08-07 マージ）: コメント除去と構文修正
  • PR #127 "Copied security considerations and IANA considerations from 1.0 to 1.1"（2024-08-12 マージ）: TBS だった 1.1 の Security 章を 1.0 と同一内容に揃える。具体的な追加節:
    • Communication Integrity and Confidentiality: PEP-PDP 間通信を transport security（HTTP REST なら TLS）で保護
    • Policy Confidentiality and Sender Authentication: PDP が呼び出し元 PEP を mutual TLS / OAuth / API key 等で認証し、policy discovery と DoS を緩和
    • Trust: 「PDP 側が PEP の入力データ正確性を疑うのは misplaced concern」と整理（最終的に enforce するのは PEP）
    • Availability & Denial of Service: payload size attack / excessive requests / invalid JSON / nested JSON attack / memory consumption への rate limiting を推奨
    • IANA Considerations: TBS から「no new identifiers requiring IANA registration」へ確定
  • 意義: 1.0 と 1.1 でセキュリティ・IANA 関連節を意図的に同一化することで、後の draft 01 / 1.1-01 並行運用時にも非機能要件が乖離しない保証を作った

PR #128 - added 1.0 to title（ogazitt、2024-08-07 マージ） ​

  • 変更内容: 仕様タイトルに「1.0」のバージョン番号を明示。書誌情報レベルでの版表記の確定

PR #129 - fixed indent（ogazitt、2024-08-07 マージ） ​

  • 変更内容: Markdown ソースのインデント修正。レンダリング結果の整形目的

PR #130 - Added the draft number in the title and the history section（davidjbrossard → ggebel 承認、2024-08-13 マージ） ​

  • 変更内容: 仕様ドキュメントのタイトルと履歴節に draft 番号を埋め込む。selfissued（Mike Jones）が review コメントを残し、その指摘を反映してから ggebel が承認・マージ
  • 意義: OIDF 標準書式（Mike Jones が ABFAB / OAuth / Connect 系仕様で長年確立した書誌規約）への適合作業。AuthZEN 仕様が「OIDF 仕様の見た目」を獲得したマイルストーン

PR #132 - Added non-normative reference（davidjbrossard → ggebel 承認、2024-08-13 マージ） ​

  • 変更内容: 仕様の参照節に non-normative reference を追加（3 コミット: 追加 / trailing text 除去 / main へのマージ）
  • レビュー状況: ggebel が承認、ogazitt はレビュー保留のままマージ。8 月のリリース時間枠を優先した運用判断

8 月内の interop website / backend PR（draft 00 ペイロード追従） ​

PR #133 - updated interop to be 1.0 compliant（ogazitt、2024-08-13 マージ） ​

  • 変更内容: HackMD 上の最新仕様変更を反映し、authzen-todo-backend の認可ミドルウェアと decisions.json を新ペイロード構造へ更新
  • 意義: draft 00 publish の前日に interop 実装を仕様変更へ追従させる「仕様と実装が常に同期している状態」を 8 月中旬時点で確立。これは 9-17 の Implementer's Draft 提出宣言で「13 実装すべてが新ペイロードに追従する必要がある」と Omri Gazitt が発言できた基盤になる

PR #135 - fix logic error in delete resource mapper（ogazitt、2024-08-13 マージ） ​

  • 変更内容: Todo backend の delete resource mapper のロジックバグ修正

PR #136 - updated all results with new payloads（ogazitt、2024-08-14 マージ） ​

  • 変更内容: 全 PDP 実装の interop テスト結果ファイルを新ペイロードで再生成

PR #137 / #138 - markdown / table 出力の改善（ogazitt、2024-08-14 マージ） ​

  • PR #137 "fixed markdown generation issue": markdown 生成のバグ修正
  • PR #138 "facelift for table/markdown interop results and generation": test runner の markdown generator を改良し、Docusaurus 上でタグ付きで見やすい形に再生成。13 実装全ての results ページを regenerate
  • 意義: Authenticate 2024 (10/15) interop イベントの広報素材として、interop 結果を公衆向けに見やすい形へ仕上げる作業の起点

8 月内のその他マージ済み / 派生 PR ​

  • PR #131 - Boxcarring（alexolivier、2024-08-06 起票 → 2024-09-26 close）: spec-1.0 / spec-1.1 フォルダ分割と boxcarring 機能を導入する大型 PR。8 月内には merge 至らず、レビュー議論を経た上で 9 月の PR #156 に役割を移譲して close
  • PR #124 - test for david（ogazitt、closed）: テスト用 PR、8 月内 close
  • PR #134, #139, #140（dependabot、いずれも 2024-09-15 マージ）: axios 1.6.7 → 1.7.4（PR #134、8-13 起票）、webpack 5.90.3 → 5.94.0（PR #139、8-31 起票）、micromatch 4.0.4 → 4.0.8（PR #140、8-31 起票）。8 月中に起票されたが 8 月内にはマージされず、9-15 にまとめて承認・マージされた。webpack と micromatch は GHSA 公表の脆弱性対応バージョン

8 月 22 日の PlainID 実装追加 ​

  • Commit 7f41928 - Add PlainID Support（Vladi Berger、2024-08-22）: interop 実装に PlainID PDP を追加。8 月時点で 13 実装規模に向けた拡張作業が継続していたことを示す（9-17 の Omri Gazitt 投稿で「13 実装」と明言される根拠の一つ）

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

AuthZEN WG は毎週火曜にコールを開催している。2024 年 8 月の定例コールは ML / GitHub 上の言及から 8 月 6 日・8 月 13 日・8 月 20 日・8 月 27 日（中止） の 4 枠が想定され、ML に直接議事録投稿があるのは 8 月 6 日コールのみ。HackMD @oidf-wg-authzen 公開索引には個別ノートへの直接リンクが見当たらず、各コールの議事録はメンバー専用の HackMD ページに格納されているため、外部からは ML 投稿で要約された分のみが公開記録として残る。

8 月 6 日（火）定例コール — Implementer's Draft 提出計画と Authenticate 2024 interop 戦略 ​

  • 議事録（ML 投稿）: #189 AuthZEN WG notes from 2024-08-06（Omri Gazitt、2024-08-06）
  • 議題 1: AuthZEN 1.0 仕様の進捗 — 「Security と Notes 章が完了した」「OIDF Board への提出は遅くとも 8 月 14 日水曜まで」と表明。目標は 10 月の Authenticate 2024 までに Implementer's Draft として批准されること
  • 議題 2: Authenticate 2024 interop イベント — 10 月 15 日火曜開催。FIDO Alliance が interop タイムスロットと report-out セッションを割り当て、10 月 14 日に Authorization パネルディスカッションも予定。「実装者と RP を惹きつけるためにマーケティング戦略を強化する必要がある」と認識共有
  • 議題 3: 1.1 開発（boxcarring） — Todo シナリオ拡張上で boxcarring を構築。具体例として「subject と action は共通だが resource が個別の複数 delete オペレーション」を提示。Alex Olivier（AlexO）に Todo アプリのレビューと推奨事項提示をアサイン
  • 議題 4: 仕様適合性作業 — 現在の interop シナリオを type と id フィールド必須化へ更新する必要があると確認。実装の 後方互換性は可能な限り維持 する方針
  • 次のステップ: 仕様レビュー、シナリオ更新、interop プランニングを継続

8 月 13 日（火）定例コール — draft 00 publish 直前の最終整備 ​

  • 公開議事録: ML 上に 8-13 コールの議事録投稿は確認できない
  • コール存在の根拠: 同日に PR #130（draft 番号埋め込み）、PR #132（non-normative reference）、PR #133（interop 1.0 compliant）、PR #135（delete resource mapper fix）が立て続けにマージされており、コール前後で「仕様文書としての見た目」と「interop 実装の追従」の最終確認が行われたと考えるのが自然
  • 議論内容（GitHub の merge 履歴から再構成）:
    • selfissued（Mike Jones）が PR #130 のタイトル節と履歴節に OIDF 標準書式に沿った draft 番号表記を求めたレビュー
    • davidjbrossard が PR #132 で non-normative reference を追加（XACML / OPA / Zanzibar 等への参照と推定されるが、PR 本文には具体名なし）
    • ogazitt が PR #133 で HackMD 上の最新仕様変更を interop バックエンドへ反映

8 月 20 日（火）定例コール — draft 00 publish 後のペイロード構造振り返り ​

  • 公開議事録: ML 上に 8-20 コールの議事録投稿は確認できない
  • コール存在と内容の根拠: 後の 9-03 アジェンダ通知（ML #193、Omri Gazitt）で次のように回顧されている:

    Based on the feedback in our Aug 20 discussion, I'm proposing a way to redesign the payload structure so that it works better with typed programming models such as json-schema and gRPC. I shared a proposed structure as a HackMD ... we'll also discuss reordering evaluations by converting the evaluations object back to an array, as it was in the original spec.

  • 読み取れる議論内容:
    • 8 月 14 日 publish の draft 00 ペイロード構造に対し、WG 内から「json-schema / gRPC のような型付きプログラミングモデルとの互換性が弱い」というフィードバック
    • 並行して「evaluations オブジェクトを map から array へ戻す」（原仕様の構造への回帰）も論点として浮上
  • 結果: 上記フィードバックは draft 00 の中身を直接訂正することなく、次版（9-06 マージの candidate Implementer's Draft 01）へ持ち越しとなる。properties オブジェクトへの集約と Evaluations API array 化はいずれも 9 月の PR #142 / #144 で実装される

8 月 21 日 ML 通知 — ロードマップと 8 月 27 日コール中止 ​

  • ML 投稿: #191 AuthZEN Authorization API 1.0 - roadmap（Omri Gazitt、2024-08-21）/ #192 AuthZEN WG meeting cancelled on August 27（Omri Gazitt、2024-08-21）
  • #191 ロードマップ宣言の内容:
    • 8-20 コールで「schema 対応強化」（strongly-typed protobuf / gRPC contract、strongly-typed JSON schema、よりよい OpenAPI 表現）の重要フィードバック
    • 1.1 仕様において evaluations フィールドを map から array へ戻す（fail-on-first-deny セマンティクス実現のため順序保持が必要）
    • 9 月 3 日コールで最小限の必要変更案をレビュー予定
    • 「Implementer's Draft の review period を上記課題が解決するまで delay する」と co-chairs として決定。Implementer's Draft 公開後に破壊的変更を加えると draft の有効性が損なわれるため、developer toolchain の現代化を盛り込む柔軟性を確保する判断
  • #192 コール中止理由: 「休暇シーズン」。次回は 9 月 3 日（火）11am Pacific
  • 意義: 8 月 27 日コール中止が単なる夏季休暇ではなく、「draft 00 を OIDF へ提出した後、ペイロード構造の見直しを慎重に進める」プロセス設計の一部 として位置付けられている点が読み取れる

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

openid-specs-authzen ML（2024 年 8 月アーカイブ）の 8 月総投稿数は 4 件（000189〜000192）。各スレッドはいずれも返信のない単発投稿だが、Implementer's Draft 提出計画の確定とロードマップ表明という意味で 8 月全体を方向付ける内容を含む。

4.1 AuthZEN WG notes from 2024-08-06 — 2024-08-06 開始（Omri Gazitt、単発） ​

8 月の議事録として ML に投稿された唯一のコール記録。詳細は §3 の 8-06 コール節に整理した通り。Implementer's Draft 提出計画（8-14 水曜まで）、Authenticate 2024 (10-15) interop、1.1 boxcarring の Todo シナリオ拡張、type / id フィールド必須化 という 4 つの方向性がこの 1 通でまとめて WG メンバーに共有された。

4.2 Reminder to review and vote — 2024-08-13（David Brossard、単発） ​

  • 発端: David Brossard が「Dear all, This is a kind reminder that our peers in the Shared Signals WG have a few drafts out up for a vote」と AuthZEN ML に Shared Signals WG の投票（poll 334）への参加を呼びかけた
  • 投票リンク:
    • openid.net/foundation/members/polls/334
    • oidf.slack.com/archives/CBB3XM402/p1723507340270129（OIDF Slack の Shared Signals チャンネル）
  • 意義: AuthZEN WG が単体で閉じた WG ではなく、OIDF 内の他 WG（とりわけ Shared Signals）の標準化プロセスに能動的に投票参加するメンバー基盤を持っていることを示す。8 月当時、Shared Signals 側は CAEP（Continuous Access Evaluation Profile）と SSF（Shared Signals Framework）の Implementer's Draft 投票を進めており、AuthZEN メンバーがその投票者層に含まれていた

4.3 AuthZEN Authorization API 1.0 - roadmap — 2024-08-21（Omri Gazitt、単発） ​

  • 発端: 8-20 コールでの 2 つの重要フィードバックを ML 全体へ展開する形でロードマップを表明
    • フィードバック 1（1.0 への影響）: 「strongly-typed protobuf / gRPC contract、strongly-typed JSON schema、よりよい OpenAPI 表現」を実現するため、1.0 仕様を 開発者向けツールチェーン対応へ作り直す
    • フィードバック 2（1.1 への影響）: 「最初の失敗で中止（fail-on-first-deny）」のようなシナリオを実現するため、evaluations フィールドを map から array へ変更
  • スケジュール:
    • 8 月 27 日コール: キャンセル（旅行・休暇）
    • 9 月 3 日コール: 最小限の必要変更案をレビュー予定
  • 理由の明示: co-chairs として「最初の Implementer's Draft の review period を、上記課題が解決するまで delay する」と決定。Implementer's Draft 公開後の破壊的変更は draft の有効性を損なうため、developer toolchain 現代化を盛り込む柔軟性を確保する判断
  • 意義: WG 議長が「スケジュールよりも仕様品質を優先する」と明示的に表明した投稿。8-14 draft 00 publish の直後にもかかわらず、ペイロード構造の根本見直しを次版で実施する判断を全メンバーへ明文化したことで、9 月の急速な作業展開（9-06 draft 01 マージ → 9-17 review 開始）の前提条件が整った

4.4 AuthZEN WG meeting cancelled on August 27 — 2024-08-21（Omri Gazitt、単発） ​

  • 発端: 8-27 コール中止の正式通知。理由は「休暇シーズン」。次回 9 月 3 日（火）11am Pacific
  • 意義: 単独スレッドとしては事務連絡だが、#191 ロードマップ投稿の直後に分離して発信されているため、WG として「8 月後半は draft 00 を熟成させ、9 月初頭から本格的な見直しを始める」運用 を明確に区切る役割を果たした

5. GitHub 上の議論 ​

openid/authzen リポジトリの 2024 年 8 月活動: 新規 PR 17 件（うち 8 月内マージ 12 件、8 月内 close 1 件、dependabot 起票 3 件は 9-15 マージへ持ち越し、PR #131 Boxcarring は 8 月末時点で未マージ継続）、新規 Issue 1 件（johakoch から 1 件）。8 月の Issue 投稿が 1 件に留まったのは、draft 00 がまだ openid.net/specs/ に publish されていない期間で外部レビュアの目に触れる機会が限定的だったため。一方 PR は仕様 draft 00 publish に同期して集中マージされた。

5.1 openid/authzen#123 — Remove "can_" from common actions（2024-08-07、johakoch） ​

  • 起票: 2024-08-07 / author: johakoch
  • 問題提起: 仕様では action を「リクエスターが実行しようとするアクセスの種類」と定義しているため、access、create、read、update、delete のようにシンプルであるべきだと主張
  • プレフィックスの役割への疑問: can_access という命名は permission を示唆するが、実際には全体的な can(<subject>, <action>, <resource>, <context>) 構造における権限表現であり、個別アクション定義に can_ を冠する必要はないのではないか、という指摘
  • 意義: 後の 2024-09-23 Issue #154（randomstuff〔Gabriel Corona〕の can_* 命名動機質問）および 2024-10-02 ML #207（Gabriel Corona の体系的 7 論点フィードバック）と直接接続する can_* 命名規約論争の出発点。8 月時点で既に外部 contributor が同じ違和感を表明していたことを示す重要な記録
  • closed: 2024-09-15（johakoch 提案が can_* 維持の方向で WG として合意せず、後段の議論に統合する形で close）

5.2 openid/authzen#131 — Boxcarring（alexolivier、2024-08 起票 → 2024-09-26 close） ​

8 月の最大の設計議論を含む PR。spec-1.0 / spec-1.1 のフォルダ分割と boxcarring 実装を持ち込んだ。

  • PR 内容:
    • 既存 application / backend を spec-1.0 フォルダへ移動
    • 新規 spec-1.1 フォルダに boxcarring 機能を導入
    • ドキュメントサイトに v1.0 / v1.1 セクションを追加
  • 議論軸（ogazitt vs alexolivier）:
    1. Website: 単一プロジェクトで複数シナリオを収容できる
    2. Frontend Application: 「we need two different apps, unless we add some kind of selector」とレビュアが指摘 → セレクタを後付けするか別アプリを残すかの判断
    3. Backend: DELETE /todos のような additive route で重複を避けられる
  • 到達点:
    • バックエンドは統合（additive route 方式）
    • フロントエンドはバージョン別に保持
  • closed の経緯: 9-26 に PR #156 が以下の構造改革を含む形で取り込まれたため、本 PR は superseded として close:
    • Evaluations フィールドの array 形式化
    • subject.userID → subject.properties.userID への プロパティ再構成
    • Resource ペイロードの resource.ownerID → resource.properties.ownerID
  • 意義: 8 月時点で WG が boxcarring 実装の具体的なアーキテクチャ判断（version 別フォルダ vs 単一フォルダ + 機能フラグ、フロントエンド分離 vs セレクタ）を真剣に議論していたことを示す唯一の公開記録。最終的に「仕様バージョンを interop website のソースコードレベルで明示的にモデル化する」という後の 9 月の運用方針はここで芽生えていた

5.3 仕様文書としての体裁を整える PR 群（8 月中旬、davidjbrossard / ogazitt / ggebel） ​

PR #125 / #126 / #127 / #128 / #129 / #130 / #132 の 7 件は、いずれも 1 〜 3 日内にレビューしてマージされた書誌情報整備 PR。draft 00 publish（8-14）を間近に控え、OIDF 標準仕様としての体裁を一気に揃えた。

  • PR #125 Notices 節追加 → PR #128 タイトルに 1.0 追加 → PR #129 インデント修正 → PR #130 draft 番号埋め込み（selfissued レビュー） → PR #132 non-normative reference 追加
  • PR #126 Security コメント除去・構文修正 → PR #127 Security / IANA を 1.0 から 1.1 へコピー
  • 意義: 個々の PR は小粒だが、8 月 7 日から 8 月 13 日までの 1 週間で書誌情報と Security / IANA を一括整備した動きは、AuthZEN WG が「コードベースとしての仕様」から「OIDF 標準仕様文書」へ品質を引き上げた転換点と読める。selfissued（Mike Jones）のレビューコメントが PR #130 で確認できる点は、OIDF 内のシニア仕様編集者から正式に書誌書式のフィードバックを受けた最初の月であったことを示す

5.4 interop website / backend 更新 PR 群（ogazitt、8 月中旬） ​

PR #133（1.0 compliant 化） → #135（delete mapper fix） → #136（全結果再生成） → #137 / #138（markdown 出力 facelift） の連鎖は、draft 00 publish と完全に同期している。

  • 意義: 「仕様変更 → 即日 interop 反映」のリズムが 8 月で確立。9 月の Implementer's Draft 提出時に「13 実装すべてが新ペイロードに追従」と Omri Gazitt が断言できる開発・運用基盤がこの時点で整った

6. 関連イベント ​

Authorization API 1.0 - draft 00 Publish（2024-08-14） ​

  • URL: openid.net/specs/authorization-api-1_0-00.html
  • document date: 2024-08-14
  • 意義: AuthZEN WG が openid.net/specs/ 配下に初めて公開仕様 URL を獲得した日。OIDF Board への candidate Implementer's Draft 提出に向けた直前版

Shared Signals WG 投票への参加要請（2024-08-13） ​

  • 発端: ML #190（David Brossard、2024-08-13）
  • 投票場所: openid.net/foundation/members/polls/334、OIDF Slack #openid-specs-risc
  • 意義: AuthZEN WG メンバーが OIDF 全体の Standards Track プロセスへ能動的に投票参加する慣行が定着していたことの記録

8 月時点で予告された 10 月の対外イベント ​

8-06 コール議事録から、WG として把握していた 10 月の対外イベント:

  • Authenticate 2024 (FIDO Alliance): 2024-10-15（火）— FIDO Alliance が interop タイムスロットと report-out セッションを割り当て、10-14 に Authorization パネルディスカッションも実施予定
  • WG として マーケティング戦略強化 が必要と認識されており、interop に参加する実装と RP（Relying Party）を惹きつけるためのアプローチが課題として共有された

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

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

  • 9 月 3 日コール: 8-20 コールで提起されたペイロード構造見直し提案（json-schema / gRPC 互換、Evaluations array 化）を最小限の必要変更案としてレビュー
  • candidate Implementer's Draft の OIDF Board 提出: 8-14 draft 00 を出発点に、9 月前半で OIDF へ candidate Implementer's Draft（draft 01）を正式提出
  • 10 月 15 日 Authenticate 2024 interop ライブセッション準備: 13 実装規模の interop デモを目指す。1.1 evaluations API（array 形式）を活用した boxcarring 評価が中心題材
  • can_* プレフィックス除去提案（Issue #123）への対応: 9 月以降の common actions 議論で取り扱い方を決定
  • 1.1-01 系列の継続開発: spec-1.0 / spec-1.1 のフォルダ分割と boxcarring 実装をどう本流に取り込むか（PR #131 の議論を基に）
  • 45 日 public review の準備: candidate Implementer's Draft が承認され次第、45 日 review 期間と Notice of Vote の段取りに入る

8. 参考情報源 ​