NFC kľúčenky pre členské systémy: UID, NDEF a mapovanie členov

Prívesok na kľúče NFC môže identifikovať člena, otvoriť webové prostredie alebo urobiť oboje. Chybou je, že sa s nimi zaobchádza ako s rovnakým technickým pracovným postupom.

V členstve alebo vernostnom programe nie je kľúčovou otázkou jednoducho to, ktorý NFC čip si kúpiť. to jektorému identifikátoru bude systém dôverovať, kde bude uložený záznam o členovi a ako bude fyzický prívesok na kľúče vydaný, nahradený, deaktivovaný a znova priradený bez porušenia tohto mapovania.

Táto príručka sa zameriava na túto dátovú architektúru. Je určený pre prevádzkovateľov telocviční, kluby, vernostné platformy, systémových integrátorov-členov a tímy obstarávateľov, ktoré plánujú hromadné nasadenie NFC kľúčenky.

 

Začnite členskou transakciou, nie kľúčenkou

NFC kľúčenka je poverenie. Nepočíta body, nerozhoduje o tom, či je členstvo aktívne, neukladá autoritatívny profil zákazníka ani neuplatňuje obchodné pravidlá.

Členská interakcia zvyčajne prebieha jednou z dvoch ciest:

Vyhradená-cesta čitateľa:
člen → prívesok na kľúče NFC → kompatibilná čítačka → identifikátor poverenia → členský softvér → záznam člena → registrácia-/ výhoda / povolenie

Cesta klepnutia na telefón-:
člen → NFC kľúčenka → smartfón → NDEF URL → backend webu alebo aplikácie → záznam účtu alebo kampane → akcia členstva

Tieto cesty môžu používať rovnaký fyzický tvarový faktor, ale nemajú rovnaké technické požiadavky.

Ak je projekt primárne prístup k dverám a nie identifikácia členstva, požiadavkou kontroly je nainštalovaný prístupový systém. Syntek'ssprievodca kompatibilitou bezdotykových príveskovpokrýva túto inú úlohu používateľa.

 

UID, NDEF a Member ID sú tri rôzne veci

Projekty členstva často zlyhávajú, pretože niekoľko identifikátorov sa považuje za vzájomne zameniteľné.

Fórum NFC definujeNDEFako bežný formát údajov aplikácií na zariadeniach a štítkoch kompatibilných{0}}s NFC Forum. Záznam NDEF môže niesť URI alebo iné užitočné zaťaženie aplikácie, ale obchodný význam tohto záznamu patrí aplikácii, ktorá za ním stojí.

NXPdokumentácie NTAG213/215/216potvrdzuje, že rodina NTAG21x podporuje správanie značiek NFC Forum Type 2, dátové štruktúry ISO/IEC 14443 typu A a NDEF. Poskytuje tiež výrobcom-naprogramované UID. Tieto funkcie sú užitočné, ale stále predstavujú rôzne vrstvy: UID pre identitu čipu, NDEF pre aplikačné dáta a backendové záznamy pre členskú logiku.

 

Vyberte si jednu z troch architektúr členstva

1. Vyhradená čítačka + mapovanie poverení

V tomto modeli operátor vydáva každú kľúčenku ako systémové poverenie. Kompatibilná čítačka zachytí identifikátor alebo údaje aplikácie očakávané členskou platformou. Backend mapuje toto poverenie na záznam člena.

Táto architektúra je vhodná pre opakujúce sa registrácie-, vstupy do klubu, skrinky,{1}}rozpoznávanie lojality s asistenciou personálu a ďalšie spravované dotykové body, kde operátor ovláda čítačku.

Kritické otázky sú:

• Aký presný čip alebo technológiu poverení podporuje nainštalovaná čítačka?
• Akú hodnotu softvér zapisuje: UID, číslo karty, údaje o sektore/súbore alebo iný systémom-definovaný identifikátor?
• Môže mať jeden člen viac ako jedno aktívne poverenie?
• Je možné deaktivovať prihlasovacie údaje nezávisle od členského účtu?
• Ako sa rieši strata, vrátenie alebo výmena príveskov?

NDEF môže byť v tejto architektúre irelevantné. Prívesok na kľúče môže byť platným poverením pre členstvo, aj keď sa nevyžaduje adresa URL-čitatelná z telefónu.

2. Klepnite na telefón + NDEF URL

Pri prvom{0}}členstve po telefóne má kľúčenka zvyčajne identifikátor URI NDEF, ktorý ukazuje na webovú stránku, postup aktivácie, portál účtu, vernostnú stránku alebo cestu aplikácie.

TheTechnický prehľad fóra NFCopisuje NFC Forum Tags ako nosiče správ NDEF, ktoré môžu spúšťať akcie, ako je otvorenie internetového odkazu. Spoločnosť Apple tiež dokumentuje na pozadí čítanie NFC tagov okolo záznamov NDEF URI na podporovaných telefónoch iPhone vJadro NFC.

Pre túto architektúru by mala jedinečná adresa URL zvyčajne obsahovať nepriehľadný token alebo identifikátor projektu, a nie odhaľovať meno člena, e-mail, zostatok alebo iné nepotrebné osobné údaje priamo v značke.

Webový server potom môže tento token preložiť do príslušného záznamu a rozhodnúť, čo môže používateľ vidieť alebo robiť.

3. Hybridná čítačka + interakcia s telefónom

Niektoré projekty vyžadujú jeden prívesok na kľúče na podporu pracovného postupu spravovanej čítačky a{0}}klepnutia na telefón.

To môže byť užitočné napríklad vtedy, keď telocvičňa chce na registráciu vyhradenú čítačku- a zároveň umožňuje členovi klepnúť na ten istý prívesok s telefónom a otvoriť si stránku účtu.

Nepredpokladajte, že tieto dve cesty sú automaticky kompatibilné, pretože zdieľajú rovnaký čip NFC. Overte ich samostatne:

• čitateľ musí podporovať presnú technológiu a identifikátor, ktorý používa členský systém;
• telefónna cesta musí prečítať schválený náklad NDEF a otvoriť očakávaný cieľ;
• backend musí vedieť, ako súvisí-identifikátor na strane čitateľa a token na strane NDEF{1}} k rovnakému účtu;
• náhrada musí aktualizovať obe cesty, ak obe zostanú aktívne.

 

 

Rozhodnite sa, ktorý záznam je zdrojom pravdy

Najbezpečnejší dizajn členstva si zvyčajne zachovávačlenský účetako zdroj pravdy a zaobchádza s kľúčenkou ako s priraditeľným poverením.

Toto oddelenie uľahčuje výmenu a preradenie.

To umožňuje operátorovi pozastaviť člena bez fyzického prepisovania prívesku, nahradiť poškodený prívesok bez vytvorenia nového členského účtu a zachovať históriu transakcií pri zmene poverení.

 

Vytvorte mapovanie predtým, ako zakódujete dávku

Nezačínajte produkciu údajov-premenných s jedným stĺpcom tabuľky s názvom ID. Najprv definujte vzťah medzi identifikátormi.

Mapa výroby a nasadenia môže obsahovať:

Pre súkromie a prevádzkovú kontrolu dodávateľ zvyčajne nepotrebuje úplný profil člena. Čistejším modelom je oddelenie súboru mapovania produkcie od členskej databázy operátora.

Dodávateľ môže vrátiť napríklad:

tlačený seriál ↔ UID ↔ kódovaný token ↔ stav výroby

Operátor potom môže pridať:

poverenie ↔ ID člena ↔ stav členstva

po vydaní.

 

Nepoužívajte UID ako bezpečnostnú skratku

UID je užitočné na identifikáciu, ale identifikácia a autentifikácia sú rôzne bezpečnostné funkcie.

Na vyhľadávanie lojality s nízkym{0}}rizikom môže postačovať mapovanie podporovaného identifikátora poverení na backendový účet. V prípadoch s vyšším-rizikom, ako je napríklad bezpečný prístup k zariadeniu, uložená hodnota alebo platba, môže systém vyžadovať silnejšiu čipovú autentifikáciu, chránené údaje aplikácií, správu kľúčov a-bezpečnosť na strane čítačky.

Základná NFC kľúčenka by nemala byť označovaná ako bezpečná len preto, že jej čip má jedinečné sériové číslo. Požadovaná úroveň zabezpečenia musí vychádzať z modelu hrozby a špecifikácie platformy vlastníka systému.

Podobne oblasť pamäte-chránená heslom nie je to isté ako kryptografické overenie.

 

Výmena-kľúča{1}}plánu pred spustením

Náhradný pracovný postup by mal zachovať členský účet pri zmene aktívnych poverení.

Praktická postupnosť je:

1. Nájdite členský účet.
2. Označte stratené poverenia ako neaktívne.
3. Potvrďte, či je identifikátor starej čítačky-blokovaný pre budúce použitie.
4. Vydajte náhradný prívesok na kľúče.
5. Priraďte nové poverenia k existujúcemu členskému účtu.
6. Ak projekt používa jedinečný token NDEF, rozhodnite sa, či sa starý token musí tiež deaktivovať alebo otočiť.
7. Overte si nový ovládač na skutočnom pracovnom postupe čítačky alebo telefónu.
8. Potvrďte, že staré poverenia už nedokončujú akciu chráneného členstva.

To je dôvod, prečo by členský účet nemal byť trvalo viazaný na jedno fyzické UID bez administratívnej náhradnej vrstvy.

 

Preradenie je iná operácia ako výmena

Náhrada zachová rovnakého člena a zmení poverenie. Opätovné pridelenie zachová fyzické poverenie a zmení člena.

Tento rozdiel je dôležitý pre opakovane použiteľné prívesky na kľúče v telocvičniach, kluboch, požičovniach a riadených zariadeniach.

Pred odovzdaním vráteného FOB inej osobe:

• odstrániť starý členský vzťah;
• potvrďte, že starý účet stále nemôže používať poverenia;
• skontrolujte fyzický prívesok na kľúče;
• prečítať späť elektronický identifikátor;
• aktualizovať alebo prepísať obsah NDEF, ak projekt používa špecifické údaje{0}}člena;
• zvážte rotáciu jedinečného webového tokenu, ak bolo možné starý odkaz skopírovať, pridať do záložiek alebo zdieľať;
• prideliť poverenie novému členovi;
• otestujte konečný výsledok čítačky a/alebo telefónu.

Pravidlá opätovného priradenia by mal definovať vlastník systému. Skutočnosť, že prívesok na kľúče možno fyzicky znovu použiť, nedokazuje, že údaje aplikácie alebo vzťah s účtom sú pripravené na opätovné použitie.

 

Vyhnite sa ukladaniu nepotrebných údajov o členoch na kľúčenku

Údaje o členstve sa menia. Mená, stav plánu, body, výhody a kontaktné údaje sa môžu zmeniť bez výmeny fyzických prihlasovacích údajov.

Z tohto dôvodu sa mnohé projekty ľahšie ovládajú, keď kľúčenka ukladá alebo odhaľuje iba stabilný identifikátor alebo nepriehľadný URL token, zatiaľ čo backend ukladá meniace sa obchodné údaje.

To znižuje potrebu prepisovania poverení a obmedzuje množstvo informácií o členoch vystavených, ak niekto naskenuje alebo prečíta značku.

Ak projekt skutočne potrebuje chránené údaje o poverení, vyberte si architektúru čipu a zabezpečenia zo systémových požiadaviek a nezačínajte s generickým produktom NTAG a pokúšajte sa pridať zabezpečenie neskôr.

 

Pred registráciou definujte duplicitné pravidlá

Existujú dva rôzne duplicitné problémy:

• duplicitné elektronické identifikátory alebo kódované tokenyvo vyrobenej dávke;
• duplicitné aktívne úlohyv členskej databáze.

Akceptačný plán by mal odhaliť oboje.

Správne vyrobený prívesok na kľúče môže byť stále zaregistrovaný nesprávnemu členovi. Správne zaregistrovaný člen môže mať stále dve aktívne poverenia, keď obchodné pravidlo zamýšľalo iba jedno. Sú to rôzni vlastníci zlyhania a mali by byť zaznamenaní samostatne.

 

Otestujte pracovný postup dokončeného členstva, nielen detekciu NFC

Po kompletnej transakcii nasleduje užitočný vzorový test.

Pre širšie pozadie testovania údajov NFC, destinácií a mapovania pred hromadnou výrobou, Syntek'sKontrolný zoznam testovania NFCvysvetľuje, prečo úspešný vodovod nie je to isté ako úspešný obchodný pracovný postup.

 

Čo vložiť do RFQ členskej kľúčenky NFC

Pre priame získavanie fyzických poverení, Syntek'sStránka produktu NFC prívesok na kľúčeje ďalší komerčný krok. Výber produktu by sa mal skôr riadiť schválenou architektúrou systému, než ju nahradiť.

 

Pravidlo nasadenia

V prípade členstva alebo vernostného programu zaobchádzajte s NFC kľúčenkou ako s priraditeľným poverením, nie ako s databázou členov.

Robustná postupnosť nasadenia je:

členská úloha → čítačka alebo telefónna cesta → technológia poverení → UID/NDEF rozhodnutie → backendový model člena → produkčné mapovanie → pravidlá vydania/nahradenia/preradenia → dokončený-test vzorky → hromadné schválenie

Táto sekvencia uchováva fyzický prívesok na kľúče, elektronický identifikátor, interakciu s telefónom a záznam člena pod jedným riadeným dátovým modelom. Umožňuje tiež spravovať výmenu stratených{1}}fob a budúce opätovné priradenie namiesto toho, aby sa zmenili na manuálne výnimky databázy.