Common questions
Answers, wherever you are starting from.
Grouped so you can begin at the beginning or jump straight to the technical detail.
Starting out
If someone has just asked you to look into digital credentials, start here.
What is a digital credential?
A digital record issued by an organisation that can confirm something about you — a qualification, a role, a licence, a membership. It is signed, so anyone you show it to can tell it is genuine and unaltered. Think of a paper certificate that can also prove it is real and say whether it is still current.
What does DiligenceID actually do?
It runs two jobs. It lets an organisation create and send credentials, and it lets another organisation check a credential someone presents. The person in the middle holds their credentials on their own phone.
Who are the three parties?
The issuer is the organisation that can vouch for the fact and creates the credential. The holder is the person it is about, who keeps it on their device. The checker is any organisation that needs proof and verifies what is presented.
Why not just email a PDF?
A PDF cannot tell you it is genuine, and it cannot tell you it stopped being true. A credential proves who issued it, proves it belongs to the person showing it, and reflects the issuer’s current position — so a lapsed registration shows as lapsed rather than as a two-year-old certificate.
Is this the same as a digital ID card?
Not quite. An ID card tries to prove who you are. A credential proves a specific fact about you — that you hold a current licence, say — which is usually what an organisation actually needs. Asking for the specific fact means less personal information moves around.
Do I need to understand the technology to use it?
No. For the person holding a credential it is a link or a QR code, then an approval on their phone. For an organisation issuing or checking, it is a web interface. The protocols matter to whoever integrates it, not to everyday use.
Is it free for the person holding the credential?
Yes. The organisations issuing and checking credentials are the customers. People holding credentials do not pay to receive, hold or share them.
Using it day to day
What the experience is actually like, for people and for the organisations on either side.
How does a credential reach me?
An organisation you are already dealing with sends you a link or shows you a QR code. You open it in a wallet on your phone, see who is offering the credential and what it says, and accept it.
What happens when someone asks me to prove something?
You see a request showing the organisation asking, what they have asked for, and which parts are required rather than optional. Nothing is sent until you approve it, and declining is a normal answer.
Can I share part of a credential rather than all of it?
Yes, for credentials DiligenceID issues. A request can name specific facts, so you can prove a licence is current without your date of birth or address going across with it.
What if I decline a request?
Nothing is shared and the organisation receives a failed result. If a request does not make sense to you, decline it and contact the organisation directly using details you already have.
Can I see what I have shared before?
Yes. The wallet keeps a record of the organisations you have shared with and what happened, and lets you end a connection you no longer want.
How long does a check take?
Seconds. Your service shows a QR code or sends a link, the person approves on their phone, and the result comes back within the same session.
What does an organisation need to start issuing?
Something you are genuinely authoritative for, a source of truth to issue from, and a decision about which provider to use. You can start by entering details by hand in the administration interface and connect your systems through the API later.
Do recipients need a specific app?
They need a wallet that supports the same credential format and protocol as the credential you issue. Which one depends on the provider you choose, so decide that before you issue at scale. Ask us about a specific device or wallet and we will tell you what is supported today.
Deciding whether it fits
The questions that come up when an organisation is weighing this against what it does today.
What problem does this solve for us?
Wherever your organisation collects document scans, phones another organisation to confirm something, or re-checks a fact it already confirmed last year. A credential turns that manual work into a check that returns an answer in seconds.
When is it not the right tool?
If nobody is currently checking the fact, there is no manual work to remove. If no organisation can properly assert the claim, a credential cannot manufacture that authority. And if the fact never changes and is never disputed, a document may be enough.
What does a first deployment look like?
One credential type, one issuer and at least one organisation willing to accept it. We help line up both ends, run the flow end to end, then widen it. Starting with both sides in place is what proves the value.
Who else has to agree before this works?
Whoever will accept the credential. An issuer with nobody checking has not changed anything yet, so the first conversation usually involves both sides.
Does it replace our identity provider or login?
No. DiligenceID does not log people into your systems and does not replace Microsoft Entra, an OpenID Connect provider or your own directory. It carries proof of a fact into a decision. Your sign-in stays your sign-in.
Will we have to change our existing systems?
Not to begin with. The administration interface covers designing credentials, issuing them and setting up checks without writing anything. Connecting your source systems through the API is the step after that.
What does it cost?
Pricing depends on the credential types, volumes and providers involved, so we quote against a specific use case rather than publishing a rate card. Tell us what you have in mind and we will work it through.
How do we try it?
Take the product tour on this site to see the screens, then book a demo and we will run it against your own use case. Sandbox access for your developers is arranged as part of an evaluation.
Privacy, security and assurance
For privacy officers, security teams and anyone completing a supplier review.
Where are credentials stored?
On the holder’s own device, together with the private key that proves the credential is theirs. DiligenceID holds no copy of an issued credential and cannot read one.
So what does DiligenceID store?
The configuration of credential types and checks, a record that a credential was issued and its current status, a record that a check took place and how it turned out, and administrative activity for audit. Those records are what make withdrawal work and give both sides an audit trail.
What does a successful check actually prove?
That a named issuer issued the credential, it is unaltered, the person presenting it holds it, it is in date, it has not been withdrawn, and it carries the facts you asked for. Whether the underlying fact is correct remains the issuer’s responsibility.
How are signing keys protected?
Private signing keys for each issuer are held in hardware-backed key storage, are never exposed to browsers or client applications, and are not shared between issuers.
Where is our data hosted, and for how long?
Hosting region and retention periods are set per deployment and written into the agreement. If data residency is a firm requirement, raise it early and we will confirm what is achievable.
Is DiligenceID certified?
DiligenceID implements published specifications and validates them through an internal automated test suite against pinned versions. It does not currently hold third-party conformance certification, an ISO 27001 certificate, a SOC 2 report, or accreditation under the New Zealand Digital Identity Services Trust Framework. A conformance register and architecture documentation are available for evaluation.
Can you complete our security questionnaire?
Yes. Send it through and we will complete it in writing with the supporting material attached, including the standards conformance register and our architecture and key management standards.
Does the Privacy Act still apply to us?
Yes. Issuing or checking credentials means handling personal information, so your obligations continue as they do today. Credentials generally help, because a request can ask for one confirmed fact instead of a copy of an identity document.
What happens to a credential if someone leaves or a registration lapses?
The issuer withdraws it. Every check from that moment returns a failure, and the checker sees that it failed. The copy on the person’s device stays where it is; what changes is the answer any checker receives.
Architecture and integration
For solution architects, identity specialists and engineers evaluating the fit.
Which specifications does it implement?
OpenID4VCI 1.0 for issuance and OpenID4VP 1.0 for presentation, with credentials in the SD-JWT VC format built on SD-JWT (RFC 9901), and credential status published through Token Status List. SD-JWT VC and Token Status List are pinned to specific drafts, which the standards page sets out in full.
Which issuance flow is supported?
Issuer-initiated, pre-authorised: you create an offer and the person accepts it in their wallet. If your design assumes a browser redirect flow instead, raise it early so we can confirm fit.
How does presentation work?
Cross-device. Your service starts a request and shows a QR code or sends a link, the person approves in their wallet, and the shared facts and the check result return to your service within the same session.
What does the verification pipeline check?
The issuer signature against the keys that issuer publishes, the holder’s proof of possession, the published status list, the validity window, and the presented facts against the request you defined. Any failure fails the check.
Can one request span two credentials?
Each request covers one credential, so a decision drawing on two is designed as two checks. Worth knowing at design time rather than at build time.
How do we integrate?
Your backend calls the API to request issuance or start a check and receives the result, described by published API specifications using OAuth 2.0 patterns your team will recognise. DiligenceID can also call your service when events occur, so you are not polling for state changes.
Where do client secrets live?
On your backend. Requests come from your server, not from a browser, and no credentials belong in client-side code.
How does the Microsoft Entra Verified ID option work?
DiligenceID administers issuance, presentation and withdrawal against your own Microsoft tenant, alongside credentials it issues itself. Microsoft remains the credential provider and signs its own credentials, so those keep Microsoft format, status handling and wallet experience throughout. You supply the tenant and an app registration you control.
Will it work with a particular wallet or provider?
An exchange works where the issuer, the wallet and the checking service agree on a format, a protocol, a signing algorithm and a status mechanism. Name the wallet or provider that matters to your design and we will tell you what has been exercised against it and what a compatibility check would involve.
Can we accept credentials issued by someone else?
Yes, where the format and protocol match. Issuing on behalf of an external authority is on the roadmap — talk to us about timing if it matters to your design.
Do you support the W3C Verifiable Credentials data model?
Credentials use the SD-JWT VC format. If your programme specifies the W3C data model, raise it early so we can confirm fit before you invest design time.
Can we test against something before committing?
Yes. An isolated sandbox is available for integration work, separate from anything carrying real credentials, and is set up as part of an evaluation so it matches what you are building.
Still have a question?
Ask us directly. Enquiries are read by someone who works on the product.