こんばんは！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-06-25（UTC基準）に公開されたInternet-DraftとRFCをまとめました。
- Internet-Draft: 本Part23件（本日のInternet-Draft合計46件）
- RFC: 本Part0件（本日のRFC合計0件）
参照先:
その日のサマリー & Hot Topics
- 2026年6月25日分の前半は、自律エージェントの識別と認可をめぐる提案が目立ちます。行動をcontent-addressedな識別子で表すaction_refや、決済記録の監査連鎖、組織をまたぐ委譲の要件整理、能力記述のACPMとAAIFなど、AIエージェントを安全につなぐ土台づくりが並びました。TLS 1.3への追加認証やOAuthのトランザクション認可、セキュリティBCPの更新といった認証まわりの動きも活発です。DNSSECのアルゴリズム世代交代やTSIG検証失敗時の扱い、EPPのDS自動化など運用寄りの整備も揃っています。
- 注目はエージェント基盤のセキュリティです。draft-hopley-x402-retention-chainはSHA-256とJCSだけで自己検証できる八つの暗号構成を定義し、発行者に問い合わせず決済の監査証跡をたどれる仕組みを示しました。session-bound agent identityは、暗号的に正しい資格情報が想定と別の相手に受理される混同を防ぐ受け入れ基準を定めます。認可ではOAuthのトランザクション認可チャレンジが、エージェント経由の操作へ人間の承認を挟む筋道を用意しました。識別子と検証の両輪が同時に動き出した前半といえる内容です。
投稿されたInternet-Draft
Supplemental Authentication in TLS 1.3
TLS 1.3のハンドシェイクでは証明書による認証に加え、任意でハンドシェイク後のクライアント認証も行えます。ただし機器と利用者の識別を別々に示したり、暗号移行期に複数の証明書チェーンを同一のTLS接続上でまとめて提示したい場面もあります。本ドラフトはこうした要求に応えるSupplemental Authenticationを定義し、既存のCertificate、CertificateVerify、Finishedのメッセージ構造をそのまま流用します。アプリケーションデータなど他のメッセージを送る前に、複数の追加証明書認証をやり取りできる設計です。
Draft Link
Action Reference: A Deterministic Identifier for Agent Actions
自律的なエージェントの行動を、誰でも独立に検証できる識別子として定義する仕様です。agent_id、action_type、scope、timestampという四つの元情報を持つ当事者なら、発行元を信頼しなくても同じ手順でaction_refという識別子を算出し照合できます。導出アルゴリズムのほか、RFC 8785のJSON Canonicalization Scheme（JCS）による正規化、タイムスタンプ形式、受領証の構造を定めています。失効やポリシー変更の監査に使う任意フィールドや、既存のexactly-once実行保証との組み合わせ方も扱う内容です。
Draft Link
Self-Verifiable Retention Chain for Payment Receipts
自己検証可能な決済記録のための暗号構成をまとめた仕様です。代表例として、外部基盤なしに改ざんを検知できる監査連鎖のretention_chain_ref、再試行時の重複処理を防ぐPayment Action Lifecycle、決済と検証済みエージェント行動を結び付けるSettlement-Action Bindingを含み、全部で八つの構成を規定します。いずれもSHA-256とJCS（RFC 8785）のみで成り立ち、発行者に問い合わせずに受領証を持つ当事者が検証できる点が共通です。MiCA、DORA、AMLRといった規制が求める記録義務にも対応する内容です。
Draft Link
SDLP Architecture (arch)
Secured Digital Lifecycle Protocol（SDLP）は、ライフサイクルで統制されるデジタルオブジェクトのためのアーキテクチャです。オブジェクトの識別、来歴、状態遷移、許可された変換を一様なモデルで扱い、異なるシステムや配布環境をまたいでもデジタル商品自身がライフサイクル規則を守れます。本ドラフトは識別子の構成方法、状態定義、遷移条件、完全性と許可操作を自ら確認する仕組みなど、SDLPを支える構成要素を説明し、生成から変換、配布、消費、廃棄までの流れと相互運用要件を示します。ワイヤーフォーマットやプロトコル自体はここでは定めません。
Draft Link
A YANG Module for Entitlement Inventory
ライセンスや認可トークン、従量課金の利用資格といったソフトウェア由来の権利を、ネットワークインベントリの中で管理するためのYANGデータモデルです。組織が持つ権利と、ネットワーク機器の能力、そして権利が能力の利用に課す制約との関係を表現します。このモデルによって事業者は、自社の機器がどのような能力を備え、そのうちどれが実際に利用許諾されているか、またどのような制限が付くのかを把握できるようになります。物理・仮想を問わずネットワーク機器を対象に、権利を一元的に管理する運用と、機器側で個別に権利を追跡する運用の両方をサポートする点が特徴です。
Draft Link
Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements
人間の代理として道具やサービス、他のエージェントを呼び出す自律的なソフトウェアエージェントが、組織の境界をまたいで動く場面が増えています。既存のワークロードやトークンによる認可の仕組みは単一の信頼領域と少ない委譲段数を前提にしており、エージェント間で再帰的に委譲される権限を独立運営の組織間で表現し、制約し、検証するには不十分です。本ドラフトは組織をまたぐエージェント委譲の課題を整理し、現行の仕組みの隙間を洗い出したうえで、WIMSEワーキンググループの検討範囲で解決策が満たすべき要件を列挙します。具体的な解決策は示していません。
Draft Link
A YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm
IS-ISのApplication-Specific Link AttributesとFlexible Algorithmという二つの機能を扱うためのYANGデータモデルを定義する仕様です。両機能に関わる設定や状態をYANGのモジュールとして表現することで、実装や機器の違いを越えて同じ形式でやり取りできるようにします。本文はモデルの構造そのものを定めるにとどまる短いドラフトですが、IS-ISまわりの既存データモデル群を補い、運用者が管理システムを通じて設定や状態を統一的に扱えるようにする位置づけの文書です。
Draft Link
Ordered Information Element Export in IP Flow Information Export (IPFIX)
IPFIXでは同一のInformation Elementがテンプレートレコード内に複数回現れることを許容しています。RFC 7011は複数出現がMetering Processの処理順に従うべきとしていますが、この順序の保証をExporting Processが伝える手段はありませんでした。収集側は繰り返し現れるInformation Elementを順序付き観測として安全に解釈できずにいました。本ドラフトはこれを踏まえ、Ordered Setという新たな型により、n番目の出現がn番目の観測に対応する順序保証を定めます。RFC 7011ほかを更新します。
Draft Link
Documenting and Managing DNSSEC Algorithm Lifecycles
暗号アルゴリズムは実験段階、採用、一般利用、主流化、縮小、非推奨、廃止という具合に、時間の経過とともに複数の局面をたどっていきます。本ドラフトはDNSSECにおけるアルゴリズム展開のこうした各局面を定義し、あるアルゴリズムを次の局面へ移す際にIETFが判断材料として使える基準を示すものです。新旧アルゴリズムの入れ替え時期を運用側が見極めやすくする狙いが根底にあり、DNSSECを支える暗号基盤全体の長期的な健全性を維持するための枠組みとして書かれています。局面ごとの位置づけを明確にすることで、移行に伴う混乱を減らす手引きにもなる文書です。
Draft Link
A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors
シリコンや機器の製造事業者が、秘密鍵や公開トラストアンカーをどのように安全に保護するかという手法を分類し整理した文書です。製造工程でトラストアンカーや秘密鍵をどのように機器へ組み込むかという活動と、製造者が保持する秘密鍵をどのように漏洩から守るかという活動の二つを扱います。個々の手法の優劣を評価するものではなく、関係者が同じ言葉で議論できるよう名称を一貫させることに主眼を置いた分類作業になっています。IRTFのT2TRGによる成果物であり、業界内で用語をそろえ、関係者同士の意思疎通を助ける基礎資料になっています。
Draft Link
Updates to OAuth 2.0 Security Best Current Practice
OAuth 2.0に関するセキュリティ上のベストプラクティス集を更新するドラフトです。RFC 6749、RFC 6750、RFC 9700で示されてきたセキュリティ助言に対し、これらの文書が公開されて以降に見つかった新たな脅威への対処を書き加える形で内容を広げています。既存の枠組みに新しい知見を積み増すことで、実装者や運用者がOAuth 2.0を利用する際に参照すべき指針を最新の状態に保つことを目的とした更新であり、対象読者は認可サーバーやクライアント、リソースサーバーの設計に関わる開発者や運用担当者です。
Draft Link
Mercurius Window System (MWS)
Mercurius Window System（MWS）は、ウィンドウや入力、音声、セッション状態を明示的に扱いながらグラフィカルなセッションを遠隔から利用できるようにする、ネットワークネイティブなサーバー側描画のシステムです。信頼できない、あるいは資源の限られたクライアント端末からでも、アプリケーションのデータやGPUの処理内容、コンポジタの状態を晒さずにワークステーションを操作できます。ゼロトラストのクライアントモデルと構造化されたセッション・ウィンドウ構成、描画・映像・音声・入力に独立した平面を持つ設計を採用し、SCTPのマルチストリーム伝送を基盤とします。
Draft Link
Handling Verification Failures of TSIG-Signed DNS Messages
DNSメッセージの正当性確認に使うTSIG（トランザクション署名）は、受信側が送信元を検証するための標準的な仕組みです。本文書は、署名付きメッセージを受け取った際に検証が失敗した場合に受信システムが取るべき挙動を更新するものです。従来の仕様では失敗時の扱いが曖昧な部分があり、実装ごとに応答や再送の判断が分かれる懸念がありました。ここでは検証失敗時にどう応答し、どのようにログや通知を扱うかを明確化し、DNS運用者や実装者が一貫した振る舞いを実現できるよう定めています。TSIGを用いる既存の相互運用性を保ちながら、失敗時の挙動をそろえる内容です。
Draft Link
A Core Acceptance Profile for Session-Bound Agent Identity
セッションに紐づくAgentのIDについて、検証者側が受け入れを判断する基準を定義する文書です。対象となるのは、暗号的に正当な資格情報が、想定と異なるサービスやテナント、Agent、タスク、権限境界に対して受け入れられてしまうコンテキストの混同という問題です。検証者は、権限付与の検証結果、鍵所有の証明、TLSや認証子エクスポートによるセッション、鮮度やリプレイの状態、必要な場合のアテステーション結果、ローカルポリシーが、すべて同一の意図した通信を指しているときに限りAgentを受け入れます。ワイヤーフォーマットや配備方法はバインディングプロファイル側に委ねられます。
Draft Link
DS Automation Status Extension for the Extensible Provisioning Protocol (EPP)
EPPにおけるドメインマッピングへの拡張を定めた文書で、EPPクライアントがサーバー側で行われるDNSSECの自動メンテナンスを有効化または無効化できるようにする仕組みを扱います。DS（Delegation Signer）レコードの管理を自動で任せるかどうかをクライアント側から制御できる点が特徴で、レジストラが個々のドメインごとに鍵管理の運用方針を切り替えられるようになります。あわせて、あるドメインの自動メンテナンス状態をRDAPの応答に含める方法も記載しており、レジストリの外部からもDNSSEC鍵管理の自動化状況を確認できるようになります。
Draft Link
Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members
Layer 2バンドルメンバー上でSegment Routing BGP Egress Peer Engineeringを実現する方法を定めた文書です。BGP-LS属性内のBGP-LSリンクNLRIにおいて、BGPピアリングリンク向けにL2 Bundle Member Attributes TLVを許可するようRFC 9085を更新します。SR-MPLSでは、同TLVのサブTLVとしてPeerAdj SID TLVを許可するよう、RFC 9085とRFC 9086を更新する内容です。バンドル構成されたリンクでも精緻な出口ピア制御が可能になります。
Draft Link
Integration of DNS Domain Names into Application Environments: Motivations and Considerations
DNSのドメイン名をアプリケーション環境に組み込む際に考慮すべき点をまとめた文書です。目的は、グローバルなDNSとそれに統合するアプリケーションとの間の衝突を減らすこと、環境をまたいで一意な識別子となる一貫したユーザー体験を提供すること、そしてグローバルDNSのセキュリティや安定性、レジリエンスへの影響を避けることにあります。懸念となりうる要素をすべて一つの文書で列挙することはできないとしつつ、少なくとも本書で扱う考慮事項を反映するだけでも、グローバルDNSと統合先アプリケーション双方のセキュリティ水準を高められるとしています。
Draft Link
Remote Two-factor Protected Services
物理的な利用者に紐づく形でサービス交換データを保護する、汎用的なサービス交換プロトコルを定義した文書です。保護には1要素または2要素を用い、所持要素に加えて知識要素または生体要素のいずれかを登録し検証する仕組みにより、2要素での保護を実現します。1FAと2FAの双方に対応した枠組みとして設計されており、認証強度に応じて要素数を切り替えるなど、状況に合わせた柔軟な運用ができます。リモート環境でも本人性を確認しながらサービスへのアクセスを制御したい場面で使われる内容で、登録から検証までの流れを一つの手順として定めています。
Draft Link
Agent Capability and Profile Model (ACPM)
AI Agentやそれを動かすプラットフォーム、呼び出すツール、基盤となる大規模言語モデルが実際に何を提供しているかを、稼働方法に左右されずに記述する、オープンでベンダー中立な仕様がAgent Capability and Profile Model、通称ACPMです。プロファイルには、識別情報、機能一覧、ツールやモデル、メモリの一覧、信頼とアテステーションの姿勢、コスト構造、サービスレベル、委任ルールが含まれます。他仕様によるAgent定義やレジストリ項目と相互参照され、レジストリやオーケストレーターが機能や信頼、コストを比較する際に使います。検証自体はACPMの範囲外です。
Draft Link
Autonomous Agent Interchange Format (AAIF)
AI Agentを可搬な形で定義するための、オープンでベンダー中立な仕様がAutonomous Agent Interchange Format、通称AAIFです。AAIF文書には、Agentの識別情報や目標、システム指示、LLMプロバイダーの選好とフォールバックの経路、順次実行や並列スワームを含むマルチAgentの構成、各種プロトコルを備えたツール一覧、メモリ設定、実行時ポリシー、テレメトリ設定、評価基準、コンプライアンス制御が収められます。定義したAgentはオフラインで検証でき、準拠ランタイムへ取り込めます。実行中のAgentを環境間で移行するチェックポイントスキーマも記載されています。
Draft Link
Placeholder for typoed email alias
タイトルからも分かる通り、これは技術的な中身を持たないプレースホルダーの登録です。abstractには内容がない旨だけが記され、綴りを誤ったメールエイリアス向けに確保された項目だと説明されています。本体は綴りの正しいdraft-rosomakho-oauth-txn-challengeであり、OAuthのトランザクション認可チャレンジを扱う仕様です。この登録はそのタイポとして生まれた入り口にあたり、実体のある技術要素は含みません。仕様を追う場合は正しい綴りの文書を参照する形になります。取り違えを避けるための注記として、あえて一覧に残しておきました。
Draft Link
BGP Flowspec Redirects to SR Policy
BGP Flowspec Version 1への拡張は、トラフィックをSegment Routing（SR）ポリシーへ誘導できるようにしていますが、本文書はBGP Flowspec Version 2でも同じ機能を提供できるよう拡張するものです。Community Container属性を用いてFSv2向けに二つの新しい標準アクションを定義しており、一つは指定したSRポリシーへ向かわせるRedirect to SR Policy Action、もう一つは追加のSRv6 SIDをカプセル化するSRv6 SID Actionです。前者は単独でも後者と組み合わせても使えます。
Draft Link
OAuth Transaction Authorization Challenge
特定の操作に対して追加の認可を求めるための、OAuthにおけるトランザクション単位の認可チャレンジの仕組みを定義した文書です。保護対象リソースは、操作に追加の認可が必要な場合にチャレンジを返す仕組みを備えており、リクエストがAgentや自動化されたワークフロー、委任サービスによって仲介され、利用者や所有者からの確認が必要な場面で役立ちます。クライアントはチャレンジを認可サーバーへ提示し、必要な承認を得たうえで、Rich Authorization Requestsで表現された操作内容を含むOAuth 2.0アクセストークンを発行します。トークンは操作が承認済みである証拠として提示されます。
Draft Link
発行されたRFC
本日発行されたRFCはありません。
編集後記
- エージェントの話題がここまで一気に増えてくると、識別子や委譲、能力の記述といった一見地味だけれど確かに土台になる部分が、いよいよ本気で議論され始めたんだなと実感できて、たくさんのドラフトを読みながらついわくわくしてしまいます。私自身、action_refのように誰でも同じ手順で後から検証できる仕組みは、あとになって履歴を追いかける側に回ったときほど本当に助けられるので、決済やAIの現場でこうした考え方がどんなふうに根づいて業務のすみずみまで広がっていくのか、これからも肩の力を抜きつつ楽しみに追いかけていきたいなと思っています。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。