Files

tegwick 1c1b5c9bc6 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.

2026-06-21 20:22:20 +02:00

4.5 KiB

Raw Blame History

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/

4.5 KiB Raw Blame History