RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8292
タイトル : RFC 8292 - Webプッシュ用の自主アプリケーションサーバー識別（VAPID）
翻訳編集 : 自動生成

[要約] RFC 8292は、Web Pushのための自発的なアプリケーションサーバー識別（VAPID）に関する規格です。VAPIDは、Web Push通知を送信するアプリケーションサーバーを識別するための仕組みを提供します。この規格の目的は、プライバシーとセキュリティを向上させ、Web Push通知の送信元を確実に識別することです。

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」認証スキームを使用すると、クライアントは、自身のIDを、要求した署名付きトークンに含めることができます。このシグニチャーは、プッシュ・サービスが使用して、同じアプリケーション・サーバーによって行われた要求を単一のエンティティーに結び付けることができます。識別情報は、プッシュサービスのオペレーターがアプリケーションサーバーのオペレーターに連絡することを可能にすることができる。この署名を使用して、プッシュメッセージサブスクリプションの使用を単一のアプリケーションサーバーに制限できます。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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で入手できます。

著作権表示

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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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

1. はじめに

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が学習される影響を軽減できます。

1.1. Voluntary Identification

1.1. 任意の身分証明書

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.

このドキュメントでは、アプリケーションサーバーが自身に関する情報をプッシュサービスに志願できるシステムについて説明します。これにより、少なくともアプリケーションサーバーに安定したIDが提供されますが、メールアドレスなどの連絡先情報が含まれる場合もあります。

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.

プッシュサービスは、一貫したIDを使用して、アプリケーションサーバーに期待される動作を確立できます。確立された基準からの大幅な逸脱は、例外処理手順をトリガーするために使用できます。

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.

使用可能な連絡先情報がない場合でも、プッシュメッセージを破棄するかどうかを選択するときに、定評のあるアプリケーションサーバーが、識別されていないアプリケーションサーバーよりも優先されることがあります。

1.2. Notational Conventions

1.2. 表記規則

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.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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]で定義されているように使用されます。

2. Application Server Self-Identification

2. アプリケーションサーバーの自己識別

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]。プッシュメッセージの送信時にこのキーを使用すると、複数のメッセージにわたって一貫したアプリケーションサーバーのIDが確立されます。

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 Token（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 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.

o "exp"（有効期限）クレームは、トークンの有効期限が切れるまでの時間に含める必要があります。これにより、トークンの有効期間が制限されます。「exp」クレームは、リクエスト時から24時間を超えてはなりません。これを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」の認証方式を使用して、Authorizationヘッダーフィールドに含まれています。 JWT署名またはそのクレームが無効な場合、プッシュサービスは403（禁止）ステータスコード[RFC7231]のリクエストを拒否してもよい（MAY）。プッシュサービスは、無効なトークンからの情報を使用してはなりません。

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 Signature（JWS）[RFC7515]を使用する必要があります。署名は、NIST P-256曲線[FIPS186]でECDSAを使用する必要があります。これは、「ES256」[RFC7518]として識別されます。

2.1. Application Server Contact Information

2.1. アプリケーションサーバーの連絡先情報

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」（件名）クレームを含めることができます（MAY）。「sub」クレームには、アプリケーションサーバーの連絡先URIを「mailto：」（メール）[RFC6068]または「https：」[RFC2818] URIとして含める必要があります（SHOULD）。

2.2. Additional Claims

2.2. 追加の主張

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はヘッダーフィールドにあるため、追加のクレームのサイズは可能な限り小さくする必要があります。

2.3. Cryptographic Agility

2.3. 暗号化アジリティ

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.

このドキュメントで定義されているJWTの特定のプロファイルを識別するには、「vapid」HTTP認証方式（セクション3）を使用します。署名アルゴリズムまたはその他のパラメーターを更新するには、別の認証スキームが必要です。これにより、新しいパラメータネゴシエーションメカニズムを定義するのではなく、認証スキームをネゴシエートするための既存のメカニズムを使用できるようになります。

2.4. Example

2.4. 例

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」認証スキームを使用する認証情報を含むAuthorizationヘッダーフィールドが含まれます。

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のContent-Length：136コンテンツエンコード：aes128gcm許可：つまらないT = eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3 B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA、K = BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-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.

