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/did-core.md

@@ -1,50 +1,109 @@
-# Did Core
+# W3C DID Core
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core.
 
 ## Domain
 
-TODO: Classify the source domain.
+Decentralized identifiers, verifiable identity subjects, DID documents, and
+verification methods.
 
 ## Why This Source Matters
 
-W3C DID Core: decentralized identifiers, DID subjects, DID controllers, verification methods, and services.
+DIDs provide externally controlled identifiers with cryptographic verification
+methods, relevant to portable identity, issuer independence, and synonymity
+across systems.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **DID**: globally unique URI following `did:method:identifier` syntax.
+- **DID subject**: entity identified by a DID; may be person, org, or thing.
+- **DID controller**: entity authorized to change DID document (may differ from
+  subject).
+- **DID document**: JSON-LD document resolved from DID; contains verification
+  methods, services, and controllers.
+- **Verification method**: cryptographic key or proof mechanism for authentication
+  or signing.
+- **Service endpoint**: machine-readable service URL in DID document.
+- **DID method**: specific ledger or resolution rules (`did:web`, `did:key`,
+  `did:ion`, etc.).
+- **Resolution**: process of retrieving DID document from DID URL.
+- **Also-known-as / equivalentId**: related identifier properties (method-specific).
+- **Delegation**: controller grants another party control via verification
+  relationship.
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| DID | Decentralized identifier string. |
+| DID subject | Entity the DID names. |
+| DID controller | Party that can update DID document. |
+| DID document | Resolved metadata about DID. |
+| Verification method | Key/material for prove/control. |
+| Service | Endpoint declaration in document. |
+| DID method | Resolution and registry rules. |
+| Resolve | Fetch DID document. |
+| Controller | Authority over DID lifecycle. |
+| Subject (DID) | Identified party; not necessarily controller. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Identifier is primary**; subject is named by DID, not stored in central directory.
+- **Control is cryptographic** via verification methods and controllers.
+- **Subject and controller may diverge** (custodial wallets, organizational DIDs).
+- **DID document is mutable** under controller authority.
+- **Methods vary in persistence, privacy, and registry model.**
+- **No built-in person/account distinction**; semantics are method and usage dependent.
+- **Relationships to other DIDs** may appear as services or custom properties.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- **DID** maps to **Identifier** (decentralized, resolvable).
+- **DID subject** maps to **Actor** or target of **Claim** depending on usage.
+- **DID controller** maps to **Representation** or **Ownership** relationship
+  over identifier control.
+- **Verification method** maps to **Credential** (cryptographic).
+- **DID document** maps to **Profile** / metadata record for Identifier.
+- **Service endpoint** maps to operational binding (downstream).
+- DID-based strong binding supports S13 (verified link), S14 (pseudonymous
+  scoped identity when using pairwise/privacy-preserving methods).
+- Reinforces **P8** (evidence via cryptographic verification).
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **Subject**: DID subject vs. OIDC sub vs. authorization subject.
+- **Controller vs. Owner**: controller is key/document authority; owner is
+  broader relationship.
+- **Identity vs. DID**: DID is identifier, not identity record.
+- **Credential vs. Verification method**: verification method is key material;
+  VC is claim artifact.
+- **Resolve vs. Lookup**: resolution is method-specific; not uniform directory.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| DID Core concept | Candidate canonical concept |
+| --- | --- |
+| DID | Identifier |
+| DID subject | Actor (context-dependent) |
+| DID controller | Representation or Ownership Relationship |
+| DID document | Profile / Identifier metadata record |
+| Verification method | Credential |
+| Service endpoint | Operational binding (downstream) |
+| DID method namespace | Scope (method-specific) |
+| Resolution result | Evidence Source |
+| equivalentId / alsoKnownAs | Synonymity Assertion (method-dependent) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should DID be a distinct Identifier subtype with method and resolution metadata?
+- How should subject/controller split map for organizational vs. personal DIDs?
+- Does equivalentId warrant weak or strong Synonymity by default?
+- How do DID methods with pairwise features (e.g., did:ion pairwise) map to
+  Scoped Identifier?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/
+- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/