Брелки NFC для систем членства: UID, NDEF и сопоставление участников

Брелок NFC может идентифицировать участника, открыть веб-интерфейс или сделать и то, и другое. Ошибка состоит в том, чтобы рассматривать их как один и тот же технический рабочий процесс.

В программе членства или лояльности ключевой вопрос заключается не просто в том, какой чип NFC купить. Этокакому идентификатору будет доверять система, где будет храниться запись участника и как будет выдаваться, заменяться, деактивироваться и переназначаться физический брелок без нарушения этого сопоставления.

В этом руководстве основное внимание уделяется этой архитектуре данных. Оно предназначено для операторов спортивных залов, клубов, платформ лояльности, системных интеграторов-членства и отделов закупок, планирующих массовое развертывание брелоков NFC.

 

Начните с транзакции членства, а не с брелока

Брелок NFC является удостоверением личности. Он не подсчитывает баллы, не решает, активно ли членство, не хранит авторитетный профиль клиента и не применяет бизнес-правила самостоятельно.

Взаимодействие с членством обычно происходит по одному из двух путей:

Выделенный-путь чтения:
участник → брелок NFC → совместимый считыватель → идентификатор учетных данных → программное обеспечение для участия → запись участника → регистрация-/преимущество/разрешение

Путь касания-телефона:
участник → брелок NFC → смартфон → URL-адрес NDEF → серверная часть веб-сайта или приложения → запись учетной записи или кампании → действие членства

Эти пути могут использовать один и тот же физический форм-фактор, но у них разные технические требования.

Если проект в первую очередь направлен на доступ к дверям, а не на идентификацию членства, то контролирующим требованием является установленная система доступа. Синтек'сРуководство по совместимости бесконтактных брелоковохватывает эту другую пользовательскую задачу.

 

UID, NDEF и идентификатор участника — три разные вещи

Проекты членства часто терпят неудачу, поскольку некоторые идентификаторы считаются взаимозаменяемыми.

Форум NFC определяетНДЭФв качестве общего формата данных приложений на устройствах и тегах, совместимых с NFC Forum-. Запись NDEF может содержать URI или другую полезную нагрузку приложения, но бизнес-значение этой записи принадлежит приложению, стоящему за ней.

NXPДокументация NTAG213/215/216подтверждает, что семейство NTAG21x поддерживает поведение тегов NFC Forum Type 2, структуры данных ISO/IEC 14443 Type A и NDEF. Он также предоставляет UID,-запрограммированный производителем. Эти возможности полезны, но они по-прежнему представляют разные уровни: UID для идентификации чипа, NDEF для данных приложения и внутренние записи для логики членства.

 

Выберите одну из трех архитектур членства

1. Специальный считыватель + сопоставление учетных данных

В этой модели оператор выдает каждый брелок в качестве системных учетных данных. Совместимый считыватель фиксирует идентификатор или данные приложения, ожидаемые платформой членства. Серверная часть сопоставляет эти учетные данные с записью участника.

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

Критические вопросы:

• Какой именно чип или технологию учетных данных поддерживает установленное считывающее устройство?
• Какое значение регистрирует программное обеспечение: UID, номер карты, данные сектора/файла или другой идентификатор,-определяемый системой?
• Может ли один участник иметь несколько активных учетных данных?
• Можно ли отключить учетные данные независимо от учетной записи участника?
• Как обрабатываются потерянные, возвращенные или замененные брелоки?

NDEF может не иметь значения в этой архитектуре. Брелок может быть действительным удостоверением членства, даже если URL-адрес,-читаемый телефоном, не требуется.

2. Нажмите на телефон + URL-адрес NDEF.

При первом членстве-по телефону брелок обычно содержит URI NDEF, который указывает на веб-страницу, процесс активации, портал учетной записи, страницу программы лояльности или маршрут приложения.