Authorizationヘッダーフィールドの "t"パラメータにはJWTが含まれています。「k」パラメーターには、そのトークンに署名したbase64urlでエンコードされたキーが含まれます。 JWTの入力値と、署名鍵に対応するJSON Web Key（JWK）[RFC7517]を図2に示します。読みやすくするために空白が追加されています。この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" }

Figure 2: Decoded Example Values

図2：デコードされたサンプル値

3. VAPID Authentication Scheme

3. VAPID認証スキーム

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.

この認証スキームは、オリジンサーバー認証専用です。したがって、この認証スキームは、Proxy-AuthenticateまたはProxy-Authorizationヘッダーフィールドと共に使用してはなりません（MUST NOT）。

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」の2つのパラメータが定義されています。「vapid」認証資格情報に対するすべての不明またはサポートされていないパラメーターは無視する必要があります。この認証方式では、「レルム」パラメータは無視されます。

This authentication scheme is intended for use by an application server when using the Web Push protocol [RFC8030].

この認証方式は、Webプッシュプロトコル[RFC8030]を使用するときにアプリケーションサーバーで使用することを目的としています。

3.1. Token Parameter ("t")

3.1. トークンパラメータ（ "t"）

The "t" parameter of the "vapid" authentication scheme carries a JWT as described in Section 2.

「vapid」認証方式の「t」パラメータは、セクション2で説明されているJWTを伝送します。

3.2. Public Key Parameter ("k")

3.2. 公開鍵パラメータ（ "k"）

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を検証できるようにするには、アプリケーションサーバーの公開鍵を学習する必要があります。「k」パラメータは、「vapid」認証方式がこの情報を運ぶために定義されています。

The "k" parameter includes an ECDSA public key [FIPS186] in uncompressed form [X9.62] that is encoded using base64url encoding [RFC7515].

「k」パラメーターには、base64urlエンコード[RFC7515]を使用してエンコードされた非圧縮形式[X9.62]のECDSA公開鍵[FIPS186]が含まれます。

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.

注：X9.62エンコーディングは、2つの理由でJWK [RFC7517]で使用されます。 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（Bad Request）ステータスコードを持つ同じ値を持つプッシュメッセージを拒否する必要があります（SHOULD）。

4. Subscription Restriction

4. サブスクリプションの制限

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.

サブスクリプションの制限により、アプリケーションサーバーがプッシュメッセージの配信を要求するときに署名済みトークンを提供する必要があるため、エンドポイントの秘密性への依存度が低くなります。これにより、プッシュメッセージサブスクリプションの詳細の漏洩に対する追加レベルの保護が提供されます。

4.1. Creating a Restricted Push Message Subscription

4.1. 制限されたプッシュメッセージサブスクリプションの作成

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).

次に、ユーザーエージェントは公開鍵をリクエストに追加して、プッシュメッセージサブスクリプションを作成します。プッシュメッセージのサブスクリプション要求は、本文を含むように拡張されています。 [RFC7159]で説明されているように、リクエストの本文はJSONオブジェクトです。ユーザーエージェントは、このJSONオブジェクトに、非圧縮形式[X9.62]およびbase64urlエンコード[RFC7515]でエンコードされたP-256曲線の公開キーを含む「vapid」メンバーを追加します。本文のメディアタイプは「application / webpush-options + 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" }

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]を使用してユーザーエージェントに公開鍵を提供する場合があります。

4.2. Using Restricted Subscriptions

4.2. 制限付きサブスクリプションの使用

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.

プッシュサービスは、メッセージに「vapid」認証が含まれていないか、無効な「vapid」認証が含まれている場合、制限されたプッシュメッセージサブスクリプションに送信されたメッセージを拒否する必要があります。認証が存在しない場合は、401（無許可）状況コードが使用される可能性があります。認証が無効な場合は、403（禁止）ステータスコードが使用されることがあります。

"vapid" authentication is invalid if:

「vapid」認証は次の場合に無効です。

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」（Audience）クレームに含まれていない、または

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または公開鍵をユーザーエージェントに転送してはなりません（MUST NOT）。

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.

