One document matched: draft-thomson-webpush-vapid-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>
<rfc ipr="trust200902" docName="draft-thomson-webpush-vapid-01" category="std">
<front>
<title abbrev="Self Identification">Voluntary Application Server Identification for Web Push</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<author initials="P." surname="Beverloo" fullname="Peter Beverloo">
<organization>Google</organization>
<address>
<email>beverloo@google.com</email>
</address>
</author>
<date year="2016"/>
<abstract>
<t>An application server can voluntarily identify itself to a push service using
the described technique. This identification information can be used by the
push service to attribute requests that are made by the same application server
to a single entity, and reduce the need for endpoint secrecy by being able to
associate subscriptions with an application server. An application server is
further able include additional information the operator of a push service can
use to contact the operator of the application server.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The Web Push protocol <xref target="I-D.ietf-webpush-protocol"></xref> describes how an application
server is able to request that a push service deliver a push message to a user
agent.</t>
<t>As a consequence of the expected deployment architecture, there is no basis for
an application server to be known to a push service prior to requesting delivery
of a push message. By the same measure, requesting the creation of a
subscription for push message receipts has no prior authentication. Requiring
that the push service be able to authenticate application servers places an
unwanted constraint on the interactions between user agents and application
servers, who are the ultimate users of a push service. That constraint would
also degrade the privacy-preserving properties the protocol provides. For these
reasons, <xref target="I-D.ietf-webpush-protocol"></xref> does not define a mandatory system for
authentication of application servers.</t>
<t>An unfortunate consequence of this design is that a push service is exposed to a
greater risk of denial of service attack. While requests from application
servers can be indirectly attributed to user agents, this is not always
efficient or even sufficient. Providing more information about the application
server more directly to a push service allows the push service to better
distinguish between legitimate and bogus requests.</t>
<t>Additionally, this design also relies on endpoint secrecy as any application
server in possession of the endpoint is able to send messages, albeit without
payloads. In situations where usage of a subscription can be limited to a
single application server, the ability to associate said subscription with the
application server provides could reduce the impact of a data leak.</t>
<t>This document describes a system whereby an application server can volunteer
information about itself to a push service. At a minimum, this provides a
stable identity for the application server, though this could also include
contact information, such as an email address.</t>
<t>A consistent identity can be used by a push service to establish behavioral
expectations for an application server. Significant deviations from an
established norm can then be used to trigger exception handling procedures.</t>
<t>Voluntarily-provided contact information can be used to contact an application
server operator in the case of exceptional situations.</t>
<t>Experience with push service deployment has shown that software errors or
unusual circumstances can cause large increases in push message volume.
Contacting the operator of the application server has proven to be valuable.</t>
<t>Even in the absence of usable contact information, an application server that
has a well-established reputation might be given preference over an unidentified
application server when choosing whether to discard a push message.</t>
<section anchor="notational-conventions" title="Notational Conventions">
<t>The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document.
It’s not shouting, when they are capitalized, they have the special meaning
described in <xref target="RFC2119"></xref>.</t>
<t>The terms “push message”, “push service”, “application server”, and “user agent”
are used as defined in <xref target="I-D.ietf-webpush-protocol"></xref></t>
</section>
</section>
<section anchor="self-identification-alternatives" title="Self-Identification Alternatives">
<t>Several options have been proposed, here are some of the more concrete options.</t>
<section anchor="certificates" title="Certificates">
<t>A push service that supports application server self-identification requests a
client certificate from application servers. The client certificate is
requested during the TLS <xref target="RFC5246"></xref> handshake.</t>
<t>An application server that does not have a client certificate offers no
certificate in response; an application server that wishes to self-identify
includes a certificate.</t>
<t>The certificate that the application server offers SHOULD be self-signed (see
Section 3.2 of <xref target="RFC5280"></xref>). The certificate MAY contain an alternative name
extension (Section 4.2.1.6 of <xref target="RFC5280"></xref>) that includes contact information. Of
the available options, an email address using the <spanx style="verb">rfc822Name</spanx> form or an HTTP
<xref target="RFC7230"></xref> (or HTTPS <xref target="RFC2818"></xref>) <spanx style="verb">uniformResourceIdentifier</spanx> SHOULD be included,
though including other options are not prohibited.</t>
<t>The offered end-entity certificate or the public key it contains becomes an
identifier for the application server. Push services are able to reduce the
data they retain for an application server, either by extracting important
information like the subject public key information (SPKI), by hashing, or a
combination. Of course, a push service might choose to ignore the provided
information.</t>
<t>To avoid requesting certificates from user agents, it might be necessary to
serve requests from user agents and requests from application servers on
different hostnames or port numbers.</t>
</section>
<section anchor="server-token" title="Server-Vended Tokens">
<t>In this model, the push service vends a token to each application server that
requests it. That token is kept secret and used as the basis for
authentication.</t>
<t>This doesn’t address the need for contact information, but it addresses the need
for a consistent application server identifier.</t>
<t>A Cookie <xref target="RFC6265"></xref> is a token of this nature. All the considerations regarding
the use (and misuse) of HTTP cookies apply should this option be chosen. A
mechanism that makes token theft more difficult, such as
<xref target="I-D.ietf-tokbind-https"></xref> might be needed. However that suggests a separate
option (see <xref target="tokbind"/>).</t>
<t>This information would be repeated with each request, but that overhead is
greatly reduced by header compression <xref target="RFC7541"></xref> in HTTP/2 <xref target="RFC7540"></xref>.</t>
</section>
<section anchor="client-token" title="Client-Vended Tokens">
<t>In this model, clients generates a token that it uses to prove ownership over a
private key. Use of the same key over time establishes a continuous identity.</t>
<t>Push message requests can be accompanied by a JSON Web Token (JWT) <xref target="RFC7519"></xref>.
An “aud” (Audience) claim in the token MUST include the push resource URL. This
binds the token to a specific push subscription, but not a specific push
message. As a result, the token is reusable, limited by the value of the “exp”
(Expiry) claim in the token. An “exp” claim MUST be included.</t>
<t>The JWT is included in an Authorization header field, using an auth-scheme of
“WebPush”.</t>
<t><list style="hanging">
<t hangText='Editor’s Note:'>
The definition of the “Bearer” auth-scheme in <xref target="RFC6750"></xref> is almost perfect, but
context would seem to indicate that this is only valid for use with OAuth.</t>
</list></t>
<t>The corresponding public key is included in a JSON Web Key (JWK) <xref target="RFC7517"></xref>.
This would be included in either a newly-defined “jwk” parameter of the
Crypto-Key header field <xref target="I-D.ietf-httpbis-encryption-encoding"></xref>; alternatively, the
“p256ecdsa” parameter defined in <xref target="I-D.thomson-http-content-signature"></xref> could be
used to transport a raw key.</t>
<t>For voluntarily-provided contact details, a separate header field could be used
(as in <xref target="from"/>) or the JWT could include claims about identity. For the
latter, the “sub” (subject) claim could include a contact URI for the
application server.</t>
<t>The JWT MUST use a JSON Web Signature (JWS) <xref target="RFC7515"></xref>. Both the JWS and JWK
MUST use an elliptic curve digital signature (ECDSA) key on the NIST P-256 curve
<xref target="FIPS186"></xref>.</t>
<t>A JWT also offers the option of including contact information as an additional
claim. An “iss” (Issuer) claim can include a contact URI: either a “mailto:”
(email) <xref target="RFC6068"></xref> or an “https:” <xref target="RFC2818"></xref> SHOULD be used.</t>
</section>
<section anchor="from" title="Contact Information Header Field">
<t>Contact information for an application server could be included in a header
field, either directly (e.g., a From header field, Section 5.5.1 of <xref target="RFC7231"></xref>),
or by reference (e.g., a new “contact” link relation <xref target="RFC5988"></xref> that identified a
vCard <xref target="RFC6350"></xref>). Note that a From header field is limited to email addresses.</t>
<t>Like an server- or client-vended token (<xref target="server-token"/>, <xref target="client-token"/>),
contact information would need to be repeated, though that cost is reduced with
HTTP/2.</t>
</section>
<section anchor="request-signing" title="Request Signing">
<t>Signing of push message requests would allow the push service to attribute
requests to an application server based on an asymmetric key. This could be
done in any number of ways JWS <xref target="RFC7515"></xref> and HTTP signatures
<xref target="I-D.cavage-http-signatures"></xref> being the most likely options. Note that the
latter does not provide a means of conveying the signing key, which would be
necessary for this application.</t>
<t>Request signing shares much in common with client-vended tokens
<xref target="client-token"/>, but it removes any possibility of token reuse in the interests
of security.</t>
<t>Request signing has a few shortcomings:</t>
<t><list style="symbols">
<t>Deciding what to sign is challenging. Signing only the body of a message is
not sufficient to prevent message replay attacks.</t>
<t>Every message contains a signature, which can increase the load on a server
signficantly. This is especially bad if a signature validation result is
input to denial of service mitigation decision making.</t>
</list></t>
</section>
<section anchor="tokbind" title="Token Binding">
<t>The mechanism proposed in <xref target="I-D.ietf-tokbind-https"></xref> can be used to provide a
stable identifier for application servers. This includes a signature over
material that is exported from the underlying TLS connection. Importantly, this
does not require a new signature for each request: the same signature is
repeated for every request, HTTP/2 is again used to reduce the cost of the
repeated information.</t>
<t>Token binding could be used independently of cookies. Consequently, an
application server would not be required to accept and store cookies, though the
push service would not be able to offload any state as a result.</t>
</section>
</section>
<section anchor="subscription-association" title="Subscription Association">
<t>A stable identifier for an application server - such as a public key or a token
- could also be used to associate a subscription with the application server.</t>
<t>Subscription association reduces the reliance on endpoint secrecy by requiring
proof of possession to be demonstrated by an application server when requesting
delivery of a push message. This provides an additional level of protection
against leaking of the details of the push subscription.</t>
<section anchor="amendments-to-subscribing-for-push-messages" title="Amendments to Subscribing for Push Messages">
<t>The user agent includes the public key or token of the application server when
requesting the creation of a subscription. For example, the Web Push API <xref target="API"></xref>
could allow an application to provide a public key as part of a new field on the
<spanx style="verb">PushSubscriptionOptions</spanx> dictionary.</t>
<t>This token might then be added to the request to create a push subscription.</t>
<t>Allowing the inclusion of multiple keys when creating a subscription would allow
a subscription to be associated with multiple application servers or application
server instances. This would require more state to be maintained by the push
service for each subscription.</t>
</section>
<section anchor="amendments-to-requesting-push-message-delivery" title="Amendments to Requesting Push Message Delivery">
<t>When a subscription has been associated with an application server, the request
for push message delivery MUST include proof of possession for the associated
private key or token that was used when creating the subscription. Requests
that do not contain proof of possession are rejected with a 401 (Unauthorized)
status code.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This document has no IANA actions (yet).</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TLS 1.2 <xref target="RFC5246"></xref> does not provide any confidentiality protections for client
certificates. A network attacker can therefore see the identification
information that is provided by the application server. A push service MAY
choose to offer confidentiality protection for application server identity by
initiating TLS renegotiation immediately after establishing the TLS connection
at the cost of some additional latency. Using TLS 1.3 <xref target="I-D.ietf-tls-tls13"></xref>
provides confidentiality protection for this information without additional
latency.</t>
<t>An application server might offer falsified contact information. A push service
operator therefore cannot use the presence of unvalidated contact information as
input to any security-critical decision-making process.</t>
<t>Many of the alternative solutions are vulnerable to replay attacks. Applying
narrow limits to the period over which a replayable token can be reused limits
the potential value of a stolen token to an attacker and can increase the
difficulty of stealing a token. The token binding solution, which binds tokens
to a single TLS connection can make tokens less reusable.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This document would have been much worse than it currently is if not for the
contributions of Benjamin Bangert, Chris Karlof, Costin Manolache, and others.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='I-D.ietf-webpush-protocol'>
<front>
<title>Generic Event Delivery Using HTTP Push</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<author initials='E' surname='Damaggio' fullname='Elio Damaggio'>
<organization />
</author>
<author initials='B' surname='Raymor' fullname='Brian Raymor'>
<organization />
</author>
<date month='November' day='23' year='2015' />
<abstract><t>A simple protocol for the delivery of realtime events to user agents is described. This scheme uses HTTP/2 server push.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-webpush-protocol-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-webpush-protocol-02.txt' />
<format type='PDF'
target='http://www.ietf.org/internet-drafts/draft-ietf-webpush-protocol-02.pdf' />
</reference>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC5246' target='http://www.rfc-editor.org/info/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' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>
<reference anchor='RFC5280' target='http://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>
<reference anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</reference>
<reference anchor='RFC6068' target='http://www.rfc-editor.org/info/rfc6068'>
<front>
<title>The 'mailto' URI Scheme</title>
<author initials='M.' surname='Duerst' fullname='M. Duerst'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<author initials='J.' surname='Zawinski' fullname='J. Zawinski'><organization /></author>
<date year='2010' month='October' />
<abstract><t>This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6068'/>
<seriesInfo name='DOI' value='10.17487/RFC6068'/>
</reference>
<reference anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>
<reference anchor="FIPS186" >
<front>
<title>Digital Signature Standard (DSS)</title>
<author >
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="NIST PUB 186-4" value=""/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC7231' target='http://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>
<reference anchor='RFC7515' target='http://www.rfc-editor.org/info/rfc7515'>
<front>
<title>JSON Web Signature (JWS)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7515'/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/>
</reference>
<reference anchor='RFC7517' target='http://www.rfc-editor.org/info/rfc7517'>
<front>
<title>JSON Web Key (JWK)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<date year='2015' month='May' />
<abstract><t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7517'/>
<seriesInfo name='DOI' value='10.17487/RFC7517'/>
</reference>
<reference anchor='RFC7519' target='http://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>
<reference anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>
<reference anchor='RFC7541' target='http://www.rfc-editor.org/info/rfc7541'>
<front>
<title>HPACK: Header Compression for HTTP/2</title>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='H.' surname='Ruellan' fullname='H. Ruellan'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</t></abstract>
</front>
<seriesInfo name='RFC' value='7541'/>
<seriesInfo name='DOI' value='10.17487/RFC7541'/>
</reference>
<reference anchor='RFC6350' target='http://www.rfc-editor.org/info/rfc6350'>
<front>
<title>vCard Format Specification</title>
<author initials='S.' surname='Perreault' fullname='S. Perreault'><organization /></author>
<date year='2011' month='August' />
<abstract><t>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6350'/>
<seriesInfo name='DOI' value='10.17487/RFC6350'/>
</reference>
<reference anchor='RFC5988' target='http://www.rfc-editor.org/info/rfc5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2010' month='October' />
<abstract><t>This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5988'/>
<seriesInfo name='DOI' value='10.17487/RFC5988'/>
</reference>
<reference anchor='RFC6265' target='http://www.rfc-editor.org/info/rfc6265'>
<front>
<title>HTTP State Management Mechanism</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='April' />
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6265'/>
<seriesInfo name='DOI' value='10.17487/RFC6265'/>
</reference>
<reference anchor='RFC6750' target='http://www.rfc-editor.org/info/rfc6750'>
<front>
<title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='D.' surname='Hardt' fullname='D. Hardt'><organization /></author>
<date year='2012' month='October' />
<abstract><t>This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6750'/>
<seriesInfo name='DOI' value='10.17487/RFC6750'/>
</reference>
<reference anchor='I-D.cavage-http-signatures'>
<front>
<title>Signing HTTP Messages</title>
<author initials='M' surname='Cavage' fullname='Mark Cavage'>
<organization />
</author>
<author initials='M' surname='Sporny' fullname='Manu Sporny'>
<organization />
</author>
<date month='October' day='7' year='2015' />
<abstract><t>When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-cavage-http-signatures-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-cavage-http-signatures-05.txt' />
</reference>
<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='December' day='28' year='2015' />
<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-11' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-11.txt' />
</reference>
<reference anchor='I-D.ietf-tokbind-https'>
<front>
<title>Token Binding over HTTP</title>
<author initials='A' surname='Popov' fullname='Andrey Popov'>
<organization />
</author>
<author initials='M' surname='Nystrom' fullname='Magnus Nystrom'>
<organization />
</author>
<author initials='D' surname='Balfanz' fullname='Dirk Balfanz'>
<organization />
</author>
<author initials='A' surname='Langley' fullname='Adam Langley'>
<organization />
</author>
<date month='October' day='15' year='2015' />
<abstract><t>This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to a TLS [RFC5246] connection. We describe both _first-party_ as well as _federated_ scenarios. In a first-party scenario, an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate. Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS [RFC5246] connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [TBPROTO]</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tokbind-https-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tokbind-https-02.txt' />
</reference>
<reference anchor='I-D.ietf-httpbis-encryption-encoding'>
<front>
<title>Encrypted Content-Encoding for HTTP</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<date month='December' day='23' year='2015' />
<abstract><t>This memo introduces a content-coding for HTTP that allows message payloads to be encrypted.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-encryption-encoding-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-encryption-encoding-00.txt' />
</reference>
<reference anchor='I-D.thomson-http-content-signature'>
<front>
<title>Content-Signature Header Field for HTTP</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<date month='July' day='2' year='2015' />
<abstract><t>A Content-Signature header field is defined for use in HTTP. This header field carries a signature of the payload body of a message.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-thomson-http-content-signature-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-thomson-http-content-signature-00.txt' />
</reference>
<reference anchor="API" target="https://w3c.github.io/push-api/">
<front>
<title>Web Push API</title>
<author initials="M." surname="van Ouwerkerk">
<organization></organization>
</author>
<author initials="M." surname="Thomson">
<organization></organization>
</author>
<date year="2015"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:06:31 |