Digital credentials can make identity checks faster and more privacy-conscious, but only when an organization verifies the proof itself rather than trusting a screenshot or an unexamined document. This guide provides a reusable workflow for checking issuer identity, validating signatures, handling expiration and revocation, recording consent, and responding to exceptions.
Overview
A digital credential is a structured claim issued to a holder and presented to a verifier. Depending on the implementation, it may represent qualifications, account attributes, memberships, permissions, or other attestations. A digital wallet can store and present the credential, but the wallet is not automatically proof that the claim is genuine.
Digital credential verification should answer several separate questions:
- Who issued the credential? The issuer should be identifiable and authorized to make the claim.
- Has the credential been altered? Its signature, integrity protection, or equivalent cryptographic evidence must validate.
- Is it still valid? Check issuance, expiration, status, and any applicable usage conditions.
- Was it presented with the holder’s permission? Consent and disclosure should be appropriate to the use case.
- Can the verification decision be explained later? The organization needs an audit record without retaining unnecessary personal data.
These checks are distinct from manually reviewing an image. A screenshot may be useful as a visual reference, but it does not reliably establish provenance, current status, or integrity. A verification service, wallet flow, or identity verification API should process the credential according to its supported format and trust configuration.
Before implementation, document which credential formats, issuers, wallets, and status mechanisms your system supports. Teams evaluating an integration can also use an identity verification API evaluation guide to structure questions about security, webhooks, data handling, and operational controls.
Checklist by scenario
When accepting a credential from a digital wallet
- Confirm the presentation context. Identify the service requesting the credential, the purpose of the check, and the specific claims required. Avoid requesting a complete identity profile when a narrower attribute is sufficient.
- Check holder consent. Make sure the holder understands what will be shared, why it is needed, and how the result will be used. Record the consent event or transaction reference required by your internal policy.
- Validate the presentation. Confirm that the presentation is associated with the intended holder or authorized presenter when the credential model requires that relationship. Do not assume that possession of a file proves ownership of the identity described in it.
- Validate the credential signature. Resolve the issuer’s verification material through the configured trust method, validate the signature, and confirm that the credential has not been modified.
- Check issuer trust. Match the issuer against an approved registry, trust list, directory, or policy. A valid signature only shows that the recognized key signed the data; it does not, by itself, show that the issuer is acceptable for your use case.
- Check time and status. Evaluate issuance time, expiration time, not-before restrictions, credential status, and any presentation-specific constraints.
- Apply business rules. Decide whether the verified claims meet the requirement. Keep cryptographic validity separate from eligibility, access, fraud, or compliance decisions.
- Return a clear result. Store a structured outcome such as verified, rejected, expired, revoked, unsupported, or manual review required.
When reviewing a credential submitted through an API
- Authenticate the calling application and authorize the requested verification operation.
- Validate the payload against the expected schema before attempting business-rule evaluation.
- Reject unexpected algorithms, issuer identifiers, formats, or key locations rather than silently accepting them.
- Use replay protections where the presentation flow requires a nonce, challenge, timestamp, or transaction binding.
- Make webhook processing idempotent so that repeated events do not create conflicting decisions.
- Protect logs from becoming an unplanned copy of the credential or its personal data.
For implementation details, see the identity verification API integration guide, particularly the sections covering architecture, webhooks, and error handling.
When a credential is used for access or account recovery
- Define the minimum claims required for the action and whether a fresh presentation is necessary.
- Separate credential verification from session management. A successful check should not automatically create a broadly privileged session.
- Apply risk controls for unusual devices, repeated failures, suspicious velocity, or changes to account recovery details.
- Provide a safe fallback for unsupported wallets, inaccessible credentials, and legitimate verification failures without weakening the primary control.
- Require additional review for high-impact actions when the credential alone does not provide sufficient assurance.
What to double-check
Issuer and key resolution
Confirm how the verifier finds the issuer’s public key and how key rotation, unavailable endpoints, and compromised keys are handled. Pinning a key indefinitely can create availability and rotation problems; trusting any key returned by an unvalidated location can create a security problem. Establish an explicit trust configuration and document its owner.
Revocation and status
A credential can be correctly signed and still no longer be usable. Implement the status mechanism associated with the credential type, and define what happens when the status service is unavailable. Depending on the risk of the transaction, your policy may require a fail-closed result, a temporary manual review, or a limited retry. Do not describe an unavailable status check as a successful verification.
Expiration and clock handling
Use a consistent time source and account for reasonable clock differences where the credential rules permit it. Check whether the credential expires at a precise time or on a date boundary, and test behavior near issuance and expiration. Keep time validation separate from revocation: an unexpired credential is not necessarily active.
Privacy and retention
Store the smallest useful record. In many workflows, the audit trail needs the verification time, issuer identifier, credential type, result, reason code, transaction reference, and policy version—not the complete credential. If the full payload must be retained for a specific operational or legal reason, define access controls, encryption, retention, deletion, and export procedures before launch.
Auditability and exceptions
Record enough context to reconstruct the decision without relying on an engineer’s memory. Useful fields include the verifier version, trust configuration version, status-check result, validation errors, consent reference, and reviewer outcome. Build explicit paths for expired, revoked, malformed, unsupported, duplicated, and unverifiable credentials.
Organizations designing broader controls can compare this workflow with an enterprise digital identity verification checklist to connect credential checks with access governance, incident response, and compliance operations.
Common mistakes
- Trusting screenshots. Images do not provide dependable issuer, signature, status, or holder-binding evidence.
- Checking only the signature. Cryptographic validity does not establish issuer approval, current status, or business eligibility.
- Ignoring revocation. Status checking is an operational part of verification, not an optional post-processing step.
- Accepting every algorithm or issuer. Verification code should enforce an allowlist and a documented trust policy.
- Logging complete credentials. Debug logs and analytics systems can spread sensitive claims beyond the original workflow.
- Failing open during outages. An unavailable status endpoint should produce a defined exception state, not an implicit approval.
- Conflating rejection reasons. “Expired,” “revoked,” “unsupported,” and “invalid signature” have different remediation paths and should remain distinguishable.
- Skipping negative tests. Test altered claims, wrong issuers, stale keys, replayed presentations, invalid timestamps, and unavailable status services before production use.
When to revisit
Review this workflow before seasonal planning cycles, major product releases, and changes to the credentials your organization accepts. Revisit it whenever you add an issuer, wallet, format, algorithm, status mechanism, or high-impact use case. It should also be reviewed after a verification failure, security incident, key rotation, trust-list change, or material update to your privacy and retention process.
Use this short review sequence:
- List every accepted credential type, issuer, wallet flow, and status mechanism.
- Run positive and negative test cases, including expired, revoked, modified, replayed, and unsupported credentials.
- Confirm that consent, data minimization, retention, and access controls still match the workflow.
- Inspect audit records and verify that an independent reviewer can understand each decision.
- Update implementation documentation, support procedures, monitoring, and exception ownership.
A reliable digital credential verification process is not a one-time integration. Treat it as a maintained trust control: verify the issuer, validate the proof, check current status, minimize retained data, and make every exception actionable.
