会員システム用の NFC キーフォブ: UID、NDEF、および会員マッピング

NFC キー フォブは、メンバーの識別、Web エクスペリエンスの開始、またはその両方を行うことができます。間違いは、これらを同じ技術的なワークフローとして扱うことです。

メンバーシップ プログラムやロイヤルティ プログラムにおいて重要な問題は、単にどの NFC チップを購入するかということではありません。それはシステムがどの識別子を信頼するか、メンバーレコードがどこに存在するか、マッピングを壊すことなく物理キーフォブがどのように発行、交換、非アクティブ化、再割り当てされるか.

このガイドでは、そのデータ アーキテクチャに焦点を当てます。これは、NFC キーフォブの一括導入を計画しているジム運営者、クラブ、ロイヤルティ プラットフォーム、会員制システム インテグレーター、調達チームを対象としています。-

 

キーホルダーではなくメンバーシップ取引から始めましょう

NFC キー フォブは認証情報です。ポイントの計算、メンバーシップが有効かどうかの決定、信頼できる顧客プロファイルの保存、ビジネス ルールの適用などは、それ自体では行われません。

メンバーシップの対話は通常、次の 2 つのパスのいずれかをたどります。

専用の-リーダー パス:
メンバー → NFC キーフォブ → 互換性のあるリーダー → 認証情報 ID → メンバーシップ ソフトウェア → メンバー レコード → チェックイン / 特典 / 権限-

スマートフォンの-タップパス:
メンバー → NFC キーフォブ → スマートフォン → NDEF URL → ウェブまたはアプリのバックエンド → アカウントまたはキャンペーンレコード → メンバーシップアクション

これらのパスは同じ物理フォーム ファクターを使用できますが、同じ技術要件はありません。

プロジェクトがメンバーシップの識別ではなく主にドアへのアクセスである場合、制御要件は設置されたアクセス システムです。シンテックの近接キーフォブ互換性ガイドでは、そのさまざまなユーザー タスクについて説明します。

 

UID、NDEF、メンバー ID は 3 つの異なるものです

メンバーシップ プロジェクトは、いくつかの識別子が交換可能として扱われるため、失敗することがよくあります。

NFC フォーラムは次のように定義しています。NDEFNFC フォーラムに準拠したデバイスとタグ上のアプリケーション データの共通形式として使用されます。{0} NDEF レコードには URI または別のアプリケーション ペイロードを含めることができますが、そのレコードのビジネス上の意味は、その背後にあるアプリケーションに属します。

NXPのNTAG213/215/216 のドキュメントNTAG21x ファミリが NFC フォーラム タイプ 2 タグの動作、ISO/IEC 14443 タイプ A、および NDEF データ構造をサポートしていることを確認します。また、メーカーがプログラムした UID も提供します。-これらの機能は便利ですが、チップ ID の UID、アプリケーション データの NDEF、メンバーシップ ロジックのバックエンド レコードなど、依然として異なるレイヤーを表しています。

 

3 つのメンバーシップ アーキテクチャから 1 つを選択

1. 専用リーダー + 認証情報マッピング

このモデルでは、オペレーターは各キー フォブをシステム資格情報として発行します。互換性のあるリーダーは、メンバーシップ プラットフォームが期待する識別子またはアプリケーション データをキャプチャします。バックエンドは、その資格情報をメンバー レコードにマップします。

このアーキテクチャは、定期的なチェックイン、クラブ入場、ロッカー、スタッフによるロイヤルティ認識、およびオペレーターがリーダーを制御するその他の管理されたタッチポイントに適しています。{0}{1}

重要な質問は次のとおりです。

• インストールされているリーダーは、正確にどのチップまたは認証テクノロジーをサポートしていますか?
• ソフトウェアは、UID、カード番号、セクター/ファイル データ、または別のシステム定義の識別子のどれを登録しますか?{0}}
• 1 人のメンバーが複数の有効な資格情報を持つことができますか?
• 資格情報をメンバーアカウントとは別に無効にすることはできますか?
• フォブの紛失、返品、交換はどのように処理されますか?

NDEF は、このアーキテクチャでは無関係である可能性があります。キーフォブは、携帯電話で読み取り可能な URL が必要ない場合でも、有効なメンバーシップ認証情報として使用できます。-

2. 電話タップ + NDEF URL

スマートフォンでの最初のメンバーシップ エクスペリエンスでは、キー フォブには通常、ウェブページ、アクティベーション フロー、アカウント ポータル、ポイント ページ、またはアプリ ルートを指す NDEF URI が含まれています。

