ウェブ生成元の概念

2.1. 適合性基準

この文書におけるキーワード： 「〜しなければ（〜しては）ならない」 = “MUST (NOT)”, 「要求される」= REQUIRED, 「〜すべきである（でない）」 = “SHOULD (NOT)”, 「推奨される」 = “RECOMMENDED”, 「〜してもよい」 = “MAY”, 「任意選択 」 = “OPTIONAL”, は、 [RFC2119] に則って解釈されるものとする。 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

アルゴリズムの中の命令的言い回しによる要件（例えば「先頭部のスペース文字並びを取り除く」, 「 false を返してこの手続きを中止する」など）は、アルゴリズムを引用する際に利用されているキーワード（「〜しなければならない」(MUST), 「〜すべき」(SHOULD), 「〜してもよい」(MAY), 等々）の意味の下に解釈されることになる。 Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.

アルゴリズムまたは特定の手続きとして記される適合性の要件は、最終的な結果が等価になるのであれば，どのように実装されてもよい。 特に、この仕様で定義されるアルゴリズムは 理解し易くなるように記述されており，パフォーマンスは考慮されていない。 Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.

2.2. 構文の表記

この仕様は [RFC5234] の ABNF （ Augmented Backus Naur Form ）記法を用いる。 This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].

次の中核規則は RFC 5234, Appendix B.1 による定義を参照する： CR（ carriage return ）, CRLF（ CR LF ）, LF（ line feed ）, SP（ space ）, HTAB（水平タブ — horizontal tab ）, WSP（空白 — whitespace ） 【この訳では、利用されていない規則は省略している。】 The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- ASCII character), VCHAR (any visible US-ASCII character), and WSP (whitespace).

ゼロ個以上の連続する空白オクテットが現れ得る所では， OWS 規則が用いられる。 OWS は、生成されないか, または１個の SP として生成されるべきである。 フィールド内容に現れる複数個の OWS オクテット並びは、そのフィールド値が解釈される前, またはメッセージを下流に転送する前に、１個の SP 置換されるか, または SP のみからなるオクテットに変換（ SP 以外の各オクテットは SP に置換）されるべきである。 The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting the field value or forwarding the message downstream.

OWS            = *( SP / HTAB / obs-fold )
               ;  “オプションの” 空白
obs-fold       = CRLF ( SP / HTAB )
               ; 廃用の行折り返し

2.3. 用語

語 “UA”, “クライアント”, “サーバ”, “プロキシ”, “生成元サーバ” は、 HTTP/1.1仕様（ RFC 2616, 1.3 節 ）によるものと同じ意味を持つものとする。 The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).

大域的一意識別子（ GUID — globally unique identifier ）は、既存の他のすべての値と異なる値である。 十分に長いランダムな文字列は，ほぼ確実に大域的一意識別子になる。 If the origin value never leaves the user agent, 【 UA が生成元の値を決して忘れないのであれば？】、 UA に局所的な単調増加するカウンタでも，大域的一意識別子として機能できる。 A globally unique identifier is a value that is different from all other previously existing values. For example, a sufficiently long random string is likely to be a globally unique identifier. If the origin value never leaves the user agent, a monotonically increasing counter local to the user agent can also serve as a globally unique identifier.

3.1. 信頼関係

同一生成元ポリシーは URI により，信頼関係を指定する。 例えば HTML 文書は、 URI を通して実行するスクリプトを指名する： The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI:

<script src="https://example.com/library.js"></script>

【 指名 — designate ： “指定” の対訳が普通だが、 “選定して役割をあてがう” 含みも込めて。 この和訳では（この段落に限らず — やや見慣れない表現になる箇所もあるが）、 “specify” を意味する 指定 との区別を優先させる。 】

UA がこのプロトコル要素を処理する際には、 UA は指名された URI のスクリプトを取得し, 文書が持つ特権の下にスクリプトを実行することになる。 このようにして，文書は、自身が持つすべての特権を URI により指名されたリソースに与える。 本質的には、文書は，その URI から取得された情報の完全性を信用することを宣言している。 When a user agent processes this element, the user agent will fetch the script at the designated URI and execute the script with the privileges of the document. In this way, the document grants all the privileges it has to the resource designated by the URI. In essence, the document declares that it trusts the integrity of information retrieved from that URI.

URI からの【スクリプトなどの】ライブラリの取り込みに加えて、 UA はまた， URI により指名されたリモート主体へ向けて情報を送信する。 例えば HTML の form 要素を考える： In addition to importing libraries from URIs, user agents also send information to remote parties designated by URI. For example, consider the HTML form element:

