How this works

What is this?

Someone proved they are a real person by presenting a government-issued mobile driver's license to IRLProof, using their phone's wallet app. IRLProof checked the license, kept nothing from it except a scrambled key that lets it recognize the same license later, and signed a short statement: "a real person presented a license and asked to be linked to this account." That statement is the proof.

What does a proof actually prove?

It proves exactly one thing: a real person, holding a real mDL, asked IRLProof to record that they hold a specific account on a specific platform.

It does not prove they control the account. IRLProof never logs into anyone's Instagram, Reddit, or anywhere else. Control is demonstrated a different way: the person publishes the proof link on the account itself. If you found the link on the account, the account's owner is the one who put it there, and that is the whole proof of control. That is why the "found it on that account" warning is on every proof page.

It also does not prove the person is who they say their username implies, that they only have one account, or anything about their name, age, or location. IRLProof never learns those things in the first place.

The round trip

This is the whole mechanism, in one picture.

How the round trip works instagram.com/MyInstaUsername MyInstaUsername irlproof.me/x7k2m9p4qw IRLProof says they are MyInstaUsername on instagram.com Signature: valid Active until 3 Sep 2027 you open the link you compare the name

You find the link (or QR code) on an account. You follow it to IRLProof, which shows you the exact username the proof claims. IRLProof's page also points back to where that account should be. Both ends have to show the same name for the proof to mean anything, and only you, comparing them, can make that call.

What is that JSON / token?

Click the Raw button on a proof page and you see something like this: 

{
  "jti": "x7k2m9p4qw",
  "token": "eyJhbGciOiJFUzI1NiJ9....<more characters>....",
  "status": { "jti": "x7k2m9p4qw", "status": "active", "checked_at": 1788480202 }
}

The token is the actual proof. It looks like gibberish, but it is three pieces of text joined by dots:

  1. A header saying which signing method was used.
  2. A payload: the actual claim, in plain JSON: which platform, which handle, when the license was checked, when the proof expires. Nothing about the person.
  3. A signature: a mathematical seal computed from the first two parts using IRLProof's private key, which nobody else has.

The first two parts are not secret or encrypted; they are just encoded text, and anyone can decode and read them (that is what tools/verify and sites like jwt.io do). What nobody but IRLProof can do is produce a signature that matches. Change one character of the claim and the signature no longer matches. Anyone checking it, using IRLProof's published public key, sees immediately that it has been tampered with. That check works without trusting this website at all; it is pure math against a key anyone can fetch.

The status field is separate from the signed token on purpose: a proof can be revoked later (or expire) without the signed claim itself ever changing. So there are always two separate questions: is the signature valid (checked once, forever, against the public key) and is it currently active (checked live, because it can be revoked). A proof page always answers both, on two separate lines, never one merged checkmark.

For the technically minded

The gist of the pipeline, not the full protocol spec.

  1. Presentation. Your wallet presents the mDL over OpenID4VP (a QR scan or a same-device hand-off). IRLProof does not implement the mDL / OpenID4VP protocol itself; a dedicated verifier service checks the credential's signature and confirms it chains to a trusted issuer (a state DMV, in production).
  2. Recognition, not identity. Every mDL carries a holder-bound key the wallet generated. IRLProof takes only that key, runs it through a keyed HMAC with a secret pepper, and stores the HMAC. That is the one thing that lets it recognize "this is the same license as last time." It cannot be reversed back into the key, and the raw key never touches storage or a log.
  3. The proof. A small JSON payload (platform, handle, day-precision dates, no names, no ids that could link two proofs together) is signed with ES256 (ECDSA P-256) as a compact JWS, the hand-rolled, minimal profile described above, not a general-purpose JWT library.
  4. Publication. You publish the short link on the account. That publication, not anything IRLProof does, is what ties the proof to the account.
  5. Verification. Anyone, a browser, a script, another language entirely, can check: is the signature valid against the issuer's published key, is the key still in its validity window, has it expired, and does the live status endpoint say it is still active. The reference verifier ships in two independent implementations (C# and Node) precisely so nobody has to trust a single codebase's interpretation of the format.

Public material: issuer metadata, the public signing keys. The full language-neutral spec and the reference verifier source are meant to be published openly; until then, this page and the source are the documentation.

This deployment's issuer id is https://sandbox.irlproof.me and is marked test: proofs from it carry "test": true and should never be trusted as real.

Back home