Технический обзор NFC-форумаописывает теги форума NFC как носители сообщений NDEF, которые могут инициировать такие действия, как открытие интернет-ссылки. Apple также документирует фоновое чтение тегов NFC вокруг записей URI NDEF на поддерживаемых iPhone вОсновной NFC.

Для этой архитектуры уникальный URL-адрес обычно должен содержать непрозрачный токен или идентификатор проекта, а не раскрывать имя участника, адрес электронной почты, баланс или другие ненужные личные данные непосредственно в теге.

Затем веб-сервер может преобразовать этот токен в соответствующую запись и решить, что пользователю разрешено видеть или делать.

3. Гибридная читалка + взаимодействие с телефоном

В некоторых проектах требуется, чтобы один брелок поддерживал управляемый рабочий процесс считывания и возможность-прослушивания телефона.

Это может быть полезно, например, когда тренажерному залу нужен специальный считыватель для регистрации,-и при этом он позволяет участнику нажать на тот же брелок на телефоне, чтобы открыть страницу учетной записи.

Не думайте, что эти два пути автоматически совместимы, поскольку они используют один и тот же чип NFC. Проверьте их отдельно:

• считыватель должен поддерживать точную технологию учетных данных и идентификатор, используемые системой членства;
• телефонный путь должен прочитать утвержденную полезную нагрузку NDEF и открыть ожидаемый пункт назначения;
• серверная часть должна знать, как идентификатор-стороны читателя и токен стороны NDEF-относятся к одному и тому же аккаунту;
• замена должна обновить оба пути, если оба остаются активными.

 

 

Решите, какая запись является источником истины

Самый безопасный дизайн членства обычно сохраняетучетная запись участникакак источник истины и рассматривает брелок как назначаемые учетные данные.

Такое разделение упрощает замену и переназначение.

Это позволяет оператору приостановить членство без физической перезаписи брелока, заменить поврежденный брелок без создания новой учетной записи участника и сохранить историю транзакций при изменении учетных данных.

 

Создайте сопоставление перед кодированием пакета

Не начинайте создание переменных-данных с одного столбца таблицы под названием "ID". Сначала определите связь между идентификаторами.

Карта производства и развертывания может включать в себя:

Для обеспечения конфиденциальности и оперативного контроля поставщику обычно не требуется полный профиль участника. Более чистая модель — отделить файл сопоставления добычи от членской базы данных оператора.

Например, поставщик может вернуть:

печатный серийный номер ↔ UID ↔ закодированный жетон ↔ статус производства

Затем оператор может добавить:

учетные данные ↔ идентификатор участника ↔ статус членства

после выдачи.

 

Не используйте UID в качестве ярлыка безопасности

UID полезен для идентификации, но идентификация и аутентификация — это разные функции безопасности.

Для поиска лояльности с низким-риском может быть достаточно сопоставить поддерживаемый идентификатор учетных данных с серверной учетной записью. Для случаев использования с повышенным-риском, таких как безопасный доступ к объектам, хранение ценностей или оплата, системе может потребоваться более строгая аутентификация по чипу, защита данных приложений, управление ключами и безопасность на стороне считывателя-.

Базовый брелок NFC не следует называть безопасным только потому, что его чип имеет уникальный серийный номер. Требуемый уровень безопасности должен определяться моделью угроз владельца системы и спецификацией платформы.

Аналогично, область памяти,-защищенная паролем, — это не то же самое, что криптографическая аутентификация.

 

План утерян-ключ-брелок, замена перед запуском

Рабочий процесс замены должен сохранить учетную запись участника при изменении активных учетных данных.

Практическая последовательность такова:

1. Найдите учетную запись участника.
2. Отметьте утерянные учетные данные как неактивные.
3. Убедитесь, что старый идентификатор стороны чтения-заблокирован от дальнейшего использования.
4. Выдайте новый брелок.
5. Сопоставьте новые учетные данные с существующей учетной записью участника.
6. Если в проекте используется уникальный токен NDEF, решите, нужно ли также отключить или повернуть старый токен.
7. Проверьте новый брелок на реальном считывателе или рабочем процессе телефона.
8. Подтвердите, что старые учетные данные больше не завершают действие защищенного членства.

