8292
PROPOSED STANDARD
Voluntary Application Server Identification (VAPID) for Web Push
Authors: M. Thomson, P. Beverloo
Date: November 2017
Area: art
Working Group: webpush
Stream: IETF
Abstract
An application server can use the Voluntary Application Server Identification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server.
RFC 8292
PROPOSED STANDARD
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8292 Mozilla
Category: Standards Track P. Beverloo
ISSN: 2070-1721 Google
November 2017
<span class="h1">Voluntary Application Server Identification (VAPID) for Web Push</span>
Abstract
An application server can use the Voluntary Application Server
Identification (VAPID) method described in this document to
voluntarily identify itself to a push service. The "vapid"
authentication scheme allows a client to include its identity in a
signed token with requests that it makes. The signature can be used
by the push service to attribute requests that are made by the same
application server to a single entity. The identification
information can allow the operator of a push service to contact the
operator of the application server. The signature can be used to
restrict the use of a push message subscription to a single
application server.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8292">https://www.rfc-editor.org/info/rfc8292</a>.
<span class="grey">Thomson & Beverloo Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Voluntary Identification ...................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Notational Conventions .....................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Application Server Self-Identification ..........................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Application Server Contact Information .....................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Additional Claims ..........................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Cryptographic Agility ......................................<a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. Example ....................................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. VAPID Authentication Scheme .....................................<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Token Parameter ("t") ......................................<a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Public Key Parameter ("k") .................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Subscription Restriction ........................................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Creating a Restricted Push Message Subscription ............<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Using Restricted Subscriptions .............................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. VAPID Authentication Scheme Registration ..................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. VAPID Authentication Scheme Parameters ....................<a href="#page-10">10</a>
<a href="#section-6.3">6.3</a>. application/webpush-options+json Media Type Registration ..11
<a href="#section-7">7</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-14">14</a>
Acknowledgements ..................................................<a href="#page-14">14</a>
Authors' Addresses ................................................<a href="#page-14">14</a>
<span class="grey">Thomson & Beverloo Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Web Push protocol [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>] describes how an application server
is able to request that a push service deliver a push message to a
user agent.
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. 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, [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>] does not define
a mandatory system for authentication of application servers.
An unfortunate consequence of the design of [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>] is that a push
service is exposed to a greater risk of denial-of-service attacks.
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 directly to a
push service allows the push service to better distinguish between
legitimate and bogus requests.
Additionally, the design of [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>] relies on maintaining the
secrecy of push message subscription URIs. Any application server in
possession of a push message subscription URI is able to send
messages to the user agent. If use of a subscription could be
limited to a single application server, this would reduce the impact
of the push message subscription URI being learned by an unauthorized
party.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Voluntary Identification</span>
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.
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.
<span class="grey">Thomson & Beverloo Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
Voluntarily provided contact information can be used to contact an
application server operator in the case of exceptional situations.
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.
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.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Notational Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
The terms "push message", "push service", "push message
subscription", "application server", and "user agent" are used as
defined in [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Application Server Self-Identification</span>
Application servers that wish to self-identify generate and maintain
a signing key pair. This key pair MUST be usable with the Elliptic
Curve Digital Signature Algorithm (ECDSA) over the P-256 curve
[<a href="#ref-FIPS186" title=""Digital Signature Standard (DSS)"">FIPS186</a>]. Use of this key when sending push messages establishes an
identity for the application server that is consistent across
multiple messages.
When requesting delivery of a push message, the application includes
a JSON Web Token (JWT) [<a href="./rfc7519" title=""JSON Web Token (JWT)"">RFC7519</a>], signed using its signing key. The
token includes a number of claims as follows:
o An "aud" (Audience) claim in the token MUST include the Unicode
serialization of the origin (<a href="./rfc6454#section-6.1">Section 6.1 of [RFC6454]</a>) of the push
resource URL. This binds the token to a specific push service and
ensures that the token is reusable for all push resource URLs that
share the same origin.
o An "exp" (Expiry) claim MUST be included with the time after which
the token expires. This limits the time over which a token is
valid. An "exp" claim MUST NOT be more than 24 hours from the
<span class="grey">Thomson & Beverloo Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
time of the request. Limiting this to 24 hours balances the need
for reuse against the potential cost and likelihood of theft of a
valid token.
This JWT is included in an Authorization header field, using an
authentication scheme of "vapid". A push service MAY reject a
request with a 403 (Forbidden) status code [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"">RFC7231</a>] if the JWT
signature or its claims are invalid. A push service MUST NOT use
information from an invalid token.
The JWT MUST use a JSON Web Signature (JWS) [<a href="./rfc7515" title=""JSON Web Signature (JWS)"">RFC7515</a>]. The signature
MUST use ECDSA on the NIST P-256 curve [<a href="#ref-FIPS186" title=""Digital Signature Standard (DSS)"">FIPS186</a>], which is identified
as "ES256" [<a href="./rfc7518" title=""JSON Web Algorithms (JWA)"">RFC7518</a>].
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Application Server Contact Information</span>
If the application server wishes to provide contact details, it MAY
include a "sub" (Subject) claim in the JWT. The "sub" claim SHOULD
include a contact URI for the application server as either a
"mailto:" (email) [<a href="./rfc6068" title=""The 'mailto' URI Scheme"">RFC6068</a>] or an "https:" [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>] URI.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Additional Claims</span>
An application server MAY include additional claims using public or
private names (see Sections <a href="#section-4.2">4.2</a> and <a href="#section-4.3">4.3</a> of [<a href="./rfc7519" title=""JSON Web Token (JWT)"">RFC7519</a>]). Since the JWT
is in a header field, the size of additional claims SHOULD be kept as
small as possible.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Cryptographic Agility</span>
The "vapid" HTTP authentication scheme (<a href="#section-3">Section 3</a>) is used to
identify the specific profile of JWT defined in this document. A
different authentication scheme is needed to update the signature
algorithm or other parameters. This ensures that existing mechanisms
for negotiating authentication schemes can be used rather than
defining new parameter negotiation mechanisms.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Example</span>
An application server requests the delivery of a push message as
described in [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>]. If the application server wishes to self-
identify, it includes an Authorization header field with credentials
that use the "vapid" authentication scheme.
<span class="grey">Thomson & Beverloo Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 30
Content-Length: 136
Content-Encoding: aes128gcm
Authorization: vapid
t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
uU_RCPCfA5aq9ojSwk5Y2EmClBPs
{ encrypted push message }
Figure 1: Requesting Push Message Delivery with JWT
Note that the example header fields in this document include extra
line wrapping to meet formatting constraints.
The "t" parameter of the Authorization header field contains a JWT;
the "k" parameter includes the base64url-encoded key that signed that
token. The JWT input values and the JSON Web Key (JWK) [<a href="./rfc7517" title=""JSON Web Key (JWK)"">RFC7517</a>]
corresponding to the signing key are shown in Figure 2 with
additional whitespace added for readability purposes. This JWT would
be valid until 2016-01-23T04:36:08Z.
JWT header = { "typ": "JWT", "alg": "ES256" }
JWT body = { "aud": "https://push.example.net",
"exp": 1453523768,
"sub": "mailto:[email protected]" }
JWK = { "crv":"P-256",
"kty":"EC",
"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
Figure 2: Decoded Example Values
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. VAPID Authentication Scheme</span>
This document defines a new HTTP authentication scheme [<a href="./rfc7235" title=""Hypertext Transfer Protocol (HTTP/1.1): Authentication"">RFC7235</a>]
named "vapid". This authentication scheme carries a signed JWT, as
described in <a href="#section-2">Section 2</a>, plus the key that signed that JWT.
This authentication scheme is for origin-server authentication only.
Therefore, this authentication scheme MUST NOT be used with the
Proxy-Authenticate or Proxy-Authorization header fields.
<span class="grey">Thomson & Beverloo Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
The challenge for the "vapid" authentication scheme contains only the
"auth-scheme" production. No parameters are currently defined.
Two parameters are defined for this authentication scheme: "t" and
"k". All unknown or unsupported parameters to "vapid" authentication
credentials MUST be ignored. The "realm" parameter is ignored for
this authentication scheme.
This authentication scheme is intended for use by an application
server when using the Web Push protocol [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Token Parameter ("t")</span>
The "t" parameter of the "vapid" authentication scheme carries a JWT
as described in <a href="#section-2">Section 2</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Public Key Parameter ("k")</span>
In order for the push service to be able to validate the JWT, it
needs to learn the public key of the application server. A "k"
parameter is defined for the "vapid" authentication scheme to carry
this information.
The "k" parameter includes an ECDSA public key [<a href="#ref-FIPS186" title=""Digital Signature Standard (DSS)"">FIPS186</a>] in
uncompressed form [<a href="#ref-X9.62" title=""Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>] that is encoded using base64url encoding
[<a href="./rfc7515" title=""JSON Web Signature (JWS)"">RFC7515</a>].
Note: X9.62 encoding is used over JWK [<a href="./rfc7517" title=""JSON Web Key (JWK)"">RFC7517</a>] for two reasons. A
JWK does not have a canonical form, so X9.62 encoding makes it
easier for the push service to handle comparison of keys from
different sources. Secondarily, the X9.62 encoding is also
considerably smaller.
Some elliptic curve implementations permit the same P-256 key to be
used for signing and key exchange. An application server MUST select
a different private key for the key exchange [<a href="./rfc8291" title=""Message Encryption for Web Push"">RFC8291</a>] and signing
the authentication token. Though a push service is not obligated to
check either parameter for every push message, a push service SHOULD
reject push messages that have identical values for these parameters
with a 400 (Bad Request) status code.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Subscription Restriction</span>
The public key of the application server serves as a stable
identifier for the server. This key can be used to restrict a push
message subscription to a specific application server.
<span class="grey">Thomson & Beverloo Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
Subscription restriction reduces the reliance on endpoint secrecy by
requiring that an application server provide a signed token when
requesting delivery of a push message. This provides an additional
level of protection against leaking of the details of the push
message subscription.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Creating a Restricted Push Message Subscription</span>
A user agent that wishes to create a restricted subscription includes
the public key of the application server when requesting the creation
of a push message subscription. This restricts use of the resulting
subscription to application servers that are able to provide a valid
JWT signed by the corresponding private key.
The user agent then adds the public key to the request to create a
push message subscription. The push message subscription request is
extended to include a body. The body of the request is a JSON object
as described in [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>]. The user agent adds a "vapid" member to
this JSON object that contains a public key on the P-256 curve,
encoded in the uncompressed form [<a href="#ref-X9.62" title=""Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>] and base64url encoded
[<a href="./rfc7515" title=""JSON Web Signature (JWS)"">RFC7515</a>]. The media type of the body is set to "application/
webpush-options+json" (see <a href="#section-6.3">Section 6.3</a> for registration of this media
type).
A push service MUST ignore the body of a request that uses a
different media type. For the "application/webpush-options+json"
media type, a push service MUST ignore any members on this object
that it does not understand.
The example in Figure 3 shows a restriction to the key used in
Figure 1. Extra whitespace is added to meet formatting constraints.
POST /subscribe/ HTTP/1.1
Host: push.example.net
Content-Type: application/webpush-options+json
Content-Length: 104
{ "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
Figure 3: Example Subscribe Request
An application might use the Push API [<a href="#ref-API" title=""Push API"">API</a>] to provide the user agent
with a public key.
<span class="grey">Thomson & Beverloo Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Using Restricted Subscriptions</span>
When a push message subscription has been restricted to an
application server, the request for push message delivery MUST
include a JWT signed by the private key that corresponds to the
public key used when creating the subscription.
A push service MUST reject a message sent to a restricted push
message subscription if that message includes no "vapid"
authentication or invalid "vapid" authentication. A 401
(Unauthorized) status code might be used if the authentication is
absent; a 403 (Forbidden) status code might be used if authentication
is invalid.
"vapid" authentication is invalid if:
o either the authentication token or public key is not included in
the request,
o the signature on the JWT cannot be successfully verified using the
included public key,
o the current time is later than the time identified in the "exp"
(Expiry) claim or more than 24 hours before the expiry time,
o the origin of the push resource is not included in the "aud"
(Audience) claim, or
o the public key used to sign the JWT doesn't match the one that was
included in the creation of the push message subscription.
A push service MUST NOT forward the JWT or public key to the user
agent when delivering the push message.
An application server that needs to replace its signing key needs to
request the creation of a new subscription by the user agent that is
restricted to the updated key. Application servers need to remember
the key that was used when requesting the creation of a subscription.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This authentication scheme is vulnerable to replay attacks if an
attacker can acquire a valid JWT. Sending requests using HTTPS as
required by [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>] provides confidentiality. Additionally,
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.
<span class="grey">Thomson & Beverloo Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
An application server might offer falsified contact information. The
application server asserts its email address or contact URI without
any evidence to support the claim. A push service operator cannot
use the presence of unvalidated contact information as input to any
security-critical decision-making process.
Validation of a signature on the JWT requires a non-trivial amount of
computation. For something that might be used to identify legitimate
requests under denial-of-service attack conditions, this is not
ideal. Application servers are therefore encouraged to reuse tokens,
which permits the push service to cache the results of signature
validation.
An application server that changes its signing key breaks linkability
between push messages that it sends under different keys. A push
service that relies on a consistent identity for application servers
might categorize requests made with new keys differently. Gradual
migration to a new signing key reduces the chances that requests that
use the new key will be categorized as abusive.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document registers a new authentication scheme, a registry for
parameters of that scheme, and a media type for push options.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. VAPID Authentication Scheme Registration</span>
This document registers the "vapid" authentication scheme in the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
established by [<a href="./rfc7235" title=""Hypertext Transfer Protocol (HTTP/1.1): Authentication"">RFC7235</a>].
Authentication Scheme Name: vapid
Pointer to specification text: <a href="#section-3">Section 3</a> of this document
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. VAPID Authentication Scheme Parameters</span>
This document creates a "VAPID Authentication Scheme Parameters"
registry for parameters to the "vapid" authentication scheme. These
parameters are defined for use in requests (in the Authorization
header field) and for challenges (in the WWW-Authenticate header
field). This registry is under the "Web Push Parameters" grouping.
The registry operates on the "Specification Required" policy
[<a href="./rfc8126" title="">RFC8126</a>].
<span class="grey">Thomson & Beverloo Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
Registrations MUST include the following information:
Parameter Name: A name for the parameter, which conforms to the
"token" grammar [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>]
Purpose (optional): Brief text identifying the purpose of the
parameter
Header Field(s): The header field(s) in which the parameter can be
used
Specification: A link to the specification that defines the format
and semantics of the parameter
This registry initially contains the following entries:
+-------------+------------------+---------------+------------------+
| Parameter | Purpose | Header | Specification |
| Name | | Field(s) | |
+-------------+------------------+---------------+------------------+
| t | JWT | Authorization | [<a href="./rfc8292">RFC8292</a>], |
| | authentication | | <a href="#section-3.1">Section 3.1</a> |
| | token | | |
| | | | |
| k | signing key | Authorization | [<a href="./rfc8292">RFC8292</a>], |
| | | | <a href="#section-3.2">Section 3.2</a> |
+-------------+------------------+---------------+------------------+
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. application/webpush-options+json Media Type Registration</span>
This document registers the "application/webpush-options+json" media
type in the "Media Types" registry following the process described in
[<a href="./rfc6838" title=""Media Type Specifications and Registration Procedures"">RFC6838</a>].
Type name: application
Subtype name: webpush-options+json
Required parameters: none
Optional parameters: none
Encoding considerations: binary (JSON is UTF-8-encoded text)
Security considerations: See [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>] for security considerations
specific to JSON.
<span class="grey">Thomson & Beverloo Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
Interoperability considerations: See [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>] for interoperability
considerations specific to JSON.
Published specification: [<a href="./rfc8292">RFC8292</a>]
Applications that use this media type: Web browsers, via the Web
Push protocol [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>]
Fragment identifier considerations: none
Additional information:
Deprecated alias names for this type: n/a
Magic number(s): n/a
File extension(s): .json
Macintosh file type code(s): TEXT
Person & email address to contact for further information: Martin
Thomson ([email protected])
Intended usage: LIMITED USE
Restrictions on usage: For use with the Web Push protocol [<a href="./rfc8030" title=""Generic Event Delivery Using HTTP Push"">RFC8030</a>]
Author: See "Authors' Addresses" section of [<a href="./rfc8292">RFC8292</a>].
Change controller: Internet Engineering Task Force
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-FIPS186">FIPS186</a>] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>,
DOI 10.17487/RFC2818, May 2000,
<<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>>.
<span class="grey">Thomson & Beverloo Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
[<a id="ref-RFC6068">RFC6068</a>] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", <a href="./rfc6068">RFC 6068</a>, DOI 10.17487/RFC6068, October 2010,
<<a href="https://www.rfc-editor.org/info/rfc6068">https://www.rfc-editor.org/info/rfc6068</a>>.
[<a id="ref-RFC6454">RFC6454</a>] Barth, A., "The Web Origin Concept", <a href="./rfc6454">RFC 6454</a>,
DOI 10.17487/RFC6454, December 2011,
<<a href="https://www.rfc-editor.org/info/rfc6454">https://www.rfc-editor.org/info/rfc6454</a>>.
[<a id="ref-RFC6838">RFC6838</a>] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>,
<a href="./rfc6838">RFC 6838</a>, DOI 10.17487/RFC6838, January 2013,
<<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>>.
[<a id="ref-RFC7159">RFC7159</a>] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", <a href="./rfc7159">RFC 7159</a>, DOI 10.17487/RFC7159, March
2014, <<a href="https://www.rfc-editor.org/info/rfc7159">https://www.rfc-editor.org/info/rfc7159</a>>.
[<a id="ref-RFC7230">RFC7230</a>] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
<a href="./rfc7230">RFC 7230</a>, DOI 10.17487/RFC7230, June 2014,
<<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>>.
[<a id="ref-RFC7231">RFC7231</a>] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", <a href="./rfc7231">RFC 7231</a>,
DOI 10.17487/RFC7231, June 2014,
<<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</a>>.
[<a id="ref-RFC7235">RFC7235</a>] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", <a href="./rfc7235">RFC 7235</a>,
DOI 10.17487/RFC7235, June 2014,
<<a href="https://www.rfc-editor.org/info/rfc7235">https://www.rfc-editor.org/info/rfc7235</a>>.
[<a id="ref-RFC7515">RFC7515</a>] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", <a href="./rfc7515">RFC 7515</a>, DOI 10.17487/RFC7515, May
2015, <<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>>.
[<a id="ref-RFC7518">RFC7518</a>] Jones, M., "JSON Web Algorithms (JWA)", <a href="./rfc7518">RFC 7518</a>,
DOI 10.17487/RFC7518, May 2015,
<<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>>.
[<a id="ref-RFC7519">RFC7519</a>] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", <a href="./rfc7519">RFC 7519</a>, DOI 10.17487/RFC7519, May 2015,
<<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>>.
[<a id="ref-RFC8030">RFC8030</a>] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", <a href="./rfc8030">RFC 8030</a>,
DOI 10.17487/RFC8030, December 2016,
<<a href="https://www.rfc-editor.org/info/rfc8030">https://www.rfc-editor.org/info/rfc8030</a>>.
<span class="grey">Thomson & Beverloo Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc8292">RFC 8292</a> VAPID for Web Push November 2017</span>
[<a id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8291">RFC8291</a>] Thomson, M., "Message Encryption for Web Push", <a href="./rfc8291">RFC 8291</a>,
DOI 10.17487/RFC8291, November 2017,
<<a href="https://www.rfc-editor.org/info/rfc8291">http://www.rfc-editor.org/info/rfc8291</a>>.
[<a id="ref-X9.62">X9.62</a>] ANSI, "Public Key Cryptography for the Financial Services
Industry: the Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 2005.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-API">API</a>] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", October 2017,
<<a href="https://www.w3.org/TR/push-api/">https://www.w3.org/TR/push-api/</a>>.
[<a id="ref-RFC7517">RFC7517</a>] Jones, M., "JSON Web Key (JWK)", <a href="./rfc7517">RFC 7517</a>,
DOI 10.17487/RFC7517, May 2015,
<<a href="https://www.rfc-editor.org/info/rfc7517">https://www.rfc-editor.org/info/rfc7517</a>>.
Acknowledgements
This document would have been much worse than it is if not for the
contributions of Benjamin Bangert, JR Conlin, Chris Karlof, Costin
Manolache, Adam Roach, and others.
Authors' Addresses
Martin Thomson
Mozilla
Email: [email protected]
Peter Beverloo
Google
Email: [email protected]
Thomson & Beverloo Standards Track [Page 14]
Annotations
Select text to annotate