NFC taustiņu piekariņi dalības sistēmām: UID, NDEF un dalībnieku kartēšana

NFC atslēgas piekariņš var identificēt dalībnieku, atvērt tīmekļa pieredzi vai veikt abus. Kļūda ir to uzskatīt par vienu un to pašu tehnisko darbplūsmu.

Dalības vai lojalitātes programmā galvenais jautājums nav tikai tas, kuru NFC mikroshēmu iegādāties. Tā irkuram identifikatoram sistēma uzticēsies, kur dzīvos dalībnieka ieraksts un kā fiziskā atslēgas piekariņa tiks izsniegta, nomainīta, deaktivizēta un atkārtoti piešķirta, nepārkāpjot šo kartēšanu..

Šajā rokasgrāmatā galvenā uzmanība ir pievērsta šai datu arhitektūrai. Tas ir paredzēts sporta zāļu operatoriem, klubiem, lojalitātes platformām, dalības{1}}sistēmu integratoriem un iepirkumu komandām, kas plāno lielapjoma NFC atslēgu piekariņu izvietošanu.

 

Sāciet ar dalības darījumu, nevis atslēgas piekariņu

NFC atslēgas piekariņš ir akreditācijas dati. Tas neaprēķina punktus, neizlemj, vai dalība ir aktīva, neuzglabā autoritatīvu klienta profilu un pati nepiemēro uzņēmējdarbības noteikumus.

Dalības mijiedarbība parasti notiek vienā no diviem ceļiem:

Īpašais{0}}lasītāja ceļš:
dalībnieks → NFC atslēgas piekariņš → saderīgs lasītājs → akreditācijas datu identifikators → dalības programmatūra → dalībnieka ieraksts → reģistrēties-/ieguvums/atļauja

Tālruņa-pieskāriena ceļš:
dalībnieks → NFC atslēgu piekariņš → viedtālrunis → NDEF URL → tīmekļa vai lietotņu aizmugursistēma → konta vai kampaņas ieraksts → dalības darbība

Šajos ceļos var izmantot vienu un to pašu fiziskās formas koeficientu, taču tiem nav vienādu tehnisko prasību.

Ja projekts galvenokārt ir durvju piekļuve, nevis dalības identifikācija, kontroles prasība ir uzstādītā piekļuves sistēma. Syntek'stuvuma atslēgas piekariņa saderības rokasgrāmataaptver šo dažādo lietotāja uzdevumu.

 

UID, NDEF un dalībnieka ID ir trīs dažādas lietas

Dalības projekti bieži neizdodas, jo vairāki identifikatori tiek uzskatīti par savstarpēji aizstājamiem.

NFC forums nosakaNDEFkā izplatītu formātu lietojumprogrammu datiem NFC foruma{0}}ierīcēs un tagos. NDEF ierakstā var būt URI vai cita lietojumprogrammas lietderīgā slodze, taču šī ieraksta biznesa nozīme pieder lietojumprogrammai, kas atrodas aiz tā.

NXPNTAG213/215/216 dokumentācijaapstiprina, ka NTAG21x saime atbalsta NFC foruma 2. tipa tagu darbību, ISO/IEC 14443 A tipa un NDEF datu struktūras. Tas nodrošina arī ražotāja-ieprogrammētu UID. Šīs iespējas ir noderīgas, taču tās joprojām pārstāv dažādus slāņus: UID mikroshēmas identitātei, NDEF lietojumprogrammas datiem un aizmugursistēmas ierakstus dalības loģikai.

 

Izvēlieties vienu no trim dalības arhitektūrām

1. Īpašs lasītājs + akreditācijas datu kartēšana

Šajā modelī operators katru atslēgu piekariņu izsniedz kā sistēmas akreditācijas datus. Saderīgs lasītājs uztver dalības platformai paredzētos identifikatoru vai lietojumprogrammas datus. Aizmugursistēma kartē šos akreditācijas datus dalībnieka ierakstam.

Šī arhitektūra ir piemērota periodiskai reģistrācijai-, ieejai klubā, skapīšiem, personāla-palīdzētai lojalitātes atpazīšanai un citiem pārvaldītiem kontaktpunktiem, kuros operators kontrolē lasītāju.

Kritiskie jautājumi ir:

• Kuru tieši mikroshēmu vai akreditācijas datu tehnoloģiju atbalsta instalētais lasītājs?
• Kuru vērtību reģistrē programmatūra: UID, kartes numuru, sektora/faila datus vai citu sistēmas{0}}definēto identifikatoru?
• Vai vienam dalībniekam var būt vairāki aktīvi akreditācijas dati?
• Vai akreditācijas datus var atspējot neatkarīgi no dalībnieka konta?
• Kā tiek apstrādāti pazaudēti, atgriezti vai nomainīti FOB?

Šajā arhitektūrā NDEF var nebūt nozīmes. Atslēgas piekariņš var būt derīgs dalības akreditācijas dati pat tad, ja nav nepieciešams tālruņa{1}}lasāms URL.

2. Tālrunis pieskarieties + NDEF URL

Tālrunī{0}}pirmajā dalības pieredzē atslēgas piekarei parasti ir NDEF URI, kas norāda uz tīmekļa lapu, aktivizācijas plūsmu, konta portālu, lojalitātes lapu vai lietotnes maršrutu.

TheNFC foruma tehniskais pārskatsapraksta NFC foruma tagus kā NDEF ziņojumu nesējus, kas var izraisīt darbības, piemēram, interneta saites atvēršanu. Apple arī dokumentē fona NFC tagu nolasīšanu ap NDEF URI ierakstiem atbalstītajos iPhone tālruņosGalvenais NFC.

Šai arhitektūrai unikālā URL parasti ir jāietver necaurspīdīgs marķieris vai projekta identifikators, nevis tieši tagā jāatklāj dalībnieka vārds, e-pasts, atlikums vai citi nevajadzīgi personas dati.

Pēc tam tīmekļa aizmugursistēma var atrisināt šo pilnvaru atbilstošajā ierakstā un izlemt, ko lietotājam ir atļauts redzēt vai darīt.

3. Hibrīda lasītājs + tālruņa mijiedarbība

Daži projekti vēlas, lai viens atslēgas piekariņš atbalstītu pārvaldītu lasītāja darbplūsmu un tālruņa{0}}pieskārienu.

Tas var būt noderīgi, piemēram, ja sporta zāle vēlas speciālu lasītāju, lai reģistrētos-, vienlaikus ļaujot dalībniekam pieskarties tam pašam pults ar tālruni, lai atvērtu konta lapu.

Nedomājiet, ka abi ceļi ir automātiski saderīgi, jo tiem ir viena un tā pati NFC mikroshēma. Apstipriniet tos atsevišķi:

• lasītājam jāatbalsta precīza akreditācijas datu tehnoloģija un identifikators, ko izmanto dalības sistēma;
• tālruņa ceļā jānolasa apstiprinātā NDEF slodze un jāatver paredzamais galamērķis;
• aizmugursistēmai ir jāzina, kā lasītāja{0}}puses identifikators un NDEF-puses pilnvara ir saistīta ar vienu un to pašu kontu;
• nomaiņai ir jāatjaunina abi ceļi, ja abi paliek aktīvi.

 

 

Izlemiet, kurš ieraksts ir patiesības avots

Drošākais dalības dizains parasti saglabādalībnieka kontskā patiesības avotu un uztver atslēgas piekariņu kā piešķiramu pilnvaru.

Šī atdalīšana atvieglo nomaiņu un pārcelšanu.

Tas ļauj operatoram apturēt dalībnieka darbību, fiziski nepārrakstot piekariņu, nomainīt bojāto atslēgu piekariņu, neizveidojot jaunu dalības kontu, un saglabāt darījumu vēsturi, kad mainās akreditācijas dati.

 

Pirms partijas kodēšanas izveidojiet kartēšanu

Nesāciet mainīgo{0}}datu veidošanu ar vienu izklājlapas kolonnu ar nosaukumu “ID”. Vispirms definējiet attiecības starp identifikatoriem.

Ražošanas un ieviešanas karte var ietvert:

Privātuma un darbības kontrolei piegādātājam parasti nav nepieciešams pilntiesīgs dalībnieka profils. Tīrāks modelis ir ražošanas kartēšanas faila atdalīšana no operatora dalībnieku datu bāzes.

Piemēram, piegādātājs var atgriezt:

drukāts seriāls ↔ UID ↔ kodēts marķieris ↔ ražošanas statuss

Pēc tam operators var pievienot:

akreditācijas dati ↔ dalībnieka ID ↔ dalības statuss

pēc izdošanas.

 

Neizmantojiet UID kā drošības saīsni

UID ir noderīgs identifikācijai, taču identifikācija un autentifikācija ir dažādas drošības funkcijas.

Zema-riska lojalitātes meklēšanai var pietikt ar atbalstīta akreditācijas datu identifikatora kartēšanu aizmugursistēmas kontam. Lielāka -riska izmantošanas gadījumos, piemēram, droša piekļuve objektam, saglabātā vērtība vai maksājums, sistēmai var būt nepieciešama spēcīgāka mikroshēmas autentifikācija, aizsargāti lietojumprogrammu dati, atslēgu pārvaldība un lasītāja{3}}puses drošība.

Pamata NFC atslēgas piekariņu nevajadzētu raksturot kā drošu tikai tāpēc, ka tā mikroshēmai ir unikāls sērijas numurs. Nepieciešamajam drošības līmenim ir jābūt no sistēmas īpašnieka apdraudējuma modeļa un platformas specifikācijas.

Tāpat ar paroli{0}}aizsargāts atmiņas apgabals nav tas pats, kas kriptogrāfiskā autentifikācija.

 

Plāna pazaudēta{0}}atslēga-Fob aizstāšana pirms palaišanas

Aizstāšanas darbplūsmai ir jāsaglabā dalībnieka konts, vienlaikus mainot aktīvos akreditācijas datus.

Praktiskā secība ir šāda:

1. Atrodiet dalībnieka kontu.
2. Atzīmējiet zaudēto akreditācijas datus neaktīvu.
3. Apstipriniet, vai vecais lasītāja{0}}puses identifikators ir bloķēts turpmākai lietošanai.
4. Izsniedziet rezerves atslēgas piekariņu.
5. Saistīt jaunos akreditācijas datus ar esošo dalībnieka kontu.
6. Ja projektā tiek izmantota unikāla NDEF pilnvara, izlemiet, vai vecais marķieris ir arī jāatspējo vai jāpagriež.
7. Pārbaudiet jauno FOB īstā lasītāja vai tālruņa darbplūsmā.
8. Apstipriniet, ka vecie akreditācijas dati vairs nepabeidz aizsargātās dalības darbību.

Tāpēc dalībnieka konts nedrīkst būt pastāvīgi saistīts ar vienu fizisko UID bez administratīvā aizstāšanas slāņa.

 

Pārcelšana ir atšķirīga darbība no aizstāšanas

Aizstāšana saglabā to pašu dalībnieku un maina akreditācijas datus. Pārcelšana saglabā fiziskos akreditācijas datus un maina dalībnieku.

Šī atšķirība ir svarīga atkārtoti lietojamiem atslēgu piekariņiem sporta zālēs, klubos, nomas programmās un pārvaldītajās telpās.

Pirms atdotas FOB nodošanas citai personai:

• noņemt vecās dalībnieka attiecības;
• apstipriniet, ka vecais konts joprojām nevar izmantot akreditācijas datus;
• pārbaudīt fizisko atslēgu piekariņu;
• nolasīt atpakaļ elektronisko identifikatoru;
• atjaunināt vai pārrakstīt NDEF saturu, ja projektā tiek izmantoti dalībnieka{0}}specifiski dati;
• apsveriet iespēju pagriezt unikālu tīmekļa marķieri, ja vecā saite varēja būt kopēta, pievienota grāmatzīmēm vai kopīgota;
• piešķirt akreditācijas datus jaunajam dalībniekam;
• pārbaudiet gala lasītāja un/vai tālruņa rezultātu.

Pārcelšanas noteikumi jānosaka sistēmas īpašniekam. Tas, ka atslēgas piekariņu var fiziski izmantot atkārtoti, nepierāda, ka lietojumprogrammas dati vai konta saistība ir gatava atkārtotai izmantošanai.

 

Izvairieties no nevajadzīgu dalībnieku datu glabāšanas atslēgas piekariņā

Dalības datu izmaiņas. Vārdi, plāna statuss, punkti, priekšrocības un kontaktinformācija var mainīties, neaizstājot fiziskos akreditācijas datus.

Šī iemesla dēļ daudzus projektus ir vieglāk vadīt, ja atslēga uzglabā vai atklāj tikai stabilu identifikatoru vai nepārskatāmu URL marķieri, savukārt aizmugursistēma saglabā mainīgos biznesa datus.

Tas samazina nepieciešamību pārrakstīt akreditācijas datus un ierobežo dalībnieku informācijas apjomu, kas tiek atklāts, ja kāds skenē vai nolasa tagu.

Ja projektam patiešām ir nepieciešami aizsargāti akreditācijas dati, izvēlieties mikroshēmu un drošības arhitektūru no sistēmas prasībām, nevis sāciet ar vispārēju NTAG produktu un mēģiniet vēlāk pievienot drošību.

 

Pirms reģistrācijas definējiet dublētos noteikumus

Pastāv divas dažādas dublētās problēmas:

• dublēt elektroniskos identifikatorus vai kodētus marķierussaražotajā partijā;
• dublēt aktīvos uzdevumusdalības datu bāzē.

Pieņemšanas plānā jāatklāj abi.

Pareizi izgatavotu atslēgu piekariņu joprojām var reģistrēt nepareizajam dalībniekam. Pareizi reģistrētam dalībniekam joprojām var būt divi aktīvi akreditācijas dati, ja uzņēmējdarbības kārtula paredz tikai vienu. Tie ir dažādi kļūdu īpašnieki, un tie ir jāreģistrē atsevišķi.

 

Pārbaudiet pabeigto dalības darbplūsmu, nevis tikai NFC noteikšanu

Noderīgs parauga tests seko pilnīgam darījumam.

Lai iegūtu plašāku informāciju par NFC datu, galamērķu un kartēšanas testēšanu pirms lielapjoma ražošanas, Syntek'sNFC testēšanas kontrolsarakstsizskaidro, kāpēc veiksmīgs pieskāriens nav tas pats, kas veiksmīga biznesa darbplūsma.

 

Ko ievietot NFC dalības atslēgas piekares piedāvājumā

Tiešai fizisko akreditācijas datu iegūšanai, Syntek'sNFC atslēgu piekariņa produkta lapair nākamais komerciālais solis. Produkta izvēlei ir jāatbilst apstiprinātajai sistēmas arhitektūrai, nevis jāaizstāj tā.

 

Izvietošanas noteikums

Dalības vai lojalitātes programmā uzskatiet NFC atslēgas piekariņu kā piešķiramu akreditācijas datus, nevis kā dalībnieku datu bāzi.

Izturīga izvietošanas secība ir:

dalības uzdevums → lasītāja vai tālruņa ceļš → akreditācijas datu tehnoloģija → UID/NDEF lēmums → aizmugursistēmas dalībnieka modelis → ražošanas kartēšana → izdošanas/aizstāšanās/pārdales noteikumi → pabeigta-pārbaudes paraugs → lielapjoma apstiprināšana

Šī secība saglabā fizisko atslēgu piekariņu, elektronisko identifikatoru, tālruņa mijiedarbību un dalībnieku ierakstu vienā kontrolētā datu modelī. Tas arī padara pazaudētu{1}}fob aizstāšanu un turpmāku pārdalīšanu pārvaldāmu, nevis pārvērš tos par manuāliem datu bāzes izņēmumiem.