Credential lifecycle
What happens to a credential from configuration to revocation, and which API call corresponds to each step.
Configuration — once
| Step | Call | Result |
|---|---|---|
| Create the organisation | Organisations_Create |
The legal entity credentials are issued on behalf of |
| Create the issuer | Issuers_Create |
A signing identity in Draft |
| Configure it | Issuers_Update |
Metadata, status mechanism, holder binding |
| Define the credential type | CredentialConfigurations_Create |
Claims, format, rules |
| Check readiness | Issuers_GetReadiness |
What is still outstanding |
| Activate | Issuers_Activate |
The issuer can now issue |
An issuer in Draft cannot issue. Activation runs the readiness checklist and refuses if anything required is
missing — it is not a status field you set.
Issuance — per credential
| Step | Who | What |
|---|---|---|
| 1. Create an issuance transaction | You | Credentials_Issue, with the claims |
| 2. Deliver the offer | You | A link or QR code the holder can act on |
| 3. Accept | Holder | In their wallet |
| 4. Request the credential | Wallet | OpenID4VCI, against the protocol endpoints |
| 5. Sign and return | DiligenceID | The credential is now held |
Steps 3 and 4 are not yours to drive. Between step 1 and step 3 the transaction sits in awaiting_wallet,
which is a correct state and not an error.
Claims are validated against the credential configuration at step 1. An unrecognised claim is rejected there, which is the cheapest possible place to find a typo.
Verification — per check
| Step | Who | What |
|---|---|---|
| 1. Create a verification | You | Verifications_Create, naming a policy |
| 2. Present the request | You | Usually a QR code |
| 3. Consent and present | Holder | Selective disclosure happens here |
| 4. Check | DiligenceID | Signature, status, policy conditions |
| 5. Read the result | You | Verifications_Get |
Between steps 1 and 3 the verification is pending.
You name a policy, not a list of claims. The policy was written by whoever understands the risk, and freezing it means a compromised front end cannot ask for more than was agreed.
Status and revocation
A credential's status is published in a status list that verifiers read directly. Revoking sets the status; verifiers find out because they check, not because they were told.
| Operation | Effect |
|---|---|
Credentials_GetStatus |
The current status of one credential |
Credentials_Revoke |
Marks it revoked, permanently |
Revocation cannot be undone. Reissue instead — which is a new credential with a new identifier, not the old one restored.
What you can and cannot observe
You can observe: transaction state, verification state, credential status.
You cannot observe: the contents of an issued credential, where a holder stored it, or which verifiers they presented it to. DiligenceID does not have that information — which is what makes the model worth using.