< draft-ietf-webpush-vapid-02.txt   draft-ietf-webpush-vapid-03.txt >
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track P. Beverloo Intended status: Standards Track P. Beverloo
Expires: June 25, 2017 Google Expires: December 20, 2017 Google
December 22, 2016 June 18, 2017
Voluntary Application Server Identification for Web Push Voluntary Application Server Identification (VAPID) for Web Push
draft-ietf-webpush-vapid-02 draft-ietf-webpush-vapid-03
Abstract Abstract
An application server can voluntarily identify itself to a push An application server can use the method described to voluntarily
service using the described technique. This identification identify itself to a push service. This identification information
information can be used by the push service to attribute requests can be used by the push service to attribute requests that are made
that are made by the same application server to a single entity. by the same application server to a single entity. An application
This can used to reduce the secrecy for push subscription URLs by server can include additional information that the operator of a push
being able to restrict subscriptions to a specific application service can use to contact the operator of the application server.
server. An application server is further able to include additional This identification information can be used to restrict the use of a
information that the operator of a push service can use to contact push subscription a single application server.
the operator of the application server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 25, 2017. This Internet-Draft will expire on December 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3 1.1. Voluntary Identification . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Application Server Self-Identification . . . . . . . . . . . 4 2. Application Server Self-Identification . . . . . . . . . . . 4
2.1. Application Server Contact Information . . . . . . . . . 4 2.1. Application Server Contact Information . . . . . . . . . 4
2.2. Additional Claims . . . . . . . . . . . . . . . . . . . . 4 2.2. Additional Claims . . . . . . . . . . . . . . . . . . . . 4
2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Cryptographic Agility . . . . . . . . . . . . . . . . . . 5
2.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Vapid Authentication Scheme . . . . . . . . . . . . . . . . . 6 3. Vapid Authentication Scheme . . . . . . . . . . . . . . . . . 6
3.1. Token Parameter (t) . . . . . . . . . . . . . . . . . . . 6 3.1. Token Parameter (t) . . . . . . . . . . . . . . . . . . . 6
3.2. Public Key Parameter (k) . . . . . . . . . . . . . . . . 6 3.2. Public Key Parameter (k) . . . . . . . . . . . . . . . . 6
4. Subscription Restriction . . . . . . . . . . . . . . . . . . 7 4. Subscription Restriction . . . . . . . . . . . . . . . . . . 7
4.1. Creating a Restricted Push Subscription . . . . . . . . . 7 4.1. Creating a Restricted Push Subscription . . . . . . . . . 7
4.2. Using Restricted Subscriptions . . . . . . . . . . . . . 8 4.2. Using Restricted Subscriptions . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Vapid Authentication Scheme Parameters . . . . . . . . . 9 6.1. Vapid Authentication Scheme Registration . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Vapid Authentication Scheme Parameters . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.3. application/webpush-options+json Media Type Registration 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Web Push protocol [I-D.ietf-webpush-protocol] describes how an The Web Push protocol [RFC8030] describes how an application server
application server is able to request that a push service deliver a is able to request that a push service deliver a push message to a
push message to a user agent. user agent.
As a consequence of the expected deployment architecture, there is no As a consequence of the expected deployment architecture, there is no
basis for an application server to be known to a push service prior basis for an application server to be known to a push service prior
to requesting delivery of a push message. Requiring that the push to requesting delivery of a push message. Requiring that the push
service be able to authenticate application servers places an service be able to authenticate application servers places an
unwanted constraint on the interactions between user agents and unwanted constraint on the interactions between user agents and
application servers, who are the ultimate users of a push service. application servers, who are the ultimate users of a push service.
That constraint would also degrade the privacy-preserving properties That constraint would also degrade the privacy-preserving properties
the protocol provides. For these reasons, the protocol provides. For these reasons, [RFC8030] does not define
[I-D.ietf-webpush-protocol] does not define a mandatory system for a mandatory system for authentication of application servers.
authentication of application servers.
An unfortunate consequence of this design is that a push service is An unfortunate consequence of this design is that a push service is
exposed to a greater risk of denial of service attack. While exposed to a greater risk of denial of service attack. While
requests from application servers can be indirectly attributed to requests from application servers can be indirectly attributed to
user agents, this is not always efficient or even sufficient. user agents, this is not always efficient or even sufficient.
Providing more information about the application server directly to a Providing more information about the application server directly to a
push service allows the push service to better distinguish between push service allows the push service to better distinguish between
legitimate and bogus requests. legitimate and bogus requests.
Additionally, this design also relies on endpoint secrecy as any Additionally, this design also relies on endpoint secrecy as any
skipping to change at page 4, line 7 skipping to change at page 4, line 7
whether to discard a push message. whether to discard a push message.
1.2. Notational Conventions 1.2. Notational Conventions
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document. It's not shouting, when they are capitalized, they have document. It's not shouting, when they are capitalized, they have
the special meaning described in [RFC2119]. the special meaning described in [RFC2119].
The terms "push message", "push service", "push subscription", The terms "push message", "push service", "push subscription",
"application server", and "user agent" are used as defined in "application server", and "user agent" are used as defined in
[I-D.ietf-webpush-protocol]. [RFC8030].
2. Application Server Self-Identification 2. Application Server Self-Identification
Application servers that wish to self-identify generate and maintain Application servers that wish to self-identify generate and maintain
a signing key pair. This key pair MUST be usable with elliptic curve a signing key pair. This key pair MUST be usable with elliptic curve
digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of digital signature (ECDSA) over the P-256 curve [FIPS186]. Use of
this key when sending push messages establishes an identity for the this key when sending push messages establishes an identity for the
application server that is consistent across multiple messages. application server that is consistent across multiple messages.
When requesting delivery of a push message, the application includes When requesting delivery of a push message, the application includes
a JSON Web Token (JWT) [RFC7519], signed using its signing key. The a JSON Web Token (JWT) [RFC7519], signed using its signing key. The
token includes a number of claims as follows: token includes a number of claims as follows:
o An "aud" (Audience) claim in the token MUST include the unicode o An "aud" (Audience) claim in the token MUST include the unicode
serialization of the origin (Section 6.1 of [RFC6454]) of the push serialization of the origin (Section 6.1 of [RFC6454]) of the push
resource URL. This binds the token to a specific push service. resource URL. This binds the token to a specific push service.
This ensures that the token is reusable for all push resource URLs This ensures that the token is reusable for all push resource URLs
that share the same origin. that share the same origin.
o An "exp" (Expiry) claim MUST be included with the time after which o An "exp" (Expiry) claim MUST be included with the time after which
the token expires. This limits the time that a token over which a the token expires. This limits the time over which a token is
token is valid. An "exp" claim MUST NOT be more than 24 hours valid. An "exp" claim MUST NOT be more than 24 hours from the
from the time of the request. time of the request.
This JWT is included in an Authorization header field, using an auth- This JWT is included in an Authorization header field, using an auth-
scheme of "vapid". A push service MAY reject a request with a 403 scheme of "vapid". A push service MAY reject a request with a 403
(Forbidden) status code [RFC7235] if the JWT signature or its claims (Forbidden) status code [RFC7235] if the JWT signature or its claims
are invalid. are invalid.
The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature The JWT MUST use a JSON Web Signature (JWS) [RFC7515]. The signature
MUST use ECDSA on the NIST P-256 curve [FIPS186] which is identified MUST use ECDSA on the NIST P-256 curve [FIPS186] which is identified
as "ES256" [RFC7518]. as "ES256" [RFC7518].
skipping to change at page 5, line 7 skipping to change at page 5, line 7
include a contact URI for the application server as either a include a contact URI for the application server as either a
"mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI. "mailto:" (email) [RFC6068] or an "https:" [RFC2818] URI.
2.2. Additional Claims 2.2. Additional Claims
An application server MAY include additional claims using public or An application server MAY include additional claims using public or
private names (see Sections 4.2 and 4.3 of [RFC7519]). Since the JWT private names (see Sections 4.2 and 4.3 of [RFC7519]). Since the JWT
is in a header field, the size of additional claims SHOULD be kept as is in a header field, the size of additional claims SHOULD be kept as
small as possible. small as possible.
2.3. Example 2.3. Cryptographic Agility
The "vapid" authentication scheme 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 scheme can be used rather than defining new parameter
negotiation mechanisms.
2.4. Example
An application server requests the delivery of a push message as An application server requests the delivery of a push message as
described in [I-D.ietf-webpush-protocol]. If the application server described in [RFC8030]. If the application server wishes to self-
wishes to self-identify, it includes an Authorization header field identify, it includes an Authorization header field with credentials
with credentials that use the "vapid" authentication scheme that use the "vapid" authentication scheme (Section 3).
(Section 3).
POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net Host: push.example.net
TTL: 30 TTL: 30
Content-Length: 136 Content-Length: 136
Content-Encoding: aes128gcm Content-Encoding: aes128gcm
Authorization: vapid Authorization: vapid
t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3 t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
skipping to change at page 5, line 40 skipping to change at page 5, line 48
Figure 1: Requesting Push Message Delivery with JWT Figure 1: Requesting Push Message Delivery with JWT
Note that the example header fields in this document include extra Note that the example header fields in this document include extra
line wrapping to meet formatting constraints. line wrapping to meet formatting constraints.
The "t" parameter of the Authorization header field contains a JWT; The "t" parameter of the Authorization header field contains a JWT;
the "k" parameter includes the base64url-encoded key that signed that the "k" parameter includes the base64url-encoded key that signed that
token. The JWT input values and the JWK [RFC7517] corresponding to token. The JWT input values and the JWK [RFC7517] corresponding to
the signing key are shown in Figure 2 with additional whitespace the signing key are shown in Figure 2 with additional whitespace
added for readability purposes. This JWT would be valid until added for readability purposes. This JWT would be valid until
2016-01-21T01:53:25Z [RFC3339]. 2016-01-23T04:36:08Z [RFC3339].
JWT header = { "typ": "JWT", "alg": "ES256" } JWT header = { "typ": "JWT", "alg": "ES256" }
JWT body = { "aud": "https://push.example.net", JWT body = { "aud": "https://push.example.net",
"exp": 1453341205, "exp": 1453523768,
"sub": "mailto:push@example.com" } "sub": "mailto:push@example.com" }
JWK = { "crv":"P-256", JWK = { "crv":"P-256",
"kty":"EC", "kty":"EC",
"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc", "x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" } "y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
Figure 2: Decoded Example Values Figure 2: Decoded Example Values
3. Vapid Authentication Scheme 3. Vapid Authentication Scheme
skipping to change at page 6, line 27 skipping to change at page 6, line 38
additional information from a server. Therefore, a challenge for additional information from a server. Therefore, a challenge for
this authentication scheme MUST NOT be sent in a WWW-Authenticate this authentication scheme MUST NOT be sent in a WWW-Authenticate
header field. header field.
Two parameters are defined for this authentication scheme: "t" and Two parameters are defined for this authentication scheme: "t" and
"k". All unknown or unsupported parameters to "vapid" authentication "k". All unknown or unsupported parameters to "vapid" authentication
credentials MUST be ignored. The "realm" parameter is ignored for credentials MUST be ignored. The "realm" parameter is ignored for
this authentication scheme. this authentication scheme.
This authentication scheme is intended for use by an application This authentication scheme is intended for use by an application
server when using the Web Push protocol [I-D.ietf-webpush-protocol], server when using the Web Push protocol [RFC8030], but it could be
but it could be used in other contexts if applicable. used in other contexts if applicable.
3.1. Token Parameter (t) 3.1. Token Parameter (t)
The "t" parameter of the "vapid" authentication scheme carries a JWT The "t" parameter of the "vapid" authentication scheme carries a JWT
as described in Section 2. as described in Section 2.
3.2. Public Key Parameter (k) 3.2. Public Key Parameter (k)
In order for the push service to be able to validate the JWT, it 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" needs to learn the public key of the application server. A "k"
skipping to change at page 7, line 37 skipping to change at page 7, line 47
The user agent includes the public key of the application server when The user agent includes the public key of the application server when
requesting the creation of a push subscription. This restricts use requesting the creation of a push subscription. This restricts use
of the resulting subscription to application servers that are able to of the resulting subscription to application servers that are able to
provide proof of possession for the corresponding private key. provide proof of possession for the corresponding private key.
The public key is then added to the request to create a push The public key is then added to the request to create a push
subscription. The push subscription request is extended to include a subscription. The push subscription request is extended to include a
body. The body of the request is a JSON object as described in body. The body of the request is a JSON object as described in
[RFC7159]. A "vapid" member is added to this JSON object, containing [RFC7159]. A "vapid" member is added to this JSON object, containing
the public key on the P-256 curve, encoded in the uncompressed form the public key on the P-256 curve, encoded in the uncompressed form
[X9.62] and base64url encoded [RFC7515]. The MIME media type of the [X9.62] and base64url encoded [RFC7515]. The media type of the body
body is set to "application/json". is set to "application/webpush-options+json" (see Section 6.3 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 The example in Figure 3 shows a restriction to the key used in
Figure 1. Extra whitespace is added to to meet formatting Figure 1. Extra whitespace is added to meet formatting constraints.
constraints.
POST /subscribe/ HTTP/1.1 POST /subscribe/ HTTP/1.1
Host: push.example.net Host: push.example.net
Content-Type: application/json;charset=utf-8 Content-Type: application/webpush-optjons+json;charset=utf-8
Content-Length: 104 Content-Length: 104
{ "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH { "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" } F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
Figure 3: Example Subscribe Request Figure 3: Example Subscribe Request
An application might use the Web Push API [API] to provide the user An application might use the Web Push API [API] to provide the user
agent with a public key. agent with a public key.
skipping to change at page 8, line 38 skipping to change at page 9, line 5
o the origin of the push resource is not included in the "aud" o the origin of the push resource is not included in the "aud"
(Audience) claim, or (Audience) claim, or
o the public key used to sign the JWT doesn't match the one that was o the public key used to sign the JWT doesn't match the one that was
included in the creation of the push subscription. included in the creation of the push subscription.
A push service MUST NOT forward the JWT or public key to the user A push service MUST NOT forward the JWT or public key to the user
agent when delivering the push message. agent when delivering the push message.
An application server that needs to replace its signing key needs to
create a new subscription that is restricted to the updated key.
Application servers need to remember the key that was used when
creating a given subscription.
5. Security Considerations 5. Security Considerations
This authentication scheme is vulnerable to replay attacks if an This authentication scheme is vulnerable to replay attacks if an
attacker can acquire a valid JWT. Applying narrow limits to the attacker can acquire a valid JWT. Applying narrow limits to the
period over which a replayable token can be reused limits 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 potential value of a stolen token to an attacker and can increase the
difficulty of stealing a token. difficulty of stealing a token.
An application server might offer falsified contact information. A An application server might offer falsified contact information. A
push service operator therefore cannot use the presence of push service operator therefore cannot use the presence of
unvalidated contact information as input to any security-critical unvalidated contact information as input to any security-critical
decision-making process. decision-making process.
Validation of a signature on the JWT requires a non-trivial amount of Validation of a signature on the JWT requires a non-trivial amount of
computation. For something that might be used to identify legitimate computation. For something that might be used to identify legitimate
requests under denial of service attack conditions, this is not requests under denial of service attack conditions, this is not
ideal. Application servers are therefore encouraged to reuse tokens, ideal. Application servers are therefore encouraged to reuse tokens,
which permits the push service to cache the results of signature which permits the push service to cache the results of signature
validation. validation.
An application server that changes its signing key breaks linkability
between push messages that it sends under the 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.
6. IANA Considerations 6. IANA Considerations
This document registers a new authentication scheme, a registry for
parameters of that scheme, and media type for push options.
6.1. Vapid Authentication Scheme Registration
This document registers the "vapid" authentication scheme in the This document registers the "vapid" authentication scheme in the
"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
established in [RFC7235]. established in [RFC7235].
Authentication Scheme Name: vapid Authentication Scheme Name: vapid
Pointer to specification text: Section 3 of this document Pointer to specification text: Section 3 of this document
Notes: This scheme is origin-server only and does not define a Notes: This scheme is origin-server only and does not define a
challenge. challenge.
6.1. Vapid Authentication Scheme Parameters 6.2. Vapid Authentication Scheme Parameters
This creates a "Vapid Authentication Scheme Parameters" registry for This document creates a "Vapid Authentication Scheme Parameters"
parameters to the "vapid" authentication scheme. This registry is registry for parameters to the "vapid" authentication scheme. This
under the "WebPush Parameters" grouping. The registry operates on registry is under the "WebPush Parameters" grouping. The registry
the "Specification Required" policy [RFC5226]. operates on the "Specification Required" policy [RFC5226].
Registrations MUST include the following information: Registrations MUST include the following information:
Parameter Name: A name for the parameter, which conforms to the Parameter Name: A name for the parameter, which conforms to the
"token" grammar [RFC7230] "token" grammar [RFC7230]
Purpose (optional): A brief identifying the purpose of the Purpose (optional): A brief identifying the purpose of the
parameter. parameter.
Specification: A link to the specification that defines the format Specification: A link to the specification that defines the format
skipping to change at page 9, line 49 skipping to change at page 10, line 34
This registry initially contains the following entries: This registry initially contains the following entries:
+---------------+-------------------------+-------------------------+ +---------------+-------------------------+-------------------------+
| Parameter | Purpose | Specification | | Parameter | Purpose | Specification |
| Name | | | | Name | | |
+---------------+-------------------------+-------------------------+ +---------------+-------------------------+-------------------------+
| t | JWT authentication | [[RFC-to-be]], Section | | t | JWT authentication | [[RFC-to-be]], Section |
| | token | 3.1 | | | token | 3.1 |
| | | | | | | |
| k | ECDSA signing key | [[RFC-to-be]], Section | | k | signing key | [[RFC-to-be]], Section |
| | | 3.2 | | | | 3.2 |
+---------------+-------------------------+-------------------------+ +---------------+-------------------------+-------------------------+
6.3. application/webpush-options+json Media Type Registration
This document registers the "application/webpush-options+json" media
type in the "Media Types" registry following the process described in
[RFC6838].
Type name: application
Subtype name: webpush-options+json
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary
Security considerations: See [RFC7159] for security considerations
specific to JSON.
Interoperability considerations: See [RFC7159] for interoperability
considerations specific to JSON.
Published specification: This document.
Applications that use this media type: Web browsers, via the Web
Push Protocol [RFC8030].
Fragment identifier considerations: None, see [RFC7159].
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 (martin.thomson@gmail.com)
Intended usage: LIMITED USE
Restrictions on usage: For use with the Web Push Protocol [RFC8030].
Author: See "Authors' Addresses" section of this document.
Change controller: Internet Engineering Task Force
7. Acknowledgements 7. Acknowledgements
This document would have been much worse than it currently is if not This document would have been much worse than it currently is if not
for the contributions of Benjamin Bangert, JR Conlin, Chris Karlof, for the contributions of Benjamin Bangert, JR Conlin, Chris Karlof,
Costin Manolache, and others. Costin Manolache, Adam Roach, and others.
8. References 8. References
8.1. Normative References 8.1. Normative References
[FIPS186] National Institute of Standards and Technology (NIST), [FIPS186] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", NIST PUB 186-4 , July "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
2013. 2013.
[I-D.ietf-webpush-protocol]
Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
Delivery Using HTTP Push", draft-ietf-webpush-protocol-12
(work in progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 10, line 46 skipping to change at page 12, line 32
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<http://www.rfc-editor.org/info/rfc6068>. <http://www.rfc-editor.org/info/rfc6068>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>. <http://www.rfc-editor.org/info/rfc6454>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 11, line 27 skipping to change at page 13, line 17
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>. <http://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016,
<http://www.rfc-editor.org/info/rfc8030>.
[X9.62] ANSI, "Public Key Cryptography For The Financial Services [X9.62] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62 , 1998. (ECDSA)", ANSI X9.62 , 1998.
8.2. Informative References 8.2. Informative References
[API] van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015, [API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan,
B., and E. Fullea, "Push API", May 2017,
<https://w3c.github.io/push-api/>. <https://w3c.github.io/push-api/>.
[I-D.ietf-webpush-encryption] [I-D.ietf-webpush-encryption]
Thomson, M., "Message Encryption for Web Push", draft- Thomson, M., "Message Encryption for Web Push", draft-
ietf-webpush-encryption-06 (work in progress), October ietf-webpush-encryption-08 (work in progress), February
2016. 2017.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>. <http://www.rfc-editor.org/info/rfc7517>.
Authors' Addresses Authors' Addresses
 End of changes. 35 change blocks. 
64 lines changed or deleted 148 lines changed or added

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