Klíčenky NFC pro členské systémy: UID, NDEF a mapování členů

NFC klíčenka může identifikovat člena, otevřít webovou zkušenost nebo obojí. Chybou je, že se s nimi zachází jako se stejným technickým pracovním postupem.

V členském nebo věrnostním programu není klíčovou otázkou pouze to, jaký čip NFC koupit. To jekterému identifikátoru bude systém důvěřovat, kde bude uložen záznam člena a jak bude fyzický přívěsek na klíče vydáván, nahrazován, deaktivován a znovu přiřazen, aniž by došlo k porušení tohoto mapování.

Tato příručka se zaměřuje na tuto datovou architekturu. Je určen pro provozovatele posiloven, kluby, věrnostní platformy, členské-systémové integrátory a týmy pro nákup, které plánují hromadné nasazení NFC klíčenky.

 

Začněte u členské transakce, ne u přívěsku na klíče

Klíčenka NFC je pověření. Nepočítá body, nerozhoduje o tom, zda je členství aktivní, neukládá autoritativní profil zákazníka ani neuplatňuje obchodní pravidla.

Interakce členství obvykle probíhá jednou ze dvou cest:

Vyhrazená-cesta čtenáře:
člen → NFC klíčenka → kompatibilní čtečka → identifikátor pověření → členský software → záznam člena → přihlášení- / výhoda / oprávnění

Cesta pro telefon-klepnutí:
člen → NFC klíčenka → smartphone → NDEF URL → backend webu nebo aplikace → záznam účtu nebo kampaně → akce členství

Tyto cesty mohou používat stejný fyzický tvarový faktor, ale nemají stejné technické požadavky.

Pokud je projekt primárně přístup ke dveřím spíše než identifikace členství, je kontrolním požadavkem nainstalovaný přístupový systém. Syntek'sprůvodce kompatibilitou bezdotykových klíčenekpokrývá tento odlišný uživatelský úkol.

 

UID, NDEF a Member ID jsou tři různé věci

Členské projekty často selhávají, protože několik identifikátorů je považováno za vzájemně zaměnitelné.

Fórum NFC definujeNDEFjako běžný formát dat aplikací v zařízeních a značkách-kompatibilních s NFC Forum. Záznam NDEF může nést URI nebo jinou aplikační datovou část, ale obchodní význam tohoto záznamu náleží aplikaci, která za ním stojí.

NXPdokumentace NTAG213/215/216potvrzuje, že řada NTAG21x podporuje chování značek NFC Forum Type 2, datové struktury ISO/IEC 14443 typu A a NDEF. Poskytuje také výrobcem-naprogramované UID. Tyto funkce jsou užitečné, ale stále představují různé vrstvy: UID pro identitu čipu, NDEF pro data aplikací a backendové záznamy pro logiku členství.

 

Vyberte si jednu ze tří architektur členství

1. Vyhrazená čtečka + mapování pověření

V tomto modelu operátor vydává každou klíčenku jako systémové pověření. Kompatibilní čtečka zachytí identifikátor nebo data aplikace očekávaná členskou platformou. Backend mapuje toto pověření na záznam člena.

Tato architektura je vhodná pro opakované odbavení-, vstup do klubu, skříňky,{1}}asistované rozpoznávání věrnosti zaměstnanců a další spravované kontaktní body, kde operátor ovládá čtečku.

Kritické otázky jsou:

• Jaký konkrétní čip nebo technologii pověření nainstalovaná čtečka podporuje?
• Jakou hodnotu software zapisuje: UID, číslo karty, data sektoru/souboru nebo jiný systém{0}}definovaný identifikátor?
• Může mít jeden člen více než jedno aktivní pověření?
• Lze přihlašovací údaje zakázat nezávisle na členském účtu?
• Jak se nakládá se ztracenými, vrácenými nebo vyměněnými přívěsky?

NDEF může být v této architektuře irelevantní. Přívěšek na klíče může být platným pověřením členství, i když není vyžadována adresa URL čitelná pro telefon-.

2. Telefon klepněte na + NDEF URL

Při prvním{0}}členství po telefonu nese klíčenka obvykle identifikátor URI NDEF, který odkazuje na webovou stránku, postup aktivace, portál účtu, věrnostní stránku nebo cestu aplikace.

