generated from coulomb/repo-seed
tegwick
1c1b5c9bc6
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
4.5 KiB
4.5 KiB
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/