This document defines the concept of an "origin", which represents a web pincipal. Typically, user agents isolate content retrieved from different origins to prevent a malicious web site operator for interfering with the operation of benign web sites. In particular, this document defines how to compute an origin from a URI, how to serialize an origin to a string, and an HTTP header, named "Origin", for indicating which origin caused the user agent to issue a particular request.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on April 11, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
2.1. Conformance Criteria
2.2. Syntax Notation
4. Comparing Origins
5. Serializing Origins
5.1. Unicode Serialization of an Origin
5.2. ASCII Serialization of an Origin
6. The HTTP Origin header
6.3. User Agent Requirements
7. Privacy Considerations
8. Security Considerations
9. IANA Considerations
10. Implementation Considerations
10.1. IDNA dependency and migration
11. Normative References
Appendix A. Acknowledgements
§ Author's Address
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
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.
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.).
The following core rules are included by reference, as defined in [RFC5234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.), 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).
The OWS (optional whitespace) rule is used where zero or more linear whitespace characters MAY appear:
OWS = *( [ obs-fold ] WSP ) ; "optional" whitespace obs-fold = CRLF
OWS SHOULD either not be produced or be produced as a single SP character.
The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.1 specification ([RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), Section 1.3).
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 indentifier.
A idna-canonicalization host name is the string generated by the following algorithm:
An origin represents a web principal. Typically, user agents determine the origin of a piece of content from the URI from which they retrieved the URI. In this section, we define how to compute an origin from a URI.
The origin of a URI is the value computed by the following algorithm:
Implementations MAY define other types of origins in addition to the scheme/host/port tuple 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 tuple.
To origins are "the same" if, and only if, they are identicial. In particular:
Two URIs are the same-origin if their origins are the same.
NOTE: It is possible for a URIs to not be same-origin with itself. For example, a data URIs is not same-origin with itself because data URIs do not use a server-based naming authority and hence have globally unique identifiers as origins.
This section defines how to serialize an origin to a unicode string and to an ASCII string.
The unicode-serialization of an origin is the value returned by the following algorithm:
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
[TODO: Check that we handle IPv6 literals correctly.]
The ascii-serialization of an origin is the value returned by the following algorithm:
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
This section defines the HTTP Origin header.
The Origin header has the following syntax:
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
When included in an HTTP request, the Origin header indicates the origin(s) that caused the user agent to generate the request.
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 inform the server that the request was issued by the script using the Origin header.
In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, user agent can list all the origins in the Origin header. For example, if the HTTP request was initially generated by one origin, but then later redirected by another origin, the user agent might wish to inform the server that two origins were invovled in causing the user agent to generate the 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 any HTTP request.
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.
NOTE: This document does not define the notion of a privacy-sensitive context. Applications that generate HTTP requests can define contexts as privacy-sensitive to impose restrictions on how user agents generate Origin headers.
When generating an Origin header, the user agent MUST meet the following requirements:
If the user agent generated an HTTP request current-request because the user agent received 3xx Status Code response to another HTTP request previous-request for URI previous-uri:
The user agent SHOULD include the Origin header in an HTTP request if the user agent issues the HTTP request on behalf of a remote origin (e.g., and 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.
[TODO: Privacy considerations.]
[TODO: Security considerations.]
[TODO: Register the Origin header.]
IDNA2008 [RFC5890] (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework,” August 2010.) supersedes IDNA2003 [RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) 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 [RFC5890] (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework,” August 2010.) 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 [RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.).
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[RFC2616]||Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999.|
|[RFC3490]||Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003 (TXT).|
See Section 10.1 (IDNA dependency and migration) for an explanation why the normative reference to an obsoleted specification is needed.
|[RFC5234]||Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax 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 Applications (IDNA): Definitions and Document Framework,” RFC 5890, August 2010 (TXT).|
|[RFC5891]||Klensin, J., “Internationalized Domain Names in Applications (IDNA): Protocol,” RFC 5891, August 2010 (TXT).|