How the tap actually works.

The marketing page keeps this short on purpose. This is the version that names the parts: the chip, the keys, the counter, the server, and what each one is actually doing when a phone touches a tag.

What the system proves, and what it does not

Start here, because the whole design follows from the limits. A secure NFC tag can prove three things:

• Credential presence. A specific cryptographic credential was physically present at the tap. The chip signed a fresh message; nothing else could have.
• Freshness. The tap happened now, not at some earlier time when a screenshot was taken. The counter advanced.
• Status. The issuer's server says the credential is active, not revoked, not replaced.

It does not prove, by itself:

• That the tag has never been removed from one object and stuck on another. That takes tamper-evident mounting, physical controls, or provenance procedures on top. For objects with closures, the NTAG 424 DNA TT's tamper loop detects opening. For objects without a closure, like a mineral specimen, the defense is photographic: a tag_in_place photo in the record, compared by later viewers.
• That the object behind the tag is what the record claims. The credential authenticates the tag; the application decides what the tag is attached to.
• That the system is unhackable, unclonable, or infallible. No honest system claims that, and this one will not either.

The tap, end to end

When a phone touches the tag, this is what happens, in order:

1. The chip wakes up. NTAG 424 DNA tags are powered by the phone's NFC field. No battery, no app required on the reader side.
2. The chip authenticates the reader with EV2 (AES-128 based mutual authentication). The tag will not talk to just anyone.
3. The chip builds a dynamic message (SDM, Secure Dynamic Messaging): encrypted payload plus a MAC, tied to the chip's current counter. The counter increments on every read. The same bytes never come out twice.
4. The phone assembles a verification URL with the credential ID, the encrypted payload, and the MAC, and opens it.
5. The server checks three things: the AES decryption and MAC verify (the message came from this specific chip with the right keys), the counter is ahead of the last seen value (this is a fresh tap, not a replay), and the credential is in an active state.
6. The server answers with the tenant's branded result page and whatever the issuer chooses to reveal.

Example of the credential reference that goes into the URL, straight from the live implementation:

https://verify.melon.tips/t?c=RM-0001-A&e=<encrypted-dynamic-payload>&m=<mac>

A bare link without e and m gets a 400. There is nothing to check. That is the point, and it is deliberate.

Opening a website with a tap

Verification answers “is this tag genuine?”. The same chip, the same cryptographic check, can also answer “may this person open this page?” — the tap becomes the credential for a website, with no password on the page to share, leak or rotate.

1. The tap is verified exactly as usual. Decrypt the SDM payload, check the MAC, require the counter to advance, require the credential to be active and unexpired. A tap that fails any of those is refused before any access exists.
2. Only then is a grant minted. The verifier signs <expires>.<session-until>.<nonce>.<mac> with a per-surface subkey that is derived from, but kept separate from, the tenant’s master keys. The URL carries the grant; it never carries a password and never a card key.
3. The page redeems the grant. The gate re-checks the signature and the expiry, burns the grant so it cannot be presented twice, and sets a session cookie. The grant lives minutes and the session it buys lives hours, so a slow read is not an outage, and there is no URL left over to pass on.
4. It fails closed by construction. A gate with no subkey configured mints nothing rather than allowing everything, and a tenant that is not in the gate’s tenant map is refused in the same way. A replayed tap is refused by the counter, a reused URL by the burn.

Live since 2026-09-20: the fleet status page at 04202030.com/status/ is opened by tapping a card issued to the tap tenant. The first card in the field was created from a single tap of a blank tag — the phone read the UID, the server issued the credential and returned its keys over the tunnel to the phone, and the same tap wrote them — and tapping the finished card then opened the page, with the chip’s counter advancing on every read.

Two limits stated plainly: a tap proves the card is present and genuine, not who is holding it, so identity still comes from a badge or an operator record. And the tap protects the door, not the building — the page behind it is only as available as the host serving it.

Keys: who holds what

The provisioning API is IP-allowlisted at the edge (api.melon.tips), and every write goes through an authenticated provisioning actor with a 409 on duplicate UIDs. Tenant isolation is a tested property: Phase C, second-tenant isolation, passed on physical hardware.

Live tenants, right now

