バーコードのローテーション

はじめに

ローテーション バーコードは通常のバーコードと同じように見えますが、定期的（通常は 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 つのクーポン利用メカニズムのみが使用されます。 。 優先順位の高いものから順に、次の利用手段が使われます。

  1. スマートタップ: スマートタップ ペイロードが指定され、デバイスがサポートしている場合 NFC/HCE <ph type="x-smartling-placeholder">
      </ph>
    • ユーザーが [コードを表示] をクリックすると、ローテーション バーコード / 静的バーコードが強制的に表示され、これをオーバーライドできます。
  2. ローテーション バーコード: ローテーション バーコードのペイロードが指定されている場合
  3. 静的バーコード: バーコードのペイロードが指定されている場合

クーポン利用ペイロードを複数指定すると、すべてのユーザーが対象になりますが、 セキュリティ上の影響を及ぼす可能性があります。特に、ローテーション バーコードの代替策として静的バーコードを使用すると、ローテーション バーコードを使用する際のセキュリティ上のメリットのほとんどが帳消しになります。静的なバーコード フォールバックはウェブビューにのみ表示されます ローテーション バーコードをサポートしていないクライアントでも使用できます。現時点では、すべての Google ウォレット クライアントでローテーション バーコードがサポートされています。

保存フロー

Google Wallet API には、次のようないくつかのフローがあります。

  • 保存の際または事前にギフトカード クラスを作成する
  • JWT で完全なオブジェクトを送信するか、事前にオブジェクトを保存する JWT で ID で参照します。
  • 保存後のオブジェクトの更新

提案された rotatingBarcode フィールドは、これらすべてのフローと互換性があります。 ただし、セキュリティを強化するために、次のことをおすすめします。

  • object:insert API を呼び出して、パスを [Google ウォレットに追加] ボタンを JWT 内の ID で特定のオブジェクトを参照します。これにより 生成される JWT にローテーション バーコードの秘密鍵は含まれません。
  • 単一のパスをスコープとする OTP 秘密鍵を使用する
  • この鍵は、更新されない限り、パスの存続期間中は有効であることが期待されます。Google は、通常のオペレーション中、この鍵がその頻度にかかわらず更新されないことを想定しています。

次のシーケンス図は、さまざまなアクター間のフローを示しています。 一般的な統合の場合:

ローテーション バーコードの使用に関するシーケンス図