こんにちは、GMOコネクトの名もなきエンジニアです。
よろしくお願いします！

日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-06-20（UTC基準）に公開されたInternet-DraftとRFCをまとめました。

Internet-Draft: 12件
RFC: 0件

この日はRFCの発行はなく、Internet-Draftが12件でした。件数が落ち着いているので、1本にまとめてお届けします。

参照先:

その日のサマリー & Hot Topics

この日はInternet-Draftが12件、RFCの発行はありませんでした。件数こそ控えめですが、話題の振れ幅は大きく、AIエージェントの認証や決済にまつわる提案がこの日も続きました。多人数での承認を求めるEP-QUORUM、トランザクショントークンをドメイン境界で引き継ぐ profile、エージェントのアイデンティティと決済トークンを扱うKYAPayなどが並びます。DNSの暗号化やRFCの編集ポリシー、SRv6の出口保護といった硬派な文書も投稿され、静かながら読みどころの多い一日でした。
特に印象に残るのは、RFCの執筆倫理を扱う文書とエージェントの多人数承認を扱う文書が同じ日に出てきたことです。前者は文書準備でのAI利用を含む著者資格の指針で、後者は高リスクな行動にM-of-Nの承認を課す仕組みです。作る側の責任と、動かす側の歯止めが、それぞれの角度から語られていました。加えてDNSCryptがdpriveの文脈で版を重ね、SRv6のMirror SID IGPエンコーディングがlsrに舞台を移すなど、地に足のついた前進も見られます。

投稿されたInternet-Draft

Mathematical notation in RFCs

RFCXMLと関連する公開フォーマットで、数式表記をどう表現するかのポリシーを定め、新しい技術の利用を認める編集系の文書です。このポリシーを実装したあとは、選ばれた数式表記をRFCXMLとHTMLの公開フォーマットで使うべきとしています。RFCはテキスト中心の文化が長く、数式を素直に書けないもどかしさがありましたが、暗号やネットワークの理論的な記述で数式が要る場面は確実に増えています。読み手にとっての可読性と、フォーマットとしての一貫性を両立させようとする、地味だけれど意味のある整備です。-01版です。
Draft Link

The DNSCrypt Protocol

クライアントとリゾルバの間のDNSトラフィックを暗号化し、認証するために設計されたDNSCryptプロトコルを規定する文書です。プロトコルとその実装を定め、DNS通信を守るための標準的なアプローチを提供します。既存のDNSインフラとの互換性を保ちながら、元のDNSプロトコルが抱える機密性や完全性の弱さ、攻撃への耐性の低さを改善するとしています。DNSCrypt自体は実運用での歴史がありますが、それをdpriveの文脈で仕様として整えていく動きで、-10版まで版を重ねています。DNS暗号化の選択肢を語るうえで押さえておきたい一本です。
Draft Link

Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining

前日に紹介したOAuthのアイデンティティ・認可チェーンの仕組みに対して、トランザクショントークンを使うプロファイルを定義する提案です。トークン交換の要求で、Txn-Tokenを主体トークンとして提示し、信頼境界を越えるためのJWT認可グラントを得ます。Txn-Tokenは単一の信頼ドメインに閉じ、進行中のトランザクションの認可コンテキスト全体を表します。人間がAPIを呼んだ場合も、内部イベントや自動化されたワークロードが起点の場合も同じ枠組みで扱え、内部の資格情報やトークン形式を境界の外に晒さずにコンテキストを引き継げるのが要点です。-01版です。
Draft Link

Multi-Party Quorum Authorization for High-Risk Agent Actions (EP-QUORUM)

高リスクなエージェントの行動に、多人数の承認を課すEP-QUORUMを定義する初版ドラフトです。EMILIA Protocolの認可レシートを土台に、一人の責任者を一つの行動に束縛する基本形を、複数の責任者を束縛する形へ一般化します。二人ルールをM-of-Nや順序付きの承認履歴まで広げ、定足数がそろうまで行動を認可しません。すべての署名が有効で、全員が同じ行動に束縛され、承認者が互いに別人で、役割で認められ、閾値と宣言された順序と時間枠を満たす、というフェイルクローズドな述語を規定します。JavaScriptとPython、Goの3実装が一致する適合ベクタで守るという徹底ぶりです。
Draft Link

Guidelines for Assignment of RFC Authorship

RFC文書で著者資格を割り当てる際の倫理的な指針を記述する文書です。文書の準備における人工知能の利用や、ほかの文書からの素材の取り込みに関する指針も含みます。あわせて謝辞や編集者、貢献者といった関連する論点にも触れます。各RFCストリームがこの指針を適用し、必要なら独自の変種を定めて優先させることが期待されています。誰を著者とするか、AIをどこまで使ってよいかという問いは、この日刊IETFを書いている身にも刺さるテーマで、標準化コミュニティが作り手の責任に正面から向き合う姿勢が伝わってきます。-05版です。
Draft Link

Applicability & Manageability Considerations for SCONE

