Architecture overview

How the pieces fit together, and which of them you actually talk to.

The shape

   your server                    DiligenceID                    holder's wallet
        |                              |                                |
        |--- Management API ---------->|  configure issuers,            |
        |    /management               |  credential types, policies    |
        |                              |                                |
        |--- Product API ------------->|  issue, verify, revoke         |
        |    /v1.0                     |                                |
        |                              |<--- Protocol endpoints --------|
        |                              |     OpenID4VCI / OpenID4VP     |
        |                              |                                |
                                       |<--- status list ---- verifier -|

Your server uses two APIs. The wallet uses the protocol endpoints. A verifier checking revocation reads a status list directly and does not call you at all.

What runs where

Configuration state — organisations, issuers, credential configurations, verification policies — lives in DiligenceID and is changed through the Management API. It is the slow-moving part.

Transaction state — issuance transactions, verification sessions — lives in DiligenceID for the duration of the transaction and is driven through the Product API.

Credentials themselves do not live in DiligenceID. Once issued, a credential is held by the holder. There is no endpoint that returns a credential's contents, because DiligenceID does not have them to return. What it retains is enough to answer "is this credential still valid?" — which is the status list.

That is a deliberate property, not a limitation. A platform that retained every credential it issued would be a far more attractive target than one that retains their status.

Signing keys are held in a key store and never leave it. The API returns key identifiers and public metadata; no endpoint returns private key material, and none accepts it.

Isolation boundaries

Three boundaries, enforced independently:

Tenant. Every request resolves to exactly one tenant, and a request that cannot resolve one fails rather than defaulting. Cross-tenant reads report as not found — never as forbidden, which would confirm the resource exists.

Environment. Sandbox and Production are separate logical environments within a tenant. A did_test. key reaches Sandbox and a did_live. key reaches Production; neither can reach the other, and the environment is taken from the key rather than from any request field.

Scope. A key carries scopes, and an operation that needs a scope the key lacks returns 403 — after authentication, so it is distinguishable from a bad key.

See tenants and environments.

What is not public

The /api/* surface serves the DiligenceID admin application through a backend-for-frontend with session cookies and CSRF protection. It is not versioned for external callers, is not in either published specification, and changes without notice. Integrate against /management and /v1.0.

Next

Edit this page on GitHub