[32] VAPID はHTTP認証の認証方式の1つです。 Web Push で使われます。
[24] auth-scheme として vapid
、
MIME型として application/webpush-options+json
が定義されています。
[16] アプリケーションサーバーは、 VAPID 署名用の鍵ペアを生成しておきます。 これは P-256 curve の ECDSA で使えるものでなければなりません。 この鍵によって、 プッシュサービスは複数のプッシュメッセージの送信に渡ってアプリケーションサーバーを識別できるのであります。 >>1 2.
[50] アプリケーションサーバーは、事前に VAPID 用鍵ペアを1組用意しておいて、 これをプッシュ購読の作成のときに毎回使うことが想定されています。 必要であれば、同じアプリケーションサーバーで複数の鍵ペアを使うこともできますが、 ある1つのプッシュ購読で使う鍵ペアは、特定の1組である必要があります。
[14]
アプリケーションサーバーは、
プッシュメッセージのデータの暗号化に使う
aes128gcm
の鍵と、
VAPID
で使う鍵に違ったものを使わなければなりません。
>>1 3., >>259
aes128gcm
の鍵はその場その場の使い捨て、
VAPID
の鍵は恒久利用、
と性質も違います。
[17] アプリケーションサーバーは、 プッシュメッセージの送信にあたって、 次のような claim を持つ JWT を作成して署名します。 >>1 2.
[20]
JWT は JWS を使わなければなりません。
署名は
ES256
を使わなければなりません。
>>1 2.
[26] アプリケーションは、 Push API で利用者エージェントに公開鍵を引き渡します。
[45]
指定する場合、
P-256 curve
上の点を
X9.62 uncompressed form
で符号化したものでなければなりません。
DOMString
の場合、それを RFC 7515 base64url
符号化したものでなければなりません。
>>259
[47]
PushSubscriptionOptionsInit
辞書の
applicationServerKey
メンバーは、
プッシュ購読作成時に使う公開鍵を指定するものです。
BufferSource
または
DOMString
または
null
で、既定値が
null
です。 >>46
[33]
PushSubscriptionOptions
インターフェイスの
applicationServerKey
属性の取得器 >>259 は、
次のようにしなければなりません。
[36]
subscribe
メソッドにおけるオプション群について
applicationServerKey
の正規化は、次のようにします。
>>35
[25] 利用者エージェントは、 プッシュサービス資源の要求で、公開鍵を送信します。 プッシュサービスは、作成したプッシュメッセージ購読でこれを保持します。
[27]
アプリケーションサーバーは、
プッシュ資源の要求で
auth-scheme
vapid
を使います。
プッシュサービスはプッシュメッセージ購読の保持する公開鍵を使ってこれを検証します。
[2] HTTP auth-scheme
vapid
は、署名した JWT
と、その署名の鍵を示すものです。
>>1 3.
[9] Web Push protocol で使うことを意図しています。 >>1 3.
[4] 起源サーバーの認証に使えます。
プロキシ認証
(Proxy-Authenticate
, Proxy-Authorization
)
で使ってはなりません。
>>1 3.
[5]
challenge
(応答)
は、
auth-scheme
である vapid
のみ含みます。引数はありません。
>>1 3.
[6]
credentials
(要求)
は、
auth-scheme
である vapid
に引数として
t
と
k
を指定します。
>>1 3.
[12]
k
引数は、
公開鍵を指定するものです。
プッシュサービスが JWT を検証できるようにするものです。
ECDSA 公開鍵を、
X9.62 uncompressed form
で、
RFC 7515
base64url
符号化したものを指定します。
>>1 3.
[15]
プッシュサービスは、
aes128gcm
の公開鍵 (keyid
)
と
VAPID
の公開鍵 (k
)
が同一の値なら、
400
応答を返すべきです。
>>1 3.
[11]
t
引数は、
JWT を指定するものです。
>>1 3.
[18]
プッシュサービスは、
JWT の署名か claim
が非妥当なら、
403
応答を返して構いません。
プッシュサービスは非妥当な JWT
の情報を使ってはなりません。
>>1 2.
[10] 指定することが認められているのか明記されていません。
[7] 未知・未対応の引数は、 無視しなければなりません。 >>1 3.
[21] 使用する JWT や署名の方法は固定されており、 他の署名方法などが必要になったときは別の auth-scheme が必要となります。 HTTP認証の auth-scheme の折衝の仕組みを流用するためとされています。 >>1 2.3.
[49]
アプリケーションサーバーは、プッシュメッセージの送信時、
プッシュ購読の特定アプリケーションサーバーに制限されているが真の場合、
アプリケーションサーバーの
(プッシュ購読用の)
VAPID 用鍵ペアの秘密鍵で署名した JWT
を含めなければなりません。
>>1 4.2
これは
auth-scheme vapid
の
credentials を
Authorization:
ヘッダーで指定することによります。
[48]
妥当な vapid
の credentials
を含まないなら拒絶しなければなりません。
認証がないとき
401
応答を返せますし、
認証が非妥当なとき
403
応答を返せます。
非妥当には次のような場合があります。
>>63
exp
を過ぎている時exp
まで24時間を超える時aud
でない時[28] VAPID は再生攻撃に弱いです。
HTTPS を使っていれば JWT は漏れませんし、
exp
を短くすれば漏洩時の悪用のリスクは抑えられます。
>>1 5.
[30] 一方で署名計算は少なからず資源を消費するので、 DoS攻撃中に正当な要求を識別するための VAPID としては矛盾した状況に置かれています。 そこでアプリケーションサーバーは JWT を再利用することが推奨されており、 プッシュサービスは検証結果をキャッシュできます。 >>1 5.
[3] に IETF の提案標準 RFC 8292 として出版されました。 >>1
[31] Web Push Parameters, https://www.iana.org/assignments/webpush-parameters/webpush-parameters.xhtml