Protocol APIs
Status: protocol-defined. These endpoints implement external standards. DiligenceID does not version them, does not wrap them in its own envelope, and does not add its own required headers to them.
Wallets and verifiers call them. Your server generally does not.
What they are
| Standard | Purpose |
|---|---|
| OpenID4VCI | How a wallet obtains a credential from an issuer |
| OpenID4VP | How a verifier requests a presentation and receives it |
| SD-JWT VC | The credential format, supporting selective disclosure |
| Status lists | How revocation is published and checked |
Issuer metadata (/.well-known/*) |
How a wallet discovers an issuer's endpoints and keys |
Why they are separate
Their shape belongs to the standards bodies that define them. If DiligenceID added an api-version parameter,
a { "data": ... } wrapper or a required x-ms- header to an OpenID4VCI endpoint, a compliant wallet would
fail against it — and the whole reason for implementing a standard is that a wallet which has never heard of
DiligenceID can still work with it.
So the DiligenceID conventions documented elsewhere in these docs stop at the protocol boundary. That is not an inconsistency; it is the boundary doing its job.
They are also absent from the canonical Management and Product specifications, because they are not DiligenceID's contract to publish.
What this means for you
Building a wallet or verifier: work from the standards. DiligenceID's implementations follow them.
Building a server integration: you almost certainly do not call these. Use the Product API, which handles the protocol side for you — that is what it is for. An integration constructing raw OpenID4VP parameters has taken on the standard's complexity for no benefit.
One exception worth knowing: a verifier checking revocation reads a status list directly. It does not call DiligenceID's API, and it does not need a key. That is by design — revocation checking must work without a relationship with the issuer.
Discovery
An issuer publishes its metadata at a well-known URL derived from its canonical issuer URI, which is returned in the issuer resource. A wallet fetches the issuer's signing keys from there rather than taking DiligenceID's word for them.