W3C Verifiable Credentials (VC) Data Model 2.0

Per VC DM 2.0: Accessibility Requirements + Internationalization + security considerations + integration with DIDs.

• VC DM evidence for W3CVCDM-4

• selective disclosure + DID integration partial

Maintain audit logs of credential issuance, status changes, verification outcomes, and key management events, and monitor for anomalies indicative of fraud or compromise.

• Audit log schema
• Log retention policy
• Monitoring alerts for anomalies

• Logs lacking the actor or the affected credential identifier
• Retention insufficient for incident investigation
• No monitoring of verifier side anomalies

Credentials must include metadata such as validFrom, validUntil, and credential identifier properties.

• Credential schema
• Metadata registry
• Issuance log

• Missing required metadata
• No issuance date
• Unclear validity

Credentials may include a credentialStatus property enabling discovery of revocation or suspension information.

• Status list
• Revocation registry
• Update process

• No revocation method
• Privacy-leaking status
• Stale list

Credentials may reference a credentialSchema to enable machine-verifiable validation of credential structure.

• JSON Schema
• Schema registry
• Validation tests

• No schema validation
• Missing types
• Schema drift

Credentials may include evidence property providing information used by the issuer to establish claim veracity.

• Evidence property documentation
• Verification log
• Source attestation

• Missing evidence
• No verification record
• Weak proofing

Per VC DM 2.0: data model including credential subject + claims + proof + status + revocation + expiration.

• VC DM evidence for W3CVCDM-2

• selective disclosure + DID integration partial

Implementations of credentials and presentations conform to the syntax and semantics defined in the Verifiable Credentials Data Model 2.0 specification, including required properties and processing rules.

• Conformance test results
• Implementation guide referencing the spec
• Mapping of properties used to spec sections

• Use of legacy 1.1 properties without migration
• Custom properties shadowing standard names
• No test suite run against published vectors

Every verifiable credential and presentation includes the v2 base context as the first value of the @context property and any additional contexts that define properties used by the credential.

• Sample credentials showing the v2 context first
• JSON LD context files served from stable URIs
• Cache control configuration for context files

• Mixing v1.1 and v2 base contexts
• Undefined terms not covered by an additional context
• Context URIs that 404 or change content

Use validFrom and validUntil to express the period during which a credential is intended to be valid, with values conforming to dateTime stamp formats.

• Issuance policy specifying validity defaults
• Verifier behaviour for absent validUntil
• Sample credentials

• Use of legacy issuanceDate and expirationDate without migration
• Off by one errors at validity boundary
• Verifiers ignoring validity entirely

Express claims about a subject through the credentialSubject property and identify the subject with an identifier where appropriate, supporting also subject identifier free credentials.

• Data model for subject claims
• Identifier strategy
• Privacy assessment for identifier choices

• Inclusion of unnecessary identifiers
• No support for subject identifier free credentials where appropriate
• Embedding cleartext personal data when a hash or selective disclosure would suffice

Set the type property to include VerifiableCredential or VerifiablePresentation as appropriate, plus specific subtypes that describe the credential's nature.

• Type registry for issued credentials
• Examples showing required base type
• Validator rejecting credentials missing the base type

• Missing the base VerifiableCredential type
• Overloaded type with non meaningful values
• Type values not defined in any context

Per W3C Verifiable Credentials Data Model 2.0: Three-Party Ecosystem + issuer + holder + verifier + verifiable data registry.

• VC DM evidence for W3CVCDM-1

• selective disclosure + DID integration partial

Provide holders with credential storage that protects credentials at rest, supports backup and recovery, and prevents unauthorized access by other applications.

• Wallet threat model
• Secure storage configuration
• Backup and recovery procedure

• Credentials stored unencrypted
• No biometric or PIN protection
• Backups uploaded to consumer cloud without user awareness

Generate verifiable presentations that bundle one or more verifiable credentials, are signed or otherwise secured by the presenter, and may optionally include domain and challenge to bind the presentation to a verifier interaction.

• Presentation generation flow
• Challenge and domain handling
• Replay protection

• Presentations without holder binding
• No challenge enforcement
• Replay windows too long

Verifiable presentations combine one or more credentials for selective disclosure to verifiers.

• Presentation builder
• Composition tests
• Presentation samples

• No composition logic
• Missing nested proofs
• No challenge handling

Presentations must cryptographically bind the holder to the presentation to prove control of the credentials.

• Holder binding proof
• Key binding tests
• Replay protection

• No holder binding
• Replay attacks possible
• Missing key proof

Presentations are typically short-lived and must include temporal validity constraints to prevent replay attacks.

• Validation policy
• Verifier rules
• Validation log

