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.
109 lines
4.5 KiB
Markdown
109 lines
4.5 KiB
Markdown
# W3C DID Core
|
|
|
|
## Source Type
|
|
|
|
Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core.
|
|
|
|
## Domain
|
|
|
|
Decentralized identifiers, verifiable identity subjects, DID documents, and
|
|
verification methods.
|
|
|
|
## Why This Source Matters
|
|
|
|
DIDs provide externally controlled identifiers with cryptographic verification
|
|
methods, relevant to portable identity, issuer independence, and synonymity
|
|
across systems.
|
|
|
|
## Key Concepts
|
|
|
|
- **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
|
|
|
|
| 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
|
|
|
|
- **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
|
|
|
|
- **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
|
|
|
|
- **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
|
|
|
|
| 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
|
|
|
|
- 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
|
|
|
|
- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/
|
|
- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/ |