NFC obeski za ključe za članske sisteme: UID, NDEF in preslikava članov

Obesek za ključe NFC lahko identificira člana, odpre spletno izkušnjo ali oboje. Napaka je, da jih obravnavamo kot isti tehnični potek dela.

V programu članstva ali programu zvestobe ključno vprašanje ni le, kateri NFC čip kupiti. Jekateremu identifikatorju bo sistem zaupal, kje bo živel zapis o članu in kako bo fizični obesek za ključe izdan, zamenjan, deaktiviran in ponovno dodeljen, ne da bi pri tem pokvaril to preslikavo.

Ta vodnik se osredotoča na to podatkovno arhitekturo. Namenjen je upravljavcem telovadnic, klubom, platformam zvestobe, članskim-sistemskim integratorjem in skupinam za nabavo, ki načrtujejo množično uvedbo obeskov za ključe NFC.

 

Začnite s transakcijo članstva, ne z obeskom za ključe

Obesek za ključe NFC je poverilnica. Samostojno ne izračunava točk, ne odloča, ali je članstvo aktivno, ne shranjuje verodostojnega profila stranke ali uporablja poslovnih pravil.

Interakcija članstva običajno sledi eni od dveh poti:

Namenska-pot bralca:
član → obesek za ključe NFC → združljiv bralnik → identifikator poverilnic → programska oprema za članstvo → zapis o članu → prijava/ugodnost/dovoljenje

Pot-telefonskega dotika:
član → obesek za ključe NFC → pametni telefon → URL NDEF → zaledje spleta ali aplikacije → zapis računa ali akcije → dejanje članstva

Te poti lahko uporabljajo isti faktor fizične oblike, vendar nimajo enakih tehničnih zahtev.

Če je projekt predvsem dostop do vrat in ne identifikacija članstva, je nadzorna zahteva nameščen sistem dostopa. Syntekovapriročnik za združljivost obeska za ključepokriva to drugačno nalogo uporabnika.

 

UID, NDEF in ID člana so tri različne stvari

Projekti članstva pogosto ne uspejo, ker se več identifikatorjev obravnava kot medsebojno zamenljivih.

Forum NFC definiraNDEFkot običajna oblika za podatke aplikacij na napravah in oznakah,-združljivih s forumom NFC. Zapis NDEF lahko nosi URI ali koristno vsebino druge aplikacije, vendar poslovni pomen tega zapisa pripada aplikaciji, ki stoji za njim.

NXP-jiDokumentacija NTAG213/215/216potrjuje, da družina NTAG21x podpira delovanje oznak NFC Forum tipa 2, podatkovne strukture ISO/IEC 14443 tipa A in NDEF. Ponuja tudi proizvajalčev-programirani UID. Te zmožnosti so uporabne, vendar še vedno predstavljajo različne plasti: UID za identiteto čipa, NDEF za podatke aplikacije in zaledne zapise za logiko članstva.

 

Izberite eno od treh arhitektur članstva

1. Namenski bralnik + preslikava poverilnic

V tem modelu operater izda vsak obesek za ključe kot sistemsko poverilnico. Združljiv bralnik zajame identifikator ali podatke o aplikaciji, ki jih pričakuje platforma za članstvo. Zaledje preslika to poverilnico v zapis člana.

Ta arhitektura ustreza ponavljajočim se prijavam-, vstopom v klub, omaricam,-prepoznavanju zvestobe s pomočjo osebja in drugim upravljanim stičnim točkam, kjer operater nadzoruje čitalnik.

Kritična vprašanja so:

• Kateri natančen čip ali tehnologijo poverilnic podpira nameščeni čitalnik?
• Katero vrednost zapiše programska oprema: UID, številko kartice, podatke o sektorju/datoteki ali drug identifikator,-ki ga določa sistem?
• Ali ima lahko en član več kot eno aktivno poverilnico?
• Ali je mogoče poverilnico onemogočiti neodvisno od članskega računa?
• Kako se ravna z izgubljenimi, vrnjenimi ali zamenjanimi fobi?

NDEF je lahko v tej arhitekturi nepomemben. Obesek za ključe je lahko veljavna poverilnica za članstvo, tudi če ni potreben URL-berljiv s telefona.

2. Dotik telefona + NDEF URL

V-izkušnji prvega članstva na telefonu nosi obesek za ključe običajno NDEF URI, ki kaže na spletno stran, tok aktivacije, portal računa, stran zvestobe ali pot do aplikacije.

TheNFC Forum tehnični pregledopisuje oznake foruma NFC kot nosilce sporočil NDEF, ki lahko sprožijo dejanja, kot je odpiranje internetne povezave. Apple prav tako dokumentira branje oznake NFC v ozadju okoli zapisov URI NDEF na podprtih telefonih iPhone vJedro NFC.

Za to arhitekturo bi moral enolični URL običajno vsebovati neprozoren žeton ali identifikator projekta, namesto da bi neposredno v oznaki izpostavil ime člana, e-poštni naslov, stanje ali druge nepotrebne osebne podatke.

Spletno zaledje lahko nato razreši ta žeton v ustrezen zapis in odloči, kaj lahko uporabnik vidi ali počne.

3. Hibridni bralnik + telefonska interakcija

Nekateri projekti želijo en obesek za ključe, ki podpira potek dela upravljanega bralnika in izku-prisluškovanje telefona.

To je lahko uporabno, na primer, ko telovadnica potrebuje namenski bralnik za prijavo-in hkrati dovoli članu, da se dotakne istega ključa s telefonom, da odpre stran računa.

Ne domnevajte, da sta obe poti samodejno združljivi, ker imata isti čip NFC. Potrdite jih ločeno:

• bralnik mora podpirati natančno tehnologijo poverilnic in identifikator, ki ju uporablja sistem članstva;
• telefonska pot mora prebrati odobreno obremenitev NDEF in odpreti pričakovani cilj;
• zaledje mora vedeti, kako sta identifikator strani-bralnika in žeton strani-NDEF povezana z istim računom;
• zamenjava mora posodobiti obe poti, če obe ostaneta aktivni.

 

 

Odločite se, kateri zapis je vir resnice

Najvarnejši dizajn članstva običajno ohranjačlanski računkot vir resnice in obesek za ključe obravnava kot poverilnico, ki jo je mogoče dodeliti.

Ta ločitev olajša zamenjavo in prerazporeditev.

To omogoča operaterju, da suspendira člana, ne da bi fizično prepisal obesek, zamenja poškodovani obesek, ne da bi ustvaril nov članski račun, in ohrani zgodovino transakcij, ko se poverilnica spremeni.

 

Zgradite preslikavo, preden kodirate paket

Ne začnite proizvodnje spremenljiv-podatkov z enim stolpcem preglednice, imenovanim »ID«. Najprej določite razmerje med identifikatorji.

Zemljevid proizvodnje in uvajanja lahko vključuje:

Zaradi zasebnosti in operativnega nadzora dobavitelj običajno ne potrebuje profila polnega člana. Čistejši model je ločiti datoteko za preslikavo proizvodnje od baze podatkov članov operaterja.

Na primer, dobavitelj lahko vrne:

natisnjena serijska številka ↔ UID ↔ kodiran žeton ↔ status proizvodnje

Operater lahko nato doda:

poverilnica ↔ ID člana ↔ status članstva

po izdaji.

 

Ne uporabljajte UID kot varnostne bližnjice

UID je uporaben za identifikacijo, vendar sta identifikacija in avtentikacija različni varnostni funkciji.

Za iskanje zvestobe z nizkim-tveganjem lahko zadostuje preslikava podprtega identifikatorja poverilnice v zaledni račun. Za-primere uporabe z večjim tveganjem, kot je varen dostop do objekta, shranjena vrednost ali plačilo, lahko sistem zahteva močnejšo avtentikacijo čipa, zaščitene podatke aplikacije, upravljanje ključev in varnost-na strani bralnika.

Osnovni NFC obesek za ključe ne bi smel biti opisan kot varen samo zato, ker ima njegov čip edinstveno serijsko številko. Zahtevana raven varnosti mora izhajati iz modela groženj lastnika sistema in specifikacije platforme.

Prav tako pomnilniško območje-zaščiteno z geslom ni isto kot kriptografska avtentikacija.

 

Načrt Izgubljen-ključ-zamenjava obeska pred lansiranjem

Nadomestni potek dela mora ohraniti članski račun, medtem ko spreminja aktivno poverilnico.

Praktično zaporedje je:

1. Poiščite članski račun.
2. Označite izgubljeno poverilnico kot neaktivno.
3. Potrdite, ali je stari identifikator na-strani bralnika blokiran za prihodnjo uporabo.
4. Izdajte nadomestni obesek za ključe.
5. Preslikajte novo poverilnico v obstoječi članski račun.
6. Če projekt uporablja edinstven žeton NDEF, se odločite, ali je treba tudi stari žeton onemogočiti ali zasukati.
7. Preverite novi fob na pravem bralniku ali telefonu.
8. Potrdite, da stara poverilnica ne dokonča več dejanja zaščitenega članstva.

Zato članski račun ne bi smel biti trajno vezan na en fizični UID brez administrativne nadomestne plasti.

 

Prerazporeditev je drugačna operacija od zamenjave

Zamenjava obdrži istega člana in spremeni poverilnico. Prerazporeditev ohrani fizično poverilnico in spremeni člana.

Ta razlika je pomembna za obeske za ključe za večkratno uporabo v telovadnicah, klubih, programih za najem in upravljanih objektih.

Preden daste vrnjeno fob drugi osebi:

• odstranite staro člansko razmerje;
• potrdite, da stari račun še vedno ne more uporabljati poverilnice;
• preglejte fizični obesek za ključe;
• prebrati elektronski identifikator;
• posodobiti ali prepisati vsebino NDEF, če projekt uporablja-specifične podatke za člana;
• razmislite o menjavi edinstvenega spletnega žetona, če bi lahko staro povezavo kopirali, dodali med zaznamke ali delili z drugimi;
• dodeli poverilnico novemu članu;
• preizkusite končni rezultat bralnika in/ali telefona.

Pravila prerazporejanja mora določiti lastnik sistema. Dejstvo, da je obesek za ključe mogoče ponovno fizično uporabiti, še ne dokazuje, da so podatki aplikacije ali razmerje računa pripravljeni za ponovno uporabo.

 

Izogibajte se shranjevanju nepotrebnih podatkov o članih na ključu

Spremembe članskih podatkov. Imena, status načrta, točke, ugodnosti in kontaktni podatki se lahko spremenijo brez zamenjave fizične poverilnice.

Zaradi tega je veliko projektov lažje upravljati, če obesek za ključe shrani ali izpostavi samo stabilen identifikator ali neprozoren žeton URL-ja, medtem ko zaledje shrani spreminjajoče se poslovne podatke.

To zmanjša potrebo po prepisovanju poverilnic in omeji količino podatkov o članu, ki so izpostavljeni, če nekdo skenira ali prebere oznako.

Če projekt resnično potrebuje zaščitene podatke na poverilnici, izberite čip in varnostno arhitekturo iz sistemskih zahtev, namesto da začnete z generičnim izdelkom NTAG in poskušate dodati varnost pozneje.

 

Določite podvojena pravila pred vpisom

Obstajata dve različni podvojeni težavi:

• podvojene elektronske identifikatorje ali kodirane žetonev izdelani seriji;
• podvojene aktivne dodelitvev bazi članstva.

Načrt sprejema mora zaznati oboje.

Pravilno izdelan obesek za ključe je lahko še vedno vpisan napačnemu članu. Pravilno vpisani član ima lahko še vedno dve aktivni poverilnici, če je poslovno pravilo predvidelo samo eno. To so različni lastniki napak in jih je treba zabeležiti ločeno.

 

Preizkusite potek dela za dokončano članstvo, ne le zaznavanje NFC

Celotni transakciji sledi uporaben vzorčni test.

Za širše ozadje testiranja podatkov NFC, destinacij in kartiranja pred množično proizvodnjo, Syntek'sKontrolni seznam testiranja NFCpojasnjuje, zakaj uspešna pipa ni enaka uspešnemu poslovnemu toku dela.

 

Kaj dati v RFQ za obesek za ključe za članstvo v NFC

Za neposredno pridobivanje fizičnih poverilnic, Syntek'sStran izdelka NFC obesek za ključeje komercialni naslednji korak. Izbira izdelka mora slediti potrjeni sistemski arhitekturi in ne nadomestiti.

 

Pravilo namestitve

Za članstvo ali program zvestobe obravnavajte obesek za ključe NFC kot poverilnico, ki jo je mogoče dodeliti, ne kot bazo podatkov članov.

Robustno zaporedje uvajanja je:

naloga članstva → bralnik ali telefonska pot → tehnologija poverilnic → odločitev UID/NDEF → model zalednega člana → preslikava proizvodnje → pravila izdaje/zamenjave/prerazporeditve → dokončan-vzorčni preizkus → množična odobritev

To zaporedje ohranja fizični obesek za ključe, elektronski identifikator, telefonsko interakcijo in evidenco članov pod enim nadzorovanim podatkovnim modelom. Omogoča tudi obvladljivost izgubljene-fob zamenjave in prihodnje vnovične dodelitve, namesto da bi jih spremenili v ročne izjeme zbirke podatkov.