2025-10-16

Cookieをオリジンに紐づける Origin-Bound Cookiesの提案仕様 (2025年版)

HTTP 雑

Cookieをオリジンに紐づける『Origin-Bound Cookies』という仕様がIETFに提出されている。

Cookieは、ポートやスキーム(http, https)が異なるURL間でも共有されます。現在のCookieはオリジンに紐づかない機能であり、現代のWebのセキュリティとして珍しいものになっています。

それに対して、Cookieをオリジンに紐づけるように変更し、セキュリティを向上するのが今回の目的である。

（なお、2022年にもGoogle勢から同様の提案があったものの、標準化には至ってない。今回は改めてIETFにDraftが提出されたものである。IETFでこれから議論されるものと思われる）

Origin-Bound Cookiesの例

簡単に動作の例を示す

ポートの同一性: https://example.comで設定されたCookieは、 https://example.com:8443 に送信されません (逆も然り)
スキームの同一性: http://example.comで設定されたCookieは、https://example.comには、送信されません（逆も然り）

なお set-cookieにdomain属性を付けることで、異なるportでもCookieを共有するように動作するようです

2025-10-06

HTTP/3のUNBOUND_DATAフレーム拡張

HTTP internet-draft

IETFに『Unbound DATA Frames in HTTP/3』という提案仕様が提出されている。

WebSocketやWebTransportといったデータをDATAフレームに格納するオーバーヘッドを減らすために、UNBOUND_DATAフレームを使うとストリーム上の後続のオクテットがデータとして解釈されるようにできます。

現状、HTTP/3でデータを送る際はストリーム上でデータフレームに格納します

新しい提案では、UNBOUND_DATAフレームを送信したあと、後続のRaw octetsが直接データとして解釈されます

UNBOUND_DATAフレーム

UNBOUND_DATAフレーム自体はこれ移行Raw octetsが流れることを示すフレームになります

かつての議論

HTTP WGのメーリングリストでは、参考として、2018年HTTP/3標準化中に似たような仕組みの議論があったとコメントが出ています。

lists.w3.org

2025-09-28

HTTPを逆向きに接続する PTTHの標準化動向メモ

HTTP internet-draft 雑

以前紹介した、逆向きにコネクションを張る Reverse HTTPという提案仕様が提出されています。

HTTPレスポンスを行う側からコネクションを確立するかたちになります。

説明は下記記事参照。

asnokaze.hatenablog.com

この取り組みは一定の興味を持たれ、IETFで標準化活動に動きがあります。7月に行われたIETF 123でもBoFが開催されました。
それが、PTTH (Protocol for Transposed Transactions over HTTP) BoF です。PTTHはHTTPの綴を逆にしたと一種のお遊びだとおもわれる。

(IETF 123 スライド)

このBoFではユースケースについて発表が行われました。主にCDNなどにおいて、オリジンサーバをインターネットリーチャブルにする必要が無いという例が挙げられます。
オリジンサーバ側からProxyにコネクションを張る形にすることで、オリジンサーバを公開する必要がなくなります（現在はProxyのグローバルIPでACL設定したり、、、設定の手間があったりします）。

まさに、CloudflareのCloudflare Tunnelのようなものです。

現在の提案仕様

古いものもあるが、現在新しく提出されているものは以下の通り

標準化に向けて

まだまだ標準化に向けて動き出したところで、幾つかの提案が出されている状態です。
現在、PTTHメーリングリストで標準化に向けて議論が進められています。

11月に開催されるIETF 124ではBoFの開催は行わないものの、WGとしてのCharter(目的やスコープを記載するも) のディスカッションが行われている。今後、そこの議論が続くものと思われます。

docs.google.com

2025-09-24

DNSレコードを自動設定するDomain Connectの標準化動向

internet-draft dns

DNSレコードの自動設定をするDomain Connectという仕組みの標準化がIETFで行われています。

未だにDNSレコードを手動設定する機会があります。例えば

メール系SaaSでSPF・DMARCレコードを設定する際、マニュアルに沿ってドメイン設定を手動設定したり
Webサイトのホスティングサーバなどでカスタムドメインを利用する際に、CNAMEレコードを設定したり

SaaSとDNS管理が別サービスであることも多いため、自動設定が出来ないケースもあります。

そこで、Domain Connectはサービスプロバイダー(SaaS)と、DNSプロバイダーが連携し、必要なDNSレコードを自動設定できるようになっています。

すでに幾つかのサービスでは利用できるようになっています

サービスプロパイダ: Google Workspace, Shopify など
DNSプロパイダ: Cloudflare, GoDaddy など

今回は、そのプロトコル部分について簡単に紹介する。

Domain Connect Protocol

『Domain Connect Protocol - DNS provisioning between Services and DNS Providers』に基づいて紹介する

登場人物

サービスプロバイダー: ドメイン名を使用して設定またはアクセスされる製品やサービスを提供する組織およびそのシステム
DNSプロバイダー: DNSゾーンホスティングサービスを提供する組織およびそのシステム
ユーザ: DNS プロバイダーでドメイン名の DNS 構成を制御する手段を持ち、サービスプロバイダーが提供するサービスと連携するように構成したいエンドユーザー

フローについて

Domain Connectには２つのフローがあります

同期フロー: ユーザ(ブラウザ)を介して、同期的にサービスプロバイダーとDNSプロバイダーの連携を行う
非同期フロー: OAuthを利用し、ユーザを介さずに非同期的に連携を行えるようにする

主には同期フローが一般的に利用されているようなので、以下は同期フローについて紹介する

同期フロー

結構長いが、ユーザ(ブラウザ)を介してサービスプロバイダーに要求を行い、DNSプロバイダーのディスカバリ(エンドポイント情報の取得)、必要なパラメータの送信を行っている。順に見ていく (手順10,11は省略する)

