One document matched: draft-ietf-websec-origin-01.xml
<?xml version="1.0"?>
<?rfc toc="yes"?>
<?xml-stylesheet type="text/xml" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-ietf-websec-origin-01" category="std">
<front>
<title abbrev="The Web Origin Concept">
The Web Origin Concept
</title>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization>
Google, Inc.
</organization>
<address>
<email>ietf@adambarth.com</email>
<uri>http://www.adambarth.com/</uri>
</address>
</author>
<date month="June" year="2011" />
<workgroup>websec</workgroup>
<abstract>
<t>This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically, user
agents isolate content retrieved from different origins to prevent
malicious web site operators from interfering with the operation of
benign web sites. In addition to outlining the principles that underly
the origin concept, this document defines how to determine the origin of
a URI, how to serialize an origin into a string, and an HTTP header,
named "Origin", that indicates which origins are associated with an HTTP
request.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some authors
might be malicious. To the extent that user agents undertake actions
based on content they process, user agent implementors might wish to
restrict the ability of malicious authors to disrupt the confidentiality
or integrity of other content or servers.</t>
<t>As an example, consider an HTTP user agent that renders HTML content
retrieved from various servers. If the user agent executes scripts
contained in those documents, the user agent implementor might wish to
prevent scripts retrieved from a malicious server from reading documents
stored on an honest server, which might, for example, be behind a
firewall.</t>
<t>Traditionally, user agents have divided content according to its
"origin". More specifically, user agents allow content retrieved from
one origin to interact freely with other content retrieved from that
origin, but user agents restrict how that content can interact with
content from another origin.</t>
<t>This document describes the principles behind the so-called
same-origin policy as well as the "nuts and bolts" of comparing and
serializing origins. This document does not describe all the facets of
the same-origin policy, the details of which are left to other
specifications, such as HTML <xref target="HTML" /> and WebSockets <xref
target="WEBSOCKETS" />, because the details are often
application-specific.</t>
</section>
<section anchor="conventions" title="Conventions">
<section anchor="conformance-criteria" title="Conformance Criteria">
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119"/>.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="syntax-notation" title="Syntax Notation">
<t>This specification uses the Augmented Backus-Naur Form (ABNF)
notation of <xref target="RFC5234"/>.</t>
<t>The following core rules are included by reference, as defined in
<xref target="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).</t>
<t>The OWS (optional whitespace) rule is used where zero or more
linear whitespace characters MAY appear:
<figure>
<artwork type="abnf">
OWS = *( [ obs-fold ] WSP )
; "optional" whitespace
obs-fold = CRLF
</artwork>
</figure>
OWS SHOULD either not be produced or be produced as a single SP
character.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification (<xref
target="RFC2616" />, Section 1.3).</t>
<t>A globally unique identifier is a value which is different from all
other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier.</t>
<t>A idna-canonicalization host name is the string generated by the
following algorithm:
<list style="numbers">
<t>Convert the host name to a sequence of NR-LDH labels (see
Section 2.3.2.2 of <xref target="RFC5890" />) and/or A-labels
according to the appropriate IDNA specification <xref
target="RFC5891" /> or <xref target="RFC3490" /> (see <xref
target="idna-migration" /> of this specification)</t>
<t>Convert the labels to lower case.</t>
<t>Concatenate the labels, separating each label from the next
with a %x2E (".") character.</t>
</list>
</t>
</section>
</section>
<section anchor="principles" title="Principles of the Same-Origin Policy">
<t>Many user agents undertake actions on behalf of remote parties. For
example, HTTP user agents follow redirects, which are instructions from
remote servers and HTML user agents expose rich DOM interfaces to
scripts retrieved from remote servers.</t>
<t>Without any security model, user agents might undertake actions
detrimental to the user or to other parties. Over time, many web-related
technologies have converged towards a common security model, known
colloquially as the "same-origin policy". Although this security model
evolved largely organically, the same-origin policy can be understood in
terms of a handful of key concepts. This section presents those concepts
and provides advice about how to use these concepts securely.</t>
<section anchor="trust" title="Trust">
<t>The same-origin policy specifies trust by URI. For example, HTML
documents designate which script to run with a URI:
<figure>
<artwork>
<![CDATA[
<script src="https://example.com/library.js"></script>
]]>
</artwork>
</figure>
</t>
<t>When a user agent process 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.</t>
<t>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:
<figure>
<artwork>
<![CDATA[
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
]]>
</artwork>
</figure>
</t>
<t>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.</t>
<section title="Pitfalls">
<t>When designing new protocols that use the same-origin policy,
make sure that important trust distinctions are visible in URIs. For
example, if both TLS and non-TLS protected resources used the "http"
URI scheme (as in <xref target="RFC2817" />), a document would be
unable to specify that it wished to retrieve a script only over TLS.
By using the "https" URI scheme, documents are able to indicate that
they wish to interact with resources that are protected from active
network attackers.</t>
</section>
</section>
<section anchor="origin" title="Origin">
<t>In principle, user agents could treat every URI as a separate
protection domain and require explicit content 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.</t>
<t>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 <xref target="origin-of-a-uri" /> for
full details.)</t>
<t>Q: Why not just use the host?</t>
<t>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 <xref
target="RFC5246" />.</t>
<t>Q: Why use the fully qualified host name instead of just the
"top-level" domain?</t>
<t>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/.</t>
<t>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.</t>
<section title="Examples">
<t>All of the following resources have the same origin:
<figure>
<artwork>
<![CDATA[
http://example.com/
http://example.com:80/
http://example.com/path/file
http://example.com/
]]>
</artwork>
</figure>
Each of the URIs has the same scheme, host, and port components.</t>
<t>Each of the following resources has a different origin from the
others.
<figure>
<artwork>
<![CDATA[
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
]]>
</artwork>
</figure>
In each case, at least one of the scheme, host, and port component
will differ from the others in the list.</t>
</section>
</section>
<section anchor="authority" title="Authority">
<t>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 RFC 3986 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.</t>
<t>User agent 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.</t>
<t>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.</t>
<section title="Pitfalls">
<t>When designing new pieces of the web platform, be careful not to
grant authority to resources irrespective of media type. Many web
applications serve untrusted content with restricted media types. A
new web platform feature that grants authority to these pieces of
content risks introducing vulnerabilities into existing
applications. Instead, prefer to grant authority to media types that
already possess the origin’s full authority or to new media types
designed specifically to carry the new authority.</t>
<t>In order to remain compatible with servers that supply incorrect
media types, some user agents employ "content sniffing" and treat
content as if had a different media type than the media type
supplied by the server. If not done carefully, content sniffing can
lead to security vulnerabilities because user agents might grant
low-authority media types, such as images, the privileges of
high-authority media types, such as HTML documents <xref
target="SNIFF" />.</t>
</section>
</section>
<section anchor="policy" title="Policy">
<t>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.</t>
<section title="Object Access">
<t>Most objects (also known as application programming interfaces or
APIs) exposed by the user agent are available only to the same
origin. Specifically, content retrieve from one URI can access
objects associated with content retrieved from another URI if, and
only if, the two URIs belong to the same origin, e.g., have same
scheme, host, and port.</t>
<t>There are some exceptions to this general rule. For example,
some parts of HTML’s Location interface are available across origins
(e.g., to allow for navigating other browsing contexts). As another
sample, HTML’s postMessage interface is visible across origins
explicitly to facilitate cross-origin communication. Exposing
objects to foreign origins is dangerous and should be done only with
great care because doing so exposes these objects to potential
attackers.</t>
</section>
<section title="Network Access">
<t>Access to network resources varies depending on whether the
resources are in the same origin as the content attempting to access
them.</t>
<t>Generally, reading information from another origin is forbidden.
However, an origin is permitted use some kinds of resources
retrieved from other origins. For example, an origin is permitted
to execute script, render images, and apply style sheets from any
origin. Likewise, an origin can display content from
another origin, such as an HTML document in an HTML frame. Network
resources can also opt into letting other origins read their
information, for example using Cross-Origin Resource Sharing <xref
target="CORS" />. In these cases, access is typically granted on a
per-origin basis.</t>
<t>Sending information to another origin is permitted. However,
sending information over the network in arbitrary formats is
dangerous. For this reason, user agents restrict documents to
sending information using particular protocols, such as in an HTTP
request without custom headers. Expanding the set of allowed
protocols, for example by adding support for WebSockets, must be
done carefully to avoid introducing vulnerabilities <xref
target="WEBSOCKETS" />.</t>
</section>
<section title="Pitfalls">
<t>Whenever user agents allow one origin to interact
with resources from another origin, they invite security issues. For
example, the ability to display images from another origin leaks
their height and width. Similarly, the ability to send network
requests to another origin gives rise to cross-site request forgery
vulnerabilities <xref target="CSRF" />. However, user agent
implementors often balance these risks against the benefits of
allowing the cross-origin interaction. For example, an HTML user
agent that blocked cross-origin network requests would prevent its
users from following hyperlinks, a core feature of the web.</t>
<t>When adding new functionality to the web platform, it can be
tempting to grant a privilege to one resource but to withhold that
privilege from another resource in the same origin. However,
withholding privileges in this way is ineffective because the
resource without the privilege can usually obtain the privilege
anyway because user agents do not isolate resources within an
origin. Instead, privileges should be granted or withheld from
origins as a whole (rather than discriminating between individual
resources within an origin) <xref target="BOFGO" />.</t>
</section>
</section>
<section anchor="conclusion" title="Conclusion">
<t>The same-origin policy uses URIs to designates 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.</t>
</section>
</section>
<section anchor="origin-of-a-uri" title="Origin of a URI">
<t>The origin of a URI is the value computed by the following algorithm:
<list style="numbers">
<t>If the URI does not use a server-based naming authority, or if the
URI is not an absolute URI, then return a globally unique
identifier.</t>
<t>Let uri-scheme be the scheme component of the URI, converted to
lowercase.</t>
<t>If the implementation doesn't support the protocol given by
uri-scheme, then return a globally unique identifier.</t>
<t>If uri-scheme is "file", the implementation MAY return an
implementation-defined value.
<list>
<t>NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege. However, granting all
local files such wide privileges can lead to privilege escalation
attacks. Some user agents have had success granting local files
directory-based privileges, but this approach has not been widely
adopted. Other user agent use a globally unique identifier each file
URI, which is the most secure option.</t>
</list>
</t>
<t>Let uri-host be the idna-canonicalization of the host component of
the URI.</t>
<t>If there is no port component of the URI:
<list>
<t>Let uri-port be the default port for the protocol given by
uri-scheme.</t>
</list>
Otherwise:
<list>
<t>Let uri-port be the port component of the URI.</t>
</list>
</t>
<t>Return the triple (uri-scheme, uri-host, uri-port).</t>
</list>
</t>
<t>Implementations MAY define other types of origins in addition to the
scheme/host/port triple type defined above. For example, an
implementation might define an origin based on a public key or an
implementation might append addition "sandbox" bits to a
scheme/host/port triple.</t>
</section>
<section anchor="same-origin" title="Comparing Origins">
<t>To origins are "the same" if, and only if, they are identical. In
particular:
<list style="symbols">
<t>If the two origins are scheme/host/port triple, the two origins are
the same if, and only if, they have identical schemes, hosts, and
ports.</t>
<t>An origin that is globally unique identifier cannot be the same as
an origin that is a scheme/host/port triple.</t>
<t>Two origins that are globally unique identifiers cannot be the same
if they were created at different times, even if they were created for
the same URI.</t>
</list>
</t>
<t>Two URIs are the same-origin if their origins are the same.
<list>
<t>NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI is not same-origin with itself because data URIs
do not use a server-based naming authority and therefore have globally
unique identifiers as origins.</t>
</list>
</t>
</section>
<section anchor="serialization" title="Serializing Origins">
<t>This section defines how to serialize an origin to a unicode string
and to an ASCII string.</t>
<section anchor="unicode-serialization"
title="Unicode Serialization of an Origin">
<t>The unicode-serialization of an origin is the value returned by the
following algorithm:
<list style="numbers">
<t>If the origin is not a scheme/host/port triple, then return the
string
<list style="empty">
<t>null</t>
</list>
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and
abort these steps.</t>
<t>Otherwise, let result be the scheme part of the origin
triple.</t>
<t>Append the string "://" to result.</t>
<t>Append the IDNA ToUnicode algorithm <xref target="RFC5891" /> to
each component of the host part of the origin triple, and append the
results of each component, in the same order, separated by U+002E
FULL STOP code points (".") to result.</t>
<t>If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the origin
triple:
<list>
<t>Append a U+003A COLON code point (":") and the given port, in
base ten, to result.</t>
</list>
</t>
<t>Return result.</t>
</list>
</t>
</section>
<section anchor="ascii-serialization"
title="ASCII Serialization of an Origin">
<t>The ascii-serialization of an origin is the value returned by the
following algorithm:
<list style="numbers">
<t>If the origin is not a scheme/host/port triple, then return the
string
<list style="empty">
<t>null</t>
</list>
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and
abort these steps.</t>
<t>Otherwise, let result be the scheme part of the origin
triple.</t>
<t>Append the string "://" to result.</t>
<t>Append the host part of the origin triple to result.</t>
<t>If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the origin
triple:
<list>
<t>Append a U+003A COLON code points (":") and the given port, in
base ten, to result.</t>
</list>
</t>
<t>Return result.</t>
</list>
</t>
</section>
</section>
<section anchor="origin-header" title="The HTTP Origin header">
<t>This section defines the HTTP Origin header.</t>
<section anchor="origin-header-syntax" title="Syntax">
<t>The Origin header has the following syntax:
<figure>
<artwork type="abnf">
<![CDATA[
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = "null" / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> productions from RFC3986
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="origin-header-semantics" title="Semantics">
<t>When included in an HTTP request, the Origin header 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.</t>
<t>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 might wish to use the Origin header to
inform the server that the request was issued by the script.</t>
<t>In some cases, a number of origins contribute to causing the user
agents to issue an HTTP request. In those cases, the user agent can
list all the origins in the Origin header. For example, if the HTTP
request was initially issued by one origin but then later redirected
by another origin, the user agent might wish to inform the server that
two origins were involved in causing the user agent to issue the
request.</t>
</section>
<section anchor="origin-header-ua-requirements"
title="User Agent Requirements">
<t>The user agent MAY include an Origin header in any HTTP
request.</t>
<t>The user agent MUST NOT include more than one Origin header field
in any HTTP request.</t>
<t>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.
<list>
<t>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 headers.</t>
</list>
</t>
<t>When generating an Origin header, the user agent MUST meet the
following requirements:
<list style="symbols">
<t>Each of the serialized-origin productions in the grammar MUST be
the ascii-serialization of an origin.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section anchor="privacy" title="Privacy Considerations">
<t>[TODO: Privacy considerations.]</t>
</section>
<section anchor="security" title="Security Considerations">
<t>[TODO: Security considerations.]</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>[TODO: Register the Origin header.]</t>
</section>
<section anchor="implementation-considerations"
title="Implementation Considerations">
<section anchor="idna-migration" title="IDNA dependency and migration">
<t>IDNA2008 <xref target="RFC5890" /> supersedes IDNA2003 <xref
target="RFC3490" /> but is not backwards-compatible. For this reason,
there will be a transition period (possibly of a number of years).
User agents SHOULD implement IDNA2008 <xref target="RFC5890" /> and
MAY implement [Unicode Technical Standard #46
<http://unicode.org/reports/tr46/>] in order to facilitate a
smoother IDNA transition. If a user agent does not implement IDNA2008,
the user agent MUST implement IDNA2003 <xref target="RFC3490" />.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<!-- http://xml.resource.org/public/rfc/bibxml/reference.RFC.XXXX.xml -->
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document:
<list>
<t>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 RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723"
target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization>University of California, Irvine</organization>
<address><email>fielding@ics.uci.edu</email></address>
</author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization>W3C</organization>
<address><email>jg@w3.org</email></address>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization>Compaq Computer Corporation</organization>
<address><email>mogul@wrl.dec.com</email></address>
</author>
<author initials="H." surname="Frystyk" fullname="H. Frystyk">
<organization>MIT Laboratory for Computer Science</organization>
<address><email>frystyk@w3.org</email></address>
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization>Xerox Corporation</organization>
<address><email>masinter@parc.xerox.com</email></address>
</author>
<author initials="P." surname="Leach" fullname="P. Leach">
<organization>Microsoft Corporation</organization>
<address><email>paulle@microsoft.com</email></address>
</author>
<author initials="T." surname="Berners-Lee"
fullname="T. Berners-Lee">
<organization>W3C</organization>
<address><email>timbl@w3.org</email></address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor="RFC3490">
<front>
<title>Internationalizing Domain Names in Applications (IDNA)</title>
<author initials="P." surname="Faltstrom" fullname="P. Faltstrom">
<organization />
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization />
</author>
<author initials="A." surname="Costello" fullname="A. Costello">
<organization />
</author>
<date year="2003" month="March" />
<abstract>
<t>Until now, there has been no standard method for domain names
to use characters outside the ASCII repertoire. This document
defines internationalized domain names (IDNs) and a mechanism
called Internationalizing Domain Names in Applications (IDNA) for
handling them in a standard fashion. IDNs use characters drawn
from a large repertoire (Unicode), but IDNA allows the non-ASCII
characters to be represented using only the ASCII characters
already allowed in so-called host names today. This
backward-compatible representation is required in existing
protocols like DNS, so that IDNs can be introduced with no
changes to the existing infrastructure. IDNA is only meant for
processing domain names, not free text. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3490" />
<format type="TXT" octets="51943" target="http://www.rfc-editor.org/rfc/rfc3490.txt" />
<annotation>
See <xref target="idna-migration" /> for an explanation why the
normative reference to an obsoleted specification is needed.
</annotation>
</reference>
<reference anchor="RFC5234">
<front>
<title abbrev="ABNF for Syntax Specifications">
Augmented BNF for Syntax Specifications: ABNF
</title>
<author initials="D." surname="Crocker"
fullname="Dave Crocker" role="editor">
<organization>Brandenburg InternetWorking</organization>
<address>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author initials="P." surname="Overell" fullname="Paul Overell">
<organization>THUS plc.</organization>
<address>
<email>paul.overell@thus.net</email>
</address>
</author>
<date month="January" year="2008"/>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization />
</author>
<date year="2010" month="August" />
<abstract>
<t>This document is one of a collection that, together, describe
the protocol and usage context for a revision of Internationalized
Domain Names for Applications (IDNA), superseding the earlier
version. It describes the document collection and provides
definitions and other material that are common to the set.
[STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890" />
<format type="TXT" octets="54245" target="http://www.rfc-editor.org/rfc/rfc5890.txt" />
</reference>
<reference anchor="RFC5891">
<front>
<title>Internationalized Domain Names in Applications (IDNA):
Protocol</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization />
</author>
<date year="2010" month="August" />
<abstract>
<t>This document is the revised protocol definition for
Internationalized Domain Names (IDNs). The rationale for changes,
the relationship to the older specification, and important
terminology are provided in other documents. This document
specifies the protocol mechanism, called Internationalized Domain
Names in Applications (IDNA), for registering and looking up IDNs
in a way that does not require changes to the DNS itself. IDNA is
only meant for processing domain names, not free text. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5891" />
<format type="TXT" octets="38105" target="http://www.rfc-editor.org/rfc/rfc5891.txt" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC5246">
<front>
<title>
The Transport Layer Security (TLS) Protocol Version 1.2
</title>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization />
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization />
</author>
<date year="2008" month="August" />
</front>
<seriesInfo name="RFC" value="5246" />
</reference>
<reference anchor="RFC2817">
<front>
<title>
FIXME: RFC2817
</title>
</front>
</reference>
<reference anchor="SNIFF">
<front>
<title>
FIXME: Media Type Sniffing
</title>
</front>
</reference>
<reference anchor="HTML">
<front>
<title>
FIXME: HTML5
</title>
</front>
</reference>
<reference anchor="WEBSOCKETS">
<front>
<title>
FIXME: WebSockets
</title>
</front>
</reference>
<reference anchor="CORS">
<front>
<title>
FIXME: Cross-Origin Resource Sharing
</title>
</front>
</reference>
<reference anchor="CSRF">
<front>
<title>
FIXME: Robust Defenses to Cross-Site Request Forgery
</title>
</front>
</reference>
<reference anchor="BOFGO">
<front>
<title>
FIXME: Beware of Finer-Grained Origins
</title>
</front>
</reference>
</references>
<section title="Acknowledgements">
We would like to thank Lucas Adamski, Ian Hickson, Anne van Kesteren,
Collin Jackson, Larry Masinter, Mark Nottingham, Julian Reschke, Jonas
Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for their valuable
feedback on this document.
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:17:48 |