Watermelon Auth
A multi-tenant NTAG 424 DNA credential and provenance system, operated by bbbuds.com as both a self-service platform and a managed provisioning service.
It grew out of a single-tenant build for Maine Freedom Academy and was generalized so any business can issue its own tap-verified identities and object records without touching another tenant's data.
Verify a tap or batch
Enter a batch or package identifier to open the public verification page, or hold a Watermelon Auth card to the reader for a cryptographic tap check.
What it is
Watermelon Auth is a multi-tenant NTAG 424 DNA credential and provenance system. The physical anchor is the NXP NTAG 424 DNA chip: an NFC tag with onboard AES authentication and SDM (secure dynamic messaging), meaning the tag itself signs its own tap and embeds a UID and a forward-only counter into the URL it serves. That single hardware primitive supports everything the system does.
Every server-side action carries whether a tenant's own staff did it or bbbuds staff did it on the tenant's behalf, so a record never silently misattributes who actually produced it.
The honesty model: three tiers, never blurred
An unverifiable claim must never borrow cryptography's credibility. Every claim a record makes falls into exactly one of three tiers:
- Proven by cryptography. The tag is authentic, via AES-CMAC and EV2 mutual authentication. Math, independently checkable by anyone.
- Attested by the server. A record is unmodified since it was written, with a timestamp and a recording principal. Append-only; no UPDATE is ever issued to a provenance row. A hash-chain across rows is in progress to promote this tier to cryptographic strength.
- Asserted by a person. The narrative content itself: an origin story, a find date, a maker's name. The system records who said it; it cannot verify the story.
The renderer gives tier 1 a checkmark and visible evidence, tier 3 an attributed but unbadged presentation, and never shares iconography between the two.
System components and hosts
- freedomAcademy (test.melon.tips): the live verifier, a Flask app and SQLite database that phones and browsers hit on a tap.
- ~/id/watermelon-auth-server (turbo): repo of record for the server code, copied to freedomAcademy to deploy.
- ~/id/MFA-NTAG424-Provisioner: Android provisioning and diagnostic client used to inspect, authenticate against, and personalize physical cards.
- ~/watermelon-tap (turbo, deployed to 04202030/pi/freedomAcademy): a separate tap-to-authorize HTTP gate that mints short-lived signed grants from a tap.
QR-seeded Conway preview
This box starts as a QR-seeded pattern for one minute, then evolves slowly using Conway’s Game of Life. If it becomes stable for 30 seconds, it reseeds automatically.
Build status (E0 through E7)
- E0, data model: deployed. principals, api_tokens, append-only provenance_events, and media tables, plus a public/partial/private disclosure ladder per identity.
- E1 / E1b, provisioning API: deployed. Role tiers viewer < provisioner < operator < owner; cross-tenant requests return 404 rather than 403 so a competitor's tenant name can't be enumerated.
- Provenance DB layer: deployed and verified, though the live database currently has zero provenance events, so chain-walk and hash-chain code haven't yet run against real production data.
- Provenance relay (/update, /entry, /media): infrastructure-only so far. Caddy on both verify hosts is whitelisted for these paths; the Flask handlers are not written. The relay uses key K4, which has no file-access rights, so a hijacked relay session is pure presence proof.
- E2, app networking: done for bundle fetch over HTTPS with Android Keystore-encrypted token storage.
- E3 through E7 (record page/permalink, admin UI, field capture, TagTamper hardware, self-service onboarding): not yet built.
Use cases
Tier 1: identity and provenance (the primary commercial wedge).
- Staff and member ID badges. A technician taps their badge; the customer's phone shows a verified, tenant-branded identity page. Proof of who is at the door.
- Mineral and fossil specimen provenance. Locality and chain-of-custody are the market's actual value driver. A tag on a specimen carries proven authenticity of the tag plus a provenance record of finds, transfers, and attributed sourcing.
Tier 2: objects and goods.
- Artwork and limited editions, maker and craft goods. Lower priority than tier 1 because the incentive to fake provenance is less acute and the tag-transplant problem matters more.
Tier 3: deferred.
- Certificates of authenticity, product recalls, equipment checkout, warranty and service records. Feature flags exist in the tenant schema but no server implementation. Regulated chain-of-custody (legal evidence, pharmaceuticals, firearms) is deliberately avoided.
Tap-gated surfaces
A separate but related use of the same tap primitive: rather than a tap opening an identity or provenance record, it opens or triggers something else entirely. Built on the watermelon-tap gate, generalized into two kinds:
- View surfaces: an ongoing but scoped session. A live tracker or status view for one specific subject or event, expiring with that event, restricted to one active viewer at a time.
- Action surfaces: a one-shot effect with no session at all. The tap itself is the record: ops access without another password, live tracking for one person or thing during one event, proof of presence in the field, feedback tied to a real interaction, device enrollment without a manual pairing code.
Of these, proof-of-presence logging is already usable today, since it reuses the existing record_surface_use() call. Device registration and survey are designed but not built yet; they need new database tables that haven't been finalized.
Known limitation
The tag can only prove the tag is genuine and registered, not that it is still physically attached to the object it was mounted on originally, since a tag can be moved to a different item.
The mitigation path is TagTamper hardware (NT4H2421Tx), whose tamper-loop status mirrors into the same SDM-readable message this system already parses, combined with tag-in-place photography and a documented mounting method. This only protects an object when the physical mounting actually routes the tamper loop through something destroyed on removal, not as a universal guarantee.
About the name
"bbbuds" has no canonical meaning; it's a name, not a fixed acronym. Where it helps to spell something out, "Backed By Buds" works as an optional reading, particularly for the tap-to-prove-presence framing: a tap is closer to a friend confirming you were there than a password proving you know a secret. Used sparingly, as an aside.