How it works
The starting point if you are working out whether this fits your architecture. It covers the split of responsibilities, what is actually available, and where the edges are.
Before any of the technical detail, the shape of the thing is simple.
Something in your organisation already knows a fact — that a course was passed, that a person holds a role. You want another party to be able to rely on that fact without phoning you. DiligenceID turns the fact into a credential the person carries, and gives the other party a way to check it.
Everything below follows from that. Your systems remain the source of truth. DiligenceID moves a provable statement about that truth between parties.
Worth designing for early: a check result is evidence, not a session. Mapping a verified fact onto an account in your system, and deciding what it entitles someone to, stays on your side of the line.
Every row is something we can demonstrate. The scope column is the part worth reading at design time.
| Capability | Available behaviour | Scope | Next step |
|---|---|---|---|
| Issuing credentials directly | Your service asks DiligenceID to issue a credential to a named person. DiligenceID produces an offer the person accepts in their wallet, and manages the signing keys on your behalf. | Issuance is issuer-initiated: you create the offer and the person accepts it. If your design assumes a browser redirect flow, raise it early so we can confirm fit. | Issuing in detail |
| Issuing through Microsoft Entra Verified ID | 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 Microsoft credentials keep Microsoft format, status handling and wallet experience throughout. | How the Microsoft option works |
| Checking credentials | Your service starts a request, shows the person a QR code or link, and receives the shared facts and the check result back within the session. | Each request covers one credential, so a decision drawing on two is designed as two checks. Presentation is cross-device, by QR code or link. | Checking in detail |
| Asking for specific facts only | A request can name individual facts inside a credential, so a person can prove one thing without disclosing the rest. | This applies to credentials DiligenceID issues in its own format. Credentials issued through Microsoft follow Microsoft’s disclosure behaviour, which you should evaluate separately. | Privacy behaviour |
| Expiry and withdrawal | Issuers set expiry dates and can withdraw a credential. DiligenceID publishes a signed status that any checker reads during a check, so withdrawal takes effect immediately. | The status mechanism differs by provider. Credentials issued through Microsoft use Microsoft’s status handling, not the DiligenceID status list. | What happens when a credential lapses |
| Accepting credentials from other issuers | DiligenceID can check presentations from credentials issued by authorities outside your tenancy, where the format and protocol match. | Accepting presentations from external authorities is available today. Issuing on their behalf is on the roadmap — talk to us about timing if it matters to your design. | Talk to us about a specific issuer |
| Notifying your systems | DiligenceID can call your service when issuance and checking events occur, so your own records stay in step. | Destinations are validated before they are called. Your endpoint must be reachable over HTTPS and must tolerate repeat delivery. | Developer documentation |
| Somewhere to build against | An isolated sandbox is available for integration work, separate from anything carrying real credentials. | Sandbox access is arranged as part of an evaluation, so we can set it up around what you are building. | Request sandbox access |
A registered application and credentials for it, held server-side. Requests come from your backend, not from a browser.
For the Microsoft option, you also need your own Microsoft tenant with Verified ID enabled and an app registration DiligenceID can use.
DiligenceID issues and checks credentials using published specifications from the OpenID Foundation and the IETF — issuance and presentation protocols, a selective disclosure credential format, and a published status list.
Confirm the profile, not just the protocol. An exchange works where the issuer, the person's wallet and the checking service agree on a format, a protocol, a signing algorithm and a status mechanism. Two products can implement the same specification and still need their profiles aligned.
If compatibility with a specific wallet or provider matters to your design, name it and we will tell you what has been exercised against it and what a compatibility check would involve.
Developer documentation covers the interfaces in detail. For an evaluation against your own systems, or a question the documentation does not answer, talk to the engineers who built it.
