← Catalogue
World Models · legacy example

Identity Register

The anchoring of identity for persons, organizations and things: one authoritative record per subject, to which identifiers, keys and assurance evidence are bound, and against which the rest of the world resolves "who or what is this". It is its own meta-model because identity anchoring, identifier binding and assurance are a distinct discipline from any profile data about the subject: the register says that a subject exists and is the same one over time, and deliberately says as little else as possible.

AI YAMLAGENTS.mdSource
IDworld.r4-identity-register
Version history0.2.0-legacy
CategoryReference example
IndustryCross-industry
Domainregistries-ledgers
Tagsidentity, register
Data structure

Bundles and layers

Bundle

anchor

The identity record itself

Layers

subjectKind`: person, organization and thing subjects and what an anchor asserts for each · `identityLifecycle`: registered, active, suspended, retired states and same-subject continuity

Bundle

binding

What attaches to an anchor

Layers

identifierSchemes`: bindings of scheme-governed identifiers to the anchor · `keyAndCredentialBinding`: cryptographic keys and authenticators bound for proof of control

Bundle

assurance

How strongly identity is established

Layers

proofingEvidence`: the evidence trail from identity proofing · `assuranceLevel`: graded confidence attached to the anchor and its bindings

Bundle

resolution

Answering lookups without oversharing

Layers

resolutionService`: identifier to status-and-keys resolution · `privacyControls`: minimal-disclosure rules, verification without attribute release

Findings

Catalogue-native findings must describe the information grouped by each layer. This legacy version does not declare them separately.

Questions & artifacts

Questions, artifact requirements and serial naming rules are required by Vercy vNext; they remain unassigned in this reference version.

Service layers

How this specification operates

Dimension & namespace

  • EXTEND `world.registry` (R1): the identity register is a specialization of the register pattern, with anchoring as its legal effect
  • REFERENCE `world.person` (H1): a person anchor points to, and never inlines, the person's profile kept elsewhere
  • REFERENCE `world.organization` (O1): organization anchors resolve to organization records governed in their own model
  • REFERENCE (inbound) `world.attestationCertificateAndLicense` (R5): issuers and subjects of attestations are anchored here
  • REFERENCE (inbound) `world.lifeEventsAndCivilStatus` (B12): birth registration creates a person anchor, death registration retires it
  • MIX-IN `world.audit` (S4): every resolution and update carries the audit facet
  • imports: w3c-did (ALIGN): decentralized identifier syntax, resolution and key rotation semantics
  • imports: iso-iec-24760 (ALIGN): identity management vocabulary and lifecycle framing
  • imports: nist-sp-800-63 (ALIGN): identity proofing and assurance level semantics

Canon, patches & standards

  • EXTEND `world.registry` (R1): the identity register is a specialization of the register pattern, with anchoring as its legal effect
  • REFERENCE `world.person` (H1): a person anchor points to, and never inlines, the person's profile kept elsewhere
  • REFERENCE `world.organization` (O1): organization anchors resolve to organization records governed in their own model
  • REFERENCE (inbound) `world.attestationCertificateAndLicense` (R5): issuers and subjects of attestations are anchored here
  • REFERENCE (inbound) `world.lifeEventsAndCivilStatus` (B12): birth registration creates a person anchor, death registration retires it
  • MIX-IN `world.audit` (S4): every resolution and update carries the audit facet
  • imports: w3c-did (ALIGN): decentralized identifier syntax, resolution and key rotation semantics
  • imports: iso-iec-24760 (ALIGN): identity management vocabulary and lifecycle framing
  • imports: nist-sp-800-63 (ALIGN): identity proofing and assurance level semantics

Artifact formats & serial data

Format-independent core. Concrete artifact formats and naming prefixes are not declared in this legacy version.

Policies & accepted processes

  • `resolutionContract`: which attributes a class of relying parties may obtain when resolving an identifier
  • `verificationContract`: yes/no confirmation of a claimed binding or status without releasing attributes
  • `registrarUpdateContract`: who may create, bind, suspend and retire anchors, under which evidence rules
  • `subjectAccessContract`: the subject's standing right to see their own full record and its access history

Read / add / edit / delete

CRUD procedures and interface bindings are not declared in this legacy version.

Ownership, roles & access

The identity registrar owns the anchors and their bindings and answers for uniqueness and continuity, while each subject holds inspection rights over their own record. Any resolution or disclosure beyond the public resolver view is granted through the S1/S2 access and consent models and audited via S4.

Existing assembly

Objects, relationships, events and projections

Objects

  • `identityRecord`: the anchor for one subject; key attributes: subjectKind, status, registeredAt, registerRef
  • `identifierBinding`: an externally schemed identifier attached to an anchor; key attributes: scheme, value, boundAt, status
  • `keyBinding`: a key or authenticator proving control of the anchor; key attributes: keyMaterialRef, purpose, validFrom, revokedAt
  • `assuranceAssessment`: a graded judgment of how well the subject was proofed; key attributes: level, method, assessedAt, evidenceRefs
  • `identityStatus`: the current standing of the anchor; key attributes: state, reason, effectiveAt
  • `linkageAssertion`: a recorded claim that two anchors denote the same subject; key attributes: confidence, basis, assertedBy
  • `resolutionPolicy`: what a resolver may disclose to whom; key attributes: audienceClass, disclosedAttributes, verificationOnlyFlag

Relationships

  • `identifierBinding` -> bindsTo -> `identityRecord` (many-to-one): a subject can carry identifiers from several schemes
  • `keyBinding` -> provesControlOf -> `identityRecord` (many-to-one): control keys rotate over one stable anchor
  • `assuranceAssessment` -> evaluates -> `identityRecord` (many-to-one): assurance is re-assessed over the anchor's life
  • `linkageAssertion` -> links -> `identityRecord` (many-to-many): duplicate or successor anchors are joined by explicit assertion, never merged silently
  • `identityRecord` -> resolvedUnder -> `resolutionPolicy` (many-to-one): disclosure at lookup follows a declared policy
  • `identityRecord` -> hasStatus -> `identityStatus` (one-to-many): status history is kept, current status is derived

Events

  • `identityRegistered`: a new anchor was created for a proofed subject
  • `identifierBound`: an external identifier was attached to an anchor
  • `identifierRetired`: an identifier binding was ended without ending the anchor
  • `keyRotated`: a control key was replaced and the old one retired
  • `assuranceRaised`: re-proofing lifted the anchor's assurance level
  • `identitySuspended`: the anchor was temporarily barred from resolution and use
  • `identityRetired`: the anchor was closed, typically on death or dissolution, with continuity preserved for history
  • `recordsLinked`: two anchors were asserted to denote the same subject

Projections

  • `publicResolverView`: identifier to current status and public keys; omits personal attributes and evidence
  • `relyingPartyView`: status plus assurance level for an authorized verifier; omits proofing evidence content
  • `subjectSelfView`: the complete own record including bindings, assessments and access history