のNFCフォーラムの技術概要では、NFC フォーラム タグを、インターネット リンクを開くなどのアクションをトリガーできる NDEF メッセージのキャリアとして説明しています。 Apple は同様に、サポートされている iPhone 上の NDEF URI レコードに関するバックグラウンドの NFC タグ読み取りを文書化しています。コアNFC.

このアーキテクチャでは、メンバーの名前、電子メール、残高、その他の不必要な個人データをタグ内で直接公開するのではなく、一意の URL に通常、不透明なトークンまたはプロジェクト ID を含める必要があります。

Web バックエンドは、そのトークンを適切なレコードに解決し、ユーザーに何を表示または実行できるかを決定します。

3. ハイブリッドリーダー + 電話インタラクション

一部のプロジェクトでは、1 つのキーフォブでマネージド リーダーのワークフローと電話タップ エクスペリエンスをサポートする必要があります。{0}

これは、たとえば、ジムがチェックイン用の専用リーダーを必要とすると同時に、会員が携帯電話で同じフォブをタップしてアカウント ページを開くこともできるようにしたい場合に便利です。{0}}

2 つのパスは同じ NFC チップを共有しているため、自動的に互換性があると想定しないでください。それらを個別に検証します。

• リーダーは、メンバーシップ システムで使用される正確な資格情報テクノロジと識別子をサポートする必要があります。
• 電話パスは、承認された NDEF ペイロードを読み取り、予期される宛先を開く必要があります。
• バックエンドは、リーダー{0}}側の識別子と NDEF- 側のトークンが同じアカウントにどのように関連しているかを認識している必要があります。
• 両方のパスがアクティブなままである場合、交換では両方のパスを更新する必要があります。

 

 

どの記録が真実の情報源であるかを決定する

最も安全なメンバーシップ設計では、通常、メンバーアカウントを信頼できる情報源として扱い、キー フォブを割り当て可能な資格情報として扱います。

この分離により、交換や再割り当てが容易になります。

これにより、オペレーターは物理的にフォブを書き換えることなくメンバーを一時停止したり、新しいメンバーシップ アカウントを作成せずに破損したキー フォブを交換したり、資格情報が変更されたときにトランザクション履歴を保存したりできます。

 

バッチをエンコードする前にマッピングを構築する

「ID」という名前の 1 つのスプレッドシート列を使用して変数データの作成を開始しないでください。{0}まず識別子間の関係を定義します。

製造および展開マップには次のものが含まれる場合があります。

プライバシーと運用管理のため、サプライヤーは通常、完全なメンバー プロフィールを必要としません。よりクリーンなモデルは、運用マッピング ファイルをオペレーターのメンバー データベースから分離することです。

たとえば、サプライヤーは次のものを返すことができます。

印刷されたシリアル ↔ UID ↔ エンコードされたトークン ↔ 生産ステータス

その後、オペレーターは以下を追加できます。

資格情報 ↔ 会員ID ↔ 会員ステータス

発行後。

 

UID をセキュリティ ショートカットとして使用しないでください

UID は識別に役立ちますが、識別と認証は異なるセキュリティ機能です。

低リスクのロイヤルティ検索の場合は、サポートされている認証情報識別子をバックエンド アカウントにマッピングするだけで十分な場合があります。{0}安全な施設へのアクセス、価値の保存や支払いなど、リスクの高いユースケースでは、システムにより強力なチップ認証、保護されたアプリケーション データ、キー管理、リーダー側のセキュリティが必要になる場合があります。-

基本的な NFC キーフォブは、そのチップに固有のシリアル番号があるという理由だけで安全であると表現されるべきではありません。必要なセキュリティ レベルは、システム所有者の脅威モデルとプラットフォームの仕様に基づいて決定される必要があります。

同様に、パスワードで保護されたメモリ領域は暗号認証と同じではありません。{0}}

 

発売前に紛失した-キー-フォブの交換を計画する

置換ワークフローでは、アクティブな資格情報を変更する際にメンバー アカウントを保持する必要があります。

実際のシーケンスは次のとおりです。

