NFC privjesci za ključeve za sustave članstva: UID, NDEF i mapiranje članova

NFC privjesak za ključeve može identificirati člana, otvoriti web iskustvo ili oboje. Pogreška je što ih tretiramo kao isti tehnički tijek rada.

U programu članstva ili vjernosti, ključno pitanje nije samo koji NFC čip kupiti. jestekojem će identifikatoru sustav vjerovati, gdje će se nalaziti zapis o članu i kako će se fizički privjesak za ključeve izdati, zamijeniti, deaktivirati i ponovno dodijeliti bez prekida tog mapiranja.

Ovaj se vodič usredotočuje na tu podatkovnu arhitekturu. Namijenjen je operaterima teretana, klubovima, platformama vjernosti, članovima-integratorima sustava i timovima za nabavu koji planiraju skupnu implementaciju NFC privjeska za ključeve.

 

Započnite s transakcijom članstva, a ne s privjeskom za ključeve

NFC privjesak za ključeve je vjerodajnica. Ne izračunava bodove, ne odlučuje je li članstvo aktivno, ne pohranjuje autoritativni profil korisnika niti primjenjuje poslovna pravila sama.

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

Namjenski-put čitatelja:
član → NFC privjesak za ključeve → kompatibilni čitač → identifikator vjerodajnica → softver za članstvo → zapis o članu → prijava-/pogodnost/dopuštenje

Telefon-prislušni put:
član → NFC privjesak za ključeve → pametni telefon → NDEF URL → pozadina weba ili aplikacije → evidencija računa ili kampanje → akcija članstva

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

Ako je projekt primarno pristup kroz vrata, a ne identifikacija članstva, kontrolni zahtjev je instaliran pristupni sustav. Syntekovavodič za kompatibilnost privjeska za blizinupokriva taj drugačiji korisnički zadatak.

 

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

Projekti članstva često propadaju jer se nekoliko identifikatora tretira kao međusobno zamjenjivo.

NFC forum definiraNDEFkao uobičajeni format za podatke aplikacije na uređajima i oznakama-kompatibilnim s NFC forumom. NDEF zapis može nositi URI ili drugi korisni sadržaj aplikacije, ali poslovno značenje tog zapisa pripada aplikaciji koja stoji iza njega.

NXP-aNTAG213/215/216 dokumentacijapotvrđuje da obitelj NTAG21x podržava NFC Forum Type 2 Tag ponašanje, ISO/IEC 14443 Type A i NDEF strukture podataka. Također pruža proizvođač-programirani UID. Te su mogućnosti korisne, ali još uvijek 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 privjesak kao vjerodajnicu sustava. Kompatibilni čitač bilježi identifikator ili podatke o aplikaciji koje očekuje platforma za članstvo. Pozadina preslikava tu vjerodajnicu u zapis člana.

Ova arhitektura odgovara ponavljajućoj prijavi-, ulasku u klub, ormarićima,-prepoznavanju lojalnosti uz pomoć osoblja i drugim upravljanim dodirnim točkama gdje operater kontrolira čitač.

Kritična pitanja su:

• Koji točno čip ili tehnologiju vjerodajnica podržava instalirani čitač?
• Koju vrijednost upisuje softver: UID, broj kartice, podatke o sektoru/datoteci ili drugi identifikator-definiran sustavom?
• Može li jedan član imati više od jedne aktivne vjerodajnice?
• Može li se vjerodajnica onemogućiti neovisno o članskom računu?
• Kako se postupa s izgubljenim, vraćenim ili zamijenjenim fobovima?

NDEF može biti irelevantan u ovoj arhitekturi. Privjesak za ključeve može biti valjana vjerodajnica za članstvo čak i kada nije potreban URL-čitljiv telefonom.

2. Prisluškivanje telefona + NDEF URL

U telefonskom-iskustvu prvog članstva, privjesak za ključeve obično nosi NDEF URI koji upućuje na web stranicu, tijek aktivacije, portal računa, stranicu vjernosti ili rutu aplikacije.

TheNFC Forum tehnički pregledopisuje NFC Forumske oznake kao nositelje 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đajimaJezgra NFC.

