# W3C Verifiable Credentials Data Model 2.0

## Source Type

Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable).

## Domain

Verifiable claims, issuers, holders, verifiers, credential lifecycle, and
portable identity assertions.

## Why This Source Matters

Verifiable Credentials formalize issuer-holder-verifier semantics for portable,
cryptographically verifiable claims about subjects — central to evidence-based
identity modeling.

## Key Concepts

- **Verifiable Credential (VC)**: tamper-evident credential making claims about
  a subject, signed by issuer.
- **Verifiable Presentation (VP)**: bundle of VCs (and proofs) presented by holder
  to verifier.
- **Issuer**: entity that asserts claims and signs VC.
- **Holder**: entity possessing VC (may or may not be subject).
- **Verifier**: entity checking VC/VP validity.
- **Subject**: entity claims are about (`credentialSubject`).
- **Claim**: individual statement within credentialSubject.
- **Proof**: cryptographic proof of integrity and issuer authenticity.
- **Credential schema**: type and structure definition for VC.
- **Status**: revocation/suspension via StatusList2021 or similar.
- **ValidFrom / ValidUntil**: temporal validity window.
- **Evidence**: supporting documents referenced in VC (DID, attachments).

## Relevant Terminology

| Term | Source meaning |
| --- | --- |
| Verifiable Credential | Signed claim set about subject. |
| Presentation | Holder-submitted package for verification. |
| Issuer | Signing authority for claims. |
| Holder | Party storing/presenting VC. |
| Verifier | Party validating VC/VP. |
| Subject | Entity described by credentialSubject. |
| credentialSubject | Claim object about subject. |
| Proof | Cryptographic verification data. |
| StatusList | Revocation/suspension mechanism. |
| type | VC semantic type(s). |
| validFrom / validUntil | Temporal bounds. |

## Modeling Assumptions

- **Claims are assertions, not ground truth** until verified by verifier policy.
- **Issuer authority is explicit** and cryptographically attributable.
- **Holder may differ from subject** (custodial credentials).
- **Revocation is first-class** via status mechanisms.
- **Temporal validity matters** for employment, membership, age claims.
- **Selective disclosure** may hide parts of credentialSubject (privacy).
- **Subject may be identified by DID, URI, or other identifier.**

## Identity-Canon Implications

- **VC** maps to **Credential** containing **Claim** set.
- **credentialSubject** claims map to individual **Claim** objects about
  **Actor**, **Membership**, or attributes.
- **Issuer** maps to issuer **Scope** + **Trust Relationship**.
- **Holder** maps to **Actor** or **Account** holding credential.
- **Verifier** maps to relying party evaluating Trust + Evidence.
- **Subject** maps to **Actor** or Identifier target.
- **Status/revocation** maps to **Lifecycle State** on Credential/Claim.
- **validFrom/validUntil** map to relationship/assertion temporal bounds.
- Supports S13 (strong verified link), S03 (org membership claims), S06
  (guardian credentials if issued).
- Reinforces **P7** and **P8**: claims are evidenced assertions.

## Terminology Conflicts

- **Credential vs. Credential (auth)**: VC vs. password/OIDC token.
- **Subject**: VC subject vs. OIDC sub.
- **Claim vs. Attribute**: VC claim vs. directory/LDAP attribute.
- **Holder vs. Account**: holder is possession role, not login account.
- **Verifier vs. RP**: overlapping but VC adds cryptographic verification step.

## Candidate Canonical Mappings

| VC Data Model concept | Candidate canonical concept |
| --- | --- |
| Verifiable Credential | Credential |
| credentialSubject claim | Claim |
| Issuer | Issuer Scope + Trust Relationship |
| Holder | Actor / Account (possession role) |
| Verifier | Relying party / verifier Scope |
| Subject | Actor or Identifier target |
| Proof | Evidence Source (cryptographic) |
| StatusList entry | Lifecycle State (revoked/suspended) |
| validFrom / validUntil | Temporal bounds on Claim |
| Presentation | Credential bundle (operational) |

## Open Questions

- Should canon treat VC as Credential subtype or parallel Claim container?
- How should membership VCs map to Membership Relationship vs. Claim only?
- Does selective disclosure require Persona or Scoped Identifier linkage?
- Should issuer DID vs. issuer URL be standardized Identifier forms?

## References

- W3C VC Data Model 2.0 — https://www.w3.org/TR/vc-data-model-2.0/
- VC Data Model 1.1 (widely deployed) — https://www.w3.org/TR/vc-data-model/
- Status List 2021 — https://www.w3.org/TR/vc-status-list-2021/