署名鍵を置き換える必要があるアプリケーションサーバーは、更新された鍵に制限されているユーザーエージェントによる新しいサブスクリプションの作成を要求する必要があります。アプリケーションサーバーは、サブスクリプションの作成を要求するときに使用されたキーを覚えておく必要があります。

5. Security Considerations

5. セキュリティに関する考慮事項

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.

署名キーを変更するアプリケーションサーバーは、異なるキーの下で送信するプッシュメッセージ間のリンクを切断します。アプリケーションサーバーの一貫したIDに依存するプッシュサービスは、新しいキーで行われた要求を異なる方法で分類する場合があります。新しい署名鍵への段階的な移行により、新しい鍵を使用するリクエストが不正行為として分類される可能性が低くなります。

6. IANA Considerations

6. IANAに関する考慮事項

This document registers a new authentication scheme, a registry for parameters of that scheme, and a media type for push options.

このドキュメントは、新しい認証スキーム、そのスキームのパラメータのレジストリ、およびプッシュオプションのメディアタイプを登録します。

6.1. VAPID Authentication Scheme Registration

6.1. VAPID認証方式の登録

This document registers the "vapid" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" established by [RFC7235].

このドキュメントは、[RFC7235]によって確立された "Hypertext Transfer Protocol（HTTP）Authentication Scheme Registry"に "vapid"認証スキームを登録します。

Authentication Scheme Name: vapid

認証スキーム名：vapid

Pointer to specification text: Section 3 of this document

仕様テキストへのポインタ：このドキュメントのセクション3

6.2. VAPID Authentication Scheme Parameters

6.2. VAPID認証方式パラメーター

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 Authentication Scheme Parameters」レジストリを作成します。これらのパラメーターは、リクエスト（Authorizationヘッダーフィールド内）およびチャレンジ（WWW-Authenticateヘッダーフィールド内）で使用するために定義されています。このレジストリは、「Webプッシュパラメータ」グループの下にあります。レジストリは「Specification Required」ポリシー[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

ヘッダーフィールド：パラメーターを使用できるヘッダーフィールド

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      |
   +-------------+------------------+---------------+------------------+

6.3. application/webpush-options+json Media Type Registration

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].

このドキュメントでは、[RFC6838]で説明されているプロセスに従って、「メディアタイプ」レジストリに「application / webpush-options + json」メディアタイプを登録します。

Type name: application

タイプ名：アプリケーション

Subtype name: webpush-options+json

サブタイプ名：webpush-options + 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ブラウザー、Webプッシュプロトコル経由[RFC8030]

Fragment identifier considerations: none

フラグメント識別子の考慮事項：なし

Additional information:

追加情報：

Deprecated alias names for this type: n/a

このタイプの非推奨のエイリアス名：n / a

      Magic number(s):  n/a

File extension(s): .json

ファイル拡張子：.json

Macintosh file type code(s): TEXT

Macintoshファイルタイプコード：TEXT

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

変更コントローラー：Internet Engineering Task Force

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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-4、2013年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。、「HTTP Over TLS」、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、「The 'mailto' URI Scheme」、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。、「The Web Origin Concept」、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]ブレイ、T。、編、「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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、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]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（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]ジョーンズ、M。、「JSON Web Algorithms（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]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（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、編、「HTTPプッシュを使用した一般的なイベント配信」、RFC 8030、DOI 10.17487 / RFC8030、2016年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]コットン、M。、レイバ、B。、およびT.ナルテン、「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。、「Message Encryption for Web Push」、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年。

7.2. Informative References

7.2. 参考引用

[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、「Push 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]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年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.

このドキュメントは、ベンジャミンバンガート、JRコンリン、クリスカーロフ、コスティンマノラチェ、アダムローチなどの貢献によるものである場合よりもはるかに悪いものでした。

Authors' Addresses

著者のアドレス

Martin Thomson Mozilla

マーティン・トムソン・モジラ

   Email: martin.thomson@gmail.com

Peter Beverloo Google

ピーターベバールーグーグル

   Email: beverloo@google.com