Tap the thing.
Verify the connection.
Watermelon Auth turns secure NFC tags into credentials that actually prove something. Tap a product, a card, a specimen with a phone and the tag answers with a fresh cryptographic response. The issuer's server checks it on the spot. If the tag was copied, photographed, or just linked to, there is nothing to check.
People. Products. Specimens. Assets. Documents.
A phone taps a physical object and the screen shows: Authentic, fresh tap. Credential RM-0001-A, status active, issued by Richard's Minerals.
Between a printed label and a smart card.
Tap is proof
Every tap makes the tag produce something new. A screenshot or a photo of a code is a copy. A tap is the thing itself showing up.
You stay in control
The keys, the status, the policy: all yours. Revoke a card and it stops verifying. The server decides, not the phone.
Your name on it
Your domain, your wording, your verification page. Watermelon Auth is the machinery underneath. Nobody has to know it is there.
A QR code is a photocopy waiting to happen.
Static identifiers
QR codes, printed numbers, plain NFC tags. All of them can be photographed, forwarded, and reproduced. A copy is indistinguishable from the original.
Enterprise systems
The strong stuff exists, but it usually needs dedicated readers, proprietary software, and a budget that small organizations do not have.
Watermelon Auth
Runs on the phones people already carry. The issuer keeps control of the keys and the records. No special hardware anywhere in the loop.
Six steps from blank tag to verified thing.
Issue
Create the identity and the credential record, with policy and status.
Provision
Securely personalize the NFC tag with card-specific derived keys.
Attach
Associate the credential with the physical thing.
Tap
A phone receives a fresh dynamic response from the secure tag.
Verify
The server validates the cryptography, counter, and credential state.
Present
Show the branded result, context, and provenance.
Want the parts and the threat model? The technical deep dive names the chip, the keys, and the counter, and says plainly what the system does and does not prove.
Who is it for?
An identity does not have to be a person. It can be a student, a package, a rock, a tractor. The system does not care what the thing is; it cares that the thing is real.
Schools
Student and staff IDs that the front office can actually revoke.
Memberships
Club cards and passes that check their own status when tapped.
Products
Tap the box, get the issuer's record. Limited runs and special batches included.
Specimens & collectibles
Auth plus provenance: photos, source, custody history, all attached to the stone.
Assets & equipment
A managed record instead of a sticker with a number on it.
Documents
Certificates and licenses that are harder to forge than the paper they are printed on.
An Android app writes the cards.
Someone has to put the credential on the tag. That is this app's job. It talks to a blank NTAG 424 DNA tag, authenticates to it, and writes the card-specific keys into it.
How it works
The app authenticates to the tag with EV2, sets the access conditions, and writes keys derived per card from the tenant's master keyset.
The master keys never leave the server. The phone only ever holds the derived keys for the cards it is writing right now.
Where it stands
The app is real and field-tested: EV2 authentication, secure messaging, SDM setup, key diversification. All proven on physical hardware.
Today the operator loads provisioning bundles onto the phone from a computer. A direct app-to-server provisioning API is the next milestone, and it is in the plan.
Authentication tells you what you tapped. Provenance tells you what is recorded about it.
Authentication answers: did I tap a valid credential?
Fresh cryptographic response, counter progression, credential state. Checked server-side, on the spot.
Provenance answers: what do we know about the thing attached to it?
Append-only records, photographs, source attribution, ownership and custody history. All of it tied to the physical object, not a spreadsheet somewhere.
The physical thing carries the credential. The platform carries the trusted context.
One platform. Many issuers.
Each tenant is its own world
Separate domain, separate branding, separate keys, separate credential namespace. One school shows Freedom Academy Credential Verification, a mineral collection shows Richard's Minerals. Same platform underneath, zero overlap in trust.
Your systems stay yours
Watermelon Auth verifies the credential. Your product database, inventory system, or portal remains the system of record. The verified identity gets handed in; nothing gets replaced.
Precise about what is proven.
The cryptography proves what the cryptography proves, and the page says so. That exactness is the point.
What the platform provides
- cryptographically authenticated credentials
- secure NFC credential technology
- fresh dynamic responses per tap
- diversified, per-card derived keys
- replay-aware verification
- tap-gated web access through short-lived, single-use grants
- tenant-specific key isolation
- issuer-controlled credential state
What the platform does not claim
- impossible to clone
- unhackable
- impossible to counterfeit
- guaranteed authentic physical object
- tamper-proof
This is not a design proposal. It is running now.
The reference implementation is at verify.melon.tips, running the provenance side as Richard's Minerals. Each specimen there carries a secure NFC credential connected to its digital record.
Try the demo credential: RM-0001-A. A bare link will not do. The verifier needs the fresh response only the physical tag can produce, and it refuses anything else.
The tap is the test.
Issue it. Verify it. Revoke it. Replace it. Audit it. Physical things, managed like real records.