Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8292 Mozilla
Category: Standards Track P. Beverloo
ISSN: 2070-1721 Google
November 2017
Web Pushのための自発的アプリケーションサーバー識別（VAPID）
概要
アプリケーションサーバーは、この文書で説明するVoluntary Application
Server Identification（VAPID）方式を使用して、プッシュサービスに対し
て自発的に自身を識別できる。「vapid」認証方式により、クライアントは、
自身が行うリクエストにおいて、署名付きトークンに自身の識別情報を含
めることができる。その署名は、同じアプリケーションサーバーによって行
われたリクエストを単一の主体に帰属させるために、プッシュサービスに
よって使用できる。この識別情報により、プッシュサービスの運用者はア
プリケーションサーバーの運用者に連絡できる場合がある。この署名は、
プッシュメッセージサブスクリプションの使用を単一のアプリケーション
サーバーに制限するために使用できる。
このメモの位置付け
これはインターネット標準化過程の文書である。
この文書はInternet Engineering Task Force（IETF）の成果物である。
これはIETFコミュニティの合意を表している。公開レビューを受け、
Internet Engineering Steering Group（IESG）によって公開が承認され
ている。インターネット標準に関する詳細情報は、
RFC 7841のSection 2で入手できる。
この文書の現在の状態、正誤表、およびフィードバックの提供方法に関す
る情報は、
https://www.rfc-editor.org/info/rfc8292で入手できる。
Thomson & Beverloo Standards Track [Page 1]
RFC 8292 Web PushのためのVAPID November 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
目次
1. はじめに ....................................................3
1.1. 自発的識別 ...........................................3
1.2. 表記上の規約 .....................................4
2. アプリケーションサーバーの自己識別 ..........................4
2.1. アプリケーションサーバーの連絡先情報 .....................5
2.2. 追加クレーム ..........................................5
2.3. 暗号学的アジリティ ......................................5
2.4. 例 ....................................................5
3. VAPID認証方式 .....................................6
3.1. トークンパラメーター（"t"） ..............................7
3.2. 公開鍵パラメーター（"k"） .................................7
4. サブスクリプション制限 ........................................7
4.1. 制限付きプッシュメッセージサブスクリプションの作成 ............8
4.2. 制限付きサブスクリプションの使用 .............................9
5. セキュリティに関する考慮事項 .........................................9
6. IANAに関する考慮事項 ............................................10
6.1. VAPID認証方式の登録 ..................10
6.2. VAPID認証方式パラメーター ....................10
6.3. application/webpush-options+jsonメディア型登録 ..11
7. 参照文献 .....................................................12
7.1. 規範的参照文献 ......................................12
7.2. 参考参照文献 ....................................14
謝辞 ..................................................14
著者の連絡先 ................................................14
Thomson & Beverloo Standards Track [Page 2]
RFC 8292 Web PushのためのVAPID November 2017
1. はじめに
Web Pushプロトコル [RFC8030] は、アプリケーションサーバーが、プッシュサービスに
プッシュメッセージをユーザーエージェントへ配送するよう要求できる仕組
みを説明している。
想定される配備アーキテクチャの結果として、アプリケーションサーバーが
プッシュメッセージの配送を要求する前に、プッシュサービスに認識される
ための基盤は存在しない。プッシュサービスがアプリケーションサーバーを
認証できることを要求すると、プッシュサービスの最終的な利用者である
ユーザーエージェントとアプリケーションサーバーとの相互作用に、望まれ
ない制約が課される。その制約はまた、このプロトコルが提供するプライバ
シー保護の性質を低下させる。これらの理由により、[RFC8030] は
アプリケーションサーバー認証のための必須システムを定義していない。
[RFC8030] の設計に伴う不幸な結果として、プッシュサービスはサービス
拒否攻撃のリスクによりさらされる。アプリケーションサーバーからのリク
エストは、ユーザーエージェントに間接的に帰属させることができるが、こ
れは常に効率的であるわけでも、十分であるわけでもない。アプリケーショ
ンサーバーに関するより多くの情報をプッシュサービスへ直接提供すること
で、プッシュサービスは正当なリクエストと偽のリクエストをより適切に区
別できる。
さらに、[RFC8030] の設計は、プッシュメッセージサブスクリプション
URIの秘匿性を維持することに依存している。プッシュメッセージサブスク
リプションURIを所有する任意のアプリケーションサーバーは、ユーザーエー
ジェントへメッセージを送信できる。サブスクリプションの使用を単一のア
プリケーションサーバーに限定できれば、プッシュメッセージサブスクリプ
ションURIが権限のない第三者に知られた場合の影響を低減できる。
1.1. 自発的識別
この文書は、アプリケーションサーバーが自身に関する情報をプッシュサー
ビスに自発的に提供できるシステムを説明する。最低限、これはアプリケー
ションサーバーに安定した識別子を提供するが、メールアドレスなどの連絡
先情報も含めることができる。
一貫した識別子は、プッシュサービスがアプリケーションサーバーに対する
振る舞い上の期待を確立するために使用できる。確立された規範からの重大
な逸脱は、例外処理手順を起動するために使用できる。
Thomson & Beverloo Standards Track [Page 3]
RFC 8292 Web PushのためのVAPID November 2017
自発的に提供された連絡先情報は、例外的な状況の場合にアプリケーション
サーバー運用者へ連絡するために使用できる。
プッシュサービス配備の経験から、ソフトウェアエラーまたは通常とは異な
る状況によって、プッシュメッセージ量が大幅に増加することがあると示さ
れている。アプリケーションサーバーの運用者に連絡することは、有益であ
ることが証明されている。
利用可能な連絡先情報がない場合であっても、十分に確立された評判を持つ
アプリケーションサーバーは、プッシュメッセージを破棄するかどうかを選
択する際に、識別されていないアプリケーションサーバーより優先される場
合がある。
1.2. 表記上の規約
この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」
、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT
RECOMMENDED」、「MAY」、「OPTIONAL」は、ここに示すようにすべて大文字で
出現する場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されている
とおりに解釈される。
「push message」、「push service」、「push message subscription」
、「application server」、「user agent」という用語は、[RFC8030] で定義
されている意味で使用する。
2. アプリケーションサーバーの自己識別
自己識別を希望するアプリケーションサーバーは、署名鍵ペアを生成し、維
持する。この鍵ペアは、P-256曲線上のElliptic Curve Digital Signature
Algorithm（ECDSA）[FIPS186] で使用可能でなければならない（MUST）。プッ
シュメッセージ送信時にこの鍵を使用することで、複数のメッセージにわた
って一貫したアプリケーションサーバーの識別子が確立される。
プッシュメッセージの配送を要求するとき、アプリケーションは、その署名
鍵を使用して署名されたJSON Web Token（JWT）[RFC7519] を含める。このトー
クンは、次のような多数のクレームを含む。
o トークン内の「aud」（Audience）クレームは、プッシュリソースURLの
オリジン（[RFC6454]のSection 6.1）のUnicodeシリアル化を含まなけれ
ばならない（MUST）。これにより、トークンは特定のプッシュサービス
に結び付けられ、同じオリジンを共有するすべてのプッシュリソースURL
に対してトークンを再利用できることが保証される。
o 「exp」（Expiry）クレームは、トークンが失効する時刻とともに含めな
ければならない（MUST）。これにより、トークンが有効である期間が制限
される。「exp」クレームは、リクエスト時刻から24時間を超えてはなら
Thomson & Beverloo Standards Track [Page 4]
RFC 8292 Web PushのためのVAPID November 2017
ない（MUST NOT）。これを24時間に制限することで、再利用の必要性と、
有効なトークンの窃取に伴う潜在的なコストおよび可能性との均衡を取
る。
このJWTは、「vapid」の認証方式を使用してAuthorizationヘッダーフィー
ルドに含められる。JWT署名またはそのクレームが無効である場合、プッシュ
サービスは、403（Forbidden）ステータスコード [RFC7231] でリクエスト
を拒否してもよい（MAY）。プッシュサービスは、無効なトークンからの情
報を使用してはならない（MUST NOT）。
JWTはJSON Web Signature（JWS）[RFC7515] を使用しなければならない（MUST）。
署名は、"ES256" [RFC7518] として識別されるNIST P-256曲線上のECDSA
[FIPS186] を使用しなければならない（MUST）。
2.1. アプリケーションサーバーの連絡先情報
アプリケーションサーバーが連絡先詳細を提供したい場合、JWTに「sub」
（Subject）クレームを含めてもよい（MAY）。「sub」クレームは、"mailto:"
（email）[RFC6068] または"https:" [RFC2818] URIのいずれかとして、アプリ
ケーションサーバーの連絡先URIを含めるべきである（SHOULD）。
2.2. 追加クレーム
アプリケーションサーバーは、公開名または私的名を使用して追加クレーム
を含めてもよい（MAY）（[RFC7519] のSections 4.2および4.3を参照）。JWT
はヘッダーフィールド内にあるため、追加クレームのサイズは可能な限り小
さく保つべきである（SHOULD）。
2.3. 暗号学的アジリティ
「vapid」HTTP認証方式（Section 3）は、この文書で定義するJWTの特
定のプロファイルを識別するために使用される。署名アルゴリズムまたはそ
の他のパラメーターを更新するには、別の認証方式が必要となる。これによ
り、新しいパラメーター交渉機構を定義するのではなく、認証方式を交渉す
る既存の機構を使用できることが保証される。
2.4. 例
アプリケーションサーバーは、[RFC8030] で説明されているように、プッ
シュメッセージの配送を要求する。アプリケーションサーバーが自己識別を
希望する場合、「vapid」認証方式を使用する資格情報を含むAuthorization
ヘッダーフィールドを含める。
Thomson & Beverloo Standards Track [Page 5]
RFC 8292 Web PushのためのVAPID November 2017
POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 30
Content-Length: 136
Content-Encoding: aes128gcm
Authorization: vapid
t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
uU_RCPCfA5aq9ojSwk5Y2EmClBPs
{ encrypted push message }
Figure 1: JWTによるプッシュメッセージ配送の要求
この文書の例示ヘッダーフィールドには、書式上の制約を満たすために余分
な改行が含まれていることに注意。
Authorizationヘッダーフィールドの「t」パラメーターはJWTを含み、「k」
パラメーターはそのトークンに署名したbase64urlエンコード鍵を含む。JWT
入力値と、署名鍵に対応するJSON Web Key（JWK）[RFC7517] を、可読性のた
めに空白を追加してFigure 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: デコードされた例の値
3. VAPID認証方式
この文書は、"vapid"という名前の新しいHTTP認証方式 [RFC7235] を定義
する。この認証方式は、Section 2で説明されている署名付きJWTと、そのJWT
に署名した鍵を運ぶ。
この認証方式は、オリジンサーバー認証専用である。したがって、この認証
方式はProxy-AuthenticateまたはProxy-Authorizationヘッダーフィールドと
ともに使用してはならない（MUST NOT）。
Thomson & Beverloo Standards Track [Page 6]
RFC 8292 Web PushのためのVAPID November 2017
「vapid」認証方式に対するチャレンジは、"auth-scheme"生成規則のみを含
む。現在、パラメーターは定義されていない。
この認証方式には、「t」と「k」の2つのパラメーターが定義されている。
「vapid」認証資格情報に対する未知または未サポートのすべてのパラメー
ターは無視しなければならない（MUST）。この認証方式では、「realm」パラ
メーターは無視される。
この認証方式は、Web Pushプロトコル [RFC8030] を使用する際に、アプリ
ケーションサーバーによって使用されることを意図している。
3.1. トークンパラメーター（"t"）
「vapid」認証方式の「t」パラメーターは、Section 2で説明されている
JWTを運ぶ。
3.2. 公開鍵パラメーター（"k"）
プッシュサービスがJWTを検証できるようにするには、アプリケーションサー
バーの公開鍵を知る必要がある。この情報を運ぶために、「vapid」認証方式
の「k」パラメーターが定義されている。
「k」パラメーターには、base64urlエンコード [RFC7515] を使用してエンコード
された、非圧縮形式 [X9.62] のECDSA公開鍵 [FIPS186] が含まれる。
注記: X9.62エンコードは、2つの理由からJWK [RFC7517] よりも使用される。
JWKには正準形式がないため、X9.62エンコードは、プッシュサービスが
異なるソースからの鍵を比較する処理を容易にする。第二に、X9.62エン
コードはかなり小さい。
一部の楕円曲線実装では、同じP-256鍵を署名と鍵交換の両方に使用できる。
アプリケーションサーバーは、認証トークンの署名と鍵交換 [RFC8291] に
異なる秘密鍵を選択しなければならない（MUST）。プッシュサービスは、す
べてのプッシュメッセージについていずれかのパラメーターを確認する義務
はないが、これらのパラメーターが同一の値を持つプッシュメッセージは、
400（Bad Request）ステータスコードで拒否すべきである（SHOULD）。
4. サブスクリプション制限
アプリケーションサーバーの公開鍵は、そのサーバーの安定した識別子とし
て機能する。この鍵は、プッシュメッセージサブスクリプションを特定のア
プリケーションサーバーに制限するために使用できる。
Thomson & Beverloo Standards Track [Page 7]
RFC 8292 Web PushのためのVAPID November 2017
サブスクリプション制限は、プッシュメッセージの配送を要求するときに、
アプリケーションサーバーが署名付きトークンを提供することを要求するこ
とで、エンドポイントの秘匿性への依存を低減する。これは、プッシュメッ
セージサブスクリプションの詳細が漏えいすることに対して、追加の保護レ
ベルを提供する。
4.1. 制限付きプッシュメッセージサブスクリプションの作成
制限付きサブスクリプションを作成したいユーザーエージェントは、プッシュ
メッセージサブスクリプションの作成を要求するときに、アプリケーション
サーバーの公開鍵を含める。これにより、結果として得られるサブスクリプ
ションの使用は、対応する秘密鍵で署名された有効なJWTを提供できるアプリ
ケーションサーバーに制限される。
その後、ユーザーエージェントは、プッシュメッセージサブスクリプション
を作成するリクエストに公開鍵を追加する。プッシュメッセージサブスクリ
プションリクエストは、本文を含むよう拡張される。リクエストの本文は、
[RFC7159] で説明されているJSONオブジェクトである。ユーザーエージェ
ントは、このJSONオブジェクトに「vapid」メンバーを追加し、そのメンバー
はP-256曲線上の公開鍵を含む。この公開鍵は、非圧縮形式 [X9.62] で
エンコードされ、base64urlエンコード [RFC7515] される。本文のメディア
型は"application/webpush-options+json"に設定される（このメディア型の
登録についてはSection 6.3を参照）。
プッシュサービスは、異なるメディア型を使用するリクエストの本文を無視
しなければならない（MUST）。"application/webpush-options+json"メディア
型については、プッシュサービスは、このオブジェクト上の理解しない任意
のメンバーを無視しなければならない（MUST）。
Figure 3の例は、Figure 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: 例示サブスクライブリクエスト
アプリケーションはPush API [API] を使用して、ユーザーエージェント
に公開鍵を提供することがある。
Thomson & Beverloo Standards Track [Page 8]
RFC 8292 Web PushのためのVAPID November 2017
4.2. 制限付きサブスクリプションの使用
プッシュメッセージサブスクリプションがアプリケーションサーバーに制限
されている場合、プッシュメッセージ配送のリクエストは、サブスクリプシ
ョン作成時に使用された公開鍵に対応する秘密鍵で署名されたJWTを含まなけ
ればならない（MUST）。
制限付きプッシュメッセージサブスクリプションに送信されたメッセージが
「vapid」認証を含まない、または無効な「vapid」認証を含む場合、プッシュ
サービスはそのメッセージを拒否しなければならない（MUST）。認証がない
場合は401（Unauthorized）ステータスコードが使用されることがあり、認証
が無効である場合は403（Forbidden）ステータスコードが使用されることが
ある。
次の場合、「vapid」認証は無効である。
o 認証トークンまたは公開鍵のいずれかがリクエストに含まれていない。
o JWT上の署名を、含まれる公開鍵を使用して正常に検証できない。
o 現在時刻が「exp」（Expiry）クレームで識別される時刻より後である、
または失効時刻の24時間より前である。
o プッシュリソースのオリジンが「aud」（Audience）クレームに含まれて
いない。
o JWTの署名に使用された公開鍵が、プッシュメッセージサブスクリプショ
ン作成時に含められたものと一致しない。
プッシュサービスは、プッシュメッセージを配送するとき、JWTまたは公開鍵
をユーザーエージェントに転送してはならない（MUST NOT）。
署名鍵を置き換える必要があるアプリケーションサーバーは、更新された鍵
に制限される新しいサブスクリプションの作成を、ユーザーエージェントに
要求する必要がある。アプリケーションサーバーは、サブスクリプション作
成を要求したときに使用された鍵を記憶する必要がある。
5. セキュリティに関する考慮事項
攻撃者が有効なJWTを取得できる場合、この認証方式はリプレイ攻撃に対し
て脆弱である。[RFC8030] で要求されるようにHTTPSを使用してリクエストを
送信することで、機密性が提供される。さらに、再利用可能なトークンを再
利用できる期間に狭い制限を適用することで、盗まれたトークンの攻撃者に
とっての潜在的価値を制限し、トークンの窃取を困難にできる。
Thomson & Beverloo Standards Track [Page 9]
RFC 8292 Web PushのためのVAPID November 2017
アプリケーションサーバーは、偽の連絡先情報を提供する場合がある。アプ
リケーションサーバーは、その主張を裏付ける証拠なしに、自身のメールア
ドレスまたは連絡先URIを主張する。プッシュサービス運用者は、検証されて
いない連絡先情報の存在を、セキュリティ上重要な意思決定プロセスへの入
力として使用することはできない。
JWT上の署名の検証には、少なくない量の計算が必要となる。サービス拒否
攻撃の状況下で正当なリクエストを識別するために使用される可能性がある
ものとしては、これは理想的ではない。そのため、アプリケーションサーバー
には、トークンを再利用することが推奨される。これにより、プッシュサー
ビスは署名検証の結果をキャッシュできる。
署名鍵を変更するアプリケーションサーバーは、異なる鍵の下で送信するプッ
シュメッセージ間のリンク可能性を壊す。アプリケーションサーバーに対し
て一貫した識別子に依存するプッシュサービスは、新しい鍵で行われたリク
エストを異なるように分類する場合がある。新しい署名鍵への段階的な移行
により、新しい鍵を使用するリクエストが濫用として分類される可能性を低
減できる。
6. IANAに関する考慮事項
この文書は、新しい認証方式、その方式のパラメーター用レジストリ、およ
びプッシュオプション用メディア型を登録する。
6.1. VAPID認証方式の登録
この文書は、[RFC7235] によって確立された「Hypertext Transfer Protocol
(HTTP) Authentication Scheme Registry」に「vapid」認証方式を登録する。
Authentication Scheme Name: vapid
Pointer to specification text: この文書のSection 3
6.2. VAPID認証方式パラメーター
この文書は、「vapid」認証方式のパラメーター用に「VAPID Authentication
Scheme Parameters」レジストリを作成する。これらのパラメーターは、リ
クエスト（Authorizationヘッダーフィールド内）およびチャレンジ
（WWW-Authenticateヘッダーフィールド内）で使用するために定義される。
このレジストリは「Web Push Parameters」グループ配下にある。このレジス
トリは「Specification Required」ポリシー [RFC8126] で運用される。
Thomson & Beverloo Standards Track [Page 10]
RFC 8292 Web PushのためのVAPID November 2017
登録には、次の情報を含めなければならない（MUST）。
Parameter Name: パラメーターの名前。これは「token」文法 [RFC7230] に
適合する。
Purpose (optional): パラメーターの目的を識別する短いテキスト。
Header Field(s): パラメーターを使用できるヘッダーフィールド。
Specification: パラメーターの形式および意味論を定義する仕様へのリン
ク。
このレジストリは当初、次のエントリーを含む。
+-------------+------------------+---------------+------------------+
| 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メディア型登録
この文書は、[RFC6838] で説明されているプロセスに従って、
"application/webpush-options+json"メディア型を「Media Types」レジスト
リに登録する。
Type name: application
Subtype name: webpush-options+json
Required parameters: なし
Optional parameters: なし
Encoding considerations: binary（JSONはUTF-8でエンコードされたテキスト）
Security considerations: JSONに固有のセキュリティに関する考慮事項につ
いては [RFC7159] を参照。
Thomson & Beverloo Standards Track [Page 11]
RFC 8292 Web PushのためのVAPID November 2017
Interoperability considerations: JSONに固有の相互運用性に関する考慮事項
については [RFC7159] を参照。
Published specification: [RFC8292]
Applications that use this media type: Web Pushプロトコル [RFC8030] を介し
たWebブラウザー。
Fragment identifier considerations: なし
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: Web Pushプロトコル [RFC8030] での使用に限定。
Author: [RFC8292] の「Authors' Addresses」セクションを参照。
Change controller: Internet Engineering Task Force
7. 参照文献
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.
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
Thomson & Beverloo Standards Track [Page 12]
RFC 8292 Web PushのためのVAPID November 2017
[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>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<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>.
[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>.
Thomson & Beverloo Standards Track [Page 13]
RFC 8292 Web PushのためのVAPID November 2017
[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>.
[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>.
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291,
DOI 10.17487/RFC8291, November 2017,
<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.
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/>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
謝辞
この文書は、Benjamin Bangert、JR Conlin、Chris Karlof、Costin
Manolache、Adam Roach、およびその他の貢献がなければ、現在よりはるかに
悪いものになっていただろう。
著者の連絡先
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
Peter Beverloo
Google
Email: beverloo@google.com
Thomson & Beverloo Standards Track [Page 14]