NFC-nyckelringar för medlemssystem: UID, NDEF och medlemskartläggning

En NFC-nyckelbricka kan identifiera en medlem, öppna en webbupplevelse eller göra både och. Felet är att behandla dem som samma tekniska arbetsflöde.

I ett medlemskap eller lojalitetsprogram är nyckelfrågan inte bara vilket NFC-chip man ska köpa. Det är detvilken identifierare systemet kommer att lita på, var medlemsposten kommer att bo och hur den fysiska nyckelbrickan kommer att utfärdas, ersättas, avaktiveras och omtilldelas utan att den kartläggningen bryts.

Den här guiden fokuserar på den dataarkitekturen. Det är för gymoperatörer, klubbar, lojalitetsplattformar, medlemskap-systemintegratörer och inköpsteam som planerar en massdistribution av NFC-nyckelbrickor.

 

Börja med medlemstransaktionen, inte nyckelbrickan

En NFC-nyckelbricka är en legitimation. Den beräknar inte poäng, avgör om ett medlemskap är aktivt, lagrar inte den auktoritativa kundprofilen eller tillämpar affärsregler på egen hand.

En medlemskapsinteraktion följer normalt en av två vägar:

Dedikerad-läsväg:
medlem → NFC-nyckelbricka → kompatibel läsare → autentiseringsidentifierare → medlemskapsprogram → medlemsregister → incheckning-/förmån/tillstånd

Telefon-tryckväg:
medlem → NFC-nyckelbricka → smartphone → NDEF URL → webb- eller appbackend → konto- eller kampanjpost → medlemskapsåtgärd

Dessa vägar kan använda samma fysiska formfaktor, men de har inte samma tekniska krav.

Om projektet primärt är dörråtkomst snarare än medlemsidentifiering, är det kontrollerande kravet det installerade åtkomstsystemet. Syntekskompatibilitetsguide för närhetsnyckelbrickatäcker den olika användaruppgiften.

 

UID, NDEF och medlems-ID är tre olika saker

Medlemskapsprojekt misslyckas ofta eftersom flera identifierare behandlas som utbytbara.

NFC-forumet definierarNDEFsom ett vanligt format för programdata på NFC Forum-kompatibla enheter och taggar. En NDEF-post kan bära en URI eller annan applikationsnyttolast, men den affärsmässiga betydelsen av den posten tillhör applikationen bakom den.

NXP:sNTAG213/215/216 dokumentationbekräftar att NTAG21x-familjen stöder NFC Forum Type 2 Tag-beteende, ISO/IEC 14443 Typ A och NDEF-datastrukturer. Den tillhandahåller också ett tillverkar-programmerat UID. Dessa funktioner är användbara, men de representerar fortfarande olika lager: UID för chipidentitet, NDEF för applikationsdata och backend-poster för medlemslogik.

 

Välj en av tre medlemsarkitekturer

1. Dedikerad läsare + autentiseringskartläggning

I denna modell utfärdar operatören varje nyckelbricka som en systemuppgift. En kompatibel läsare fångar identifieraren eller applikationsdata som förväntas av medlemsplattformen. Backend mappar den referensen till en medlemspost.

Den här arkitekturen passar återkommande incheckning-, klubbinträde, skåp, personal-assisterad lojalitetsidentifiering och andra hanterade kontaktpunkter där operatören kontrollerar läsaren.

De kritiska frågorna är:

• Vilken exakt chip- eller autentiseringsteknik stöder den installerade läsaren?
• Vilket värde registrerar programvaran: UID, kortnummer, sektor-/fildata eller annan -systemdefinierad identifierare?
• Kan en medlem ha mer än en aktiv legitimation?
• Kan en inloggningsinformation inaktiveras oberoende av medlemskontot?
• Hur hanteras förlorade, återlämnade eller utbytta fobs?

NDEF kan vara irrelevant i denna arkitektur. En nyckelbricka kan vara ett giltigt medlemskap även när ingen -läsbar webbadress krävs.

2. Telefontryck + NDEF URL

I en telefon-första medlemskapsupplevelse har nyckelbrickan vanligtvis en NDEF URI som pekar på en webbsida, aktiveringsflöde, kontoportal, lojalitetssida eller apprutt.

DeNFC Forum teknisk översiktbeskriver NFC-forumtaggar som bärare av NDEF-meddelanden som kan utlösa åtgärder som att öppna en internetlänk. Apple dokumenterar också bakgrunds-NFC-taggläsning runt NDEF URI-poster på stödda iPhones iCore NFC.

För denna arkitektur bör en unik URL normalt innehålla en ogenomskinlig token eller projektidentifierare istället för att exponera en medlems namn, e-post, saldo eller andra onödiga personliga data direkt i taggen.

Webbservern kan sedan lösa den token till lämplig post och bestämma vad användaren får se eller göra.

3. Hybridläsare + telefoninteraktion

Vissa projekt vill ha en nyckelbricka för att stödja ett hanterat läsararbetsflöde och en telefon-avtrycksupplevelse.

Det kan till exempel vara användbart när ett gym vill ha en dedikerad läsare för incheckning-och samtidigt låter medlemmen trycka på samma fob med en telefon för att öppna en kontosida.

Anta inte att de två vägarna är automatiskt kompatibla eftersom de delar samma NFC-chip. Validera dem separat:

• läsaren måste stödja den exakta legitimationsteknik och identifierare som används av medlemssystemet;
• telefonsökvägen måste läsa den godkända NDEF-nyttolasten och öppna den förväntade destinationen;
• backend måste veta hur läsarens-sideidentifierare och NDEF-sidetoken relaterar till samma konto;
• en ersättare måste uppdatera båda sökvägarna om båda förblir aktiva.

 

 

Bestäm vilken uppteckning som är källan till sanningen

Den säkraste medlemskapsdesignen håller vanligtvismedlemskontosom källan till sanningen och behandlar nyckelbrickan som en tilldelbar legitimation.

Den separationen gör utbyte och omplacering enklare.

Detta låter operatören stänga av en medlem utan att fysiskt skriva om fob, ersätta en skadad nyckelbricka utan att skapa ett nytt medlemskonto, och bevara transaktionshistorik när autentiseringsuppgifterna ändras.

 

Bygg kartläggningen innan du kodar batchen

Starta inte produktion av variabel-data med en kalkylarkskolumn som heter "ID". Definiera relationen mellan identifierare först.

En tillverknings- och distributionskarta kan innehålla:

För integritets- och driftskontroll behöver leverantören vanligtvis inte den fullständiga medlemsprofilen. En renare modell är att separera produktionskartläggningsfilen från operatörens medlemsdatabas.

Till exempel kan leverantören returnera:

tryckt seriell ↔ UID ↔ kodad token ↔ produktionsstatus

Operatören kan sedan lägga till:

legitimation ↔ medlems-ID ↔ medlemsstatus

efter utfärdandet.

 

Använd inte UID som en säkerhetsgenväg

Ett UID är användbart för identifiering, men identifiering och autentisering är olika säkerhetsfunktioner.

För en lojalitetssökning med låg-risk kan det räcka med att mappa en stödd autentiseringsidentifierare till ett backend-konto. För användningsfall med högre-risk, såsom säker tillgång till anläggningar, lagrat värde eller betalning, kan systemet kräva starkare chipautentisering, skyddad applikationsdata, nyckelhantering och läsarsäkerhet på-sidan.

En grundläggande NFC-nyckelbricka ska inte beskrivas som säker bara för att dess chip har ett unikt serienummer. Den säkerhetsnivå som krävs måste komma från systemägarens hotmodell och plattformsspecifikation.

På samma sätt är ett lösenordsskyddat-minnesområde inte detsamma som kryptografisk autentisering.

 

Planering förlorad-nyckel-Byte av fob före lansering

Ett ersättningsarbetsflöde bör bevara medlemskontot samtidigt som den aktiva referensen ändras.

En praktisk sekvens är:

1. Hitta medlemskontot.
2. Markera den förlorade referensen som inaktiv.
3. Bekräfta om den gamla -läsarsidans identifierare är blockerad från framtida användning.
4. Ge den nya nyckelbrickan.
5. Mappa den nya inloggningsinformationen till det befintliga medlemskontot.
6. Om projektet använder en unik NDEF-token, bestäm om den gamla token också måste inaktiveras eller roteras.
7. Verifiera den nya fobben vid det verkliga arbetsflödet för läsaren eller telefonen.
8. Bekräfta att den gamla inloggningsinformationen inte längre slutför den skyddade medlemskapsåtgärden.

Det är därför medlemskontot inte ska vara permanent bundet till ett fysiskt UID utan ett administrativt ersättningslager.

 

Omplacering är en annan operation än utbyte

Ersättning behåller samma medlem och ändrar autentiseringsuppgifterna. Omtilldelning behåller den fysiska referensen och ändrar medlem.

Den skillnaden har betydelse för återanvändbara nyckelbrickor i gym, klubbar, uthyrningsprogram och hanterade anläggningar.

Innan du ger en återlämnad fob till en annan person:

• ta bort det gamla medlemsförhållandet;
• bekräfta att det gamla kontot fortfarande inte kan använda inloggningsuppgifterna;
• inspektera den fysiska nyckelbrickan;
• läsa tillbaka den elektroniska identifieraren;
• uppdatera eller skriva över NDEF-innehåll om projektet använder medlemsspecifik-data;
• överväg att rotera en unik webbtoken om den gamla länken kunde ha kopierats, bokmärkts eller delats;
• tilldela legitimationen till den nya medlemmen;
• testa det slutliga läsaren och/eller telefonresultatet.

Regler för omtilldelning bör definieras av systemägaren. Det faktum att en nyckelbricka kan återanvändas fysiskt bevisar inte att applikationsdata eller kontoförhållande är redo för återanvändning.

 

Undvik att lagra onödiga medlemsdata på nyckelbrickan

Medlemsdata ändras. Namn, planstatus, poäng, förmåner och kontaktuppgifter kan alla ändras utan att ersätta den fysiska referensen.

Av den anledningen är många projekt enklare att driva när nyckelbrickan endast lagrar eller exponerar en stabil identifierare eller ogenomskinlig URL-token, medan backend lagrar de förändrade affärsdata.

Detta minskar behovet av att skriva om inloggningsuppgifter och begränsar mängden medlemsinformation som exponeras om någon skannar eller läser taggen.

Om ett projekt verkligen behöver skyddad data på referensen, välj chip och säkerhetsarkitektur från systemkravet istället för att börja med en generisk NTAG-produkt och försöka lägga till säkerhet senare.

 

Definiera dubbletter av regler före registrering

Det finns två olika dubblettproblem:

• dubbletter av elektroniska identifierare eller kodade tokensi den tillverkade satsen;
• dubbletter av aktiva uppdragi medlemsdatabasen.

Acceptansplanen bör upptäcka båda.

En korrekt tillverkad nyckelbricka kan fortfarande registreras till fel medlem. En korrekt registrerad medlem kan fortfarande ha två aktiva referenser när affärsregeln endast avsåg en. Dessa är olika felägare och bör loggas separat.

 

Testa det färdiga arbetsflödet för medlemskap, inte bara NFC-detektering

Ett användbart exempeltest följer den fullständiga transaktionen.

För bredare bakgrund om testning av NFC-data, destinationer och kartläggning inför bulkproduktion, SynteksChecklista för NFC-testningförklarar varför en framgångsrik kran inte är detsamma som ett framgångsrikt arbetsflöde.

 

Vad du ska lägga i en NFC-medlemskapsnyckelförfrågan

För direkt inköp av den fysiska referensen, SynteksNFC-nyckelbricka produktsidaär det kommersiella nästa steget. Produktvalet bör följa den godkända systemarkitekturen snarare än att ersätta den.

 

Implementeringsregeln

För ett medlemskap eller lojalitetsprogram, behandla NFC-nyckelbrickan som en tilldelningsbar referens, inte som medlemsdatabasen.

En robust distributionssekvens är:

medlemsuppgift → läsare eller telefonsökväg → legitimationsteknik → UID/NDEF-beslut → backend-medlemsmodell → produktionskartläggning → regler för utfärdande/ersättning/omtilldelning → avslutat-provtest → massgodkännande

Den sekvensen håller den fysiska nyckelbrickan, elektronisk identifierare, telefoninteraktion och medlemsregistrering under en kontrollerad datamodell. Det gör också borttappad-fjärrbyte och framtida omtilldelning hanterbara istället för att göra dem till manuella databasundantag.