A credential is a claim that somebody hands you: this consultant was verified, this audit was completed, this listing is genuinely ours. It travels as ordinary JSON and it lives in their own hands rather than in ours, which is the whole design of the format and not a weakness anyone left in it.
VERIFIABLE CREDENTIALS · W3C VC 2.0 · FREE
A signed credential you can check yourself, without asking us.
Paste it, and the mathematics answers - then the registry says whether it still stands.
W3C VC 2.0
eddsa-jcs-2022
Ed25519
JCS canonical
Revocation check
Our promise
“A mark is a claim. The signature is the proof.”
The verifier re-derives the signature rather than trusting the one attached, then reads the registry live — and reports valid only when both answer yes, never either. No account, and nothing kept.
Verify a credentialThe case file
A verifiable credential, in three chapters
Attached to it is a Data Integrity proof: the document canonicalized, hashed and signed with our own Ed25519 key. Change one character of a name, a tier or a date and the arithmetic simply stops agreeing. That is not a warning printed on the file - it is a property of the file itself.
This page is the reader’s side of that bargain. Paste one in and we re-derive the same hash, test the signature against our published key, and look the id up in our registry — so you learn both that it is intact and whether it still stands, which are two different facts, and only one is arithmetic.
What we issue, what we report
Two questions. One paste answers both.
The document says who signed it. Only the registry says whether it still stands.
- Verified consultant - a person who cleared our review
- Completed audit - an engagement we finished, and its date
- Registry listing - an entry we publish, tied to its holder
- Each one a VC 2.0 document carrying a single Ed25519 proof
- Active - signed by us, in the registry, and still standing today
- Revoked - withdrawn by us, with the recorded reason
- Expired - it lapsed on its own date and has not been renewed
- Unknown - an id we hold no record of ever having issued
Know your side
The proof is ours. The check is yours.
The person being shown it
A credential is a claim in the hands of whoever is presenting it, and the whole design assumes you will not take their word for it. Checking it is your side of that bargain, it costs one paste, and nobody needs to know you did it - not us, and not them.
The people showing you one
They hold the file and choose when to present it, which is the point of the format rather than a weakness in it. What they cannot do is alter a word of it: change one character of the subject, the date or the id, and the signature stops verifying against our key.
A good signature is not a live credential
Signatures are permanent and standing is not. A credential we revoked this morning still carries the signature we put on it in March, and only the registry knows the difference. Reading the signature alone is the most confident way to be wrong about this.
What most people assume
“They showed me the certificate, so it’s real.”
What the proof says
A file proves nothing until somebody re-derives it.
It takes one paste, and nobody is told that you ran it.
- Who it is for
- Clients & counterparties
- Procurement and vendor risk
- Regulators & assessors
- Employers hiring consultants
- Marketplaces and registries
Why the check exists
02
A signature is permanent and standing is not. A credential we withdrew this morning still carries the signature we put on it in March.
03
Change a single character - a name, a tier, a date, the id - and the re-derived hash stops matching. There is no partial credit in this arithmetic.
04
The key is published and the suite is a public specification, so anyone can write a second verifier and get the same answer this one does.
The verifier
One paste. Then you’ll know.
No account, no key, and no record kept of what you check.
Opens in a panel. Close it any time - your paste is kept.
Verifiable Credential
Your verification reading
The lifecycle
Four moments, and two of them happen without us.
Two of these are in our hands and two are not - which is exactly why the file and the registry have to be read together rather than in turn.
-
Signed
At issueWe sign the finished document with our Ed25519 key and write its id into the registry as active.
-
Presented
Whenever they likeThe holder sends you the file. It travels as plain JSON, through any channel, and we are not told.
-
Verified
One paste, any timeYou re-derive the hash and read the status here. The answer is the same for everyone who checks it.
-
Withdrawn
After the factRevoked or expired, the file is unchanged and still signed. Only the registry records that it no longer stands.
The trap
People check the signature, see it pass, and stop — but a signature never expires. Step 04 leaves the file untouched, so the only thing that can tell you a credential has been withdrawn is the registry lookup you skipped.
Check & coverage
What the proof asserts, what we check
12 checks, and what each one establishes. Paired, so every claim on this page can be held against the check beside it.
- What "valid" means Signature AND status - never either alone
- A verdict that is only green when the signature verifies and the registry still calls it active.
- What it does not mean The check is of the document, not of the world
- A reading confined to what we signed and when - it does not re-audit the finding behind it.
- Proof present at all A proof object with a proofValue on it
- A refusal rather than a guess: no Data Integrity proof, no verdict, and the reason said in words.
- The right cryptosuite eddsa-jcs-2022, and nothing else
- The suite read off the proof and flagged when it is not the one we issue, before anything is decoded.
- Encoding of the signature Multibase base58btc - it starts with z
- The prefix and the alphabet checked, so a truncated or re-encoded proofValue fails loudly not quietly.
- Canonical form JCS, RFC 8785, over the document without its proof
- The same canonicalization we signed with, so key order and whitespace cannot change the answer.
- The two hashes, in order Proof options first, then the document
- SHA-256 over each, concatenated in the order the suite fixes - reversed, every credential would fail.
- The signature itself Ed25519, against our published key
- A verify against the key our verificationMethod resolves to, not against one carried in the file.
- Tamper evidence One character is enough
- Any edit to the subject, the dates or the id breaks the hash, and the result says so rather than warns.
- Registry standing active, revoked, expired or unknown
- The id looked up in our issued-credential ledger, with the revocation reason printed when there is one.
- Expiry validUntil, where the credential carries one
- The expiry read from our own record rather than from the file, so a stale copy cannot argue with it.
- Credentials we never issued An id that is not in the registry
- Said plainly as unknown rather than dressed as a failure, with the signature reported separately.
The check
One document, read twice
From the arithmetic to the registry, in about a second.
-
Paste
The whole credential, proof object included. Nothing is stored and no account is asked for.
-
Re-derive
We canonicalize it, hash it again, and check the signature against our published key.
-
Read the status
Then the registry: active, revoked, expired or unknown - and what each one lets you rely on.
Struck in the open
Why this check can be trusted with the question
Open, not proprietary
W3C VC 2.0 and a published cryptosuite, so a second verifier can be written against the spec.
Free and unmetered
No account, no key, no quota. Anyone shown one of our credentials can check it themselves.
Nothing is retained
What you paste is verified and dropped. We do not log it, keep it, or tell the holder about it.
Status, not just signature
Revocation and expiry are read every time, because a signed credential can still be withdrawn.
Four marks, and not one of them needs an account.
What comes back
What you get
Concrete answers, each with a name and a shape - you know what lands before you paste.
The verification reading
The whole answer on one card: whether the signature verifies against our issuing key, what the registry says about the credential today, the type and issuer it declares, its credential id, and every reason behind the verdict written in plain words rather than left as a status code for you to look up.
Signature verdict
Whether the re-derived hash matches the signature on the document, stated as one line before any of the detail underneath it.
Registry status
Active, revoked, expired or unknown, read at the moment you ask rather than taken from anything written inside the file itself.
Revocation reason
Where a credential has been withdrawn, the reason recorded when it was withdrawn - not merely the fact that something happened to it.
Declared type and issuer
What the credential says it is and who it says signed it, printed back so a mismatch with what you were told is visible at a glance.
Credential id
The identifier the registry was searched on, shown in full so you can quote it back to us if anything about the answer looks wrong.
Reasons, itemised
Each thing that failed and each thing that was merely unexpected, listed separately - so a warning is never mistaken for a rejection.
Format & cost
No charge, no account.
- Scope
- One credential, checked in full
- Input
- The credential JSON, proof included
- Re-check
- As often as you like - free every single time
The format fixed the cost, not us - nothing to meter, and nothing kept once you have your answer.
Verify a credential
Public verifier · Always open
Free always
- Signature re-derived, not trusted
- Registry status read live
- Revocation reason printed
- Nothing logged, nothing stored
Show your hand
Four things a credential has to establish
Cryptography is not graded on intent. Each of these either holds when you check it, or it does not.
The file,
intact
The bytes we signed, character for character. Re-canonicalized and re-hashed on every check, so an edited name or a moved date cannot survive the arithmetic.
The issuer,
established
A signature that verifies against the key that our verificationMethod resolves to - not against a key travelling inside the file, which would prove only self-consistency.
The standing,
current
Looked up in our registry at the very moment you ask: active, revoked, expired or unknown. This is the half of it that changes after the credential leaves our hands.
The subject,
legible
Who it is about and what is claimed, printed back in plain words. A proof nobody can read is a proof nobody checks, whatever the mathematics underneath says.
Four marks, and the third is the one people forget to read.
FAQ
Plain answers
What the verdict means, and what it does not. Answered straight.
Verify a credentialWhat does a valid result actually tell me?
Two things at once: the document has not been altered since we signed it, and our registry still lists it as active. Valid means both. Either one alone is not a credential you should rely on.
The signature verifies but the status says revoked. Now what?
Do not rely on it. The signature only proves we signed those bytes at some point; revocation is our record that the credential no longer stands. The reason we recorded is printed with the result.
Can I verify one without using this page?
Yes, and that is the point of using a published format. Canonicalize with JCS, hash the proof options and the document with SHA-256, concatenate proof options first, and check the Ed25519 signature against our public key.
Do you keep what I paste?
No. The credential is parsed, verified and dropped. It is not logged, not stored and not associated with you - there is no account here to associate it with.
What should I do if verification fails?
Ask the holder for the original file rather than a copy - most failures are a truncated or reformatted paste. If a clean copy still fails, tell us the credential id and we will say whether we issued it.
Get started
Get your own credentials issued
Tell us what you want attested and we come back with a scoping call within one business day.
What we need from you
Nothing you do not already have. Most of it is a folder somebody can assemble in an afternoon, and we name every document first, in writing, before you commit.
- What you want attested - a person, an audit or a listing
- Who will be holding and presenting the credential
- Any evidence behind the claim you want it to carry
- Whether it should expire, and on what date if so
- Where it will be shown, if that is somewhere public
What happens next
- You send the five items we need.
- You get a scoping call within one business day.
- Nothing is charged until you approve the scope.
Sources & standing
Where this page gets its facts
What the claims on this page rest on, and what they are worth - stated, not assumed.
What it is drawn from
- W3C VC Data Model 2.0 - the credential
- W3C Data Integrity EdDSA - the proof
- Cryptosuite
- eddsa-jcs-2022
- Issuer
- did:web:idharma.us
What it means
- A reading is a statement about a document — that it is the one we signed, and whether our registry still lists it. It is not an opinion about the work described inside it.
- Where a check is inconclusive the result says so, rather than the convenient thing.
Scope & limitation
- It checks iDharma-issued credentials; another issuer’s will not verify here.
- A passing check does not re-audit the finding the credential is about.
- Do not rest a decision on a screenshot - run the check yourself, on the file.
A credential behaving oddly here?
Tell usFrom Insights
What sits behind a credential
What Is an AI Audit? Scope, Standards, and What You Get
An independent review of what your AI actually does, measured against a named standard — not a certificate, and not a review of what the documentation says it does.
Read the notes
METHODOLOGY NOTES
How to Prepare for an AI Audit: The Readiness Checklist
Six things to have ready before the engagement starts. Assembling them takes a fortnight off the clock — and tends to find the first two findings before an auditor does.
STANDARDS EXPLAINED
What an AI Governance Framework Actually Contains
Five working parts, not a policy document. What each one has to do, how to tell whether yours is real, and why a framework is not the same thing as compliance.
STANDARDS EXPLAINED
ISO/IEC 42001, SOC 2 and NIST AI RMF: Which One Your Buyer Is Actually Asking For
One certifies an organisation, one is an opinion about controls over a window, one is a method with nothing to issue. What each covers — and what none of them answers.
