commerce-canon/research/verifiable-claims/did-core.md

# 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/