<form method="POST" action="https://example.com/login">
 ... <input type="password"> ...
</form>

利用者が自身のパスワードを入力してフォームを送信するとき、 UA は，その URI により指名されたネットワーク端点へ向けてパスワードを送信する。 このようにして、文書はその秘匿データをその URI に開示する。 すなわち、その URI へ向けて送信される情報の機密性を信用することを宣言する。 When the user enters his or her password and submits the form, the user agent sends the password to the network endpoint designated by the URI. In this way, the document exports its secret data to that URI, in essence declaring that it trusts the confidentiality of information sent to that URI.

3.2. 生成元 — Origin

原理的には、 UA がどの URI も別個の保護ドメインとして扱い，ある URI から取得された内容と 別の URI とのやりとりに，明示的な合意を要するようにすることも考えられる。 しかしながら、ウェブアプリケーションはしばしば，協調して働くいくつものリソースからなるので、この設計は開発者にとっては厄介なものになる。 In principle, user agents could treat every URI as a separate protection domain and require explicit consent for content retrieved from one URI to interact with another URI. Unfortunately, this design is cumbersome for developers because web applications often consist of a number of resources acting in concert.

代案として、 UA は URI を “生成元” と呼ばれる保護ドメインに，ひとまとめにする。 大雑把に言えば、２つの URI は，それらが同じ［スキーム, ホスト, ポート］を持つならば，同じ生成元に属する（すなわち，同じ主体を表現する）。 （全部的な詳細は 4 節 に。） Instead, user agents group URIs together into protection domains called "origins". Roughly speaking, two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port. (See Section 4 for full details.)

Q： 単にホスト名だけでも十分ではありませんか？ Q: Why not just use the host?

A： スキームを生成元に組み入れることは、セキュリティにとって本質的です。 UA がスキームを組み入れなかったなら、 http://example.com と https://example.com は同じホストを持つことになり，隔離されなくなります。 しかしながら，この隔離がなければ、ネットワーク攻撃者は， 【 TLS などによる保護のない，】 http://example.com から取得される内容に細工を施すことにより，その内容から https://example.com から取得される内容の機密性と完全性を弱体化させる指示を UA に出せてしまいます。 その結果、 TLS [RFC5246] が提供する保護は迂回されてしまいます。 A: Including the scheme in the origin tuple is essential for security. If user agents did not include the scheme, there would be no isolation between http://example.com and https://example.com because the two have the same host. However, without this isolation, an active network attacker could corrupt content retrieved from http://example.com and have that content instruct the user agent to compromise the confidentiality and integrity of content retrieved from https://example.com, bypassing the protections afforded by TLS [RFC5246].

Q： 何故、単に “トップレベル” のドメインではなく，完全修飾ホスト名を用いるのですか？ Q: Why use the fully qualified host name instead of just the "top-level" domain?

A： DNS は階層的な委譲を備えていますが、ホスト名の間の信頼関係は、配置­状況により様々です。 例えば，多くの教育機関では、学生たちは https://example.edu/~student/ の下に内容をホストできますが、一学生が作成した文書と https://grades.example.edu/ の下にホストされている成績管理用のウェブアプリケーションとが，同じ生成元に属する（すなわち，同じ保護ドメイン下にある）と見なされるべきではないでしょう。 A: Although the DNS has hierarchical delegation, the trust relationships between host names vary by deployment. For example, at many educational institutions, students can host content at https://example.edu/~student/, but that does not mean a document authored by a student should be part of the same origin (i.e., inhabit the same protection domain) as a web application for managing grades hosted at https://grades.example.edu/.

example.edu の配置の例は、生成元によるリソースの仕分けが，どの配置­状況にも常に完璧に沿えるわけではないことを示してもいます。 この配置の場合，どの学生のウェブサイトも同じ生成元の下にあり、望まれるものではないかもしれません。 ある意味、生成元の粒度は，セキュリティモデルの発展過程で生じた歴史的な歪みです。 The example.edu deployment illustrates that grouping resources by origin does not always align perfectly with every deployment scenario. In this deployment, every student's web site inhabits the same origin, which might not be desirable. In some sense, the origin granularity is a historical artifact of how the security model evolved.

http://example.com/
http://example.com:80/
http://example.com/path/file

http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/

3.3. 権限