TheTechnický přehled fóra NFCpopisuje NFC Forum Tags jako nosiče zpráv NDEF, které mohou spouštět akce, jako je otevření internetového odkazu. Apple také dokumentuje čtení NFC tagů na pozadí kolem záznamů NDEF URI na podporovaných iPhonechJádro NFC.

Pro tuto architekturu by měla jedinečná adresa URL obvykle obsahovat neprůhledný token nebo identifikátor projektu, spíše než odhalovat jméno člena, e-mail, zůstatek nebo jiná nepotřebná osobní data přímo v tagu.

Webový backend pak může tento token převést na příslušný záznam a rozhodnout, co smí uživatel vidět nebo dělat.

3. Hybridní čtečka + interakce s telefonem

Některé projekty požadují jednu klíčenku pro podporu pracovního postupu spravované čtečky a{0}}klepání na telefon.

To může být užitečné, například když posilovna požaduje vyhrazenou čtečku pro přihlášení-a zároveň umožňuje členovi klepnout na stejný přívěsek s telefonem a otevřít stránku účtu.

Nepředpokládejte, že tyto dvě cesty jsou automaticky kompatibilní, protože sdílejí stejný čip NFC. Ověřte je samostatně:

• čtenář musí podporovat přesnou technologii pověření a identifikátor používaný členským systémem;
• telefonní cesta musí číst schválený náklad NDEF a otevřít očekávaný cíl;
• backend musí vědět, jak souvisí -identifikátor na straně čtenáře a token na straně NDEF{1}} ke stejnému účtu;
• náhrada musí aktualizovat obě cesty, pokud obě zůstanou aktivní.

 

 

Rozhodněte, který záznam je zdrojem pravdy

Nejbezpečnější design členství obvykle zachováváčlenský účetjako zdroj pravdy a zachází s klíčenkou jako s přiřaditelným pověřením.

Toto oddělení usnadňuje výměnu a přeřazení.

To umožňuje operátorovi pozastavit člena bez fyzického přepisování přívěsku, vyměnit poškozený přívěsek na klíče bez vytvoření nového členského účtu a zachovat historii transakcí, když se pověření změní.

 

Před zakódováním dávky vytvořte mapování

Nezačínejte produkci proměnných-dat s jedním sloupcem tabulky s názvem „ID“. Nejprve definujte vztah mezi identifikátory.

Mapa výroby a nasazení může obsahovat:

Pro ochranu soukromí a provozní kontrolu dodavatel obvykle nepotřebuje úplný profil člena. Čistším modelem je oddělení souboru mapování výroby od členské databáze operátora.

Dodavatel může vrátit například:

tištěný seriál ↔ UID ↔ kódovaný token ↔ stav výroby

Operátor pak může přidat:

pověření ↔ ID člena ↔ stav členství

po vydání.

 

Nepoužívejte UID jako bezpečnostní zkratku

UID je užitečné pro identifikaci, ale identifikace a autentizace jsou různé bezpečnostní funkce.

Pro vyhledávání loajality s nízkým{0}}rizikem může postačovat mapování podporovaného identifikátoru pověření k backendovému účtu. Pro případy použití s ​​vyšším-rizikem, jako je zabezpečený přístup k zařízení, uložená hodnota nebo platba, může systém vyžadovat silnější čipovou autentizaci, chráněná data aplikací, správu klíčů a-zabezpečení na straně čtečky.

Základní NFC klíčenka by neměla být popisována jako bezpečná pouze proto, že její čip má jedinečné sériové číslo. Požadovaná úroveň zabezpečení musí pocházet z modelu ohrožení vlastníka systému a specifikace platformy.

Stejně tak oblast paměti chráněná heslem-není totéž jako kryptografické ověřování.

 

Výměna klíče-ztraceného plánu-před spuštěním

Náhradní pracovní postup by měl zachovat členský účet při změně aktivního pověření.

Praktická sekvence je:

1. Najděte členský účet.
2. Označte ztracené přihlašovací údaje jako neaktivní.
3. Ověřte, zda není identifikátor na straně staré čtečky-blokován pro budoucí použití.
4. Vydejte náhradní přívěsek na klíče.
5. Namapujte nové přihlašovací údaje ke stávajícímu členskému účtu.
6. Pokud projekt používá jedinečný token NDEF, rozhodněte, zda musí být starý token také zakázán nebo otočen.
7. Ověřte nový ovladač na skutečné čtečce nebo pracovním postupu telefonu.
8. Potvrďte, že staré přihlašovací údaje již nedokončují akci chráněného členství.

