draft-ietf-websec-origin-00.txt   draft-ietf-websec-origin-01.txt 
websec A. Barth websec A. Barth
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track December 29, 2010 Intended status: Standards Track June 21, 2011
Expires: July 2, 2011 Expires: December 23, 2011
The Web Origin Concept The Web Origin Concept
draft-ietf-websec-origin-00 draft-ietf-websec-origin-01
Abstract Abstract
This document defines the concept of an "origin", which represents a This document defines the concept of an "origin", which is often used
web principal. Typically, user agents isolate content retrieved from as the scope of authority or privilege by user agents. Typically,
different origins to prevent a malicious web site operator from user agents isolate content retrieved from different origins to
interfering with the operation of benign web sites. In particular, prevent malicious web site operators from interfering with the
this document defines how to compute an origin from a URI, how to operation of benign web sites. In addition to outlining the
serialize an origin to a string, and an HTTP header, named "Origin", principles that underly the origin concept, this document defines how
for indicating which origin caused the user agent to issue a to determine the origin of a URI, how to serialize an origin into a
particular HTTP request. string, and an HTTP header, named "Origin", that indicates which
origins are associated with an HTTP request.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2011. This Internet-Draft will expire on December 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 7
4. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Unicode Serialization of an Origin . . . . . . . . . . . . 9 3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 9 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 9
6. The HTTP Origin header . . . . . . . . . . . . . . . . . . . . 11 3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. User Agent Requirements . . . . . . . . . . . . . . . . . 11 3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 10
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Implementation Considerations . . . . . . . . . . . . . . . . 16 4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. IDNA dependency and migration . . . . . . . . . . . . . . 16 5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . . 17 6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15
7. The HTTP Origin header . . . . . . . . . . . . . . . . . . . . 17
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Implementation Considerations . . . . . . . . . . . . . . . . 22
11.1. IDNA dependency and migration . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
User agents interact with content created by a large number of User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some authors. Although many of those authors are well-meaning, some
authors might be malicious. To the extent that user agents undertake authors might be malicious. To the extent that user agents undertake
actions based on content they process, user agent implementors might actions based on content they process, user agent implementors might
wish to restrict the ability of malicious authors to disrupt the wish to restrict the ability of malicious authors to disrupt the
confidentiality or integrity of other content or servers. confidentiality or integrity of other content or servers.
skipping to change at page 3, line 27 skipping to change at page 4, line 27
to prevent scripts retrieved from a malicious server from reading to prevent scripts retrieved from a malicious server from reading
documents stored on an honest server, which might, for example, be documents stored on an honest server, which might, for example, be
behind a firewall. behind a firewall.
Traditionally, user agents have divided content according to its Traditionally, user agents have divided content according to its
"origin". More specifically, user agents allow content retrieved "origin". More specifically, user agents allow content retrieved
from one origin to interact freely with other content retrieved from from one origin to interact freely with other content retrieved from
that origin, but user agents restrict how that content can interact that origin, but user agents restrict how that content can interact
with content from another origin. with content from another origin.
This document does not describe the restrictions user agents ought to This document describes the principles behind the so-called same-
impose on cross-origin interaction. Instead, this document defines origin policy as well as the "nuts and bolts" of comparing and
the origin concept itself in such a way that other specifications, serializing origins. This document does not describe all the facets
such for HTTP [cite] or for HTML [cite], can refer to this document of the same-origin policy, the details of which are left to other
for a precise, common definition of the web origin concept. specifications, such as HTML [HTML] and WebSockets [WEBSOCKETS],
because the details are often application-specific.
Specifically, a user agent can compute the origin of a piece of
content based on the URI from which the user agent retrieved the
content. Given two origins computed in this way, the user agent can
compare the origins to determine if they are "the same", which is
useful for performing some security checks. Finally, given an
origin, the user agent can serialize that origin into either an ASCII
or a Unicode representation.
This document also defines one use of the ASCII serialization: the
HTTP Origin header. An Origin header attached to an HTTP request
contains the ASCII serializations of the origins that caused the user
agent to issue the HTTP request. The Origin header has a number of
uses, including for cross-origin resource sharing [cite].
2. Conventions 2. Conventions
2.1. Conformance Criteria 2.1. Conformance Criteria
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
skipping to change at page 5, line 15 skipping to change at page 6, line 15
A globally unique identifier is a value which is different from all A globally unique identifier is a value which is different from all
other previously existing values. For example, a sufficiently long other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier. random string is likely to be a globally unique identifier.
A idna-canonicalization host name is the string generated by the A idna-canonicalization host name is the string generated by the
following algorithm: following algorithm:
1. Convert the host name to a sequence of NR-LDH labels (see Section 1. Convert the host name to a sequence of NR-LDH labels (see Section
2.3.2.2 of [RFC5890]) and/or A-labels according to the 2.3.2.2 of [RFC5890]) and/or A-labels according to the
appropriate IDNA specification [RFC5891] or [RFC3490] (see appropriate IDNA specification [RFC5891] or [RFC3490] (see
Section 10.1 of this specification) Section 11.1 of this specification)
2. Convert the labels to lower case. 2. Convert the labels to lower case.
3. Concatenate the labels, separating each label from the next with 3. Concatenate the labels, separating each label from the next with
a %x2E (".") character. a %x2E (".") character.
3. Origin 3. Principles of the Same-Origin Policy
An origin represents a web principal. Typically, user agents Many user agents undertake actions on behalf of remote parties. For
determine the origin of a piece of content from the URI from which example, HTTP user agents follow redirects, which are instructions
they retrieved the content. In this section, we define how to from remote servers and HTML user agents expose rich DOM interfaces
compute an origin from a URI. to scripts retrieved from remote servers.
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.
3.1. Trust
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>
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.
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>
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.1.1. Pitfalls
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 [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.
3.2. Origin
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.
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: Why not just use the host?
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: Why use the fully qualified host name instead of just the "top-
level" domain?
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/.
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.
3.2.1. Examples
All of the following resources have the same origin:
http://example.com/
http://example.com:80/
http://example.com/path/file
http://example.com/
Each of the URIs has the same scheme, host, and port components.
Each of the following resources has a different origin from the
others.
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
In each case, at least one of the scheme, host, and port component
will differ from the others in the list.
3.3. Authority
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.
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.
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.3.1. Pitfalls
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.
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 [SNIFF].
3.4. Policy
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.4.1. Object Access
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.
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.
3.4.2. Network Access
Access to network resources varies depending on whether the resources
are in the same origin as the content attempting to access them.
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 [CORS]. In these cases, access is
typically granted on a per-origin basis.
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 [WEBSOCKETS].
3.4.3. Pitfalls
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
[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.
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) [BOFGO].
3.5. Conclusion
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.
4. Origin of a URI
The origin of a URI is the value computed by the following algorithm: The origin of a URI is the value computed by the following algorithm:
1. If the URI does not use a server-based naming authority, or if 1. 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 the URI is not an absolute URI, then return a globally unique
identifier. identifier.
2. Let uri-scheme be the scheme component of the URI, converted to 2. Let uri-scheme be the scheme component of the URI, converted to
lowercase. lowercase.
3. If the implementation doesn't support the protocol given by uri- 3. If the implementation doesn't support the protocol given by uri-
scheme, then return a globally unique identifier. scheme, then return a globally unique identifier.
4. If uri-scheme is "file", the implementation MAY return an 4. If uri-scheme is "file", the implementation MAY return an
implementation-defined value. implementation-defined value.
1. NOTE: Historically, user agents have granted content from the 1. NOTE: Historically, user agents have granted content from the
file scheme a tremendous number of privileges. However, file scheme a tremendous amount of privilege. However,
granting all local files such wide privileges can lead to granting all local files such wide privileges can lead to
privilege escalation attacks. Some user agents have had privilege escalation attacks. Some user agents have had
success granting local files directory-based privileges, but success granting local files directory-based privileges, but
this approach has not been widely adopted. Other user agent this approach has not been widely adopted. Other user agent
use a globally unique identifier each file URI, which is the use a globally unique identifier each file URI, which is the
most secure option. most secure option.
5. Let uri-host be the idna-canonicalization of the host component 5. Let uri-host be the idna-canonicalization of the host component
of the URI. of the URI.
skipping to change at page 8, line 5 skipping to change at page 14, line 5
2. Let uri-port be the port component of the URI. 2. Let uri-port be the port component of the URI.
7. Return the triple (uri-scheme, uri-host, uri-port). 7. Return the triple (uri-scheme, uri-host, uri-port).
Implementations MAY define other types of origins in addition to the Implementations MAY define other types of origins in addition to the
scheme/host/port triple type defined above. For example, an scheme/host/port triple type defined above. For example, an
implementation might define an origin based on a public key or an implementation might define an origin based on a public key or an
implementation might append addition "sandbox" bits to a scheme/host/ implementation might append addition "sandbox" bits to a scheme/host/
port triple. port triple.
4. Comparing Origins 5. Comparing Origins
To origins are "the same" if, and only if, they are identical. In To origins are "the same" if, and only if, they are identical. In
particular: particular:
o If the two origins are scheme/host/port triple, the two origins o If the two origins are scheme/host/port triple, the two origins
are the same if, and only if, they have identical schemes, hosts, are the same if, and only if, they have identical schemes, hosts,
and ports. and ports.
o An origin that is globally unique identifier cannot be the same as o An origin that is globally unique identifier cannot be the same as
an origin that is a scheme/host/port triple. an origin that is a scheme/host/port triple.
skipping to change at page 9, line 5 skipping to change at page 15, line 5
same if they were created at different times, even if they were same if they were created at different times, even if they were
created for the same URI. created for the same URI.
Two URIs are the same-origin if their origins are the same. Two URIs are the same-origin if their origins are the same.
NOTE: A URI is not necessarily same-origin with itself. For NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI is not same-origin with itself because data example, a data URI is not same-origin with itself because data
URIs do not use a server-based naming authority and therefore have URIs do not use a server-based naming authority and therefore have
globally unique identifiers as origins. globally unique identifiers as origins.
5. Serializing Origins 6. Serializing Origins
This section defines how to serialize an origin to a unicode string This section defines how to serialize an origin to a unicode string
and to an ASCII string. and to an ASCII string.
5.1. Unicode Serialization of an Origin 6.1. Unicode Serialization of an Origin
The unicode-serialization of an origin is the value returned by the The unicode-serialization of an origin is the value returned by the
following algorithm: following algorithm:
1. If the origin is not a scheme/host/port triple, then return the 1. If the origin is not a scheme/host/port triple, then return the
string string
null null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Append the [TODO: IDNA ToUnicode] algorithm to each component of 4. Append the IDNA ToUnicode algorithm [RFC5891] to each component
the host part of the origin triple, and append the results of 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 each component, in the same order, separated by U+002E FULL STOP
code points (".") to result. code points (".") to result.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code point (":") and the given port, in 1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result. base ten, to result.
6. Return result. 6. Return result.
[TODO: Check that we handle IPv6 literals correctly.] 6.2. ASCII Serialization of an Origin
5.2. ASCII Serialization of an Origin
The ascii-serialization of an origin is the value returned by the The ascii-serialization of an origin is the value returned by the
following algorithm: following algorithm:
1. If the origin is not a scheme/host/port triple, then return the 1. If the origin is not a scheme/host/port triple, then return the
string string
null null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Append the host port of the origin triple to result. 4. Append the host part of the origin triple to result.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code points (":") and the given port, 1. Append a U+003A COLON code points (":") and the given port,
in base ten, to result. in base ten, to result.
6. Return result. 6. Return result.
6. The HTTP Origin header 7. The HTTP Origin header
This section defines the HTTP Origin header. This section defines the HTTP Origin header.
6.1. Syntax 7.1. Syntax
The Origin header has the following syntax: The Origin header has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = "null" / origin-list origin-list-or-null = "null" / origin-list
origin-list = serialized-origin *( SP serialized-origin ) origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ] serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> productions from RFC3986 ; <scheme>, <host>, <port> productions from RFC3986
6.2. Semantics 7.2. Semantics
When included in an HTTP request, the Origin header indicates the When included in an HTTP request, the Origin header indicates the
origin(s) that caused the user agent to issue the request. 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.
For example, consider a user agent that executes scripts on behalf of 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 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 HTTP request, the user agent might wish to use the Origin header to
inform the server that the request was issued by the script. inform the server that the request was issued by the script.
In some cases, a number of origins contribute to causing the user 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 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 list all the origins in the Origin header. For example, if the HTTP
request was initially issued by one origin but then later redirected request was initially issued by one origin but then later redirected
by another origin, the user agent might wish to inform the server 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 that two origins were involved in causing the user agent to issue the
request. request.
6.3. User Agent Requirements 7.3. User Agent Requirements
The user agent MAY include an Origin header in any HTTP request. The user agent MAY include an Origin header in any HTTP request.
The user agent MUST NOT include more than one Origin header field in The user agent MUST NOT include more than one Origin header field in
any HTTP request. any HTTP request.
Whenever a user agent issues an HTTP request from a "privacy- Whenever a user agent issues an HTTP request from a "privacy-
sensitive" context, the user agent MUST send the value "null" in the sensitive" context, the user agent MUST send the value "null" in the
Origin header. Origin header.
skipping to change at page 12, line 17 skipping to change at page 19, line 5
following requirements: following requirements:
o Each of the serialized-origin productions in the grammar MUST be o Each of the serialized-origin productions in the grammar MUST be
the ascii-serialization of an origin. the ascii-serialization of an origin.
o No two consecutive serialized-origin productions in the grammar o No two consecutive serialized-origin productions in the grammar
can be identical. In particular, if the user agent would generate can be identical. In particular, if the user agent would generate
two consecutive serialized-origins, the user agent MUST NOT two consecutive serialized-origins, the user agent MUST NOT
generate the second one. generate the second one.
If the user agent issued an HTTP request current-request because the 8. Privacy Considerations
user agent received 3xx Status Code response to another HTTP request
previous-request for URI previous-uri:
o The HTTP request current-request MUST include an Origin header.
o The value of the Origin header MUST be either:
* The string "null" (i.e., the byte sequence %x6E, %x75, %x6C,
%x6C).
* The value of the Origin header in the previous-request. The
user agent MUST NOT choose this option if the ascii-
serialization of previous-uri is not identical to the last
serialized-origin in the Origin header of the previous request.
* The value of the Origin header in previous header extended with
a space and the ascii-serialization of the origin of previous-
uri. The user agent MUST NOT choose this option if the ascii-
serialization of the origin of previous-uri is "null".
The user agent SHOULD include the Origin header in an HTTP request if
the user agent issues the HTTP request on behalf of an origin (e.g.,
not by the user operating a trusted user interface surface). In this
case, the user agent SHOULD set the value of the Origin header to the
ascii-serialization of that origin.
NOTE: This behavior differs from the usual user agent behavior for
the HTTP Referer header, which user agents often suppress when an
origin with an "https" scheme issues a request for a URI with an
"http" scheme.
7. Privacy Considerations
[TODO: Privacy considerations.] [TODO: Privacy considerations.]
8. Security Considerations 9. Security Considerations
[TODO: Security considerations.] [TODO: Security considerations.]
9. IANA Considerations 10. IANA Considerations
[TODO: Register the Origin header.] [TODO: Register the Origin header.]
10. Implementation Considerations 11. Implementation Considerations
10.1. IDNA dependency and migration 11.1. IDNA dependency and migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not
backwards-compatible. For this reason, there will be a transition backwards-compatible. For this reason, there will be a transition
period (possibly of a number of years). User agents SHOULD implement period (possibly of a number of years). User agents SHOULD implement
IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46 IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46
<http://unicode.org/reports/tr46/>] in order to facilitate a smoother <http://unicode.org/reports/tr46/>] in order to facilitate a smoother
IDNA transition. If a user agent does not implement IDNA2008, the IDNA transition. If a user agent does not implement IDNA2008, the
user agent MUST implement IDNA2003 [RFC3490]. user agent MUST implement IDNA2003 [RFC3490].
11. Normative References 12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
See Section 10.1 for an explanation why the normative See Section 11.1 for an explanation why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
12.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2817] "FIXME: RFC2817".
[SNIFF] "FIXME: Media Type Sniffing".
[HTML] "FIXME: HTML5".
[WEBSOCKETS]
"FIXME: WebSockets".
[CORS] "FIXME: Cross-Origin Resource Sharing".
[CSRF] "FIXME: Robust Defenses to Cross-Site Request Forgery".
[BOFGO] "FIXME: Beware of Finer-Grained Origins".
Appendix A. Acknowledgements Appendix A. Acknowledgements
Author's Address Author's Address
Adam Barth Adam Barth
Google, Inc. Google, Inc.
Email: ietf@adambarth.com Email: ietf@adambarth.com
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 31 change blocks. 
117 lines changed or deleted 352 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/