Credential Lifecycle
Credential trust must be managed throughout its life. A credential is not permanently trustworthy simply because it was valid when issued.
The lifecycle connects issuer authority, holder custody, verification policy, status, renewal, and evidence.
Lifecycle stages
| Stage | Purpose | Key questions |
|---|---|---|
| Definition | Establish the credential type and governance. | Who may issue it? Which claims belong in it? |
| Proofing and approval | Evaluate evidence and authorize issuance. | What assurance is required? Who approves? |
| Issuance | Create and sign the credential. | Which issuer and key version are used? |
| Delivery and acceptance | Transfer the credential to the holder. | Was it delivered to the intended holder? |
| Custody | Protect the credential and related holder material. | Which devices are approved? How is access controlled? |
| Presentation | Disclose the required claims. | What is requested, to whom, and for what purpose? |
| Verification | Evaluate provenance, integrity, status, freshness, and policy. | Is the credential sufficient for this transaction? |
| Maintenance | Renew, replace, suspend, or revoke. | Has the underlying fact or risk changed? |
| Retirement | End acceptance and apply retention or deletion policy. | What evidence must remain, and for how long? |
Definition and issuance
Before issuance, an institution should define the credential purpose, schema, issuer authority, approval process, validity period, status behavior, and intended verification context.
The issuance event should connect the credential to the policy and evidence used without exposing secret material. A profile update or correction should result in a new governed artifact or another explicit lifecycle action rather than silently changing a signed credential.
Holder acceptance and custody
The holder should understand the credential received, the issuer, the purpose, and any relevant validity conditions. The wallet protects the credential and supports presentation and device continuity.
Custody is not the same as ownership of the issuer's claim. The holder controls use, while the issuer remains accountable for the claim and its status.
Presentation and verification
Each presentation is a separate trust event. The verifier should request only the required evidence and should bind the interaction to the intended context where the protocol supports it.
A credential that was valid at issuance may later be expired, suspended, revoked, replaced, or insufficient for a new policy. Verification must evaluate the current conditions.
Renewal and replacement
Renewal extends or re-establishes trust under current policy. It may require new evidence, updated claims, a fresh signature, and a new validity period.
Replacement may be appropriate when:
- claims have changed;
- the credential format or schema has evolved;
- the issuer signing key has rotated;
- a device or holder-binding relationship must be re-established;
- the previous credential should no longer be used.
Suspension and revocation
Suspension temporarily changes acceptance, while revocation generally indicates that the credential should no longer be accepted under the issuer's policy.
Status decisions must be governed and explainable. Verifiers need a reliable way to evaluate status without receiving unrelated personal information.
Local deletion versus issuer status
Deleting a credential from a wallet removes the holder's local copy. It does not automatically notify the issuer or revoke the credential.
Likewise, revocation changes how verifiers should treat the credential, but it does not guarantee that every local copy has been erased. These are different lifecycle actions with different responsibilities.
Evidence and retention
Issuers, holders, and verifiers may retain different evidence. Retention should be purpose-bound and limited. Useful evidence may include credential type, policy version, status event, requesting party, disclosed claim set, timestamps, and verification outcome, without recording private keys or unnecessary credential contents.