Za ovu arhitekturu, jedinstveni URL trebao bi normalno sadržavati neproziran token ili identifikator projekta, umjesto da izlaže ime člana, e-poštu, stanje ili druge nepotrebne osobne podatke izravno u oznaci.

Web pozadina tada može razlučiti taj token u odgovarajući zapis i odlučiti što korisnik smije vidjeti ili učiniti.

3. Hibridni čitač + telefonska interakcija

Neki projekti žele jedan privjesak za ključeve koji podržava tijek rada upravljanog čitača i iskustvo-prisluškivanja telefona.

To može biti korisno, na primjer, kada teretana želi namjenski čitač za-prijavu, a istovremeno dopušta članu da dodirne isti fob s telefonom da otvori stranicu računa.

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

• čitač mora podržavati točnu tehnologiju vjerodajnica i identifikator koji koristi sustav članstva;
• telefonski put mora pročitati odobreni NDEF korisni teret i otvoriti očekivano odredište;
• pozadina mora znati kako se identifikator-strane čitača i token NDEF-strane odnose na isti račun;
• zamjena mora ažurirati obje staze ako obje ostanu aktivne.

 

 

Odlučite koji je zapis izvor istine

Najsigurniji dizajn članstva obično zadržavačlanski računkao izvor istine i tretira privjesak kao vjerodajnicu koja se može dodijeliti.

To odvajanje olakšava zamjenu i preraspodjelu.

To operateru omogućuje suspendiranje člana bez fizičkog ponovnog pisanja privjeska, zamjenu oštećenog privjeska bez kreiranja novog članskog računa i očuvanje povijesti transakcija kada se vjerodajnica promijeni.

 

Izgradite mapiranje prije nego što kodirate skup

Ne započinjite proizvodnju-podataka varijable s jednim stupcem proračunske tablice pod nazivom "ID." Prvo definirajte odnos između identifikatora.

Mapa proizvodnje i postavljanja može uključivati:

Zbog privatnosti i operativne kontrole, dobavljaču obično nije potreban profil punog člana. Čistiji model je odvojiti datoteku mapiranja proizvodnje od baze podataka članova operatera.

Na primjer, dobavljač može vratiti:

tiskani serijski ↔ UID ↔ kodirani token ↔ status proizvodnje

Operater tada može dodati:

vjerodajnica ↔ ID člana ↔ status članstva

nakon izdavanja.

 

Nemojte koristiti UID kao sigurnosni prečac

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

Za nisko{0}}rizično pretraživanje lojalnosti, mapiranje podržanog identifikatora vjerodajnice na pozadinski račun može biti dovoljno. Za-slučajeve upotrebe s višim rizikom kao što je siguran pristup objektu, pohranjena vrijednost ili plaćanje, sustav može zahtijevati jaču autentifikaciju čipa, zaštićene podatke aplikacije, upravljanje ključevima i sigurnost-strane čitača.

Osnovni NFC privjesak za ključeve ne bi se trebao opisati kao siguran samo zato što njegov čip ima jedinstveni serijski broj. Potrebna razina sigurnosti mora proizaći iz modela prijetnji vlasnika sustava i specifikacije platforme.

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

 

Plan Izgubljen-Ključ-Zamjena privjeska prije lansiranja

Zamjenski tijek rada trebao bi sačuvati račun člana dok mijenja aktivnu vjerodajnicu.

Praktičan slijed je:

1. Pronađite članski račun.
2. Označite izgubljenu vjerodajnicu neaktivnom.
3. Provjerite je li stari identifikator-strane čitača blokiran za buduću upotrebu.
4. Izdajte zamjenski privjesak za ključeve.
5. Mapirajte novu vjerodajnicu s postojećim računom člana.
6. Ako projekt koristi jedinstveni NDEF token, odlučite treba li i stari token biti onemogućen ili rotiran.
7. Provjerite novi fob na stvarnom čitaču ili telefonu.
8. Potvrdite da stara vjerodajnica više ne dovršava radnju zaštićenog članstva.

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

 