1. メンバーアカウントを見つけます。
2. 紛失した資格情報を非アクティブとしてマークします。
3. 古いリーダー側の識別子が今後の使用からブロックされているかどうかを確認します。{0}
4. 交換用のキーフォブを発行します。
5. 新しい認証情報を既存のメンバー アカウントにマッピングします。
6. プロジェクトが一意の NDEF トークンを使用している場合は、古いトークンも無効にするかローテーションする必要があるかどうかを決定します。
7. 実際のリーダーまたは電話ワークフローで新しいフォブを確認します。
8. 古い資格情報では保護されたメンバーシップのアクションが完了しなくなっていることを確認します。

このため、管理置換層なしでメンバー アカウントを 1 つの物理 UID に永続的に関連付けるべきではありません。

 

再割り当ては置換とは異なる操作です

置換では同じメンバーが維持され、資格情報が変更されます。再割り当てでは、物理的な資格情報が保持され、メンバーが変更されます。

この違いは、ジム、クラブ、レンタル プログラム、管理施設の再利用可能なキーフォブにとって重要です。

返品されたフォブを他の人に渡す前に:

• 古いメンバー関係を削除します。
• 古いアカウントが引き続き資格情報を使用できないことを確認します。
• 物理的なキーフォブを検査します。
• 電子識別子を読み戻します。
• プロジェクトでメンバー固有のデータが使用されている場合は、NDEF コンテンツを更新または上書きします。{0}
• 古いリンクがコピー、ブックマーク、または共有された可能性がある場合は、一意の Web トークンをローテーションすることを検討してください。
• 新しいメンバーに資格情報を割り当てます。
• 最終的なリーダーや電話の結果をテストします。

再割り当てルールはシステム所有者が定義する必要があります。キー フォブが物理的に再利用できるという事実は、アプリケーション データまたはアカウント関係が再利用できる状態にあることを証明するものではありません。

 

キーフォブに不必要なメンバーデータを保存しないようにする

会員データが変わります。名前、プランのステータス、ポイント、特典、連​​絡先の詳細はすべて、物理的な認証情報を置き換えることなく変更できます。

そのため、キー フォブが安定した識別子または不透明な URL トークンのみを保存または公開し、バックエンドが変化するビジネス データを保存すると、多くのプロジェクトが操作しやすくなります。

これにより、認証情報を書き換える必要性が減り、誰かがタグをスキャンまたは読み取った場合に公開されるメンバー情報の量が制限されます。

プロジェクトで認証情報上の保護されたデータが本当に必要な場合は、汎用の NTAG 製品から始めて後からセキュリティを追加するのではなく、システム要件からチップとセキュリティ アーキテクチャを選択します。

 

登録前に重複ルールを定義する

次の 2 つの異なる重複問題があります。

• 重複した電子識別子またはエンコードされたトークン製造されたバッチ内で。
• アクティブな割り当てが重複している会員データベースにあります。

受け入れ計画では両方を検出する必要があります。

正しく製造されたキー フォブでも、間違ったメンバーに登録される可能性があります。ビジネス ルールで 1 つだけが意図されている場合でも、正しく登録されたメンバーは 2 つのアクティブな資格情報を持つことができます。これらは異なる障害所有者であるため、個別にログに記録する必要があります。

 

NFC 検出だけでなく、完成したメンバーシップ ワークフローをテストする

トランザクション完了後には、役立つサンプル テストが行​​われます。

大量生産前の NFC データ、宛先、マッピングのテストに関する幅広い背景については、Syntek のNFCテストのチェックリストタップの成功がビジネス ワークフローの成功と同じではない理由を説明します。

 

NFC メンバーシップ キー フォブの RFQ に記載する内容

物理的な認証情報を直接入手するには、Syntek のNFCキーホルダー製品ページ商業的な次のステップです。製品の選択は、承認されたシステム アーキテクチャを置き換えるのではなく、それに従う必要があります。

 

展開ルール

メンバーシップまたはロイヤルティ プログラムの場合、NFC キー フォブをメンバー データベースとしてではなく、割り当て可能な資格情報として扱います。

堅牢な展開シーケンスは次のとおりです。

メンバーシップ タスク → リーダーまたは電話パス → 認証情報テクノロジー → UID/NDEF 決定 → バックエンド メンバー モデル → 運用マッピング → 発行/交換/再割り当てルール → 終了-サンプル テスト → 一括承認

このシーケンスにより、物理的なキーフォブ、電子識別子、電話でのやり取り、およびメンバーの記録が 1 つの制御されたデータ モデルの下に保持されます。また、紛失したフォブの交換や将来の再割り当ても、手動のデータベース例外にせずに管理可能になります。