Вращающиеся штрих-коды

Введение

Вращающиеся штрих-коды выглядят так же, как обычные штрих-коды, но меняются периодически, обычно каждую минуту, а терминал/считыватель запрограммирован на прием только самого последнего штрих-кода. Эта мера безопасности снижает риски, связанные со снятием скриншотов штрих-кода, в частности кражу билета или несанкционированную перепродажу билета. Вращающиеся штрих-коды также могут служить запасным вариантом для устройств, которые не могут использовать преимущества Smart Tap из-за отсутствия поддержки NFC (отсутствие оборудования или отключенное программное обеспечение).

Справочник по API

Технические подробности о вращающихся штрих-кодах см. в разделе Тип RotatingBarcode .

Пример полезной нагрузки

{
  "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. Smart Tap: если указана полезная нагрузка Smart-Tap и если устройство поддерживает NFC/HCE.
   • Обратите внимание: пользователь может отменить это действие, нажав «Показать код», что приведет к принудительному отображению вращающегося/статического штрих-кода.
2. Вращающийся штрих-код: если указана вращающаяся полезная нагрузка штрих-кода.
3. Статический штрих-код: если указана полезная нагрузка штрих-кода.

Указание нескольких полезных данных погашения может гарантировать поддержку всех пользователей, но может иметь последствия для безопасности. В частности, использование статического штрих-кода в качестве альтернативы вращающемуся штрих-коду сводит на нет большую часть преимуществ безопасности, связанных с использованием вращающихся штрих-кодов. Резервный статический штрих-код будет отображаться только в веб-представлениях или на клиентах, которые не поддерживают вращающиеся штрих-коды. На сегодняшний день мы ожидаем, что все клиенты Google Кошелька будут поддерживать чередующиеся штрих-коды.

Сохранить поток

API Google Кошелька предлагает несколько потоков, в том числе:

• Создание транзитных классов в кратчайшие сроки или заранее
• Отправка полных объектов в JWT или предварительное сохранение объектов с последующей ссылкой на них по идентификатору в JWT.
• Обновление объектов после их сохранения

Предлагаемое поле RotatingBarcode совместимо со всеми этими потоками, однако в целях повышения безопасности мы предлагаем следующее:

• Вызовите API object:insert , чтобы вставить пропуск на сервер Google Кошелька, и настройте кнопку «Добавить в Google Кошелек» для ссылки на конкретный объект по идентификатору в вашем JWT. Это гарантирует, что полученный JWT не будет включать секретный ключ вращающегося штрих-кода.
• Используйте секретный ключ OTP, ограниченный одним проходом.
• Ожидается, что ключ, если он не будет обновлен, будет действителен в течение всего срока действия пропуска. Мы не ожидаем, что этот ключ будет обновляться с какой-либо частотой в ходе нормальной работы.

Следующая диаграмма последовательности иллюстрирует поток между различными участниками типичной интеграции: