Complete IDENTITY-WP-0003 corpus backfill and model refinement

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.

research/verifiable-claims/vc-data-model-2.md

@@ -1,50 +1,110 @@
-# Vc Data Model 2
+# W3C Verifiable Credentials Data Model 2.0
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable).
 
 ## Domain
 
-TODO: Classify the source domain.
+Verifiable claims, issuers, holders, verifiers, credential lifecycle, and
+portable identity assertions.
 
 ## Why This Source Matters
 
-W3C Verifiable Credentials Data Model 2.0: issuer, holder, subject, verifier, claims, presentations.
+Verifiable Credentials formalize issuer-holder-verifier semantics for portable,
+cryptographically verifiable claims about subjects — central to evidence-based
+identity modeling.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **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
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| 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
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **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
 
-TODO: Explain what this source suggests for the canonical identity model.
+- **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
 
-TODO: Record where this source uses terms differently from other sources.
+- **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
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| 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
 
-TODO:
-- Question 1
-- Question 2
+- 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
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- 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/