To je důvod, proč by členský účet neměl být trvale svázán s jedním fyzickým UID bez administrativní náhradní vrstvy.

 

Změna přiřazení je jiná operace než výměna

Nahrazení zachová stejného člena a změní pověření. Změna přiřazení zachová fyzické pověření a změní člena.

Tento rozdíl je důležitý pro opakovaně použitelné přívěsky na klíče v tělocvičnách, klubech, půjčovnách a spravovaných zařízeních.

Před předáním vráceného FOB jiné osobě:

• odstranit starý členský vztah;
• potvrďte, že starý účet stále nemůže používat přihlašovací údaje;
• zkontrolujte fyzický přívěsek na klíče;
• přečíst zpět elektronický identifikátor;
• aktualizovat nebo přepsat obsah NDEF, pokud projekt používá specifická data{0}}člena;
• zvažte otočení jedinečného webového tokenu, pokud bylo možné starý odkaz zkopírovat, přidat do záložek nebo sdílet;
• přiřadit pověření novému členovi;
• otestujte konečný výsledek čtečky a/nebo telefonu.

Pravidla pro opětovné přiřazení by měl definovat vlastník systému. Skutečnost, že klíčenku lze fyzicky znovu použít, nedokazuje, že data aplikace nebo vztah účtu jsou připraveny k opětovnému použití.

 

Vyvarujte se ukládání nepotřebných dat členů na klíčenku

Údaje o členství se mění. Jména, stav plánu, body, výhody a kontaktní údaje se mohou změnit, aniž byste museli nahrazovat fyzické přihlašovací údaje.

Z tohoto důvodu je provoz mnoha projektů snazší, když klíčenka ukládá nebo zpřístupňuje pouze stabilní identifikátor nebo neprůhledný URL token, zatímco backend ukládá měnící se obchodní data.

To snižuje potřebu přepisovat přihlašovací údaje a omezuje množství informací o členech vystavených, pokud někdo naskenuje nebo přečte značku.

Pokud projekt skutečně potřebuje chráněná data na pověření, vyberte si architekturu čipu a zabezpečení ze systémových požadavků, než abyste začínali s obecným produktem NTAG a snažili se přidat zabezpečení později.

 

Před registrací definujte duplicitní pravidla

Existují dva různé duplicitní problémy:

• duplicitní elektronické identifikátory nebo kódované tokenyve vyrobené šarži;
• duplicitní aktivní úkolyv členské databázi.

Akceptační plán by měl odhalit obojí.

Správně vyrobený přívěsek na klíče může být stále zapsán do nesprávného člena. Správně zaregistrovaný člen může mít stále dvě aktivní přihlašovací údaje, pokud obchodní pravidlo zamýšlelo pouze jedno. Jedná se o různé vlastníky selhání a měli by být protokolováni samostatně.

 

Otestujte pracovní postup dokončeného členství, nejen detekci NFC

Po dokončení transakce následuje užitečný vzorový test.

Pro širší pozadí testování NFC dat, destinací a mapování před hromadnou výrobou, Syntek'sKontrolní seznam testování NFCvysvětluje, proč úspěšný kohoutek není totéž jako úspěšný obchodní pracovní postup.

 

Co vložit do RFQ členské klíčenky NFC

Pro přímé získávání fyzických pověření od společnosti SyntekStránka produktu NFC klíčenkyje dalším komerčním krokem. Volba produktu by se měla spíše řídit schválenou architekturou systému, než ji nahrazovat.

 

Pravidlo nasazení

V případě členství nebo věrnostního programu zacházejte s NFC klíčenkou jako s přiřaditelným pověřením, nikoli s databází členů.

Robustní sekvence nasazení je:

úkol členství → čtečka nebo telefonní cesta → technologie pověření → rozhodnutí UID/NDEF → backendový model člena → mapování výroby → pravidla vydání/náhrady/přeřazení → dokončeno-vzorový test → hromadné schválení

Tato sekvence uchovává fyzický přívěsek na klíče, elektronický identifikátor, interakci s telefonem a záznam člena pod jedním řízeným datovým modelem. Umožňuje také spravovat-náhradu ztracených fobů a budoucí změnu přiřazení namísto toho, aby se z nich staly ruční výjimky z databáze.