• No validation rules
• Missing expiry check
• No revocation lookup

Identify the issuer of a credential by a URI, typically a Decentralized Identifier or HTTPS URL, that can be dereferenced to verify the issuer's public keys.

• Issuer identifier registry
• DID document or HTTPS resolution evidence
• Key publication policy

• Opaque identifiers that cannot be resolved
• Multiple identifiers used inconsistently
• No documented key publication policy

Manage cryptographic keys used for issuance under a documented key management policy that covers generation, storage, rotation, revocation, and recovery.

• Key management policy
• HSM or KMS configuration evidence
• Key rotation log
• Key compromise response plan

• Long lived signing keys with no rotation
• Keys stored outside hardware backed protection
• No revocation pathway documented

Document operational procedures for credential issuance, suspension, revocation, and reissuance, including approval gates, fraud checks, and audit logging.

• Issuance workflow documentation
• Approver matrix
• Audit log of issuance and revocation events

• Manual issuance with no audit trail
• Revocation handled by support staff without authorization
• No reconciliation between business records and the status list

Where revocation, suspension, or other status information is required, include a credentialStatus property using a defined status method that allows verifiers to determine the current status.

• Choice of status mechanism such as a BitstringStatusList
• Status list publication endpoint
• Issuer procedure for status updates

• No status mechanism implemented
• Status list endpoints not cached or scaled
• Bit positions reused after revocation

Implement status lists in a way that preserves holder privacy, for example by publishing large status lists that prevent correlation between status queries and individual holders.

• Status list size configuration
• Caching strategy for verifiers
• Privacy assessment of status approach

• Status lists small enough to leak holder identity
• Endpoints logging IP addresses for status lookups without minimization
• No privacy assessment of the chosen status method

Where appropriate, support selective disclosure techniques such as SD JWT or BBS signatures that allow holders to share only the claims required for a particular verifier.

• Selective disclosure design
• Claim selection UI
• Privacy assessment

• All claims released regardless of need
• Selective disclosure available but not enabled by default
• No user understanding of disclosure choices

Design issuance and presentation flows to minimize correlation across verifiers, for example through one time use credentials, batch issuance, or unlinkable proofs.

• Correlation risk assessment
• Batch issuance design where applicable
• Holder education materials

• Reuse of the same credential and identifier across all verifiers
• No mitigation for verifier collusion
• No holder controls over linkability

Per VC DM 2.0: Privacy Considerations + selective disclosure + zero-knowledge proofs + minimal disclosure.

• VC DM evidence for W3CVCDM-3

• selective disclosure + DID integration partial

Where Decentralized Identifiers are used as issuer, holder, or subject identifiers, comply with the DID Core specification and select DID methods appropriate to the use case.

• DID method selection rationale
• DID resolver configuration
• Method specific security review

• Use of unsupported or deprecated DID methods
• No fallback when resolvers are unavailable
• Method choice without privacy or governance evaluation

Secure verifiable credentials and presentations using one of the standard securing mechanisms, such as Data Integrity proofs or JWT and SD JWT based representations, as specified in the companion specifications.

• Choice of securing mechanism
• Cryptosuite selection rationale
• Library versions and CVE monitoring

• Custom non standard securing mechanisms
• No documented choice between embedded and enveloping proofs
• Outdated libraries without CVE tracking

Choose cryptosuites that are appropriate to the risk and lifetime of the credential, prefer modern, peer reviewed cryptosuites, and document the choice and migration path.

• Approved cryptosuite list
• Crypto agility plan
• Deprecation schedule

• Single cryptosuite hard coded with no migration path
• No deprecation schedule for legacy algorithms
• Cryptosuite mismatched to key type

Adopt or define interoperability profiles that constrain securing mechanisms, schemas, and transport protocols so that issuers, holders, and verifiers across vendors can interoperate.

• Selected profile such as the relevant interop profile
• Conformance evidence against the profile
• Vendor interop test results

• No profile selected
• Profile chosen but not enforced
• Interop only tested with a single counterparty

Verifiers perform the verification algorithm including syntax checks, signature verification, validity period checks, status checks, and trust framework evaluation before relying on the credential.

• Verification policy
• Sequence diagram of verification steps
• Logs of verification outcomes

• Status checks skipped due to performance concerns
• No trust framework consultation
• Failure modes not differentiated in logs

Verifiers establish a trust framework that defines which issuers are acceptable for which credential types and decisions, and document the basis for trust.

• Trust list configuration
• Onboarding procedure for new issuers
• Periodic review of trust decisions

• Implicit trust based only on cryptographic validity
• No revocation of trust when issuer governance lapses
• Trust list updates not authenticated