Three tenants are running on the same platform, each on its own hostname, each with its own key profile:

Each tenant owns its own namespace, branding, and keyset. A credential issued under one tenant cannot verify under another, and the isolation is hardware-tested, not assumed.

Credential lifecycle

A credential is a managed record, not a one-time write. The platform supports the full cycle:

• Issue — create the identity and the credential with policy and status.
• Provision — write card-specific keys to a blank tag.
• Verify — every tap checks crypto, counter, and state.
• Revoke — a revoked credential stops verifying immediately.
• Replace — a replacement credential inherits the relationship; the old one is dead.
• Audit — provisioning events, tap evidence, and provenance entries are recorded and chain-covered.

The provenance layer extends this: append-only records, media with attribution, a hash chain over entries, and tap evidence folded into the chain. The Richard's Minerals implementation is the live demonstration.

Maturity, stated honestly

The project is a working platform moving from engineering validation into productization. Everything in the PASS/SHIPPED rows has been exercised on real hardware against the live server. The gaps are named, not hidden.

The chip: NTAG 424 DNA

The current credential technology is the NXP NTAG 424 DNA (NT4H2421x), an AES-128 based secure NFC chip. It is the first credential provider, not the last: the platform is deliberately general, and other secure NFC credential technologies can sit behind the same model.

The tap counter

Every tap advances a read counter inside the chip. The counter is a 24-bit unsigned integer, reset when SDM is enabled, and incremented before the first read response of a tap. It tops out at 16,777,215 (FFFFFFh) before the chip refuses further reads unless a lower limit is configured.

The verifier tracks the last-seen counter per credential. A tap that arrives with a counter equal to or lower than the last recorded value is rejected as a replay. That is the replay defense, and it is a minimum requirement the datasheet itself recommends for any SDM verifier.

The tamper feature (and where it works)

The NTAG 424 DNA TT variant has a Tag Tamper detection pin. A conductive loop routed through the pin is monitored by the chip: if the loop is broken, the chip permanently stores the event and mirrors the tamper status into the NDEF message, so a single tap reveals that the tag has been opened or removed.

That works wherever there is a closure to route the loop through: sealed packaging, bottle caps, closed boxes, tamper-evident labels, envelopes, document seals. Break the seal, break the loop, the tag remembers forever.

It does not work for a mineral specimen, and the design record says so plainly. A rock has no closure. There is nothing to route a loop through, so a card sitting beside a stone cannot use the TT loop as its tamper defense.

How the mineral case is handled instead

The project's own card design brief (MINERAL_ID_CARD_BRIEF) makes the decision explicit:

• The card does not attach to the specimen. It sits beside the stone in the gem box.
• The tamper defense is photographic: a tag_in_place photograph of card and specimen together, taken at issue time, becomes part of the provenance record. A later viewer compares what they are holding against that photograph.
• A tamper-evident chip variant whose loop routes through something that must be destroyed to remove the tag is a possible future mitigation, but only if the form factor moves to a tether or seal that physically bridges card and specimen.

So the honest statement is: the chip's tamper loop is a real capability for objects with closures, and the mineral application deliberately does not rely on it. The threat model section above names exactly what is and is not proven in each case.

Other chip facts worth knowing

• 416 bytes of user memory in a Type 4 tag file system; 256-byte NDEF message, 128-byte extra data file.
• 50-year data retention; 200,000 write endurance cycles (a card is written a handful of times and tapped for decades).
• Five customer-defined AES-128 keys with key versions, plus an ECC-based NXP originality signature.
• Common Criteria EAL4 certification, hardware and software.
• Optional Random ID and encrypted UID/data mirroring for privacy-sensitive deployments.
• Works on Android without a dedicated app; on iOS 11+ via an application.

Sources

• NXP NT4H2421x data sheet, rev. 3.0 (31 January 2019): https://www.nxp.com/docs/en/data-sheet/NT4H2421Tx.pdf
• NXP NTAG 424 DNA TT product page: https://www.nxp.com/products/...NT4H2421Tx
• Project design record, mineral specimen ID card brief (mounting decision, photographic defense): on the project repo.

Honest questions, honest answers

open the live implementation back to the marketing page