Decentralized Identifiers

Decentralized Identifiers (DIDs) are a W3C standard for self-sovereign digital identity. Unlike traditional identifiers (email addresses, usernames, government IDs), DIDs are created, owned, and controlled by the identity subject without requiring a central authority. OMXUS implements DIDs through NFC rings with secure elements, creating a physical-digital identity layer that is cryptographically verifiable, privacy-preserving, and resistant to both forgery and revocation by external parties.

Definition

A DID is a globally unique identifier that:

• Is created by the identity owner -- not assigned by a central authority
• Does not require a central registration authority
• Is cryptographically verifiable -- proof of ownership without trusted third parties
• Can be resolved to a DID Document containing verification methods and service endpoints
• Is persistent -- cannot be revoked by any external party
• Supports selective disclosure -- reveal only what is needed for a given interaction

Example DID format:

did:omxus:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Structure

A DID consists of three parts:

did:omxus:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
|   |     +-- Method-specific identifier (unique within method)
|   +-- DID Method (defines how to create, resolve, update, deactivate)
+-- Scheme (always "did")

DID Document

Every DID resolves to a DID Document -- a JSON-LD structure containing everything needed to interact with the DID subject:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:omxus:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "verificationMethod": [{
    "id": "did:omxus:z6Mkha...#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:omxus:z6Mkha...",
    "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
  }],
  "authentication": ["did:omxus:z6Mkha...#keys-1"],
  "assertionMethod": ["did:omxus:z6Mkha...#keys-1"],
  "service": [{
    "id": "did:omxus:z6Mkha...#omxus",
    "type": "OMXUSIdentity",
    "serviceEndpoint": "ipfs://Qm..."
  }]
}

The Problem: Identity Under Centralised Control

Every widely used identity system today places control in the hands of someone other than the identity holder:

Traditional Identifier	Controller	Problem	Real-World Consequence
Email address	Email provider (Google, Microsoft, etc.)	Can be suspended, scanned, or deleted by provider	Loss of access to all linked services; surveillance
Social media handle	Platform (Meta, X, etc.)	Subject to terms of service; can be removed arbitrarily	De-platforming destroys social connections and business
Phone number	Carrier	Requires subscription; can be reassigned	SIM-swapping attacks; loss of 2FA access
Government ID	State	Can be revoked; requires state recognition; not universal	Stateless people (10+ million globally) have no legal identity
Username/password	Service provider	Stored by service; vulnerable to breaches	4.1 billion records exposed in data breaches in 2023 alone
Biometrics	Whoever holds the database	Cannot be changed if compromised; surveillance	India's Aadhaar system linked to exclusion from welfare services

The Core Problem

All centralised identity systems share a fundamental flaw: the entity that grants your identity can also revoke it. Your identity exists at the pleasure of a third party. This creates:

• Dependency: You cannot prove who you are without the cooperation of the issuing authority
• Surveillance: The issuer can track every use of your identity
• Exclusion: Those the issuer does not recognise effectively do not exist
• Fragility: A single point of failure (database breach, government collapse, corporate bankruptcy) can destroy identity

Self-Sovereign Identity

Self-sovereign identity (SSI) is the principle that individuals should own and control their digital identities without relying on any external authority.

Christopher Allen's Ten Principles of SSI

Principle	Description	OMXUS Implementation
Existence	Users must have an independent existence	Human Existence Records verified by peers
Control	Users must control their identities	Private keys on NFC ring; user-held data
Access	Users must have access to their own data	Data stored on ring, IPFS, and local device
Transparency	Systems must be transparent	Open-source; Bitcoin-anchored audit trail
Persistence	Identities must be long-lived	Bitcoin anchoring; no expiration
Portability	Information must be transportable	W3C standard; not locked to any platform
Interoperability	Identities should be usable across systems	DID standard; Verifiable Credentials
Consent	Users must agree to identity use	Selective disclosure; no data shared without consent
Minimisation	Disclosure must be minimised	Zero-knowledge proofs where possible
Protection	Rights of users must be protected	Cryptographic enforcement; no central override

W3C Specification

The DID specification was published as a W3C Recommendation in July 2022 -- the highest level of endorsement from the World Wide Web Consortium.

Key documents:

• Decentralized Identifiers (DIDs) v1.0 -- Core specification
• DID Specification Registries -- Registry of DID methods
• Verifiable Credentials Data Model v1.1 -- Credential specification

DID Methods

DID Methods define how to create, resolve, update, and deactivate DIDs on a specific platform:

Method	Ledger/Platform	Strengths	Limitations
did:btcr	Bitcoin	Bitcoin security; no additional infrastructure	Limited metadata; UTXO management complexity
did:ethr	Ethereum	Rich smart contract support	Ethereum fee volatility; separate security model
did:web	Web servers (DNS + HTTPS)	Simple; no blockchain needed	Depends on DNS; centralised hosting
did:key	None (self-contained)	Zero infrastructure dependency	No update mechanism; static
did:ion	Bitcoin (Layer 2, Sidetree)	Scalable; Bitcoin security	Microsoft dependency; complex resolution
did:peer	Peer-to-peer	No ledger needed; instant creation	No global resolution; requires direct exchange
did:omxus	Bitcoin (RGB Protocol)	Bitcoin security; privacy; scalable; full RGB smart contract capability	Newer ecosystem; requires RGB tooling

Verifiable Credentials

