Credential data handling
Credentials carry claims about real people. What you do with those claims is your responsibility, and the architecture is designed to leave you holding as little as possible.
What DiligenceID holds
Issuers, credential configurations, verification policies — configuration, not personal data.
Issuance transactions — enough to complete an issuance, including the claims you supplied, for the life of the transaction.
Credential status — whether a credential is active or revoked.
Not the issued credential. Once issued, a credential is held by the holder. There is no endpoint that returns its contents because DiligenceID does not have them. A platform retaining every credential it issued would be a far more attractive target than one retaining their status.
What you should hold
Less than you think.
When issuing: you already hold the source data — that is why you can assert it. You do not additionally need to store the credential. Store the transaction identifier and the outcome.
When verifying: you asked for the smallest fact that supports your decision. Store the decision and the verification identifier. Not a copy of what was presented.
The temptation is to keep the verification payload "in case we need it". That converts a system that checks a fact into a system that accumulates personal data, with the retention, access-control and breach obligations that follow.
Ask for less
Selective disclosure only helps if you use it. A policy that requests a full profile when you needed one boolean has given up the main privacy benefit of the model.
Write policies around the question you are actually answering: "is this person a current member?" rather than "give me their membership record".
In transit and at rest
All API traffic is HTTPS. Claim values are not logged by DiligenceID, and should not be logged by you — application logs are widely readable inside most organisations and are rarely covered by the same controls as a database.
When you must log something about an issuance, log the transaction identifier and x-ms-request-id, not the
claims.
Errors never carry claim values
DiligenceID errors contain a code, a message, a target and diagnostic identifiers. They do not contain claim values, credential proofs, nonces, tokens, cookies or key material. If you build your own error surface on top, keep that property.
Retention
Decide a retention period for issuance and verification records before you go live, and implement deletion. "Keep everything" is a decision too, and usually the wrong one.