UA は URI を生成元により仕分けるが、同じ生成元に属するどのリソースも同じ権限（ “authority” — [RFC3986] による意味の “authority”† ではなく，セキュリティの意味で）を有するとは限らない。 例えば，画像は受動的な内容なので、何ら権限を有しない††。 すなわち，画像は、その生成元にて可用なオブジェクトやリソースへのアクセスを持たない。 対して、 HTML 文書は，その生成元に対する全権限を有し、その文書­内の（またはそれに取り込まれた）スクリプトは，その生成元に属するどのリソースにもアクセスし得る。 Although user agents group URIs into origins, not every resource in an origin carries the same authority (in the security sense of the word "authority", not in the [RFC3986] sense). For example, an image is passive content and, therefore, carries no authority, meaning the image has no access to the objects and resources available to its origin. By contrast, an HTML document carries the full authority of its origin, and scripts within (or imported into) the document can access every resource in its origin.

【† URI 構文の一部を成す “authority” 】【†† 同じ画像でも， SVG のような HTML と同程度に高機能になり得る画像は、通常の画像と同程度に低リスクなものと見なすためには，その能動的な部分の機能を制約する必要があることになる。 】

UA は，リソースのメディア型を吟味することにより、リソースに与える権限の度合いを決定する。 例えば、メディア型 image/png のリソースは画像として扱われ，メディア型 text/html のリソースは HTML 文書として扱われる。 User agents determine how much authority to grant a resource by examining its media type. For example, resources with a media type of image/png are treated as images, and resources with a media type of text/html are treated as HTML documents.

ウェブアプリケーションは、信用できない内容（利用者により生成された内容など）をホストする際に、そのメディア型を制約することにより，内容の権限を制限できる。 例えば、利用者により生成された内容を image/png としてサービス供与するリスクは， text/html としてサービス供与するより小さい。 無論、多くのウェブアプリケーションは，信用できない内容を自身の HTML 文書に統合するが、注意深く行わなければ、これらのアプリケーションは，その生成元の権限を，信用できない内容にも漏洩するリスクにさらすことになる。 これは、一般に XSS （クロスサイトスクリプティング）として知られている脆弱性である。 When hosting untrusted content (such as user-generated content), web applications can limit that content's authority by restricting its media type. For example, serving user-generated content as image/png is less risky than serving user-generated content as text/html. Of course, many web applications incorporate untrusted content in their HTML documents. If not done carefully, these applications risk leaking their origin's authority to the untrusted content, a vulnerability commonly known as cross-site scripting.

3.4. ポリシー

一般に、 UA は異なる生成元を隔離しつつ，生成元どうしの通信は制御された形で許可する。 UA が隔離と通信をどのような形で提供するかについての詳細は、いくつかの要因に依存して様々になる。 Generally speaking, user agents isolate different origins and permit controlled communication between origins. The details of how user agents provide isolation and communication vary depending on several factors.

3.5. 要約

同一生成元ポリシーは、信頼関係の指名に URI を用いる。 各 URI は生成元ごとにまとめられ，保護ドメインを表現する。 生成元に属する一部のリソース（例えば，能動的な内容）には，その生成元の全権限が与えられる一方で、生成元に属する他のリソース（例えば，受動的な内容）には，生成元の権限は与えられない。 その生成元の権限を有する内容は、自身の生成元に属する オブジェクトやネットワークリソース へのアクセス権が与えられる。 この内容には，他の生成元の オブジェクトやネットワークリソース への制限されたアクセス権も与えられるが、これらの非同一生成元 特権は，セキュリティ脆弱性を避けるように注意深く設計されなければならない。 The same-origin policy uses URIs to designate trust relationships. URIs are grouped together into origins, which represent protection domains. Some resources in an origin (e.g., active content) are granted the origin's full authority, whereas other resources in the origin (e.g., passive content) are not granted the origin's authority. Content that carries its origin's authority is granted access to objects and network resources within its own origin. This content is also granted limited access to objects and network resources of other origins, but these cross-origin privileges must be designed carefully to avoid security vulnerabilities.

6.1. Unicode による生成元の直列化

生成元の unicode 直列化とは、次のアルゴリズムにより返される値である： The unicode-serialization of an origin is the value returned by the following algorithm:

1. 生成元が スキーム/ホスト/ポート の三つ組でないならば、文字列 null （すなわち，符号位置の並び U+006E, U+0075, U+006C, U+006C ）を返してこの手続きを中止する。 If the origin is not a scheme/host/port triple, then return the string null (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
2. 他の場合、 結果 を三つ組 生成元のスキーム部とする。 Otherwise, let result be the scheme part of the origin triple.
3. 文字列 "://" を 結果 の末尾に付加する。 Append the string "://" to result.

4. 三つ組 生成元のホスト部の各­成分を（次の様に変換してから） U+002E FULL STOP 符号位置（ "." ）で区切って 結果 の末尾に付加する： Append each component of the host part of the origin triple (converted as follows) to the result, separated by U+002E FULL STOP code points ("."):

   1. 成分が A-label であるならば、対応する U-label を代わりに用いる（ [RFC5890], [RFC5891] 参照）。 If the component is an A-label, use the corresponding U-label instead (see [RFC5890] and [RFC5891]).
   2. 他の場合、その成分をそのまま用いる。 Otherwise, use the component verbatim.

5. 三つ組 生成元のポート部がスキーム部で与えられるプロトコルに対する既定ポートとは異なるならば： If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:

   1. U+003A COLON 符号位置（ ":" ）に続けて，与えられたポートの十進表記を 結果 の末尾に付加する。 Append a U+003A COLON code point (":") and the given port, in base ten, to result.
6. 結果 を返す。 Return result.

6.2. ASCII による生成元の直列化

生成元の ASCII 直列化とは、次のアルゴリズムにより返される値である： The ascii-serialization of an origin is the value returned by the following algorithm:

1. 生成元が スキーム/ホスト/ポート の三つ組でないならば、文字列 null （すなわち，符号位置の並び U+006E, U+0075, U+006C, U+006C ）を返してこの手続きを中止する。 If the origin is not a scheme/host/port triple, then return the string null (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
2. 他の場合、 結果 を三つ組 生成元のスキーム部とする。 Otherwise, let result be the scheme part of the origin triple.
3. 文字列 "://" を 結果 の末尾に付加する。 Append the string "://" to result.
4. 三つ組 生成元のホスト部を 結果 の末尾に付加する。 Append the host part of the origin triple to result.

5. 三つ組 生成元のポート部が, 三つ組 生成元のスキーム部で与えられるプロトコルに対する既定ポートと異なるならば： If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:

   1. U+003A COLON 符号位置（ ":" ）に続けて，与えられたポートの十進表記を 結果 の末尾に付加する。 Append a U+003A COLON code point (":") and the given port, in base ten, to result.
6. 結果 を返す。 Return result.

7.1. 構文

Origin ヘッダフィールドの構文は次で与えられる： The Origin header field has the following syntax:

origin              = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list         = serialized-origin *( SP serialized-origin )
serialized-origin   = scheme "://" host [ ":" port ]
                    ; <scheme>, <host>, <port> from RFC 3986

【 この構文では、ヘッダフィールド値が，複数個の生成元を含み得るが、現時点のウェブ­プラットフォームでは，1 個に限るように制約が追加されている。 したがって、以下の 7.2, 7.3 節の記述も，実際には より単純化し得るであろう。 】

7.2. 意味論

HTTP リクエストに含められている Origin ヘッダフィールドは、 UA によるリクエストの発行を（ UA が供するリクエスト発行のための API の定義に従って） “誘発” した生成元（複数個もあり得る）を指示する。 When included in an HTTP request, the Origin header field indicates the origin(s) that "caused" the user agent to issue the request, as defined by the API that triggered the user agent to issue the request.

例えば、生成元を代表するスクリプトを実行する UA を考える。 UA は、これらのスクリプトのいずれかが UA による HTTP リクエストの発行を誘発した際に、 Origin ヘッダフィールドを用いて，スクリプトを実行中のセキュリティ文脈をサーバに伝達してもよい。 For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request, the user agent MAY use the Origin header field to inform the server of the security context in which the script was executing when it caused the user agent to issue the request.

場合によっては、複数の生成元が UA による HTTP リクエスト発行の誘発に寄与することがある。 そのような場合、 UA は Origin ヘッダフィールド内にそれらの生成元すべてをリストしてもよい。 例えば、初期時は ある生成元により HTTP リクエストが発行されていて，後で別の生成元にリダイレクトされた場合、 UA は UA に対するリクエスト発行の誘発に２つの生成元が寄与していることをサーバに伝達してもよい。 In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, the user agent MAY list all the origins in the Origin header field. For example, if the HTTP request was initially issued by one origin but then later redirected by another origin, the user agent MAY inform the server that two origins were involved in causing the user agent to issue the request.

【 “リスト”しても… — 次節最後の要件も考慮するなら，誘発への寄与の順序も考慮されるべき？ 】

7.3. UA に課される要件

UA はどの HTTP リクエストにも， Origin ヘッダフィールドを含めてもよい。 The user agent MAY include an Origin header field in any HTTP request.

UA はどの HTTP リクエストにも，複数個の Origin ヘッダフィールドを含めてはならない。 The user agent MUST NOT include more than one Origin header field in any HTTP request.

UA が “プライバシーに敏感な” 文脈の下から HTTP リクエストを発行するときは，常に、 Origin ヘッダフィールドに値 “null” を送信しなければならない。 Whenever a user agent issues an HTTP request from a "privacy- sensitive" context, the user agent MUST send the value "null" in the Origin header field.

注記： この文書は、どのような表層概念（ notion ）をもって “プライバシーに敏感な” 文脈 とされるかは，定義しない。 HTTP リクエストを生成するアプリケーションは、文脈をプライバシーに敏感であるものと指名して， UA による Origin ヘッダフィールドの生成の仕方に制約を課すことができる。 NOTE: This document does not define the notion of a privacy- sensitive context. Applications that generate HTTP requests can designate contexts as privacy-sensitive to impose restrictions on how user agents generate Origin header fields.

Origin ヘッダフィールドの生成­時には、 UA は次の要件に従わなければならない。 When generating an Origin header field, the user agent MUST meet the following requirements:

• serialized-origin 生成規則によるそれぞれの生成結果は、生成元の ASCII 直列化でなければならない。 Each of the serialized-origin productions in the grammar MUST be the ascii-serialization of an origin.

• 連続するどの２つの生成結果も，一致することはない。 特に、 UA が【同じ？】生成結果を連続して生成することになる場合、２個目を生成してはならない。 No two consecutive serialized-origin productions in the grammar can be identical. In particular, if the user agent would generate two consecutive serialized-origins, the user agent MUST NOT generate the second one.

8.1. DNS への依存性

実施においては、 http などの共通して用いられる URI スキームの多くは， DNS （ Domain Name System ）に基づく命名機関を利用しているので、同一生成元ポリシーのセキュリティは DNS に立脚することになる。 DNS が部分的にでも弱体化された場合、同一生成元ポリシーは，アプリケーションが要求するセキュリティの特質を満たせなくなるであろう。 In practice, the same-origin policy relies upon the Domain Name System (DNS) for security because many commonly used URI schemes, such as http, use DNS-based naming authorities. If the DNS is partially or fully compromised, the same-origin policy might fail to provide the security properties required by applications.

https など一部の URI スキームは、 UA がこれらの URI から取得された内容のソースを検証するために，証明書のような他の仕組みを使役しているので、 DNS の汚染に対し，より抵抗力がある。 chrome-extension URI スキーム（ [CRX] 4.3 節を参照）などの他の URI スキームは、公開鍵に基づく命名機関を用いるものであり， DNS 汚染に対し十分にセキュアである。 Some URI schemes, such as https, are more resistant to DNS compromise because user agents employ other mechanisms, such as certificates, to verify the source of content retrieved from these URIs. Other URI schemes, such as the chrome-extension URI scheme (see Section 4.3 of [CRX]), use a public-key-based naming authority and are fully secure against DNS compromise.

ウェブ生成元の概念は、異なる URI スキームから取得された内容を隔離する。 これは、 DNS 汚染による影響を一定範囲に封じ込めることに本質的である。 The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise.

8.2. 隔離単位の分岐

これまで，いくつもの技術が、便利な隔離単位として，ウェブ生成元の概念に収束してきた。 しかしながら，クッキー [RFC6265] などの今日用いられる多くの技術が、現代のウェブ生成元の概念に先行して存在している。 これらの技術における隔離­単位は，生成元とは異なることも多いため、脆弱性がもたらされる。 Over time, a number of technologies have converged on the web origin concept as a convenient unit of isolation. However, many technologies in use today, such as cookies [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities.

代替案として、隔離単位に完全修飾ドメイン名（ FQDN ）ではなく， “登録制” によるドメインのみを利用することも考えられるが（例えば "www.example.com" の代わりに "example.com" ）、この実施にはいくつもの理由から問題があり，推奨されない： One alternative is to use only the "registry-controlled" domain rather than the fully qualified domain name as the unit of isolation (e.g., "example.com" instead of "www.example.com"). This practice is problematic for a number of reasons and is NOT RECOMMENDED:

1. “登録制” ドメインの表層概念は、 DNS 自体に備わる特質ではなく， DNS を取り巻く，人による実施の役割になる。 例えば、日本の多くの地方自治体の公共レジストリは，極めて深い DNS 階層で運用されている。 広く利用されている "public suffix lists" があるが、これらのリストは最新の状態に保つことが困難であり，実装間で様々になる。 The notion of a "registry-controlled" domain is a function of human practice surrounding the DNS rather than a property of the DNS itself. For example, many municipalities in Japan run public registries quite deep in the DNS hierarchy. There are widely used "public suffix lists", but these lists are difficult to keep up to date and vary between implementations.
2. この実施は DNS に基づく命名機関を利用しない URI スキームと互換性が無い。 例えば，命名機関として公開鍵を利用する URI スキームの場合、 “登録制” 公開鍵の表層概念には矛盾を孕む部分がある。 加えて、 nntp などの一部の URI スキームは，委譲­関係に DNS とは逆順のドット区切りを用いており（例えば alt.usenet.kooks ）、また， DNS を用いつつ, 通常とは逆順にラベルを表示するものもある（例えば com.example.www ）。 This practice is incompatible with URI schemes that do not use a DNS-based naming authority. For example, if a given URI scheme uses public keys as naming authorities, the notion of a "registry-controlled" public key is somewhat incoherent. Worse, some URI schemes, such as nntp, use dotted delegation in the opposite direction from DNS (e.g., alt.usenet.kooks), and others use the DNS but present the labels in the reverse of the usual order (e.g., com.example.www).

“登録制” ドメインの利用は、良くても URI スキームと実装に固有である。 最悪の場合、 URI スキームと実装との相違から脆弱性がもたらされ得る。 At best, using "registry-controlled" domains is URI-scheme- and implementation-specific. At worst, differences between URI schemes and implementations can lead to vulnerabilities.

8.3. ambient 権限

同一生成元ポリシーが利用される下では、 UA は内容に対し、その内容がどのオブジェクトを指名し得るか ではなく，内容の URI に基づいて権限を与える。 この、指名が，権限から分離されることは、 ambient 権限の一例であり，脆弱性をもたらし得る。 When using the same-origin policy, user agents grant authority to content based on its URI rather than based on which objects the content can designate. This disentangling of designation from authority is an example of ambient authority and can lead to vulnerabilities.

【 ambient 権限 ：環境から暗黙的に与えられる権限 — 参考 】

例えば HTML 文書における XSS を考える。 もし攻撃者が HTML 文書­内にスクリプト内容を注入できたなら、これらのスクリプトは，文書の生成元の権限の下に実行され、利用者の医療記録など，大事な情報へのスクリプト­アクセスが許容されてしまうことになる。 しかしながら、スクリプトの権限が，スクリプトが指名し得るオブジェクトに制限されるのであれば、攻撃者が，第三者にホストされている HTML 文書にスクリプトを注入することにより優位を得ることもなくなるであろう。 Consider, for example, cross-site scripting in HTML documents. If an attacker can inject script content into an HTML document, those scripts will run with the authority of the document's origin, perhaps allowing the script access to sensitive information, such as the user's medical records. If, however, the script's authority were limited to those objects that the script could designate, the attacker would not gain any advantage by injecting the script into an HTML document hosted by a third party.

8.4. IDNA への依存とその移行

同一生成元ポリシーのセキュリティの特質は、 UA に使役されている IDNA アルゴリズムの詳細に決定的に依存し得る。 特に，一部の国際化ドメイン名（例えば U+00DF 文字を含むもの ）については、 UA が IDNA2003 [RFC3490] か IDNA2008 [RFC5890] のいずれを用いているかに依存して，別々の ASCII 表現に対応付け得る。 The security properties of the same-origin policy can depend crucially on details of the IDNA algorithm employed by the user agent. In particular, a user agent might map some international domain names (for example, those involving the U+00DF character) to different ASCII representations depending on whether the user agent uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].

IDNA アルゴリズムを別のものへ移行させることは、いくつかのセキュリティ境界を書き換えることになり得る： 新たなセキュリティ境界を敷いたり，より望ましくない方では，互いに信用できない複数の主体­間のセキュリティ境界を取り払ってしまうなど。 特に後者の場合，一方が他方を攻撃することが許容されるので、セキュリティ境界の変更はリスクを伴う。 Migrating from one IDNA algorithm to another might redraw a number of security boundaries, potentially erecting new security boundaries or, worse, tearing down security boundaries between two mutually distrusting entities. Changing security boundaries is risky because combining two mutually distrusting entities into the same origin might allow one to attack the other.