輪替條碼

簡介

旋轉條碼看起來與一般條碼相似，但通常會每分鐘變更一次，而終端機/讀取器經過設計後只會接受最新的條碼。這項安全措施可降低與條碼螢幕截圖有關的風險，尤其是竊盜票或未經授權的票券轉售。如果裝置不支援 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
    • 請注意，使用者只要點選「顯示程式碼」就能覆寫這項設定，強制顯示旋轉的條碼/靜態條碼。
  2. 輪替條碼：如果指定了輪替的條碼酬載
  3. 靜態條碼：如果已指定條碼酬載

指定多個兌換酬載可確保系統支援所有使用者，但這可能會帶來安全性影響。具體來說，使用靜態條碼做為旋轉條碼的備用方案，將大幅降低使用輪替條碼的好處，只有網頁檢視畫面或不支援旋轉條碼的用戶端，才會顯示靜態條碼備用項。從今天起，我們希望所有 Google 錢包用戶端都支援輪替條碼。

儲存流程

Google Wallet API 提供以下幾種流程：

  • 節省時間或預先建立大眾運輸類別
  • 傳送 JWT 中完整的物件，或是預先儲存物件，然後在 JWT 中依 ID 參照這些物件
  • 在儲存物件後更新物件

建議的 rotatingBarcode 欄位與這些流程相容，但為了提高安全性，建議您採取下列做法：

  • 呼叫 object:insert API，將票證插入 Google 錢包伺服器並設定「新增至 Google 錢包」按鈕，以便在 JWT 中依據 ID 參照特定物件。這樣可以確保產生的 JWT 不含輪替條碼的密鑰。
  • 使用限定為單次票證的動態密碼密鑰
  • 金鑰除非更新，否則應在票證的生命週期內有效。我們預計在正常作業期間，這個金鑰應該不會收到任何頻率更新。

下圖說明典型整合作業的各執行者之間的流程：

使用旋轉條碼的序列圖