One document matched: draft-farrell-decade-ni-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3642 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3642.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY RFC5395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5395.xml">
<!ENTITY RFC5050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!-- Defines the URI Syntax -->
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!-- Design guide -->
<!ENTITY RFC4395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
<!-- Defines the well known services URL positions -->
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!-- Defines the URI safe BASE64 encoding mechanism -->
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!-- Defines the Cryptographic Algorithm registry-->
<!ENTITY RFC5698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5698.xml">
<!-- Defines sha-256 identifier -->
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!--MIME Media Type Registry -->
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY RFC4843 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4843.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" submissionType="independent" docName="draft-farrell-decade-ni-01">
<front>
<title abbrev="hash names">Naming things with hashes</title>
<author fullname="Stephen Farrell" initials="S."
surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dirk Kutscher" initials="D."
surname="Kutscher">
<organization>NEC</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<!-- Reorder these if your country does things differently -->
<city>Heidelberg</city>
<region></region>
<code></code>
<country>Germany</country>
</postal>
<phone></phone>
<email>kutscher@neclab.eu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Christian Dannewitz" initials="C" surname="Dannewitz">
<organization>University of Paderborn</organization>
<address>
<postal>
<street></street>
<city>Paderborn</city>
<!--code> 12345</code-->
<country>Germany</country>
</postal>
<email>cdannewitz@upb.de</email>
</address>
</author>
<author fullname="Borje Ohlman" initials="B" surname="Ohlman">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<code> S-16480</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>Borje.Ohlman@ericsson.com</email>
</address>
</author>
<author initials="A." surname="Keranen" fullname="Ari Keranen">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<date month="March" year="2012" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Cryptography</keyword>
<keyword>URI</keyword>
<keyword>Information Centric Networking</keyword>
<abstract>
<t>
This document defines a set of ways to identify a
thing using the output from a hash function, specifying
URI, URL and binary
formats for these names.
The various formats
are designed to support, but not require, a strong link to the referenced object
such that the referenced object may be authenticated to the
same degree as the reference to it.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
URIs <xref target="RFC3986"/> are used in various protocols
for identifying resources. In many deployments those URIs
contain strings that are hash function outputs in order to
ensure uniqueness in terms of mapping the URI to a specific
resource, or to make URIs hard to guess for security
reasons. However, there is no standard way to interpret
those strings, and so today in general only the creator of
the URI knows how to use the hash function output.
</t>
<t>
For example, protocols for accessing in-network storage
servers (as defined in the IETF DECADE WG) need a way to
identify the stored resources uniquely and in a
location-independent way so that replicas on different servers
can be accessed by the same name. Also, such applications may
require verifying that a resource that has been obtained
actually corresponds to the name that was used to request the
resource, i.e., verifying the name-content binding.
</t>
<t>
Similarly, in the context of information-centric networking
<xref target="ref.netinf-design"/> <xref target="ref.ccn"/>
and elsewhere there is value in being able to compare a
presented resource against the URI that was de-referenced in
order to access that resource. If a cryptographically-strong
comparison function can be used then this allows for many
forms of in-network storage, without requiring as much trust
in the infrastructure used to present the resource. The
outputs of hash functions can be used in this manner, if
presented in a standard way.
</t>
<t>
Additional applications might include creating references from
web pages delivered over HTTP/TLS; DNS resource records
signed using DNSSEC or Data values embedded in certificates,
CRLs, OCSP tokens and other signed data objects.
</t>
<t>
Accordingly, the "ni" URI scheme allows for checking of the
integrity of the URI/resource mapping, but it is OPTIONAL for
implementations to do so when sending, receiving or processing
"ni" URIs.
</t>
<t>
The URI scheme defined here allows for the use of a
query-string, similar to how query-strings are used in HTTP
URLs. A companion specification <xref target="niexts"/>
describes specific values that can be used in such query
strings in for various purposes.
That document also specifies additional
optional algorithms for truncated hashes and for hashing of
dynamic objects.
</t>
<t>
In addition to the URI form we also define a ".well-known"
URL equivalent
as well as a binary format for use in protocols that
require more compact forms of name and a human-speakable
text form that could be used, e.g. for reading out (parts of)
the name over a voice connection.
</t>
<t>
Not all uses of these names require use of the full hash
output - truncated hashes can be safely used in some
environments. For this reason, we define a new IANA
registry for hash functions to be used with this
specification.
</t>
<t>[[Add a note somewhere that these are sort-of the same as
magnet: links. http://en.wikipedia.org/wiki/Magnet_link ]]</t>
<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 <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
Syntax definitions in this memo are specified according to
ABNF <xref target="RFC4648"/>.
</t>
<t>[[Comments are included in double-square brackets, like this.]]</t>
</section>
<section anchor="syntax" title="ni URI Format">
<t>
In this section we provide an informal description of the ni URI syntax.
An ni URI consists of the following components:
</t>
<t>
<list style="hanging">
<t hangText="Scheme Name [Required]">The scheme name is 'ni'.
</t>
<t hangText="Colon and Slashes [Required]">The literal "://" </t>
<t hangText="Authority [Optional]">
The optional authority component may assist applications in
accessing the object named by an ni URI. Note that while the
ni names with and without an authority differ syntactically,
both names will almost always refer to the same object.
</t>
<t hangText="One slash [Required]">The literal "/" </t>
<t hangText="Digest Algorithm [Required]">
The name of the digest algorithm, as specified in the IANA registry titled
"Data Structure for the Security Suitability of Cryptographic Algorithms
registry 'Cryptographic Algorithms'"
<xref target="RFC5698" />.
</t>
<t hangText="Separator [Required]">The literal ";" </t>
<t hangText="Digest Value [Required]">
The digest value encoded in the specified encoding. The digest value MAY be
truncated at a 64 byte boundary.
<!-- TODO: bit boundary? -->
</t>
<t hangText="Query Parameter separator [Optional] '?'">
The query parameter separator acts a
separator between the digest value
and the query parameters (if specified).
</t>
<t hangText="Query Parameters [Optional]">
A tag=value list of optional query parameters as are used with HTTP URLs.
</t>
</list>
</t>
<t>
It is OPTIONAL for implementations to check the integrity of the
URI/resource mapping when sending, receiving or processing "ni"
URIs.
</t>
<t>
When verifying whether two NI URIs refer to same object, an
implementation MUST only consider the Digest Algorithm identifier
and the Digest Value, i.e., it MUST NOT consider the authority
field or any parameters.
</t>
<t>
The digest value MUST be encoded using base64url
<xref target="RFC4648"/> encoding.
</t>
<t>
The query segment of an URI is NOT hierarchical. Thus escape
encoding of slash '/' characters is NOT required. Since application
code often attempts to enforce such encoding, decoders MUST
recognize the use of URI escape encoding.
Section 3.4 of <xref target="RFC3986" /> states
that "The characters slash ("/") and question mark ("?") may represent data
within the query component."
</t>
<t>
Consequently no special escaping mechanism is required for the
query parameter portion of ni URIs. URI escaping is however frequently
imposed automatically by scripting environments. Thus to
ensure interoperability, implementations SHOULD NOT generate URIs that
employ URI character escaping, and implementations MUST accept any
URIs that employ URI character escaping.
[[That might need to be more specific.]]
</t>
<t>
The Named Information URI has the following syntax:
</t>
<figure title="ni Name syntax" anchor="fig_abnf">
<artwork type="abnf">
niname ="ni://" [ authority ] "/" alg ";" val [ "?" query ]
alg = 1*CHAR
val = 1*CHAR
</artwork>
</figure>
<t>The "authority" and "query" types are as in the URI specification. <xref target="RFC3986"/> </t>
<t>
Implementations MUST support the sha-256 algorithm as specified in
<xref target="RFC4055" />.
</t>
<t>
Implementations MAY support other algorithms specified in the
Data Structure for the Security Suitability of Cryptographic Algorithms
registry 'Cryptographic Algorithms'
<xref target="RFC5698" />.
</t>
<t>Note that additional algorithms are specified in the
companion document to this one <xref target="niexts"/> that
implementations can choose to support if they wish. Those
algorithms use a different IANA registry defined in that
document.
</t>
<t>
The "val" field MUST contain the output of applying the hash function
("alg") to its defined input, which defaults to the object bytes that are
expected to be returned when the URI is de-referenced.
</t>
</section>
<section title="URL Format">
<t>
We define a bidirectional
mapping between the ni URI scheme and a subset of the the HTTP scheme
that makes use of the .well-known URI <xref target="RFC5785"/> by defining an
"ni" suffix (see <xref target="IANACons"/>).
</t>
<t>
The HTTP(s) mapping MAY be used in any context where legacy clients
without support for ni identifiers is required without loss
of interoperability or functionality. A legacy client interprets
the ni identifier as an ordinary HTTP(s) URL while a ni aware client
can determine the corresponding ni form of the URI and apply
ni processing.
</t>
<t>
Implementations SHOULD support this mapping, in both directions.
[[Not sure if we really want 2119 language for the mapping, nor
if we need to specify both directions, so this
is kind of a placeholder.]]
</t>
<t>
For an ni name of the form "ni://n-authority/alg;val?query-string"
the corresponding HTTP URL produced by this algorithm is
"http://h-authority/.well-known/ni/alg/val?query-string". If the ni
name has a specified authority then the h-authority MUST have the same value.
If the ni name has no authority specified (i.e. the n-authority string is
empty), a h-authority value MAY be derived from the application
context. For example, if the mapping is being done in the context of a web page
then the origin <xref target="websec-origin"/> for that web site can be used. Of course, there are in
general no guarantees that the object named by the ni name will be available at
the corresponding HTTP URL. But in the case that any data is returned, the
retreiver can determine if it is the correct content.
</t>
<t>
If an application is presented with a HTTP URL with "/.well-known/ni/"
as the start of its pathname component, then the reverse mapping to an
ni name either including or excluding the authority might produce an ni name
that is meaningful depending on the application.
</t>
<t>
In all of the above the application MAY use the "https" URI scheme
if security considerations warrant use of TLS.
</t>
<t>[[Might want to add a URL-fragment thing for other HTTP URLs too.]]</t>
</section>
<section anchor="binary-format" title="Binary Format">
<t> When a more space-efficient version of the identifier is needed,
the identifier can be presented in binary format. The binary format
identifier consists of two parts: header and the hash. The header
defines how the identifier has been created and the hash part
contains a (possibly truncated) result of a one-way hash over the a
constant value, identifier header, and the public key. The binary
presentation of the identifier is shown in <xref
target="fig-format"/>. </t>
<figure anchor="fig-format" title="Identifier Format">
<artwork align="center">
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Suite ID | Hash /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t> The Res field is reserved for future use and MUST be set to zero
if only Suite IDs defined in this document are used. </t>
<t> The hash algorithm and truncation length is given by the Suite
ID. For maintaining efficient encoding for the binary presentation,
only few hash algorithms and truncation lengths are supported. The
following initial Suite IDs are defined:
<figure anchor="fig-ids" title="Suite Identifiers">
<artwork align="center">
<![CDATA[
ID Hash algorithm Truncation Text
1 SHA-256 120 bits sha-256-120
2 SHA-3 120 bits sha-3-120
32 Reserved
]]></artwork></figure>
</t>
<t> The Suite ID value 32 is reserved for compatibility with ORCHIDs
<xref target="RFC4843"/>. The hash algorithm matching to the Suite ID
MUST be used for generating the hash. The hash is truncated by taking
the 120 last (rightmost) bits of the hash, resulting in total length
of 128 bits for the whole identifier. Future suite IDs MAY define
different truncating rules and hence different length
identifiers. </t>
</section>
<section title="Human-readable Format">
<t> Sometimes the identifier may need to be used in a format that is
easy for humans to read and possibly communicate, for example, over
the phone. For this purpose, the following encoding is
RECOMMENDED. </t>
<t> The hash is encoded using base32 encoding <xref
target="RFC4648"/> and lower-case alphabets. </t>
<t> The hash is preceded by the the hash algorithm identifier (TBD)
</t>
<t> After the hash, there MAY be a checksum; calculated as defined
in <xref target="checksum"/>. </t>
<t> The identifier, hash, and checksum fields are delimited by colon
(:) character. </t>
<t> ABNF TBD </t>
<section anchor="checksum" title="Checksum">
<t> When the identifier is communicated using a non-reliable
channel, it should include a checksum for detecting errors in the
communication. The human readable format checksum MUST be
calculated as a crc32 over the parts preceding the checksum, i.e.,
the algorithm identifier, the delimiter, and the hash value. The
result of crc32 is encoded like the hash: with base32 encoding and
lower-case alphabets. </t>
</section>
</section>
<section title="Public Key Identifiers">
<t> When the identifier is calculated from a cryptographic public
key, the hash is calculated over constant value (TBD) and the public
key in a X.509 SubjectPublicKeyInfo structure (Section 4.1 of <xref
target="RFC5280"/>). </t>
<t>[[Need to check why that constant was wanted. Doesn't seem useful
and would break DANE compatibility.]]</t>
</section>
<section title="Examples">
<t>[[Note: check examples and make sure they're correct sometime.]]
</t>
<t>
The following digest URI specifies a reference to
the text "Hello World !" using the SHA-2 algorithm with 256
bit output and no authority field:
</t>
<t>ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc</t>
<t>And the same example shown with an authority would be:</t>
<t>ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc</t>
<t>The following HTTP URL represents a mapping from the
previous ni name based on the algorithm outlined above.
</t>
<t>http://example.com/.well-known/ni/sha-256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc</t>
</section>
<section title="Security Considerations" anchor="sec_cons">
<t>
No secret information is required to
generate or verify an ni URI. Therefore
an ni URI only provides a proof of integrity for the
referenced object and the proof of integrity provided is
only as good as the proof of integrity for the ni URI.
In other words, the digest value can provide
name-data integrity binding the ni name value to the
object bytes returned when the ni name is de-referenced
using some protocol.
</t>
<t>
Disclosure of an ni URI value does not necessarily
entail disclosure of the referenced object but may enable
an attacker to determine the contents of the referenced object
by reference to a search engine or other data repository or,
for highly formatted object with little variation,
by simply guessing the value and checking if the digest
value matches.
</t>
<t>
The integrity of the referenced content would be compromised if
a weak digest were used.
</t>
<t>
If a truncated digest is used, certain security properties
MAY be affected.
In general a digest algorithm is designed to produce sufficient
bits to prevent a 'birthday attack' collision occurring. To ensure that
the difficulty of discovering two pieces of content that result in the same
digest with a work factor O(2^x) by brute force requires a digest length of 2x.
Many security applications only require protection against a
2nd pre-image attack which only requires a digest length of x to
achieve the same work factor.
</t>
<t>
[[Don't reduce too much, and don't rely on a digest that has been
truncated as being the strength of the original digest alg.]]
</t>
</section>
<section title="Acknowledgements">
<t>
This work has been supported by the EU FP7 project SAIL.
The authors would like to thank SAIL participants to our
naming discussions, especially Jean-Francois Peltier, for
their input.
</t>
<t> The authors would also like to thank Bob Moskowitz, Tero
Kivinen, Zach Shelby, Carsten Bormann, David McGrew, Eric
Rescorla, and Tobias Heer for their comments and input to the
document. </t>
<t>
[[Mention folk on the WebSec list who contributed to the
discussions]]
</t>
</section>
<section title="IANA Considerations" anchor="IANACons">
<t> IANA is requested to create a new registry for (TBD) Suite
IDs. Initial values are given in <xref target="binary-format"/>,
future assignments are to be made through IETF Review or IESG
Approval <xref target="RFC5226"/>. </t>
<section title="Assignment of Network Information (ni) URI Scheme">
<t>
The procedures for registration of a URI scheme are specified in
<xref target="RFC4395">RFC 4395</xref>. The following is the proposed
assignment template.
</t>
<t>
URI scheme name: ni
</t>
<t>
Status: Permanent
</t>
<t>
URI scheme syntax. See <xref target="syntax" />
</t>
<t>
URI scheme semantics. See <xref target="syntax" />
</t>
<t>
Encoding considerations. See <xref target="syntax" />
</t>
<t>
Applications/protocols that use this URI scheme name:
General applicability with initial use cases provided by WEBSEC
and DECADE
</t>
<t>
Interoperability considerations: TBS
</t>
<t>
Security considerations: See <xref target="sec_cons" />
</t>
<t>
Contact: TBD
</t>
<t>
Author/Change controller: IETF
</t>
<t>
References: As specified in this document
</t>
</section>
<section title="Assignment of Well Known URI prefix ni">
<t>
The procedures for registration of a Well Known URI entry
are specified in <xref target="RFC5785">RFC 5785</xref>.
The following is the proposed
assignment template.
</t>
<t>
URI suffix: ni
</t>
<t>
Change controller: IETF
</t>
<t>
Specification document(s): This document
</t>
<t>
Related information: None
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<!--&RFC1035;-->
&RFC2119;
&RFC3986;
<!--&RFC4033;-->
&RFC4055;
&RFC4395;
&RFC4648;
<!--&RFC5395;-->
&RFC5698;
&RFC5785;
&RFC4843;
&RFC5226;
&RFC5280;
</references>
<references title="Informative References">
<reference anchor="niexts">
<front>
<title>The Network Information (ni) URI Scheme: Parameters</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'/>
<author initials='R' surname='Stradling' fullname='Rob Stradling'/>
<author initials='S' surname='Farrell' fullname='Stephen Farrell'> </author>
<author initials='C' surname='Kutscher' fullname='Dirk Kutscher'> </author>
<author initials='B' surname='Ohlman' fullname='Borje Ohlman'> </author>
<date month='October' year='2011' />
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-decade-ni-params-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-decade-ni-params-00.txt' />
</reference>
<!--
<reference anchor="NIST-ALGS">
<front>
<title>Cryptographic Algorithm Registration</title>
<author>
<organization abbrev="NIST">
National Institute of Standards and Technology
</organization>
</author>
<date day="11" month="March" year="2009"/>
</front>
<format type="HTML" target="http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html"/>
</reference>
-->
<reference anchor="ref.netinf-design">
<front>
<title>Design Considerations for a Network of Information</title>
<author surname="Ahlgren" fullname="Bengt Ahlgren"></author>
<author surname="D'Ambrosio" fullname="Matteo D'Ambrosio"></author>
<author surname="Dannewitz" fullname="Christian Dannewitz"></author>
<author surname="Marchisio" fullname="Marco Marchisio"></author>
<author surname="Marsh" fullname="Ian Marsh"></author>
<author surname="Ohlman" fullname="Boerje Ohlman"></author>
<author surname="Pentikousis" fullname="Kostas Pentikousis"></author>
<author surname="Rembarz" fullname="Rene Rembarz"></author>
<author surname="Strandberg" fullname="Ove Strandberg"></author>
<author surname="Vercellone" fullname="Vinicio Vercellone"></author>
<date month="December" year="2008"/>
</front>
<seriesInfo name="Re-Arch 2008 Workshop" value=""/>
</reference>
<reference anchor="ref.ccn">
<front>
<title>Networking Named Content</title>
<author surname="Jacobsen" fullname="Van Jacobsen"></author>
<author surname="K" fullname="Diana K. Smetters"></author>
<author surname="D" fullname="James D. Thornton"></author>
<author surname="F" fullname="Michael F. Plass"></author>
<author surname="H" fullname="Nicholas H. Briggs"></author>
<author surname="L" fullname="Rebecca L. Braynard"></author>
<date month="December" year="2009"/>
</front>
<seriesInfo name="CoNEXT 2009" value=""/>
</reference>
<reference anchor='websec-origin'>
<front>
<title>The Web Origin Concept</title>
<author initials='A' surname='Barth' fullname='Adam Barth'>
<organization />
</author>
<date month='October' day='3' year='2011' />
<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 underlie the concept of origin, this document defines how to determine the origin of a URI, how to serialize an origin into a string, and an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-websec-origin-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-websec-origin-06.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:40:04 |