はじめに
ローテーション バーコードは通常のバーコードと同じように見えますが、定期的(通常は 1 分ごと)に変わります。端末 / リーダーは最新のバーコードのみを受け入れるようにプログラムされています。このセキュリティ対策により、バーコードのスクリーンショット撮影、特にチケットの盗難や不正なチケットの再販に関連するリスクが軽減されます。NFC がサポートされていない(ハードウェアがないかソフトウェアが使用できない)ためにスマートタップを利用できないデバイスでは、ローテーション バーコードがフォールバックとして機能することもあります。
API リファレンス
ローテーション バーコードの技術的な詳細については、RotatingBarcode
タイプをご覧ください。
ペイロードの例
JSON | |
---|---|
{ "rotatingBarcode": { "type": "QR_CODE", "valuePattern": "MyRotatingBarcode-{totp_timestamp_seconds}-{totp_value_0}", "alternateText": "Ticket#: 1234567890", "totpDetails": { "algorithm": "TOTP_SHA1", "periodMillis": "3000", "parameters": [ { "key": "3132333435363738393031323334353637383930", "valueLength": "8" } ] } } } |
フォールバックの仕組み
ユーザー デバイスでは、パスの構成法やデバイスの機能によって、所定の時間に 1 つの利用手段だけが使われます。優先順位の高いものから順に、次の利用手段が使われます。
-
スマートタップ: スマートタップ ペイロードが指定されていて、デバイスが NFC / HCE をサポートしている場合
- ユーザーが [コードを表示] をクリックすると、ローテーション バーコード / 静的バーコードが強制的に表示され、これをオーバーライドできます。
- ローテーション バーコード: ローテーション バーコードのペイロードが指定されている場合
- 静的バーコード: バーコード ペイロードが指定されている場合
複数の利用ペイロードを指定すると、すべてのユーザーがサポートされますが、セキュリティに悪影響を及ぼす可能性があります。特に、ローテーション バーコードの代替策として静的バーコードを使用すると、ローテーション バーコードを使用する際のセキュリティ上のメリットのほとんどが帳消しになります。静的なバーコードによる代替策は、ローテーション バーコードをサポートしていないウェブ表示やクライアントにのみ表示されます。現時点では、すべての Google ウォレット クライアントでローテーション バーコードがサポートされています。
保存フロー
Google Wallet API には、次のようないくつかのフローがあります。
- 保存の際または事前にギフトカード クラスを作成する
- JWT 内で完全なオブジェクトを送信するか、オブジェクトをあらかじめ保存してから JWT 内の ID で参照する。
- 保存されているオブジェクトを更新する
指定される rotatingBarcode フィールドは、これらのフローすべてに対応していますが、セキュリティを強化するため、次のようにすることをおすすめします。
-
object:insert
API を呼び出して Google ウォレット サーバーにパスを挿入し、[Google ウォレットに追加] ボタンを構成して JWT 内の ID で特定のオブジェクトを参照します。これにより、生成される JWT が、ローテーション バーコードの秘密鍵を含まなくなります。 - 単一のパスをスコープとする OTP 秘密鍵を使用する
- この鍵は、更新されない限り、パスの存続期間中は有効であることが期待されます。Google は、通常のオペレーション中、この鍵がその頻度にかかわらず更新されないことを想定しています。
次のシーケンス図は、一般的な統合におけるさまざまな要素間のフローを示しています。
