NFC ključevi za sisteme članstva: UID, NDEF i mapiranje članova

NFC privjesak za ključeve može identificirati člana, otvoriti web iskustvo ili učiniti oboje. Greška je u tome da se oni tretiraju kao isti tehnički tok posla.

U članstvu ili programu lojalnosti, ključno pitanje nije jednostavno koji NFC čip kupiti. Jestekojem identifikatoru će sistem vjerovati, gdje će se nalaziti zapis o članu i kako će fizički privezak biti izdat, zamijenjen, deaktiviran i ponovno dodijeljen bez prekida tog mapiranja.

Ovaj vodič se fokusira na tu arhitekturu podataka. Namijenjen je operaterima teretana, klubovima, platformama lojalnosti, članskim{1}}sistemskim integratorima i timovima za nabavku koji planiraju masovnu implementaciju NFC privezka za ključeve.

 

Počnite s transakcijom članstva, a ne s privezkom

NFC privezak za ključeve je akreditiv. Ne izračunava bodove, ne odlučuje da li je članstvo aktivno, ne pohranjuje autoritativni profil korisnika, niti sam primjenjuje poslovna pravila.

Interakcija članstva obično prati jedan od dva puta:

Namjenski-put za čitanje:
član → NFC privezak za ključeve → kompatibilni čitač → identifikator vjerodajnica → softver za članstvo → evidencija člana → prijava-prijava / pogodnost / dozvola

Putanja{0}}dodirivanja telefona:
član → NFC privezak za ključeve → pametni telefon → NDEF URL → web ili pozadina aplikacije → račun ili evidencija kampanje → radnja članstva

Te staze mogu koristiti isti fizički faktor forme, ali nemaju iste tehničke zahtjeve.

Ako je projekat prvenstveno pristup vratima, a ne identifikacija članstva, kontrolni zahtjev je instalirani pristupni sistem. Syntek'sVodič za kompatibilnost privezaka za blizinupokriva taj drugačiji korisnički zadatak.

 

UID, NDEF i ID člana su tri različite stvari

Projekti članstva često ne uspijevaju jer se nekoliko identifikatora tretira kao zamjenjivo.

NFC Forum definiraNDEFkao uobičajeni format za podatke aplikacija na uređajima i oznakama kompatibilnim sa NFC Forum-. NDEF zapis može nositi URI ili drugu korisni teret aplikacije, ali poslovno značenje tog zapisa pripada aplikaciji koja stoji iza njega.

NXP'sNTAG213/215/216 dokumentacijapotvrđuje da porodica NTAG21x podržava NFC Forum Tip 2 Tag ponašanja, ISO/IEC 14443 Tip A i NDEF strukture podataka. Također pruža proizvođač{4}}programiran UID. Te mogućnosti su korisne, ali i dalje predstavljaju različite slojeve: UID za identitet čipa, NDEF za podatke aplikacije i pozadinske zapise za logiku članstva.

 

Odaberite jednu od tri arhitekture članstva

1. Namjenski čitač + mapiranje vjerodajnica

U ovom modelu, operater izdaje svaki privezak za ključeve kao sistemski akreditiv. Kompatibilni čitač bilježi identifikator ili podatke aplikacije koje očekuje platforma za članstvo. Pozadina mapira taj akreditiv u zapis člana.

Ova arhitektura se uklapa u ponavljajuću prijavu-ulazak u klub, ormariće, prepoznavanje lojalnosti uz{1}}potpomognuto osobljem i druge upravljane dodirne tačke gdje operater kontrolira čitač.

Kritična pitanja su:

• Koji tačno čip ili tehnologiju akreditiva podržava instalirani čitač?
• Koju vrijednost softver upisuje: UID, broj kartice, podaci sektora/fajla ili drugi sistem{0}}definirani identifikator?
• Može li jedan član imati više aktivnih vjerodajnica?
• Da li se vjerodajnica može onemogućiti nezavisno od korisničkog računa?
• Kako se postupa sa izgubljenim, vraćenim ili zamijenjenim fobovima?

NDEF može biti irelevantan u ovoj arhitekturi. Privezak za ključeve može biti važeći akreditiv za članstvo čak i kada nije potreban URL koji-čitljiv telefonom.

2. Dodirnite telefon + NDEF URL

U telefonskom{0}}prvom iskustvu članstva, privezak obično nosi NDEF URI koji ukazuje na web stranicu, tok aktivacije, portal računa, stranicu vjernosti ili rutu aplikacije.

TheNFC Forum tehnički pregledopisuje NFC Forumske oznake kao nosioce NDEF poruka koje mogu pokrenuti radnje kao što je otvaranje internetske veze. Apple također dokumentira čitanje pozadinske NFC oznake oko NDEF URI zapisa na podržanim iPhone uređajimaCore NFC.

Za ovu arhitekturu, jedinstveni URL bi obično trebao sadržavati neprozirni token ili identifikator projekta umjesto da izlaže ime člana, e-poštu, stanje ili druge nepotrebne lične podatke direktno u oznaci.

Pozadina weba tada može razriješiti taj token u odgovarajući zapis i odlučiti šta korisnik smije vidjeti ili učiniti.

3. Hibridni čitač + telefonska interakcija

Neki projekti žele jedan privjesak za ključeve koji podržava radni tok upravljanog čitača i iskustvo{0}}pritiskanja telefona.

To može biti korisno, na primjer, kada teretana želi posvećenog čitača za prijavu-i istovremeno dozvoljava članu da dodirne istu fob telefonom da otvori stranicu računa.

Nemojte pretpostavljati da su dvije staze automatski kompatibilne jer dijele isti NFC čip. Potvrdite ih zasebno:

• čitalac mora podržati tačnu tehnologiju akreditiva i identifikator koji koristi sistem članstva;
• telefonska putanja mora pročitati odobreni NDEF korisni teret i otvoriti očekivano odredište;
• backend mora znati kako se identifikator{0}}strane čitača i NDEF-token odnose na isti račun;
• zamjena mora ažurirati obje staze ako obje ostanu aktivne.

 

 

Odlučite koji zapis je izvor istine

Najsigurniji dizajn članstva obično zadržavačlanski računkao izvor istine i tretira privezak kao akreditiv koji se može dodijeliti.

To razdvajanje olakšava zamjenu i preraspodjelu.

Ovo omogućava operateru da suspenduje člana bez fizičkog prepisivanja fob-a, da zameni oštećeni privezak bez kreiranja novog naloga za članstvo i da sačuva istoriju transakcija kada se akreditivi promene.

 

Napravite mapiranje prije nego što kodirate paket

Nemojte započinjati proizvodnju varijabilnih{0}}podataka s jednom kolonom tabele koja se zove "ID." Prvo definirajte odnos između identifikatora.

Mapa proizvodnje i implementacije može uključivati:

Za privatnost i operativnu kontrolu, dobavljaču obično nije potreban profil punopravnog člana. Čistiji model je odvajanje datoteke mapiranja proizvodnje od baze podataka članova operatera.

Na primjer, dobavljač može vratiti:

štampani serijski ↔ UID ↔ kodirani token ↔ status proizvodnje

Operater tada može dodati:

vjerodajnica ↔ ID člana ↔ status članstva

nakon izdavanja.

 

Nemojte koristiti UID kao sigurnosnu prečicu

UID je koristan za identifikaciju, ali identifikacija i autentifikacija su različite sigurnosne funkcije.

Za nisko{0}}provjeru lojalnosti, mapiranje podržanog identifikatora akreditiva na pozadinski račun može biti dovoljno. Za slučajeve veće-rizične upotrebe kao što je siguran pristup objektu, pohranjena vrijednost ili plaćanje, sistem može zahtijevati jaču autentifikaciju čipom, zaštićene podatke aplikacije, upravljanje ključevima i sigurnost{3}}na strani čitača.

Osnovni NFC privezak za ključeve ne treba opisati kao siguran samo zato što njegov čip ima jedinstveni serijski broj. Potrebni nivo sigurnosti mora proizaći iz modela prijetnje vlasnika sistema i specifikacije platforme.

Isto tako, memorijsko područje-zaštićeno lozinkom nije isto što i kriptografska autentifikacija.

 

Planirajte zamjenu izgubljenog-ključa-fob-a prije lansiranja

Zamjenski tok posla bi trebao sačuvati nalog člana dok mijenja aktivnu vjerodajnicu.

Praktična sekvenca je:

1. Pronađite korisnički račun.
2. Označite izgubljenu vjerodajnicu neaktivnom.
3. Potvrdite da li je stari identifikator{0}}strane čitača blokiran za buduću upotrebu.
4. Izdajte zamjenski privezak za ključeve.
5. Mapirajte nove vjerodajnice na postojeći korisnički račun.
6. Ako projekt koristi jedinstveni NDEF token, odlučite da li i stari token mora biti onemogućen ili rotiran.
7. Provjerite novi fob u stvarnom toku rada čitača ili telefona.
8. Potvrdite da stara vjerodajnica više ne dovršava radnju zaštićenog članstva.

To je razlog zašto račun člana ne bi trebao biti trajno vezan za jedan fizički UID bez administrativnog sloja zamjene.

 

Preraspodjela je drugačija operacija od zamjene

Zamjena zadržava istog člana i mijenja vjerodajnicu. Preraspodjela zadržava fizičke vjerodajnice i mijenja člana.

Ta razlika je važna za privjeske za ključeve za višekratnu upotrebu u teretanama, klubovima, programima iznajmljivanja i upravljanim objektima.

Prije davanja vraćenog fob-a drugoj osobi:

• ukloniti odnos starog člana;
• potvrdite da stari račun i dalje ne može koristiti vjerodajnicu;
• pregledati fizički privezak za ključeve;
• ponovo pročitajte elektronski identifikator;
• ažurirati ili prepisati NDEF sadržaj ako projekat koristi podatke specifične za članove;
• razmislite o rotiranju jedinstvenog web tokena ako je stara veza mogla biti kopirana, označena ili podijeljena;
• dodijeliti akreditiv novom članu;
• testirajte konačni rezultat čitača i/ili telefona.

Pravila preraspodjele treba definirati od strane vlasnika sistema. Činjenica da se privezak za ključeve može fizički ponovo koristiti ne dokazuje da su podaci aplikacije ili odnos računa spremni za ponovnu upotrebu.

 

Izbjegavajte pohranjivanje nepotrebnih podataka o članovima na privjesku

Podaci o članstvu se mijenjaju. Imena, status plana, bodovi, pogodnosti i kontakt detalji se mogu promijeniti bez zamjene fizičke akreditive.

Iz tog razloga, mnogim projektima je lakše upravljati kada privezak za ključeve pohranjuje ili izlaže samo stabilan identifikator ili neproziran URL token, dok backend pohranjuje poslovne podatke koji se mijenjaju.

Ovo smanjuje potrebu za ponovnim pisanjem akreditiva i ograničava količinu informacija o članovima koji su izloženi ako neko skenira ili pročita oznaku.

Ako su projektu zaista potrebni zaštićeni podaci o vjerodajnicama, odaberite čip i sigurnosnu arhitekturu iz zahtjeva sistema umjesto da počnete s generičkim NTAG proizvodom i pokušavate da dodate sigurnost kasnije.

 

Definirajte duplicirana pravila prije upisa

Postoje dva različita problema dupliranja:

• dupli elektronski identifikatori ili kodirani tokeniu proizvedenoj seriji;
• dupliranje aktivnih zadatakau bazi podataka o članstvu.

Plan prihvatanja treba da otkrije i jedno i drugo.

Ispravno proizveden privezak za ključeve i dalje može biti upisan na pogrešnog člana. Ispravno upisan član i dalje može imati dvije aktivne vjerodajnice kada je poslovno pravilo namijenjeno samo jednom. To su različiti vlasnici grešaka i treba ih posebno evidentirati.

 

Testirajte gotov radni tok članstva, a ne samo NFC detekciju

Koristan uzorak testa prati kompletnu transakciju.

Za širu pozadinu o testiranju NFC podataka, odredišta i mapiranja prije masovne proizvodnje, SyntekKontrolna lista za NFC testiranjeobjašnjava zašto uspješan dodir nije isto što i uspješan poslovni tok.

 

Šta staviti u RFQ za privezak za NFC članstvo

Za direktan izvor fizičkih akreditiva, SyntekStranica proizvoda za NFC privezakje komercijalni sljedeći korak. Izbor proizvoda treba da prati odobrenu arhitekturu sistema, a ne da je zamenjuje.

 

Pravilo raspoređivanja

Za članstvo ili program lojalnosti, NFC privezak za ključeve tretirajte kao akreditiv koji se može dodijeliti, a ne kao bazu podataka članova.

Robustan slijed implementacije je:

zadatak članstva → čitač ili put telefona → tehnologija vjerodajnica → odluka o UID/NDEF → model pozadinskog člana → mapiranje proizvodnje → pravila za izdavanje/zamjena/preraspodjelu → završen-uzorak testa → grupno odobrenje

Taj niz drži fizički privezak za ključeve, elektronski identifikator, telefonsku interakciju i evidenciju članova pod jednim kontroliranim modelom podataka. Također omogućava upravljanje izgubljenom-fob zamjenom i budućim preraspodjelom umjesto da ih pretvara u ručne izuzetke baze podataka.