NFC-avaimenperät jäsenjärjestelmiin: UID, NDEF ja jäsenkartoitus

NFC-avaimenperä voi tunnistaa jäsenen, avata verkkokokemuksen tai tehdä molempia. Virhe on käsitellä niitä samana teknisenä työnkulkuna.

Jäsenyys- tai kanta-asiakasohjelmassa keskeinen kysymys ei ole pelkästään se, mikä NFC-siru ostaa. Se onmihin tunnisteeseen järjestelmä luottaa, missä jäsentietue asuu ja miten fyysinen avaimenperä myönnetään, korvataan, deaktivoidaan ja osoitetaan uudelleen rikkomatta tätä kartoitusta.

Tämä opas keskittyy tähän tietoarkkitehtuuriin. Se on tarkoitettu kuntosalioperaattoreille, klubeille, kanta-asiakasalustoille, jäsen{1}}järjestelmäintegraattoreille ja hankintatiimeille, jotka suunnittelevat NFC-avaimenperän käyttöönottoa.

 

Aloita jäsenyystapahtumasta, ei avaimenperästä

NFC-avaimenperä on valtuustieto. Se ei laske pisteitä, päätä, onko jäsenyys aktiivinen, tallenna arvovaltaista asiakasprofiilia tai sovella liiketoimintasääntöjä itse.

Jäsenyysvuorovaikutus noudattaa yleensä jompaakumpaa kahdesta polusta:

Omistettu{0}}lukijapolku:
jäsen → NFC-avain → yhteensopiva lukija → käyttöoikeustunniste → jäsenohjelmisto → jäsentietue → kirjautuminen-sisään / etu / lupa

Puhelin-kosketuspolku:
jäsen → NFC-avaimenperä → älypuhelin → NDEF-URL → verkko- tai sovelluksen taustajärjestelmä → tili- tai kampanjatietue → jäsenyystoiminto

Nämä polut voivat käyttää samaa fyysistä muototekijää, mutta niillä ei ole samoja teknisiä vaatimuksia.

Jos projekti on ensisijaisesti ovesta sisäänpääsy eikä jäsentunnistus, ohjaava vaatimus on asennettu pääsyjärjestelmä. Syntekinproximity key fob -yhteensopivuusopaskattaa kyseisen käyttäjän erilaisen tehtävän.

 

UID, NDEF ja jäsentunnus ovat kolme eri asiaa

Jäsenyysprojektit epäonnistuvat usein, koska useita tunnisteita käsitellään keskenään vaihtokelpoisina.

NFC-foorumi määritteleeNDEFyleisenä muotona sovellustiedoille NFC Forum{0}}yhteensopivilla laitteilla ja tunnisteilla. NDEF-tietue voi sisältää URI:n tai muun sovelluksen hyötykuorman, mutta tietueen liiketoiminnallinen merkitys kuuluu sen takana olevalle sovellukselle.

NXP:tNTAG213/215/216 dokumentaatiovahvistaa, että NTAG21x-perhe tukee NFC Forum Type 2 -tunnisteen käyttäytymistä, ISO/IEC 14443 Type A- ja NDEF-tietorakenteita. Se tarjoaa myös valmistajan-ohjelmoidun UID:n. Nämä ominaisuudet ovat hyödyllisiä, mutta ne edustavat silti eri tasoja: UID sirun identiteetille, NDEF sovellustiedoille ja taustatietueet jäsenlogiikkaan.

 

Valitse yksi kolmesta jäsenarkkitehtuurista

1. Oma lukija + valtuustietojen kartoitus

Tässä mallissa operaattori antaa jokaisen avaimen järjestelmän valtuustiedoksi. Yhteensopiva lukija kaappaa tunnisteen tai sovellustiedot, joita jäsenalusta odottaa. Taustaohjelma yhdistää kyseiset valtuustiedot jäsentietueeseen.

Tämä arkkitehtuuri sopii toistuvaan-sisäänkirjautumiseen, klubien sisäänpääsyyn, kaappiin, henkilökunnan-avusteiseen uskollisuuden tunnistamiseen ja muihin hallinnoituihin kosketuspisteisiin, joissa käyttäjä ohjaa lukijaa.

Kriittiset kysymykset ovat:

• Mitä sirua tai valtuustietotekniikkaa asennettu lukija tukee?
• Minkä arvon ohjelmisto rekisteröi: UID:n, kortin numeron, sektorin/tiedoston tiedot vai muun järjestelmän{0}}määrittämän tunnisteen?
• Voiko yhdellä jäsenellä olla useampi kuin yksi aktiivinen tunniste?
• Voiko tunnistetiedot poistaa käytöstä jäsentilistä riippumatta?
• Miten kadonneita, palautettuja tai vaihdettuja fobeja käsitellään?

NDEF voi olla epäolennainen tässä arkkitehtuurissa. Avaimenperä voi olla kelvollinen jäsentunnus, vaikka puhelimella -luettavaa URL-osoitetta ei tarvita.

2. Puhelin napauta + NDEF URL

Puhelimen-ensimmäisessä jäsenyyskokemuksessa avaimenperässä on yleensä NDEF-URI, joka osoittaa verkkosivulle, aktivointikulkuun, tiliportaaliin, kanta-asiakassivuun tai sovelluksen reittiin.

TheNFC Forumin tekninen yleiskatsauskuvaa NFC-foorumitunnisteita NDEF-viestien välittäjiksi, jotka voivat käynnistää toimintoja, kuten Internet-linkin avaamisen. Apple dokumentoi myös taustan NFC-tunnisteen NDEF URI -tietueiden lukemisen tuetuissa iPhoneissaYdin NFC.

Tässä arkkitehtuurissa yksilöllisen URL-osoitteen tulisi tavallisesti sisältää läpinäkymätön tunnus tai projektin tunniste sen sijaan, että se paljastaisi jäsenen nimen, sähköpostiosoitteen, saldon tai muita tarpeettomia henkilötietoja suoraan tagissa.

Web-taustaosa voi sitten määrittää kyseisen tunnuksen sopivaksi tietueeksi ja päättää, mitä käyttäjä saa nähdä tai tehdä.

3. Hybridilukija + puhelimen vuorovaikutus

Jotkut projektit haluavat yhden avaimen tukemaan hallittua lukijan työnkulkua ja puhelin{0}}napautuskokemusta.

Siitä voi olla hyötyä esimerkiksi silloin, kun kuntosali haluaa erillisen lukijan sisäänkirjautumista varten-, mutta samalla jäsenen voi avata tilisivun napauttamalla samaa kaukosäädintä puhelimella.

Älä oleta, että nämä kaksi polkua ovat automaattisesti yhteensopivia, koska niillä on sama NFC-siru. Vahvista ne erikseen:

• lukijan on tuettava jäsenjärjestelmän käyttämää täsmällistä tunnistetekniikkaa ja tunnistetta;
• puhelinpolun on luettava hyväksytty NDEF-hyötykuorma ja avattava odotettu kohde;
• taustajärjestelmän on tiedettävä, miten lukija{0}}puolen tunniste ja NDEF-puolen tunnus liittyvät samaan tiliin;
• korvaavan on päivitettävä molemmat polut, jos molemmat pysyvät aktiivisina.

 

 

Päätä, mikä tallenne on totuuden lähde

Turvallisin jäsenyysrakenne yleensä säilyttääjäsentilitotuuden lähteenä ja pitää avaimenperää luovutettavana valtuustietona.

Tämä erottaminen helpottaa vaihtamista ja uudelleen osoittamista.

Tämän avulla käyttäjä voi jäädyttää jäsenen kirjoittamatta fyysistä fobia uudelleen, vaihtaa vahingoittuneen avaimenperän luomatta uutta jäsentiliä ja säilyttää tapahtumahistorian, kun tunnistetiedot muuttuvat.

 

Luo kartoitus ennen erän koodausta

Älä aloita muuttujan{0}}tietojen tuotantoa yhdellä laskentataulukon sarakkeella nimeltä "ID". Määritä ensin tunnisteiden välinen suhde.

Valmistus- ja käyttöönottokartta voi sisältää:

Yksityisyyden ja toiminnan valvontaa varten toimittaja ei yleensä tarvitse täyttä jäsenprofiilia. Puhtaampi malli on erottaa tuotannon kartoitustiedosto operaattorin jäsentietokannasta.

Toimittaja voi palauttaa esimerkiksi:

painettu sarja ↔ UID ↔ koodattu tunnus ↔ tuotannon tila

Operaattori voi sitten lisätä:

valtuustiedot ↔ jäsentunnus ↔ jäsenyyden tila

myöntämisen jälkeen.

 

Älä käytä UID-tunnusta suojauksen pikakuvakkeena

UID on hyödyllinen tunnistamisessa, mutta tunnistaminen ja todennus ovat eri suojaustoimintoja.

Pienen{0}}riskin uskollisuushakua varten voi riittää tuetun tunnistetunnuksen yhdistäminen taustatiliin. Suuremman -riskin käyttötapauksissa, kuten suojattu toimintojen käyttö, tallennettu arvo tai maksu, järjestelmä saattaa vaatia vahvempaa sirutodennusta, suojattuja sovellustietoja, avainten hallintaa ja lukijapuolen suojausta.

Perus-NFC-avaimenperää ei pidä kuvata turvalliseksi vain siksi, että sen sirulla on yksilöllinen sarjanumero. Vaaditun suojaustason on perustuttava järjestelmän omistajan uhkamallin ja alustan määrittelyyn.

Samoin salasanalla{0}}suojattu muistialue ei ole sama asia kuin salaustodennus.

 

Suunnitelma kadonnut{0}}avain-Fob-korvaus ennen julkaisua

Korvaavan työnkulun tulisi säilyttää jäsentili aktiivisen tunnistetietojen muuttamisen aikana.

Käytännön sekvenssi on:

1. Etsi jäsentili.
2. Merkitse kadonnut valtuustieto ei-aktiiviseksi.
3. Varmista, onko vanha lukijan{0}}puolen tunniste estetty tulevasta käytöstä.
4. Anna vaihtoavaimenperä.
5. Yhdistä uudet tunnistetiedot olemassa olevaan jäsentiliin.
6. Jos projekti käyttää ainutlaatuista NDEF-tunnusta, päätä, pitääkö vanha merkki myös poistaa käytöstä vai kiertää.
7. Tarkista uusi fob todellisessa lukijan tai puhelimen työnkulussa.
8. Varmista, että vanhat kirjautumistiedot eivät enää suorita suojattua jäsenyystoimintoa.

Tästä syystä jäsentiliä ei pitäisi pysyvästi liittää yhteen fyysiseen UID:hen ilman hallinnollista korvauskerrosta.

 

Uudelleenmäärääminen on eri asia kuin korvaaminen

Korvaaminen säilyttää saman jäsenen ja muuttaa valtuustietoja. Uudelleenmäärääminen säilyttää fyysiset valtuustiedot ja vaihtaa jäsentä.

Tällä erolla on merkitystä uudelleenkäytettäville avaimenperäille kuntosaleissa, klubeissa, vuokraohjelmissa ja hallinnoiduissa tiloissa.

Ennen kuin annat palautetun fobin toiselle henkilölle:

• poista vanha jäsensuhde;
• varmista, että vanha tili ei voi edelleenkään käyttää tunnistetietoja;
• tarkasta fyysinen avaimenperä;
• lukea takaisin sähköinen tunniste;
• päivittää tai korvata NDEF-sisältöä, jos projekti käyttää jäsen{0}}kohtaisia ​​tietoja;
• harkitse ainutlaatuisen verkkotunnuksen kiertämistä, jos vanha linkki olisi voitu kopioida, lisätä kirjanmerkkeihin tai jakaa.
• määritä valtuustiedot uudelle jäsenelle;
• testaa lopullista lukijan ja/tai puhelimen tulosta.

Järjestelmän omistajan tulee määrittää uudelleenmäärityssäännöt. Se, että avaimenperää voidaan käyttää fyysisesti uudelleen, ei todista, että sovellustiedot tai tilisuhde on valmis käytettäväksi uudelleen.

 

Vältä tarpeettomien jäsentietojen tallentamista avaimenperään

Jäsentietojen muutokset. Nimet, suunnitelman tila, pisteet, edut ja yhteystiedot voivat muuttua ilman, että fyysisiä tunnistetietoja vaihdetaan.

Tästä syystä monia projekteja on helpompi käyttää, kun avaimenperä tallentaa tai paljastaa vain vakaan tunnisteen tai läpinäkymättömän URL-tunnuksen, kun taas taustajärjestelmä tallentaa muuttuvat liiketoimintatiedot.

Tämä vähentää tarvetta kirjoittaa valtuustietoja uudelleen ja rajoittaa paljastettavien jäsentietojen määrää, jos joku skannaa tai lukee tunnisteen.

Jos projekti todella tarvitsee suojattuja tietoja valtuustiedoissa, valitse siru ja suojausarkkitehtuuri järjestelmävaatimuksista sen sijaan, että aloitat yleisellä NTAG-tuotteella ja yrität lisätä suojausta myöhemmin.

 

Määritä päällekkäiset säännöt ennen ilmoittautumista

On olemassa kaksi erilaista päällekkäistä ongelmaa:

• kopioida sähköisiä tunnisteita tai koodattuja tunnuksiavalmistetussa erässä;
• päällekkäisiä aktiivisia tehtäviäjäsentietokannassa.

Hyväksymissuunnitelman tulee havaita molemmat.

Oikein valmistettu avaimenperä voidaan silti rekisteröidä väärälle jäsenelle. Oikein rekisteröidyllä jäsenellä voi silti olla kaksi aktiivista kirjautumistietoa, jos liiketoimintasääntö tarkoitti vain yhtä. Nämä ovat eri vikojen omistajia, ja ne tulee kirjata erikseen.

 

Testaa valmiin jäsenyyden työnkulkua, ei vain NFC-tunnistusta

Hyödyllinen näytetesti seuraa koko tapahtumaa.

Syntek's tarjoaa laajempaa taustaa NFC-tietojen, kohteiden ja kartoituksen testaamiseen ennen joukkotuotantoaNFC-testauksen tarkistuslistaselittää, miksi onnistunut hana ei ole sama asia kuin onnistunut liiketoiminnan työnkulku.

 

Mitä laittaa NFC-jäsenyyden avaimenperän tarjouspyyntöön

Suoraan fyysisten valtuustietojen hankintaan, SyntekNFC-avaimenperän tuotesivuon kaupallinen seuraava askel. Tuotevalinnan tulee noudattaa hyväksyttyä järjestelmäarkkitehtuuria eikä korvata sitä.

 

Käyttöönottosääntö

Käsittele jäsen- tai kanta-asiakasohjelmassa NFC-avaimenperää määritettävänä tunnistetietona, ei jäsentietokantana.

Vankka käyttöönottojärjestys on:

jäsentehtävä → lukija- tai puhelinpolku → valtuustietotekniikka → UID/NDEF-päätös → taustajäsenmalli → tuotannon kartoitus → ongelma-/korvaus-/uudelleenmäärityssäännöt → valmis-näytetesti → joukkohyväksyntä

Tämä järjestys pitää fyysisen avaimenperän, elektronisen tunnisteen, puhelimen vuorovaikutuksen ja jäsentietueen yhden ohjatun tietomallin alla. Se tekee myös kadonneen-kauko-ohjaimen vaihtamisesta ja tulevasta uudelleenmäärityksestä hallittavissa sen sijaan, että ne muuttaisivat manuaalisia tietokantapoikkeuksia.