1. ユーザーが、サービスプロバイダーにドメイン名を入力する
2. サービスプロバイダーは入力されたドメインにおいて『 _domainconnect.(入力されたドメイン) 』のTXTレコードを引く
3. DNSプロパイダーは、(2)の問い合わせに対して、Domain Connect用APIサーバのURLを返す
4. サービスプロバイダーは URL を使用して、DNSプロバイダーにDomain Connect 設定を開始する
5. DNSプロバイダーは、API エンドポイントに関する情報を含む設定を返す
6. サービスプロバイダーは、DNSプロバイダーがサービスに必要な特定のテンプレートをサポートしているかどうかを確認する
7. DNSプロバイダーは、要求されたテンプレートをサポートしているかどうかを確認し、応答する
8. サービスプロバイダーは、DNSプロバイダーのDomain Connectサービスにつながるリンクをユーザーに提供する
9. ユーザーがリンクに移動し、ユーザーエージェントは DNSプロバイダーの Web サイトにアクセスする
12~13. DNS プロバイダーはユーザーを認証します
14. DNSプロバイダーは、ユーザーがドメインの DNSゾーンを変更する権限を持っていることをチェックする
15. DNSプロバイダーは、DNS ゾーンに変更を適用することへの同意をユーザーに求める
16. ユーザーは、DNSレコードの変更に対する同意を示す
17. DNS プロバイダーはゾーンに変更を適用する
18. DNSプロバイダーは、ユーザーをサービスロバイダーにリダイレクトするか、Webページの処理としては終わりとする
19~20. サービスプロバイダーは、DNSレコードを照会して変更が適用されたことを確認する
21. サービスプロバイダーは、ドメインがサービスに正常に接続されたことをユーザーに示し完了する

テンプレートについて

プロトコルのやり取りの中に"テンプレート"というものが登場します。
テンプレートはサービスプロパイダの必要な情報が記載されたものです。

この中には、サービスプロパイダが必要としているDNSレコードも記載されており、こと変数 (%verifytxt%) がプロトコル中で注入され、DNSプロパイダがDNSレコードを変更するということになります。

https://github.com/Domain-Connect/Templates/blob/master/google.com.domain-verification.json

{
  "providerId":"google.com",
  "providerName":"Google",
  "serviceId":"domain-verification",
  "serviceName":"Domain Verification",
  "sharedServiceName": true,
  "version": 3,
  "logoUrl":"",
  "description":"Enables a domain to work with Google",
  "variableDescription":"Unique verification code provided for purpose of verification",
  "multiInstance": true,
  "syncBlock": false,
  "syncPubKeyDomain": "google.com",
  "records":[
    {
      "groupId": "verification",
      "type": "TXT",
      "host": "@",
      "data": "%verifytxt%",
      "ttl": 3600
    }
  ]
}

標準化動向

IETFでは先述の通り、Domain Connect Protocolの標準化が進められています。現在は、Working Groupの立ち上げが行われている最中になります。
Draft自体は改版を重ねているところになるので、WGになりしだい標準化に向けて進むものと思われます。

datatracker.ietf.org

2025-08-28

ブラウザからマルチキャスト通信を行う Multicast in Direct Sockets

Web 雑

以前紹介したブラウザからTCP・UDP通信を行えるDirect Sockets APIというものがあります。（ Isolated Web Appsで動作する場合のみ使用できます ）
asnokaze.hatenablog.com

このDirect Sockets APIに、マルチキャスト通信を行えるようにする提案が出ています。
github.com

これによりネットワーク内の必要なノードに対して効率的にデータ送信ができるようになります。

簡単に Explainerを眺めておく。

ユースケース

送信者から、ネットワーク内の複数ノードへの動画データの送信
mDNSを用いたネットワーク内の特定端末のディスカバリ

コード例

送信例

// Params that sender and receiver are agreed upon.
var PORT = 12345;
var MULTICAST_GROUP_ADDR = "239.0.0.1";

// Can be bound or connected socket as you like.
// This is example of connected one.
const socket = new UDPSocket({
    remoteAddress: MULTICAST_GROUP_ADDR,
    remotePort: PORT,
    // How much network hops are allowed until the packet is discarded.
    multicastTimeToLive: 5,
    // For debug purposes, send this datagram also back to this machine.
    multicastLoopback: true
});

const encoder = new TextEncoder();
const { writable, remoteAddress, remotePort, localAddress, localPort } = await socket.opened;

const writer = writable.getWriter();
await writer.ready;

for (let i = 0; i < 3; i++) { 
    await writer.write({data: encoder.encode(`message from CLIENT = ${i}`)});
}

2025-08-08

オリジンを表現・比較可能にするOrigin Objectの提案

whatwg Web

WHATWGで、オリジンを表現し比較可能にするOrigin Objectの定義が提案されている。
github.com

今までオリジンの比較などはポリフィルで行われていたが、仕様に加える提案である。

具体例

Explainerを実際に見たほうがイメージが湧くと思います

// Tuple Origins
const origin = new Origin("https://origin.example");
const portedOrigin = new Origin("https://origin.example:8443");
const sameSiteOrigin = new Origin("https://sub.origin.example");
const notSameSiteOrigin = new Origin("http://other.example");

origin.isSameOrigin(origin);          // True!
origin.isSameOrigin(portedOrigin);    // False!
origin.isSameOrigin(sameSiteOrigin);  // False!

origin.isSameSite(portedOrigin);      // True!
origin.isSameSite(sameSiteOrigin);    // True!
origin.isSameSite(notSameSiteOrigin); // False!

Originという名前を使用しても既存のWebで問題ないかなど、懸念事項はあるが引き続き議論がされるのではないかと思う