What is DiligenceID?

DiligenceID is a platform for issuing, verifying and revoking digital credentials — the machine-checkable equivalent of a membership card, a licence, a qualification or an entitlement.

An organisation that already knows something about a person can turn that knowledge into a credential the person holds, and that anyone they choose to show it to can verify without calling the organisation back.

The problem it solves

Today, proving a fact about yourself usually means handing over far more than the fact.

To prove you are over 18, you show a driver's licence — which also discloses your address, your date of birth, your licence number and your photograph. The verifier reads all of it, often stores all of it, and now carries the risk of holding it. You had one fact to prove and you disclosed nine.

The alternative has usually been an integration: the verifier calls the issuer's API to ask. That works, and it creates its own problems. Every verifier needs a relationship with every issuer. The issuer learns every time someone checks — where you were, when, and who was asking. And nothing works when the issuer's API is down.

Digital credentials take a third path. The issuer signs a statement once. The holder keeps it. A verifier checks the signature and the revocation status, and learns only what the holder chose to present.

• The verifier does not need a relationship with the issuer.
• The issuer does not learn who is checking, or when.
• The holder decides what is disclosed, claim by claim.

The three roles

Issuer — an organisation that asserts something and signs it. A university asserting a degree, a professional body asserting registration, an employer asserting employment.

Holder — the person the credential is about. They hold it in a wallet on their device. Nothing is issued to them without their participation, and nothing is presented without their consent.

Verifier — anyone the holder chooses to show a credential to. They check the signature, check the credential has not been revoked, and read only the claims presented.

DiligenceID provides the issuer and verifier infrastructure. The holder's wallet is theirs.

The trust model

A verifier trusts a credential because of three checks, in order:

1. The signature is valid and was made by a key the issuer published. The verifier fetches that key from the issuer's own metadata — not from DiligenceID's word for it.
2. The credential has not been revoked. Status is published in a form the verifier reads directly.
3. The issuer is who they claim to be, established when the issuer was onboarded and reflected in the credential's issuer identifier.

What this deliberately does not require: the verifier trusting DiligenceID. The cryptography is checkable independently. DiligenceID makes issuing and verifying practical; it is not the thing being trusted.

What it does not provide on its own: any assurance about whether the underlying fact is true. A credential asserting a degree is only as good as the university's records. DiligenceID signs what an issuer asserts; it does not verify the assertion.

What a credential's life looks like

     Issuer                    Holder                    Verifier
       |                         |                          |
   1.  |-- configure -------->   |                          |
   2.  |-- create offer ------>  |                          |
   3.  |                      accept                        |
   4.  |<----- request credential |                        |
   5.  |------ signed credential ->|                       |
   6.  |                         |  <---- ask for proof ----|
   7.  |                         |  ---- present proof ---->|
   8.  |                         |                       check
   9.  |-- revoke --------------------------------------> (status)

Steps 3 and 7 involve the holder and cannot be automated away. An integration that appears to issue a credential without the holder doing anything has not issued a credential — it has created an offer that is still waiting.

See credential lifecycle for what each step means in API terms.

What you work with

The first three are configured through the Management API. The last three are runtime operations on the Product API.

Standards

DiligenceID implements existing standards rather than a proprietary protocol, so a credential it issues can be held in a wallet it has never heard of, and verified by a verifier that has never integrated with it.

• OpenID4VCI — how a wallet obtains a credential
• OpenID4VP — how a verifier requests and receives a presentation
• SD-JWT VC — the credential format, which supports disclosing individual claims
• Status lists — how revocation is published and checked

See protocol APIs.

Next

• API planes — the two APIs and which you need
• Architecture overview — how the pieces fit
• Developer onboarding — get a key and make a call