Instead of collecting copies
A new contractor proves a current ticket or licence, rather than emailing a scan that someone has to eyeball and file.
What you can do
Check a credential someone presents.
Ask a person to prove something. They approve it on their phone. You get an answer in seconds — and you know exactly what that answer covers.
Where checking helps
At the point of the decision
Someone arriving on site or joining a job proves the specific clearance that job needs, at the moment it matters.
When something may have changed
A periodic re-check confirms a registration is still current, because withdrawal shows up immediately.
What the experience looks like
You define what you need to know once, then run it as often as you like.
You say what you need
Set up a request naming the specific facts you need — that a licence is current, that a course was completed — and which issuers you are prepared to accept it from.
The person is shown a code
Your service shows a QR code on screen, or sends a link. The person opens it with the wallet holding the credential.
They see who is asking, and decide
Their wallet shows your organisation, what you have asked for and why. They approve, or they decline. Declining is a real option.
You get a result
Your service receives the facts that were shared and whether the checks passed, within the same session.
What the system actually checks
Five things, in order. If any of them fails, the check fails.
- Did the issuer really issue this?
- The issuer's signature is verified against the keys that issuer publishes. A credential that has been altered will not verify.
- Does it belong to the person presenting it?
- The wallet proves it holds the private key the credential was bound to. A copied credential presented by someone else fails here.
- Has it been withdrawn?
- The issuer's published status is fetched and checked. A credential the issuer has withdrawn fails.
- Is it in date?
- Start and expiry dates are checked against the time of the request.
- Does it answer what you asked?
- The facts shared are checked against the request you defined. A credential that does not carry them does not satisfy the request.
Reading the result
What a pass confirms
A named issuer issued this credential, it is unaltered, the person presenting it holds it, it is in date and not withdrawn, and it carries the facts you asked for.
What stays with the issuer
Whether the underlying fact is correct remains the issuing organisation's responsibility. That makes your list of accepted issuers the decision that carries the weight — and it is one you control.
It is evidence, not a session
A pass gives your service verified facts to act on. What happens next is yours: match it to an account, grant access, record the outcome.
When a check fails
The person declined, the session timed out, the credential expired or was withdrawn, or the issuer is outside your accepted list. Each case returns a clear reason your service can act on.
Ask for only what you need. A request can name individual facts from a credential rather than pulling the whole record across. Each request covers one credential, so where a decision draws on two, design it as two checks.See the standards
Know what you need people to prove?
Bring the check you run today — the one with the document scans and the follow-up emails. We will show you what it looks like as a credential check.