Authorizationヘッダの先頭に記述するスキームがBearerからWebPushに変更されたようですので、更新しました。(GCM)の登録とキーやIDの取得が必要となります。従って、Webアプリ側では、Chrome専用のマニフェスト記述が、アプリケーションサーバ側ではGCMサーバの認証用に専用のHTTPヘッダの記述が必要となっています。これに対し、ようやくプッシュサーバのアプリサーバに対する認証などの仕様について、IETFでの策定が進み、ChromeやFirefoxで実装が進んできています。Pushを試してみます。これで、ChromeでもFirefoxでも完全に同じ手順でプッシュ通知に対応できるようになります。FeaturesをEnabledにすると使えるようになります。(VAPID)の標準化作業が進んでいます。このVAPIDの全体の流れを説明します。アプリケーションサーバはECDSAの鍵ペアを生成する。Agent)はアプリケーションサーバからECDSA公開鍵を受け取る。ブラウザがプッシュサーバにプッシュ通知の購読を登録する際、アプリケーションサーバのECDSA公開鍵を渡す。(JWT)形式の署名トークンを生成し、ECDSA公開鍵と合わせてプッシュサーバに渡す。プッシュサーバは、ECDSA公開鍵を使ってアプリケーションサーバから受け取ったJWTを検証し、内容に問題がなければプッシュ通知をブラウザに転送する。Pushの手順の中で合わせて行う形となります。VAPIDはVoluntary(自発的)というだけあって、この仕様自体はJWTによる認証を必須にしているわけではありません。3.の手順を踏むことで、そのブラウザ(Webアプリ)に対するプッシュ通知に対してJWTによる認証が必須になりますが、Firefoxでは今のところ3.の手順は必須ではありません。Chromeの場合、今のところ、従来のGCM専用拡張かVAPIDによる認証のいずれかを使うことが必須になっています。Pushでブラウザにプッシュ通知を送ってみるを参照して下さい。本記事では、サーバの登録や認証に関連する部分にフォーカスして説明します。(≦51)に対応する必要がなければ、マニフェストに記載していたgcm_sender_id等が不要になります。詳細はサンプルコードおよびデモをご覧下さい。ブラウザからプッシュサーバへの鍵登録以外の部分については、次のNode.js向けコードが参考になります。(P-256楕円曲線)による署名からJWTを生成する処理を伴います。APIでECDSAの署名と検証を試してみるを参照して下さい。ブラウザでのプッシュ通知の購読とサーバ公開鍵の登録まず、ブラウザのWebアプリでは、アプリケーションサーバからP-256楕円曲線のECDSA公開鍵を予め受け取るようにします。このECDSA公開鍵をArrayBufferもしくはUint8Arrayに格納した上で、プッシュ通知の購読処理を次のようにします。*/});すなわち、PushManager.subscribe()のオプションとして、applicationServerKeyメンバにアプリケーションサーバの公開鍵を渡すようにします。この時、公開鍵が65バイトのバイナリデータではない場合に、購読処理がエラーとなります。47以前では、このオプションは無視されます。POSTでリクエストする際、サーバ認証の必要なヘッダを追加する必要があります。具体的には次の内容をHTTPリクエストヘッダに追加します。Push暗号化では既に同名のヘッダを使っていますので、その末尾等に;(セミコロン)区切りでp256ecdsaフィールドを追加することになります。Authorizationヘッダについては、WebPush(+空白)の後にJWTを記述します。ここで、JWTのヘッダとクレームの内容は次のようにします。ECDSAで署名を作成し、最初の連結文字列にさらに、.と、署名をURLセーフBase64でエンコードしたものを連結すると、JWTが生成できますので、これをAuthorizationヘッダ(WebPushの後)に記述することとなります。Messagingを経由したプッシュ通知に移行されています(参考)。↓https://gcm-http.googleapis.com/gcm/[registration_id]のように書き換えないと正常に動作しないようです。ECDSAで署名してJWTを生成する際の注意事項アプリケーションサーバでJWTを生成する際、ECDSAによる電子署名のフォーマットに注意が必要です。8のjava.security.Signature等で扱われるECDSA署名は、JWTのシグネチャ部(JWS)とは異なるフォーマットとなっているため、変換が必要になります。APIでECDSAの署名と検証を試してみるを参照して下さい。*`Authorization`ヘッダの先頭に記述するスキームが[`Bearer`から`WebPush`に変更](https://developers.google.com/web/updates/2016/07/web-push-interop-wins?hl=en)されたようですので、更新しました。(GCM)の登録とキーやIDの取得が必要となります。従って、Webアプリ側では、Chrome専用のマニフェスト記述が、アプリケーションサーバ側ではGCMサーバの認証用に専用のHTTPヘッダの記述が必要となっています。これに対し、ようやくプッシュサーバのアプリサーバに対する認証などの仕様について、IETFでの策定が進み、ChromeやFirefoxで実装が進んできています。Pushを試してみます。これで、**ChromeでもFirefoxでも完全に同じ手順でプッシュ通知に対応できるようになります**。FeaturesをEnabledにすると使えるようになります。(VAPID)](https://tools.ietf.org/html/draft-ietf-webpush-vapid-00)の標準化作業が進んでいます。このVAPIDの全体の流れを説明します。アプリケーションサーバはECDSAの鍵ペアを生成する。Agent)はアプリケーションサーバからECDSA公開鍵を受け取る。ブラウザがプッシュサーバにプッシュ通知の購読を登録する際、アプリケーションサーバのECDSA公開鍵を渡す。(JWT)形式の署名トークンを生成し、ECDSA公開鍵と合わせてプッシュサーバに渡す。プッシュサーバは、ECDSA公開鍵を使ってアプリケーションサーバから受け取ったJWTを検証し、内容に問題がなければプッシュ通知をブラウザに転送する。Pushの手順の中で合わせて行う形となります。VAPIDはVoluntary(自発的)というだけあって、この仕様自体はJWTによる認証を必須にしているわけではありません。3.の手順を踏むことで、そのブラウザ(Webアプリ)に対するプッシュ通知に対してJWTによる認証が必須になりますが、*Firefoxでは今のところ3.の手順は必須ではありません*。Chromeの場合、今のところ、従来のGCM専用拡張かVAPIDによる認証のいずれかを使うことが必須になっています。Pushでブラウザにプッシュ通知を送ってみる](http://qiita.com/tomoyukilabs/items/217915676603fda73b0a)を参照して下さい。本記事では、サーバの登録や認証に関連する部分にフォーカスして説明します。(≦51)に対応する必要がなければ、マニフェストに記載していた`gcm_sender_id`等が不要になります。詳細は[サンプルコード](https://github.com/tomoyukilabs/WebPushTest)および[デモ](https://labs.othersight.jp/webpushtest/)をご覧下さい。ブラウザからプッシュサーバへの鍵登録以外の部分については、次のNode.js向けコードが参考になります。(P-256楕円曲線)による署名からJWTを生成する処理を伴います。APIでECDSAの署名と検証を試してみる](http://qiita.com/tomoyukilabs/items/b346a71a920eb7a93501)を参照して下さい。ブラウザでのプッシュ通知の購読とサーバ公開鍵の登録まず、ブラウザのWebアプリでは、アプリケーションサーバからP-256楕円曲線のECDSA公開鍵を予め受け取るようにします。このECDSA公開鍵をArrayBufferもしくはUint8Arrayに格納した上で、プッシュ通知の購読処理を次のようにします。*/});```すなわち、PushManager.subscribe()のオプションとして、applicationServerKeyメンバにアプリケーションサーバの公開鍵を渡すようにします。この時、公開鍵が65バイトのバイナリデータではない場合に、購読処理がエラーとなります。47以前では、このオプションは無視されます。POSTでリクエストする際、サーバ認証の必要なヘッダを追加する必要があります。具体的には次の内容をHTTPリクエストヘッダに追加します。Push暗号化では既に同名のヘッダを使っていますので、その末尾等に`;`(セミコロン)区切りで`p256ecdsa`フィールドを追加することになります。`Authorization`ヘッダについては、`WebPush`(+空白)の後にJWTを記述します。ここで、JWTのヘッダとクレームの内容は次のようにします。ECDSAで署名を作成し、最初の連結文字列にさらに、`.`と、署名をURLセーフBase64でエンコードしたものを連結すると、JWTが生成できますので、これを`Authorization`ヘッダ(`WebPush`の後)に記述することとなります。Messaging](https://firebase.google.com/docs/cloud-messaging/)を経由したプッシュ通知に移行されています([参考](http://blog.chromium.org/2016/06/chrome-52-beta-css-containment-simpler.html))。Push対応と同様に、endpointのURLを```texthttps://android.googleapis.com/gcm/send/[registration_id]↓https://gcm-http.googleapis.com/gcm/[registration_id]```のように書き換えないと正常に動作しないようです。ECDSAで署名してJWTを生成する際の注意事項アプリケーションサーバでJWTを生成する際、ECDSAによる電子署名のフォーマットに注意が必要です。8の`java.security.Signature`等で扱われるECDSA署名は、JWTのシグネチャ部(JWS)とは異なるフォーマットとなっているため、変換が必要になります。APIでECDSAの署名と検証を試してみる](http://qiita.com/tomoyukilabs/items/b346a71a920eb7a93501)を参照して下さい。送信いただいたご意見への返信は行っておりません。お問い合わせください。