アプリケーションのエンドポイントにスループットのガイダンスを提供するにあたっての、適用性と管理性の考慮事項を記述するWG文書です。このガイダンスは、SCONEプロトコルを使う通信サービスプロバイダのネットワークという文脈で具体的に扱われます。ネットワーク側が持つ帯域の見立てをアプリに伝えられれば、動画配信などで無駄な再送や過剰な要求を避けやすくなります。プロトコルそのものの定義というより、実際に運用へ載せるときに何を考えるべきかを整理する文書で、標準を現場に橋渡しする役割を担っています。-02版です。
Draft Link

KYAPay Profile

エージェントのアイデンティティと決済のトークンを、JWT形式で扱うためのプロファイルを定義する提案です。異なるベンダーの認可サーバとリソースサーバが、このプロファイルを使うことで、アイデンティティトークンと決済トークンを相互運用可能な形で受け取れるようにします。この日はエージェントの決済に関わる提案が複数出ており、KYAPayもその流れの一つです。エージェントが自律的に支払いを扱う世界では、誰のエージェントで、どんな支払い能力を持つのかを共通の形式で示せることが鍵になります。著者にはJWT界隈でおなじみのMichael B. Jones氏の名前もあります。-02版です。
Draft Link

The Network File System Access Control List Protocol

NFS_ACLプロトコルを記述する情報提供カテゴリの文書です。NFS_ACLは、NFSファイルシステム群のなかでも古くからのメンバーで、NFSクライアントがバージョン2や3のサーバに保存されたアクセス制御リストを閲覧し更新するために使います。新しい仕組みというより、長年動いてきた既存プロトコルをきちんと文書として残す性格の一本です。稼働中の実装や相互運用のために、古い技術でも仕様を明文化しておく価値は大きく、こうした地道な記録作業がインターネットの土台を支えているのだと感じます。-02版です。
Draft Link

Hexadecimal Color-Based Domain Name Resolution (Hex-DNS)

DNSの代替、あるいは補完となるアドレッシングの仕組みを提案する、かなり大胆な初版ドラフトです。従来のアルファベットのドメイン名を、標準的な6文字のRGB16進コードによる視覚的な識別子に置き換えるルーティングの考え方を導入します。国コードを接頭辞に、カテゴリの識別子を接尾辞に付ける構成です。色でドメインを表すという発想は目を引きますが、可読性や衝突、既存DNSとの整合など論点も多そうです。I-D Announceを眺めていると、こうした自由な思考実験にも出会えるのが楽しいところです。
Draft Link

IGP Encoding for SRv6 Mirror SID in Egress Protection

SRv6パスの出口ノード保護をMirror SIDの仕組みで実現するために必要なIGP拡張を定義する初版ドラフトで、前日に紹介したものが今回はlsrワーキンググループの文脈で投稿されています。IS-ISとOSPFv3に新しいサブTLVを定め、Mirror SIDと保護対象ロケータの集合を広告できるようにし、バックアップの出口ノードが単一のリンクステートIGPエリア内で主たる出口ノードを保護できる能力を通知します。出口保護の全体機構を定める文書の姉妹編で、こちらはシグナリングの土台を与える役割です。適切なWGへ整理されていく過程がうかがえます。
Draft Link

The Open Tabs Standard: Passkey-Rooted Delegated Signers for Non-Custodial Payment Channels on Solana

Solana上の非カストディ型ペイメントチャネルであるOpen Tabs Standardについて、パスキーを起点とする委任署名者の認可モデルを規定する初版ドラフトです。Solanaのネイティブなsecp256r1署名検証のプリコンパイルを使い、WebAuthnのパスキーでバウチャーの署名者を認可します。Solana Session Intentと相互運用でき、チャネルとバウチャーのプリミティブを共有します。参照実装がSolanaメインネットで稼働中と書かれており、具体的なアカウントまで示されています。特定チェーンに深く踏み込んだ提案がIETFに出てくること自体、決済とエージェントをめぐる裾野の広がりを感じさせます。
Draft Link

SakiAgentSSH Secure Protocol Specification

信頼されたエージェント間で、認証付きのリモートコマンド実行やプロセス入出力のストリーミング、バイナリファイル転送を行うためのアプリケーション層のオーバーレイプロトコル、SASSのバージョン1.4を記述する提案です。制御と転送を切り離すアーキテクチャを採り、CBORとJSONを基本のシリアライズとする抽象メッセージングモデルを定めます。前方秘匿の監査ハッシュ連鎖や、tls-exporterのチャネルバインディングの取り込みなど、四つの節目でセキュリティを段階的に進化させてきたと説明します。独特の用語が多い野心的な文書ですが、エージェント同士の安全な遠隔操作という主題は今の関心によく響きます。-08版です。
Draft Link

編集後記

件数が少ない日ほど、一件ずつの個性が際立つように思います。この日はRFCの著者資格とAI利用の倫理を説く文書を読みながら、まさにAIの助けを借りて日刊IETFを書いている自分の手が、少しだけ止まりました。作る責任も、動かす歯止めも、結局は人間がどこで判断するかに帰ってくるのだなと。みなさんはAIを使って文章を書くとき、どこまでを自分の仕事だと感じますか。よければコメントで聞かせてください。

最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ: https://gmo-connect.jp/contactus/