DIDs enable Verifiable Credentials (VCs) -- cryptographically signed statements about a subject that can be independently verified without contacting the issuer:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential", "OMXUSVouchCredential"],
  "issuer": "did:omxus:voucher123...",
  "issuanceDate": "2026-01-15T10:30:00Z",
  "credentialSubject": {
    "id": "did:omxus:newmember456...",
    "vouchedAt": "2026-01-15T10:30:00Z",
    "vouchedLocation": "Melbourne, AU",
    "attestation": "I have met this person face-to-face and attest to their unique human existence"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-01-15T10:30:05Z",
    "verificationMethod": "did:omxus:voucher123...#keys-1",
    "proofValue": "z58DAdFfa9..."
  }
}

In OMXUS, the three vouching attestations required for Human Existence Record creation are Verifiable Credentials.

Selective Disclosure

Verifiable Credentials support selective disclosure -- revealing only what is necessary:

Scenario	What Is Revealed	What Is NOT Revealed
Voting	"This DID is a valid OMXUS participant"	Name, age, location, vouching chain
Age verification	"This person is over 18"	Exact age, name, address
Residency check	"This person resides in region X"	Exact address, name, other personal data
Vouching	"This DID has been vouched by 3+ valid DIDs"	Identity of vouchers, details of vouching ceremony

This is achieved through zero-knowledge proofs and derived credentials -- cryptographic techniques that prove a statement is true without revealing the underlying data.

Comparison with Government Identity Systems

Feature	Government ID	DID (OMXUS)
Issuer	State authority	Self (with peer attestation)
Control	State controls issuance, renewal, revocation	User controls all aspects
Revocation	State can revoke at will	Cannot be revoked by any external party
Privacy	State tracks all usage; centralised database	User controls what is shared; no central database
Universality	Limited to citizens/residents of issuing state	Universal -- no state recognition required
Interoperability	Limited to issuing jurisdiction	Global W3C standard
Cost	Fees for issuance, renewal	No recurring cost; one-time creation
Surveillance resistance	None -- designed for state tracking	High -- cryptographic privacy
Resilience	Depends on state infrastructure	Distributed; survives state failure
Biometric link	Photo, fingerprint in centralised database	Optional; user-controlled
Forgery resistance	Physical security features	Cryptographic; mathematically unforgeable

OMXUS Implementation

Creation Process

1. User obtains an OMXUS NFC ring containing a secure element
2. Ring generates a cryptographic key pair internally (private key never leaves the secure element)
3. DID is derived from the public key using the did:omxus method
4. User undergoes the vouching ceremony -- three existing OMXUS members attest face-to-face
5. Each voucher signs an attestation (Verifiable Credential) linking their DID to the new DID
6. Attestations are bundled into a Human Existence Record (HER)
7. HER is stored on IPFS (content-addressed, distributed) and periodically anchored to Bitcoin via RGB Protocol

The NFC Ring

The physical ring serves as the identity device:

Component	Function	Security Property
Secure element	Stores private key; performs cryptographic operations	Key never leaves the chip; tamper-resistant
NFC interface	Communicates with phones and readers via tap	Short range (< 10cm) prevents remote attacks
No battery	Powered by NFC field	Always available; no charging required
Waterproof	Daily wear	Durable enough for continuous use

The ring is:

• Always with you -- worn on your finger, not stored in a wallet or on a server
• Offline-capable -- can sign transactions without internet access
• Intuitive -- tap to authenticate, vote, or verify
• Sovereign -- you hold your keys; no one else can access them

Storage Architecture

• Private key: Secure element in NFC ring (never extracted)
• DID Document: IPFS (content-addressed, globally distributed)
• Attestations: IPFS + Bitcoin (RGB Protocol anchoring)
• Personal data: User's device (encrypted, user-controlled)
• Backup: Shamir secret sharing -- key split into N shards, requiring M of N to recover

Verification

Anyone can verify an OMXUS identity:

1. Obtain the DID (from NFC tap, QR code, or direct communication)
2. Resolve the DID to its DID Document (via IPFS)
3. Retrieve the Human Existence Record
4. Verify the three vouching attestation signatures
5. Follow the vouching chain back to anchored DIDs
6. Verify the Bitcoin anchoring transactions via RGB Protocol

The entire chain is trustlessly verifiable -- no phone call to an authority, no database lookup, no trusted third party.

Recovery

Key loss is addressed through Shamir Secret Sharing:

• The recovery seed is split into N shares (e.g., 5)
• Any M shares (e.g., 3) can reconstruct the seed
• Shares are distributed to trusted vouchers and/or stored in geographically separated locations
• Recovery requires a threshold of cooperation, preventing single-point compromise
• A new ring can be provisioned with the recovered seed, and the DID Document updated via a key rotation transition

Privacy Architecture

OMXUS DIDs implement privacy at every layer:

Layer	Privacy Mechanism	What It Prevents
Identity creation	No central registry; peer-to-peer vouching	Mass surveillance; identity database breaches
Authentication	Zero-knowledge proof of identity	Tracking across services
Voting	Encrypted individual votes; aggregated tallies	Vote buying; voter intimidation; government retaliation
Communication	Yggdrasil encrypted overlay	Network surveillance; traffic analysis
Data storage	User-held encrypted data on IPFS	Centralised data breaches
Anchoring	RGB client-side validation	Blockchain analysis of identity activity

See Also

• Sybil Resistance
• RGB Protocol
• Technical Architecture
• Mesh Networks
• Voting
• Getting Started
• Main Page