RFID, NFC & UWB · Study deck

NFC Tags and NDEF Format

Picture a maintenance tag that opens the wrong asset page after it is mounted.

Radio Remi is your guide for this deck.

tagsndef

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Review NFC tag family fit for simple NDEF records, file-style NDEF storage, vicinity-style labels, and application-specific credential behavior.
Explain the relationship among tag memory, NDEF TLV containers, NDEF messages, record headers, record types, and payloads.
Choose URI, Text, MIME, External, or composite record patterns for a practical IoT tag workflow.
Validate capacity, write state, lock or protection behavior, parser output, application policy, fallback, and read-back evidence.

Major section

Start With the Story

A successful tap does not show that the stored record, app rule, and physical label agree.

Near Field Communication, or NFC, is a short-range radio system used for taps.
A payload means the useful data carried inside a message or record.
This runway does not prove that a nearby tag is trusted or authorized.

Major section

Tag Capability Review

The PUMP-014 label is a candidate, so first verify its family, NDEF support, capacity, and write state on the actual part.

The planned payload and headers must fit, and the mounting surface can change read behavior.

NFC tag capability review map covering tag family, NDEF support, usable capacity, write state, physical fit, validation, and release evidence.

Major section

Tag Types and Discovery Path

NDEF is the data; the NFC Forum tag types are the chips that hold it, and they differ in memory, speed, and underlying technology.

The silicon holds the tag functions while the surrounding coil couples to the reader field.
Those properties need a part record and a read test on the intended surface.

A bare NFC tag chip bonded to its antenna coil -- this silicon-plus-coil pairing is what the table above is really classifying row by row, whether it ends up laminated into a Topaz Type 1 label or a DESFire Type 4 card. Photo: HenryWortel, CC BY-SA 4.0

Major section

Tag Types and Discovery Path (continued)

Packaging can put that pair in a sticker or card, but a photograph of the bare part cannot identify its exact tag family, memory size, security features, or final read range.

The image helps explain the physical boundary behind a capability table; it is not release evidence for a specific label.
Regardless of type, a reader first discovers whether an NDEF mapping is present.
Choosing a tag type is a memory, security, and reader-support decision.

Major section

Tag Types and Discovery Path (continued)

On small labels this can mean reading a Capability Container or TLV-style metadata that declares NDEF memory size and access state.

On file-oriented tags it can mean selecting and reading an NDEF file.
That discovery step is what lets one phone handle a small NTAG poster sticker and a multi-kilobyte DESFire card with the same NDEF parsing logic.
Choosing NDEF records is a behavior decision.

Major section

NDEF Message Structure

NDEF turns tag bytes into records that many NFC devices can parse.

MB and ME delimit the ordered message; SR selects the one-byte payload-length form for a payload under 256 bytes, and IL determines whether an ID-length field follows.
Those flags are parsing instructions, not application content, and malformed combinations must be rejected.

NDEF message structure showing the NDEF message container, record fields, header flags, TNF values, and common record types.

Major section

NDEF Record Planning

A tag that seems to open a URL, join Wi-Fi, or show text when you tap it is usually storing data as NDEF (NFC Data Exchange Format), the common format NFC readers understand.

An NDEF message is a list of NDEF records, and each record is a typed container with a type, optional ID, and payload.
The record type is what lets a reader choose an action.
The release decision starts with capacity and lifecycle.

Major section

NDEF Record Planning (continued)

A URI record says "this is a link"; a Text record says "this is text"; a MIME or External record says "this is app-specific structured data." The tag is not running the workflow.

For a maintenance label, a safe NDEF plan might use one URI record and one Text record.
The Text record stores a short printed fallback such as PUMP-014, so support can compare the phone result with the visible label.
The tag still does not authorize work; it only selects the asset and gives the application structured input to validate.

Major section

Validation and Security Boundary

That also means it should not carry authority.

A public NDEF record can route a phone to an object or setup reference; it should not carry a secret or a direct protected command.
The app validates record type, host, route, and session before policy decides whether to allow any action.
The same layering explains the security boundary.

NFC tag and NDEF security boundary separating public payloads, application validation, forbidden data, credential systems, fallback, and audit evidence.

Major section

Validation and Security Boundary (continued)

A credential flow needs separate proof and a verifier, while the audit and fallback record show what happened when the tap failed or was denied.

The tag helps select context, and the application owns the trust decision.
Public payload: A URL, text label, external type, or MIME payload can identify context or launch an app path.
Credential system: If the tap controls access or authenticity, use a credential proof path outside ordinary readable NDEF and document revocation.

Major section

Validation and Security Boundary (continued)

Public NDEF is useful because it is easy to read.