Вот почему учетная запись участника не должна быть постоянно привязана к одному физическому UID без уровня административной замены.

 

Переназначение отличается от замены

При замене сохраняется тот же участник и изменяются учетные данные. При переназначении физические учетные данные сохраняются, а член изменяется.

Эта разница имеет значение для многоразовых брелоков в спортивных залах, клубах, программах аренды и управляемых объектах.

Прежде чем передать возвращенный брелок другому человеку:

• удалить старые отношения участников;
• подтвердите, что старая учетная запись все еще не может использовать учетные данные;
• осмотрите физический брелок;
• считать электронный идентификатор;
• обновлять или перезаписывать содержимое NDEF, если проект использует данные,-специфичные для участников;
• рассмотрите возможность ротации уникального веб-токена, если старую ссылку можно было скопировать, добавить в закладки или поделиться ею;
• назначить учетные данные новому участнику;
• протестируйте конечный результат чтения и/или телефона.

Правила переназначения должны определяться владельцем системы. Тот факт, что брелок можно физически использовать повторно, не доказывает, что данные приложения или отношения с учетными записями готовы к повторному использованию.

 

Избегайте хранения ненужных данных участника на брелоке

Данные о членстве меняются. Имена, статус плана, баллы, преимущества и контактные данные могут быть изменены без замены физических учетных данных.

По этой причине во многих проектах легче работать, когда брелок хранит или предоставляет только стабильный идентификатор или непрозрачный URL-токен, а серверная часть хранит меняющиеся бизнес-данные.

Это уменьшает необходимость перезаписывать учетные данные и ограничивает объем информации об участниках, раскрываемой, если кто-то сканирует или читает тег.

Если проекту действительно необходимы защищенные данные учетных данных, выберите чип и архитектуру безопасности из системных требований, а не начинайте с обычного продукта NTAG и пытайтесь добавить безопасность позже.

 

Определите повторяющиеся правила перед регистрацией

Есть две разные проблемы дублирования:

• дубликаты электронных идентификаторов или закодированных токеновв изготовленной партии;
• дублировать активные заданияв базе данных участников.

План приемки должен учитывать и то, и другое.

Правильно изготовленный брелок все равно может быть зарегистрирован не тому участнику. Правильно зарегистрированный участник по-прежнему может иметь два активных учетных данных, хотя бизнес-правило предусматривает только один. Это разные владельцы сбоев, и их следует регистрировать отдельно.

 

Тестируйте готовый рабочий процесс членства, а не только обнаружение NFC

За полной транзакцией следует полезный образец теста.

Чтобы получить более широкий опыт тестирования данных NFC, пунктов назначения и картографирования перед массовым производством, SyntekКонтрольный список тестирования NFCобъясняет, почему успешный кран — это не то же самое, что успешный бизнес-процесс.

 

Что указать в запросе на брелок членства NFC

Для прямого получения физических учетных данных компания SyntekСтраница продукта с брелоком NFCследующий шаг в рекламе. Выбор продукта должен соответствовать утвержденной архитектуре системы, а не заменять ее.

 

Правило развертывания

Для участия в программе членства или программы лояльности рассматривайте брелок NFC как назначаемые учетные данные, а не как базу данных участников.

Надежная последовательность развертывания:

задача членства → путь к считывателю или телефону → технология учетных данных → решение UID/NDEF → внутренняя модель члена → картирование производства → правила выпуска/замены/переназначения → законченный-образец теста → массовое утверждение

Эта последовательность сохраняет физический брелок, электронный идентификатор, телефонное взаимодействие и записи участников в одной контролируемой модели данных. Это также позволяет управлять заменой утерянного-брелока и будущим переназначением вместо того, чтобы вручную создавать исключения в базе данных.