Codes-barres rotatifs

Introduction

Les codes-barres rotatifs ressemblent à des codes-barres standards, mais changent régulièrement, généralement toutes les minutes. Le terminal ou lecteur est programmé pour n'accepter que la dernière version. Cette mesure de sécurité réduit les risques associés à la capture d'écran de codes-barres, en particulier le vol de billets ou la revente de billets non autorisée. La rotation des codes-barres peut également faire office de solution de remplacement pour les appareils qui ne peuvent pas bénéficier de la fonctionnalité Smart Tap, car ils ne sont pas compatibles avec la technologie NFC (incompatibilité matérielle ou logiciel désactivé).

Documentation de référence de l'API

Pour obtenir des informations techniques sur la rotation des codes-barres, reportez-vous au type RotatingBarcode.

Exemple de charge utile

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"
        }
      ]
    }
  }
}

Mécanismes de remplacement

Sur l'appareil de l'utilisateur, un seul mécanisme d'utilisation est utilisé à la fois, en fonction de la configuration de la carte et des fonctionnalités de l'appareil. Voici les mécanismes d'utilisation classés par ordre de priorité :

  1. Smart Tap : si une charge utile Smart Tap est spécifiée et si l'appareil est compatible avec NFC/HCE
    • Notez que l'utilisateur peut la remplacer en cliquant sur "Afficher le code", ce qui force l'affichage du code-barres rotatif/statique.
  2. Code-barres rotatif : si une charge utile de code-barres rotatif est spécifiée
  3. Code-barres statique : si une charge utile de code-barres est spécifiée

La spécification de plusieurs charges utiles permet de garantir la disponibilité pour tous les utilisateurs, mais peut avoir des implications en termes de sécurité. En particulier, l'utilisation d'un code-barres statique en remplacement d'un code-barres rotatif annule la plupart des avantages liés à ce dernier. Les codes-barres statiques utilisés en remplacement ne s'affichent que dans les vues Web ou sur les clients non compatibles avec les codes-barres rotatifs. À présent, tous les clients Google Wallet devraient être compatibles avec les codes-barres rotatifs.

Flux d'enregistrement

L'API Google Wallet propose plusieurs flux, y compris :

  • Créer les classes des cartes cadeaux au moment de la sauvegarde ou à l'avance
  • Envoyer les objets complets dans votre JWT ou enregistrer les objets à l'avance, puis les référencer par ID dans votre JWT
  • Mettre à jour les objets après leur enregistrement

Le champ "rotatingBarcode" proposé est compatible avec tous ces flux. Toutefois, pour une sécurité optimale, nous vous suggérons de procéder comme suit :

  • Appelez l'API object:insert pour insérer la carte sur le serveur Google Wallet et configurer le bouton "Ajouter à Google Wallet" de manière à référencer l'objet spécifique par ID dans votre jeton JWT. De la sorte, le jeton JWT obtenu n'inclut pas la clé secrète du code-barres rotatif.
  • Utilisez une clé secrète OTP limitée à une seule carte.
  • À moins qu'elle ne soit mise à jour, la clé doit être valide pendant toute la durée de vie de la carte. Il n'est pas prévu que cette clé soit mise à jour selon une fréquence donnée lors d'une opération standard.

Le schéma de séquence suivant illustre le flux entre les différents acteurs pour une intégration type :

Schéma séquentiel pour l'utilisation de codes-barres rotatifs