Type 2 and Type 5 labels are often excellent public pointers, but ordinary readable NDEF does not hide secrets from a phone.
Type 4 tags can support file access conditions and larger payloads, but an NDEF file is still only one part of a credential system.
If a copied NDEF message can trigger the final action, the tag has been given too much authority.

Major section

Write and Release Loop

App validation must accept the intended route, reject a wrong host, and test duplicate taps and fallback lookup.

A successful write only proves a command completed; it cannot substitute for those later checks.

NFC tag write and release loop from payload plan through capacity check, write, read-back, app validation, field test, lock decision, and retest evidence.

Major section

Common Review Findings

Tag type chosen by habit: The tag must fit capacity, NDEF support, write state, placement, reader path, and support needs.

Payload too large after overhead: A payload that fits in a note may not fit once NDEF headers, language fields, type fields, and fallback data are included.
Authority stored in NDEF: Readable records should not carry secrets, credentials, roles, unlock commands, or policy decisions.
No fallback value: A printed or text fallback keeps the workflow usable when the reader, phone setting, tag placement, or app route fails.

Major section

Checkpoint: Summary

NFC tag review starts with family, NDEF support, usable capacity, write state, physical fit, and release evidence.

NDEF messages are structured as records with header flags, type information, optional IDs, and payloads that applications must validate.
URI, Text, MIME, External, and composite records are useful when each record has a clear workflow role.
Ordinary NDEF should carry context and routing data, not credentials, private data, unlock commands, long-lived secrets, or policy decisions.

Deck summary

Key takeaways

A successful tap does not show that the stored record, app rule, and physical label agree.

The PUMP-014 label is a candidate, so first verify its family, NDEF support, capacity, and write state on the actual part.
NDEF is the data; the NFC Forum tag types are the chips that hold it, and they differ in memory, speed, and underlying technology.
Packaging can put that pair in a sticker or card, but a photograph of the bare part cannot identify its exact tag family, memory size, security features, or final read range.
NDEF turns tag bytes into records that many NFC devices can parse.

Retrieval practice

Recall check 1 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q1According to this chapter, NFC tag work should start with what, before choosing a payload idea?

AThe marketing copy for the URL that will eventually be written to it.

BThe colour of the tag's plastic housing or its printed sticker.

CThe brand of phone that will eventually be used to read the tag.

DThe tag family, NDEF support, usable capacity, and lock state.

Show answer

Answer: D NFC tag work starts with tag family, NDEF support, usable capacity, and lock/write state, not the payload idea.

Retrieval practice

Recall check 2 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q2You need cheap stickers that open a URL on tap, plus a smaller number of tags that store a secured, file-structured credential of several kilobytes. Which choices fit?

AUse Type 4 tags for both, so the URL stickers and secured credentials share one reader and provisioning workflow.

BStore the URL as a MIME application/json record because URI records are not supported.

CType 2 (NTAG) tags for the URL stickers; Type 4 (DESFire) tags for the secured multi-KB credential.

DUse Type 5 for the stickers because ISO 15693 is the cheapest 14443 variant available.

Show answer

Answer: C NDEF records such as the Well-Known URI record define behavior; NFC Forum tag types T1T-T5T define memory, access, and radio mapping.

Retrieval practice

Recall check 3 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q3A public NFC label opens an asset page. What should it store?

AA private access token with no expiry

BA final allow decision for every future user

CA reusable administrator password

DA public pointer that the app validates

Show answer

Answer: D Readable NDEF is suitable for a pointer, not a secret.

Retrieval practice

Recall check 4 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q4A team writes an NFC tag with a URI record and the writer app reports success. What is the best next step before the tag is locked and installed?

ALock the tag immediately, because a successful write already proves the final payload is correct and installed.

BAdd a private credential to the NDEF payload so the application can skip later checks.

CReplace the URI record with raw bytes so that phones cannot inspect the payload.

DRead and decode the tag, compare the plan, validate the app route and record release proof.

Show answer

Answer: D A safe NDEF release loop verifies the final tag bytes through decoded read-back, validates app behavior, checks denied cases and fallback, and records evidence before locking or installing the tag.

Print reference

Answers 1 of 2

Answer key.

D · NFC tag work starts with tag family, NDEF support, usable capacity, and lock/write state, not the payload idea.
C · NDEF records such as the Well-Known URI record define behavior; NFC Forum tag types T1T-T5T define memory, access, and radio mapping.
D · Readable NDEF is suitable for a pointer, not a secret.

Print reference

Answers 2 of 2

Answer key.

D · A safe NDEF release loop verifies the final tag bytes through decoded read-back, validates app behavior, checks denied cases and fallback, and records evidence before locking or installing the tag.