Preraspodjela je drugačija operacija od zamjene

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

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

Prije davanja vraćenog foba drugoj osobi:

• ukloniti stari članski odnos;
• potvrdite da stari račun još uvijek ne može koristiti vjerodajnicu;
• pregledajte fizički privjesak za ključeve;
• ponovno pročitati elektronički identifikator;
• ažurirati ili prebrisati NDEF sadržaj ako projekt koristi podatke specifične za-člana;
• razmislite o rotiranju jedinstvenog web tokena ako je stara veza mogla biti kopirana, označena ili podijeljena;
• dodijeliti vjerodajnicu novom članu;
• testirajte konačni rezultat čitača i/ili telefona.

Pravila preraspodjele treba definirati vlasnik sustava. Činjenica da se privjesak za ključeve može ponovno fizički upotrijebiti ne dokazuje da su podaci aplikacije ili odnos računa spremni za ponovnu upotrebu.

 

Izbjegavajte pohranjivanje nepotrebnih podataka o članu na privjesku za ključeve

Promjene podataka o članstvu. Imena, status plana, bodovi, pogodnosti i detalji za kontakt mogu se promijeniti bez zamjene fizičke vjerodajnice.

Iz tog je razloga mnogim projektima lakše upravljati kada privjesak za ključeve pohranjuje ili izlaže samo stabilni identifikator ili neprozirni URL token, dok pozadina pohranjuje promjenjive poslovne podatke.

Ovo smanjuje potrebu za prepisivanjem vjerodajnica i ograničava količinu izloženih podataka o članu ako netko skenira ili pročita oznaku.

Ako projekt uistinu treba zaštićene podatke na vjerodajnici, odaberite čip i sigurnosnu arhitekturu iz zahtjeva sustava umjesto da počnete s generičkim NTAG proizvodom i pokušavate dodati sigurnost kasnije.

 

Definirajte duplicirana pravila prije upisa

Postoje dva različita dvostruka problema:

• dvostruki elektronički identifikatori ili kodirani tokeniu proizvedenoj seriji;
• duplicirati aktivne zadatkeu bazi podataka o članstvu.

Plan prihvaćanja trebao bi otkriti oboje.

Ispravno proizvedeni privjesak za ključeve još uvijek može biti upisan za pogrešnog člana. Ispravno upisani član još uvijek može imati dvije aktivne vjerodajnice kada je poslovno pravilo namijenjeno samo jednoj. To su različiti vlasnici grešaka i treba ih zasebno bilježiti.

 

Testirajte tijek završenog članstva, a ne samo otkrivanje NFC-a

Koristan uzorak testa prati kompletnu transakciju.

Za širu pozadinu o testiranju NFC podataka, odredišta i mapiranja prije masovne proizvodnje, Syntek'sKontrolni popis testiranja NFC-aobjašnjava zašto uspješna slavina nije isto što i uspješan poslovni tijek rada.

 

Što staviti u zahtjev za ponudu privjeska za ključeve za NFC članstvo

Za izravan izvor fizičke vjerodajnice, Syntek'sStranica proizvoda NFC privjeska za ključeveje sljedeći komercijalni korak. Izbor proizvoda trebao bi slijediti odobrenu arhitekturu sustava, a ne zamijeniti ga.

 

Pravilo raspoređivanja

Za članstvo ili program vjernosti, tretirajte NFC privjesak kao vjerodajnicu koja se može dodijeliti, a ne kao bazu podataka članova.

Robusna sekvenca implementacije je:

zadatak članstva → čitač ili telefonski put → tehnologija vjerodajnica → UID/NDEF odluka → model pozadinskog člana → mapiranje proizvodnje → pravila izdavanja/zamjene/ponovne dodjele → završen-test uzorka → skupno odobrenje

Taj slijed drži fizički privjesak za ključeve, elektronički identifikator, telefonsku interakciju i evidenciju članova pod jednim kontroliranim podatkovnim modelom. Također čini upravljivim izgubljen-fob zamjenu i buduću ponovnu dodjelu umjesto da ih pretvara u ručne iznimke baze podataka.