Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8292 Mozilla
Category: Standards Track P. Beverloo
ISSN: 2070-1721 Google
November 2017
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8292 Mozilla
Category: Standards Track P. Beverloo
ISSN: 2070-1721 Google
November 2017
Voluntary Application Server Identification (VAPID) for Web Push
Web推送的自愿应用程序服务器标识（VAPID）
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.
应用程序服务器可以使用本文档中描述的自愿应用程序服务器标识（VAPID）方法自愿向推送服务标识自己。“vapid”身份验证方案允许客户端将其身份包含在已签名令牌中，并发出请求。推送服务可以使用该签名将同一应用服务器向单个实体发出的请求属性化。标识信息允许推送服务的操作员联系应用服务器的操作员。签名可用于将推送消息订阅的使用限制到单个应用程序服务器。
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 Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8292.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8292.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Voluntary Identification ...................................3
1.2. Notational Conventions .....................................4
2. Application Server Self-Identification ..........................4
2.1. Application Server Contact Information .....................5
2.2. Additional Claims ..........................................5
2.3. Cryptographic Agility ......................................5
2.4. Example ....................................................5
3. VAPID Authentication Scheme .....................................6
3.1. Token Parameter ("t") ......................................7
3.2. Public Key Parameter ("k") .................................7
4. Subscription Restriction ........................................7
4.1. Creating a Restricted Push Message Subscription ............8
4.2. Using Restricted Subscriptions .............................9
5. Security Considerations .........................................9
6. IANA Considerations ............................................10
6.1. VAPID Authentication Scheme Registration ..................10
6.2. VAPID Authentication Scheme Parameters ....................10
6.3. application/webpush-options+json Media Type Registration ..11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................14
1. Introduction ....................................................3
1.1. Voluntary Identification ...................................3
1.2. Notational Conventions .....................................4
2. Application Server Self-Identification ..........................4
2.1. Application Server Contact Information .....................5
2.2. Additional Claims ..........................................5
2.3. Cryptographic Agility ......................................5
2.4. Example ....................................................5
3. VAPID Authentication Scheme .....................................6
3.1. Token Parameter ("t") ......................................7
3.2. Public Key Parameter ("k") .................................7
4. Subscription Restriction ........................................7
4.1. Creating a Restricted Push Message Subscription ............8
4.2. Using Restricted Subscriptions .............................9
5. Security Considerations .........................................9
6. IANA Considerations ............................................10
6.1. VAPID Authentication Scheme Registration ..................10
6.2. VAPID Authentication Scheme Parameters ....................10
6.3. application/webpush-options+json Media Type Registration ..11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................14
The Web Push protocol [RFC8030] describes how an application server is able to request that a push service deliver a push message to a user agent.
Web推送协议[RFC8030]描述了应用服务器如何请求推送服务向用户代理发送推送消息。
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, [RFC8030] does not define a mandatory system for authentication of application servers.
由于预期的部署体系结构，推送服务在请求传递推送消息之前不知道应用程序服务器。要求推送服务能够对应用程序服务器进行身份验证会对用户代理和应用程序服务器（推送服务的最终用户）之间的交互造成不必要的限制。该约束还将降低协议提供的隐私保护属性。由于这些原因，[RFC8030]没有定义应用服务器身份验证的强制系统。
An unfortunate consequence of the design of [RFC8030] 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.
[RFC8030]设计的一个不幸后果是推送服务面临更大的拒绝服务攻击风险。虽然来自应用程序服务器的请求可以间接归因于用户代理，但这并不总是有效的，甚至不够。直接向推送服务提供有关应用程序服务器的更多信息可以使推送服务更好地区分合法请求和虚假请求。
Additionally, the design of [RFC8030] 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.
此外，[RFC8030]的设计依赖于维护推送消息订阅URI的保密性。拥有推送消息订阅URI的任何应用程序服务器都能够向用户代理发送消息。如果订阅的使用可以限制在单个应用程序服务器上，这将减少未授权方学习推送消息订阅URI的影响。
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.
推送服务可以使用一致的标识来建立应用程序服务器的行为期望。与既定规范的重大偏差可用于触发异常处理程序。
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.
即使在没有可用的联系信息的情况下，在选择是否放弃推送消息时，具有良好声誉的应用程序服务器也可能优先于身份不明的应用程序服务器。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The terms "push message", "push service", "push message subscription", "application server", and "user agent" are used as defined in [RFC8030].
术语“推送消息”、“推送服务”、“推送消息订阅”、“应用服务器”和“用户代理”的使用如[RFC8030]中所定义。
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 [FIPS186]. Use of this key when sending push messages establishes an identity for the application server that is consistent across multiple messages.
希望自行识别的应用程序服务器生成并维护签名密钥对。此密钥对必须可用于P-256曲线上的椭圆曲线数字签名算法（ECDSA）[FIPS186]。发送推送消息时使用此键可为应用程序服务器建立跨多条消息一致的标识。
When requesting delivery of a push message, the application includes a JSON Web Token (JWT) [RFC7519], signed using its signing key. The token includes a number of claims as follows:
当请求传递推送消息时，应用程序包含一个JSON Web令牌（JWT）[RFC7519]，使用其签名密钥进行签名。该令牌包括如下多个权利要求：
o An "aud" (Audience) claim in the token MUST include the Unicode serialization of the origin (Section 6.1 of [RFC6454]) 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 令牌中的“aud”（受众）声明必须包括推送资源URL的源（RFC6454的第6.1节）的Unicode序列化。这将令牌绑定到特定的推送服务，并确保令牌可用于共享同一来源的所有推送资源URL。
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
o 令牌过期的时间必须包括“exp”（到期）声明。这限制了令牌有效的时间。“exp”索赔不得超过24小时
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.
请求的时间。将这一时间限制在24小时内可以平衡重用需求与有效代币被盗的潜在成本和可能性。
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 [RFC7231] if the JWT signature or its claims are invalid. A push service MUST NOT use information from an invalid token.
该JWT使用“vapid”身份验证方案包含在授权标头字段中。如果JWT签名或其声明无效，推送服务可能会拒绝状态代码为403（禁止）的请求[RFC7231]。推送服务不得使用来自无效令牌的信息。
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 as "ES256" [RFC7518].
JWT必须使用JSON Web签名（JWS）[RFC7515]。签名必须在NIST P-256曲线[FIPS186]上使用ECDSA，该曲线标识为“ES256”[RFC7518]。
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) [RFC6068] or an "https:" [RFC2818] URI.
如果应用服务器希望提供联系详细信息，则可以在JWT中包含“子”（主题）声明。“sub”声明应该包括应用服务器的联系人URI，作为“mailto:”（email）[RFC6068]或“https:”[RFC2818]URI。
An application server MAY include additional claims using public or 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 small as possible.
应用服务器可能包括使用公共或私有名称的附加声明（参见[RFC7519]第4.2节和第4.3节）。由于JWT位于标题字段中，因此附加索赔的大小应尽可能小。
The "vapid" HTTP authentication scheme (Section 3) 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.
“vapid”HTTP认证方案（第3节）用于识别本文档中定义的JWT的特定概要文件。需要使用不同的身份验证方案来更新签名算法或其他参数。这确保了可以使用协商身份验证方案的现有机制，而不是定义新的参数协商机制。
An application server requests the delivery of a push message as described in [RFC8030]. If the application server wishes to self-identify, it includes an Authorization header field with credentials that use the "vapid" authentication scheme.
应用服务器请求传递推送消息，如[RFC8030]中所述。如果应用程序服务器希望进行自我识别，它将包括一个授权标头字段，其中包含使用“vapid”身份验证方案的凭据。
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 }
POST/p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1主机：push.example.net TTL:30内容长度：136内容编码：aes128gcm授权：vapid t=EYJ0EXAIIIJKV1QIGCIOIJFUZI1NIJ9.eyJhdWQiOiJodHRwczovL3 B1C2GUZHHBXBSS5UZXQILCJLEOJJOE0NTM1MJM3NJIN1YI6IM1HA WBZPWNOQ4GV4Y1WBUY2PTUY9LGKMLMUCGSK2RPIUFNK9OJFWDXB1JERTMYSAZNJVW2L9OKSHZVOD1OA，k=BA1HXZYI1RUM1B5WJXSN7NGXASZW2U61M164I3RAIXHF6YK5H4SDYIC dR uU RCPCfA5aq9ojSwk5Y2EmClBPs{加密推送消息}
Figure 1: Requesting Push Message Delivery with JWT
图1：使用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) [RFC7517] 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.
授权头字段的“t”参数包含一个JWT；“k”参数包括签署该令牌的base64url编码密钥。图2中显示了与签名密钥相对应的JWT输入值和JSON Web密钥（JWK）[RFC7517]，并添加了额外的空白以便于阅读。本JWT有效期至2016-01-23T04:36:08Z。
JWT header = { "typ": "JWT", "alg": "ES256" }
JWT body = { "aud": "https://push.example.net",
"exp": 1453523768,
"sub": "mailto:push@example.com" }
JWK = { "crv":"P-256",
"kty":"EC",
"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
JWT header = { "typ": "JWT", "alg": "ES256" }
JWT body = { "aud": "https://push.example.net",
"exp": 1453523768,
"sub": "mailto:push@example.com" }
JWK = { "crv":"P-256",
"kty":"EC",
"x":"DUfHPKLVFQzVvnCPGyfucbECzPDa7rWbXriLcysAjEc",
"y":"F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
Figure 2: Decoded Example Values
图2：解码的示例值
This document defines a new HTTP authentication scheme [RFC7235] named "vapid". This authentication scheme carries a signed JWT, as described in Section 2, plus the key that signed that JWT.
本文档定义了一个名为“vapid”的新HTTP身份验证方案[RFC7235]。如第2节所述，此身份验证方案携带一个签名的JWT，以及签名该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.
此身份验证方案仅用于源服务器身份验证。因此，此身份验证方案不得与代理身份验证或代理授权标头字段一起使用。
The challenge for the "vapid" authentication scheme contains only the "auth-scheme" production. No parameters are currently defined.
“vapid”身份验证方案的挑战仅包含“auth scheme”产品。当前未定义任何参数。
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.
此身份验证方案定义了两个参数：“t”和“k”。必须忽略“vapid”身份验证凭据的所有未知或不受支持的参数。此身份验证方案忽略“realm”参数。
This authentication scheme is intended for use by an application server when using the Web Push protocol [RFC8030].
此身份验证方案旨在供应用程序服务器在使用Web推送协议[RFC8030]时使用。
The "t" parameter of the "vapid" authentication scheme carries a JWT as described in Section 2.
“vapid”认证方案的“t”参数携带一个JWT，如第2节所述。
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.
为了使推送服务能够验证JWT，它需要了解应用服务器的公钥。为“vapid”身份验证方案定义了一个“k”参数来携带此信息。
The "k" parameter includes an ECDSA public key [FIPS186] in uncompressed form [X9.62] that is encoded using base64url encoding [RFC7515].
“k”参数包括未压缩形式[X9.62]的ECDSA公钥[FIPS186]，该公钥使用base64url编码[RFC7515]进行编码。
Note: X9.62 encoding is used over JWK [RFC7517] 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.
注：在JWK[RFC7517]上使用X9.62编码有两个原因。JWK没有规范形式，因此X9.62编码使推送服务更容易处理来自不同来源的密钥的比较。其次，X9.62编码也相当小。
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 [RFC8291] 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.
一些椭圆曲线实现允许使用相同的P-256密钥进行签名和密钥交换。应用程序服务器必须为密钥交换[RFC8291]选择不同的私钥，并对身份验证令牌进行签名。尽管推送服务没有义务为每个推送消息检查任何一个参数，但推送服务应该拒绝具有与这些参数相同值且状态代码为400（错误请求）的推送消息。
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.
应用服务器的公钥用作服务器的稳定标识符。此密钥可用于将推送消息订阅限制到特定的应用程序服务器。
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.
订阅限制通过要求应用服务器在请求传递推送消息时提供签名令牌来减少对端点保密性的依赖。这为防止推送消息订阅的详细信息泄漏提供了额外的保护级别。
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.
希望创建受限订阅的用户代理在请求创建推送消息订阅时包括应用程序服务器的公钥。这将限制对能够提供由相应私钥签名的有效JWT的应用程序服务器使用生成的订阅。
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 [RFC7159]. 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 [X9.62] and base64url encoded [RFC7515]. The media type of the body is set to "application/ webpush-options+json" (see Section 6.3 for registration of this media type).
然后，用户代理将公钥添加到请求中，以创建推送消息订阅。推送消息订阅请求已扩展为包含正文。请求的主体是一个JSON对象，如[RFC7159]中所述。用户代理向这个JSON对象添加一个“vapid”成员，该对象在P-256曲线上包含一个公钥，以未压缩格式[X9.62]编码，以base64url编码[RFC7515]。正文的媒体类型设置为“应用程序/webpush选项+json”（有关此媒体类型的注册，请参阅第6.3节）。
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.
推送服务必须忽略使用不同媒体类型的请求主体。对于“application/webpush options+json”媒体类型，推送服务必须忽略此对象上它不理解的任何成员。
The example in Figure 3 shows a restriction to the key used in Figure 1. Extra whitespace is added to meet formatting constraints.
图3中的示例显示了对图1中使用的键的限制。添加额外的空白以满足格式限制。
POST /subscribe/ HTTP/1.1
Host: push.example.net
Content-Type: application/webpush-options+json
Content-Length: 104
{ "vapid": "BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxH
F6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs" }
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
图3：订阅请求示例
An application might use the Push API [API] to provide the user agent with a public key.
应用程序可以使用推送API[API]向用户代理提供公钥。
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.
当推送消息订阅仅限于应用程序服务器时，推送消息传递请求必须包括一个由私钥签名的JWT，该私钥与创建订阅时使用的公钥相对应。
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.
推送服务必须拒绝发送到受限推送消息订阅的消息，如果该消息不包含“无意义”身份验证或无效的“无意义”身份验证。如果没有身份验证，可能会使用401（未经授权）状态代码；如果身份验证无效，则可能会使用403（禁止）状态代码。
"vapid" authentication is invalid if:
如果出现以下情况，“无趣”身份验证无效：
o either the authentication token or public key is not included in the request,
o 请求中不包括身份验证令牌或公钥，
o the signature on the JWT cannot be successfully verified using the included public key,
o 无法使用包含的公钥成功验证JWT上的签名，
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 当前时间晚于“exp”（到期）索赔中确定的时间，或超过到期时间前24小时，
o the origin of the push resource is not included in the "aud" (Audience) claim, or
o 推送资源的来源不包括在“aud”（受众）声明中，或者
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.
o 用于签署JWT的公钥与创建推送消息订阅时包含的公钥不匹配。
A push service MUST NOT forward the JWT or public key to the user agent when delivering the push message.
推送服务在传递推送消息时不得将JWT或公钥转发给用户代理。
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.
需要替换其签名密钥的应用程序服务器需要请求用户代理创建新的订阅，该订阅仅限于更新的密钥。应用服务器需要记住请求创建订阅时使用的密钥。
This authentication scheme is vulnerable to replay attacks if an attacker can acquire a valid JWT. Sending requests using HTTPS as required by [RFC8030] 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.
如果攻击者可以获取有效的JWT，则此身份验证方案容易受到重播攻击。按照[RFC8030]的要求使用HTTPS发送请求可提供机密性。此外，对可重复使用令牌的时间段应用狭窄限制会限制攻击者窃取令牌的潜在价值，并会增加窃取令牌的难度。
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.
应用服务器可能提供伪造的联系信息。应用程序服务器声明其电子邮件地址或联系人URI，而没有任何证据支持该声明。推送服务运营商不能将未经验证的联系信息作为任何安全关键决策过程的输入。
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.
JWT上签名的验证需要大量的计算。对于可能用于在拒绝服务攻击条件下识别合法请求的内容，这并不理想。因此，鼓励应用服务器重用令牌，这允许推送服务缓存签名验证的结果。
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.
更改其签名密钥的应用程序服务器会断开它在不同密钥下发送的推送消息之间的链接。依赖于应用服务器一致身份的推送服务可能会对使用新密钥发出的请求进行不同的分类。逐步迁移到新的签名密钥可以减少使用新密钥的请求被归类为滥用的可能性。
This document registers a new authentication scheme, a registry for parameters of that scheme, and a media type for push options.
此文档注册了一个新的身份验证方案、该方案参数的注册表以及推送选项的媒体类型。
This document registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established by [RFC7235].
本文件在[RFC7235]建立的“超文本传输协议（HTTP）认证方案注册表”中注册“vapid”认证方案。
Authentication Scheme Name: vapid
身份验证方案名称：vapid
Pointer to specification text: Section 3 of this document
规范文本指针：本文件第3节
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 [RFC8126].
本文档为“VAPID”身份验证方案的参数创建“VAPID身份验证方案参数”注册表。这些参数定义用于请求（在授权标头字段中）和质询（在WWW Authenticate标头字段中）。此注册表位于“Web推送参数”分组下。注册表按照“所需规范”策略[RFC8126]运行。
Registrations MUST include the following information:
注册必须包括以下信息：
Parameter Name: A name for the parameter, which conforms to the "token" grammar [RFC7230]
参数名称：参数的名称，符合“令牌”语法[RFC7230]
Purpose (optional): Brief text identifying the purpose of the parameter
用途（可选）：标识参数用途的简短文本
Header Field(s): The header field(s) in which the parameter can be used
Header字段：可以使用参数的Header字段
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 | [RFC8292], |
| | authentication | | Section 3.1 |
| | token | | |
| | | | |
| k | signing key | Authorization | [RFC8292], |
| | | | Section 3.2 |
+-------------+------------------+---------------+------------------+
+-------------+------------------+---------------+------------------+
| Parameter | Purpose | Header | Specification |
| Name | | Field(s) | |
+-------------+------------------+---------------+------------------+
| t | JWT | Authorization | [RFC8292], |
| | authentication | | Section 3.1 |
| | token | | |
| | | | |
| k | signing key | Authorization | [RFC8292], |
| | | | Section 3.2 |
+-------------+------------------+---------------+------------------+
This document registers the "application/webpush-options+json" media type in the "Media Types" registry following the process described in [RFC6838].
本文档按照[RFC6838]中描述的过程，在“媒体类型”注册表中注册“应用程序/webpush选项+json”媒体类型。
Type name: application
类型名称：应用程序
Subtype name: webpush-options+json
子类型名称：webpush选项+json
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: binary (JSON is UTF-8-encoded text)
编码注意事项：二进制（JSON是UTF-8编码的文本）
Security considerations: See [RFC7159] for security considerations specific to JSON.
安全注意事项：有关JSON特有的安全注意事项，请参见[RFC7159]。
Interoperability considerations: See [RFC7159] for interoperability considerations specific to JSON.
互操作性注意事项：有关JSON特有的互操作性注意事项，请参见[RFC7159]。
Published specification: [RFC8292]
已发布规范：[RFC8292]
Applications that use this media type: Web browsers, via the Web Push protocol [RFC8030]
使用此媒体类型的应用程序：通过Web推送协议[RFC8030]的Web浏览器
Fragment identifier considerations: none
片段标识符注意事项：无
Additional information:
其他信息：
Deprecated alias names for this type: n/a
此类型的已弃用别名：不适用
Magic number(s): n/a
Magic number(s): n/a
File extension(s): .json
文件扩展名：.json
Macintosh file type code(s): TEXT
Macintosh文件类型代码：文本
Person & email address to contact for further information: Martin Thomson (martin.thomson@gmail.com)
联系人和电子邮件地址，以获取更多信息：Martin Thomson（Martin。thomson@gmail.com)
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: For use with the Web Push protocol [RFC8030]
使用限制：用于Web推送协议[RFC8030]
Author: See "Authors' Addresses" section of [RFC8292].
作者：参见[RFC8292]的“作者地址”一节。
Change controller: Internet Engineering Task Force
变更控制员：互联网工程特别工作组
[FIPS186] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013.
[FIPS186]国家标准与技术研究所（NIST），“数字签名标准（DSS）”，FIPS PUB 186-4，DOI 10.6028/NIST.FIPS.186-42013年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <https://www.rfc-editor.org/info/rfc6068>.
[RFC6068]Duerst，M.，Masinter，L.，和J.Zawinski，“mailto”URI方案”，RFC 6068，DOI 10.17487/RFC6068，2010年10月<https://www.rfc-editor.org/info/rfc6068>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<https://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, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<https://www.rfc-editor.org/info/rfc6838>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<https://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<https://www.rfc-editor.org/info/rfc7235>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518]Jones，M.，“JSON网络算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<https://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, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030]Thomson，M.，Damaggio，E.，和B.Raymor，Ed.，“使用HTTP推送的通用事件交付”，RFC 8030，DOI 10.17487/RFC80302016年12月<https://www.rfc-editor.org/info/rfc8030>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <http://www.rfc-editor.org/info/rfc8291>.
[RFC8291]Thomson，M.，“Web推送的消息加密”，RFC 8291，DOI 10.17487/RFC8291，2017年11月<http://www.rfc-editor.org/info/rfc8291>.
[X9.62] ANSI, "Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 2005.
[X9.62]ANSI，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62，2005年。
[API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan, B., and E. Fullea, "Push API", October 2017, <https://www.w3.org/TR/push-api/>.
[API]Beverloo，P.，Thomson，M.，van Ouwerkerk，M.，Sullivan，B.，和E.Fullea，“推送API”，2017年10月<https://www.w3.org/TR/push-api/>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC7517]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<https://www.rfc-editor.org/info/rfc7517>.
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.
如果没有Benjamin Bangert、JR Conlin、Chris Karlof、Costin Manolache、Adam Roach和其他人的贡献，这份文件会比现在糟糕得多。
Authors' Addresses
作者地址
Martin Thomson Mozilla
马丁·汤姆森·莫齐拉
Email: martin.thomson@gmail.com
Email: martin.thomson@gmail.com
Peter Beverloo Google
彼得·贝弗洛谷歌
Email: beverloo@google.com
Email: beverloo@google.com