xID: Unlinkable Digital Identity

Executive Summary

xID gives every user an unlinkable digital identity wallet. Per-verifier ephemeral DIDs ensure that a pharmacy, a bar, and a bank all see completely different identities from the same holder. Self-converging identity means the master seed never exists at rest — it reconverges from K-of-N independent signals only when needed, exists for ~50 microseconds, then is purged.

The world mandated digital identity wallets. The frameworks they built are broken. A 2025 formal privacy evaluation confirmed that eIDAS 2.0's Architecture Reference Framework fails to achieve unlinkability — the single most important privacy property for 450 million citizens. SD-JWT leaks static vct claims. BBS+ anchors to persistent issuer signatures. Every revocation status check reveals which credential is being verified. Static seeds stored in keychains are permanent compromise targets.

xID fixes all four correlation vectors. Ephemeral identity derives per-verifier, per-epoch DIDs from an HKDF-SHA256 derivation tree. Self-converging identity ensures the master seed is never stored — it exists only as K-of-N XorIDA shares distributed across independent signal channels (biometric, device, credential, knowledge, hardware token, push auth, behavioral, location). Any K-1 shares reveal zero information (information-theoretic security, not computational). The seed reconverges in volatile memory for ~50 microseconds per presentation, derives the ephemeral DID, and is immediately purged.

Zero configuration out of the box. Zero npm runtime dependencies. Runs anywhere the Web Crypto API is available — Node.js, Deno, Bun, Cloudflare Workers, browsers.

Developer Experience

xID provides real-time progress tracking and 50+ structured error codes to help developers build reliable, privacy-preserving identity systems.

Progress Callbacks

All long-running operations (unlinkablePresent, backupWallet, restoreWallet) support onProgress callbacks for tracking multi-step pipelines, especially useful for self-convergence where K-of-N signal channels must respond before the seed reconverges.

const result = await unlinkablePresent({
  masterSeed,
  credentialShares,
  requestedAttributes: ['dateOfBirth', 'nationality'],
  context: { verifierId, scope, epoch },
  consentCallback: async () => userApproved,
  onProgress: async (event) => {
    switch (event.stage) {
      case 'reconstructing':
        console.log('Reconstructing master seed...');
        break;
      case 'deriving':
        console.log('Deriving ephemeral DID...');
        break;
      case 'signing':
        console.log('Signing with ephemeral key...');
        break;
      case 'purging':
        console.log('Purging key material...');
        break;
      case 'complete':
        console.log('Presentation ready');
        break;
    }
  }
});

Structured Error Handling

xID uses a Result<T, E> pattern with detailed error structures. Every error includes a machine-readable code, human-readable message, actionable hint, and documentation URL.

interface ErrorDetail {
  code: string;         // e.g., 'INVALID_CONTEXT'
  message: string;      // Human-readable description
  hint?: string;        // Actionable suggestion
  field?: string;       // Field that caused the error
  docs?: string;        // Documentation URL
}

Error Categories

xID organizes 50+ error codes across 8 categories, making it easy to handle errors systematically:

Fast Onboarding: 3 Acceleration Levels

Traditional identity setups require manual DID generation, key management, and trust registry configuration. xID collapses this to 15 seconds with zero-click accept, one-line CLI, and one-click deploy buttons.

// .env file
XID_INVITE_CODE=XID-abc123

// Auto-accept on first use
import { deriveContextDid } from '@private.me/xid';

const ephemeral = await deriveContextDid(
  masterSeed,
  { verifierId, scope, epoch }
);
//  Invite auto-accepted, ready to use

# Install and initialize
npx @private.me/xid init

# Output:
#  Master seed generated
#  Saved to .env (XID_MASTER_SEED)
#  Ready to derive ephemeral DIDs

# Use immediately
const ephemeral = await deriveContextDid(
  masterSeed,
  { verifierId, scope, epoch }
);

# Node.js TypeScript starter
packages/xid/templates/node-typescript/

# Vercel Edge Function
packages/xid/templates/vercel/

# Multi-platform starter
packages/xid/templates/github-starter/

Setup Time Comparison

Example: Zero-Click Accept

Set invite code in environment, derive ephemeral DID on first use. No manual setup required.

// 1. Set environment variable
// .env file:
XID_INVITE_CODE=https://xid.private.me/invite/XID-abc123

// 2. Derive ephemeral DID (auto-accepts invite)
import { deriveContextDid } from '@private.me/xid';

const masterSeed = new Uint8Array(32);
crypto.getRandomValues(masterSeed);

const result = await deriveContextDid(
  masterSeed,
  {
    verifierId: 'did:key:z6Mk...',
    scope: 'login',
    epoch: 0,
  }
);

if (result.ok) {
  console.log('Ephemeral DID:', result.value.did);
  //  Invite auto-accepted in background
  //  Ready to use immediately
}

// CRITICAL: Purge master seed after use
masterSeed.fill(0);

Templates

All three templates included in packages/xid/templates/:

• node-typescript/ — Node.js/Deno/Bun TypeScript starter with zero-click accept
• vercel/ — Vercel Edge Function with ephemeral DID API endpoints
• github-starter/ — Multi-platform starter with deploy buttons for Vercel/Netlify/Railway

Identity Architecture: Where xID Fits

xID is Layer 2 (unlinkability) in a three-layer identity architecture. Layer 1 (Xlink) provides the authenticated communication foundation. Layer 2 (xID) adds ephemeral, per-verifier identity. Layer 3 (Xfuse) adds high-assurance K-of-N convergence from multiple identity signals.

Three-Layer Stack

Digital identity requires three distinct capabilities: secure communication, unlinkable presentation, and high-assurance verification. Each layer builds on the one below it.

When to Use xID vs Xlink-Only

Many applications need authenticated communication but do not require unlinkable identity. The table below clarifies when to add xID on top of Xlink.

xID + Xlink Integration Example

Below is a complete healthcare prescription verification flow showing how xID's ephemeral DIDs compose with Xlink's authenticated messaging.

import { Agent } from '@private.me/xlink';
import { unlinkablePresent } from '@private.me/xid';

// Layer 1: Create authenticated Xlink agent (pharmacy)
const pharmacyAgent = await Agent.fromSeed(pharmacySeed);

// Layer 2: Derive ephemeral DID for this specific pharmacy
const ephemeralDID = await unlinkablePresent({
  masterSeed: patientMasterSeed,
  credentialShares,
  requestedAttributes: ['dateOfBirth', 'prescriptionID'],
  context: {
    verifierId: pharmacyAgent.did,  // Scoped to pharmacy's DID
    scope: 'rx-verification',
    epoch: getCurrentEpoch()       // Rotates daily
  },
  consentCallback: async () => true
});

// Layer 1: Send credential presentation via Xlink's authenticated channel
const result = await pharmacyAgent.sendSecure({
  recipientDID: prescribingDoctorDID,
  payload: {
    ephemeralDID: ephemeralDID.did,       // Pharmacy-specific DID
    presentation: ephemeralDID.presentation,
    signature: ephemeralDID.signature
  }
});

// Result: Doctor sees patient's ephemeral DID for THIS pharmacy only.
// Different pharmacy = different DID. Tomorrow's epoch = new DID.
// Xlink ensures the message's integrity and authenticity.

Layer Benefits Summary

Layer 1 (Xlink): Authenticated communication via DIDs, XorIDA threshold splitting, end-to-end integrity, multi-transport routing, nonce-based replay protection, trust registry, scope-based authorization.

Layer 2 (xID): Per-verifier ephemeral DIDs, HKDF-derived identity scoping, temporal epoch rotation, ~50µs seed exposure, self-converging K-of-N identity, ISO 24745 cancelable biometrics, eIDAS 2.0 unlinkability.

Layer 3 (Xfuse): K-of-N threshold identity convergence from 8 signal types (biometric, device, credential, knowledge, hardware token, push auth, behavioral, location), IAL1/2/3 assurance levels, continuous refresh, adaptive refinement, atomic pipeline, NIST AAL3 compliance.

The Problem: Digital Identity's Privacy Paradox

eIDAS 2.0 mandates digital identity wallets for 450 million EU citizens by 2026. The regulation explicitly requires privacy-preserving presentations. The frameworks being built to deliver it cannot achieve this requirement.

A 2025 formal privacy evaluation of the eIDAS 2.0 Architecture Reference Framework (ARF) found what cryptographers suspected: "the ARF fails to achieve unlinkability due to linkable cryptographic metadata." An 80+ organization coalition has raised concerns. The gap is not a configuration issue — it is architectural.

Four Correlation Vectors

Current identity frameworks leak correlation through four independent channels. Each alone is sufficient for behavioral profiling at scale. Combined, they make unlinkability impossible.

1. Static DIDs. SD-JWT credentials carry a static vct (verifiable credential type) claim and bind to a persistent holder DID. Every verifier sees the same identifier. A pharmacy, a bar, and a bank can all correlate the same citizen from three independent presentations.

2. Persistent issuer signatures. BBS+ achieves selective disclosure of attributes but anchors every presentation to the same issuer signature. The cryptographic relationship between disclosed attributes and the base signature is a persistent correlation handle that colluding verifiers can exploit.

3. Revocation tracking. Revocation registries use static credential indices. Every revocation status check reveals which specific credential is being verified, creating a global tracking vector that is independent of the presentation itself.

4. Static identity seeds. Every existing identity wallet stores a master key or seed as a persistent artifact — in keychains, secure enclaves, or encrypted databases. A static seed is a static target. If the device is compromised at any point, the seed is compromised forever. The identity material should never exist at rest.

Competitive Failure Table

No production system ships unlinkable holder identity, unlinkable revocation, post-quantum security, and information-theoretic guarantees together. xID is the first.

The Solution: Ephemeral Identity + Self-Convergence

xID derives per-verifier, per-epoch DIDs from a master seed that never exists at rest. The seed is split into K-of-N XorIDA shares bound to independent signal channels. When identity is needed, K signals reconverge the seed in volatile memory (~50µs), derive the ephemeral DID, and purge all key material.

Three Properties

Per-verifier identity (HKDF derivation). The master seed is reconstructed from threshold shares in volatile memory. HKDF-SHA256 derives a 32-byte seed scoped to the verifier's DID, a context string, and the current epoch. An Ed25519 keypair is generated from this seed. The resulting DID is cryptographically independent from all other derived DIDs — a pharmacy and a bank see completely different identities from the same holder.

Temporal unlinkability (epoch rotation). When the epoch advances, all derived DIDs rotate automatically. A verifier who saw DID-A in epoch 3 sees DID-B in epoch 4 for the same holder. The derivation is deterministic within an epoch (enabling session continuity) but unlinkable across epochs. Default epoch: 24 hours.

IT-secure seed protection (self-convergence). The master identity seed is never stored whole. It exists only as K-of-N XorIDA shares distributed across independent signal channels (biometric, device, credential, knowledge, hardware token, push auth, behavioral, location). Any K-1 shares reveal zero information about the seed — not probabilistically, but unconditionally. No quantum computer, no unbounded adversary, no future mathematical breakthrough can extract the seed from fewer than K shares.

Ephemeral Identity Pipeline

Architecture

Three pipelines define the xID architecture: Ephemeral Present (unlinkable disclosure), Self-Convergence (K-of-N seed reconvergence), and Wallet Lifecycle (backup/restore).

Ephemeral Present Pipeline

Self-Convergence Pipeline

Your identity seed never exists at rest. Like Face ID's 30,000 IR dots converging into one recognition, xID reconverges your master seed from K-of-N independent signal channels every time identity is needed. Below threshold = zero information. Seed exists only during derivation (~50µs), then is purged.

Signal Type Taxonomy

Identity Assurance Levels

Wallet Lifecycle

Identity

xID uses did:key for all identity representations. Ephemeral DIDs are Ed25519-based. Self-convergence signals can use any cryptographic binding appropriate to the channel type.

DID Method

All xID identities use the did:key method. For ephemeral DIDs derived from Ed25519 keys, the format is did:key:z6Mk... (multicodec 0xed for Ed25519). This ensures maximum interoperability with existing verifiable credential ecosystems while maintaining unlinkability through per-verifier derivation.

Derivation Tree

The ephemeral DID derivation uses a three-level HKDF tree:

Level 1 (Master): XorIDA-reconstructed master seed (32 bytes, never persisted).

Level 2 (Context): HKDF-SHA256 with info = verifierId || scope || epoch. Produces a 32-byte context seed.

Level 3 (Keypair): Ed25519 keypair generation from context seed via standard RFC 8032 derivation.

import { deriveContextDid, computeCurrentEpoch } from '@private.me/xid';

// Compute current epoch (24-hour rotation by default)
const epoch = computeCurrentEpoch(86_400_000);

// Derive ephemeral DID for specific verifier + scope + epoch
const result = await deriveContextDid(masterSeed, {
  verifierId: 'did:key:z6MkVerifier123...',
  scope: 'age-verification',
  epoch,
});

if (result.ok) {
  console.log(result.value.did); // did:key:z6MkEphemeral456...
  console.log(result.value.expiresAt); // End of current epoch
}

Complete Flow

From wallet creation to unlinkable presentation, here is the full xID lifecycle.

1. Wallet Initialization

import { createWallet } from '@private.me/xid';

const result = createWallet({
  ownerDid: 'did:key:z6MkOwner...',
  name: 'Personal Identity Wallet',
});

if (result.ok) {
  const wallet = result.value;
  console.log(wallet.credentials.length); // 0 (empty)
}

2. Import Credential

import { importCredential } from '@private.me/xid';

const result = await importCredential(
  wallet,
  credentialData, // Raw credential payload
  verifySignature, // Issuer signature verification function
);

if (result.ok) {
  console.log(result.value.category); // Auto-detected: 'government', 'education', etc.
}

3. Ephemeral Presentation

import { unlinkablePresent, computeCurrentEpoch } from '@private.me/xid';

const epoch = computeCurrentEpoch(86_400_000);

const result = await unlinkablePresent(
  masterSeed,
  credentialShares,
  ['dateOfBirth', 'nationality'], // Requested attributes
  {
    verifierId: 'did:key:z6MkVerifier...',
    scope: 'age-check',
    epoch,
  },
  async (req) => {
    // Consent callback — show UI to user
    return await showConsentDialog(req);
  },
);

if (result.ok) {
  const { presentation, ephemeralDid, derivationProof } = result.value;
  // Send presentation to verifier
  // ephemeralDid is unique to this verifier + epoch
}

4. Wallet Backup

import { backupWallet } from '@private.me/xid';

const result = await backupWallet(wallet, { k: 2, n: 3 });

if (result.ok) {
  const [share0, share1, share2] = result.value;
  // Store shares independently (cloud, device, paper)
  // Any 2 shares can restore the wallet
}

5. Wallet Restore

import { restoreWallet } from '@private.me/xid';

const result = await restoreWallet([share0, share2]);

if (result.ok) {
  const restoredWallet = result.value;
  // Byte-identical to original
  // HMAC-verified before reconstruction
}

Integration

xID integrates with existing verifiable credential ecosystems through standard interfaces. Ephemeral identity is an opt-in enhancement that requires no changes to verifiers.

Credential Formats

xID supports multiple credential formats through auto-detection during import:

• SD-JWT (RFC 7519 + selective disclosure)
• W3C Verifiable Credentials (JSON-LD with proof)
• ISO mDL (18013-5 mobile driving license)
• Custom formats (user-provided parser + verifier)

Presentation Protocols

xID presentations are compatible with:

• OpenID4VP (presentation request/response)
• DIDComm (encrypted message transport)
• CHAPI (Credential Handler API for web browsers)

Verifier Requirements

To accept ephemeral identity presentations, verifiers need:

1. DID resolution — Ability to resolve did:key to Ed25519 public key.

2. Signature verification — Standard Ed25519 signature verification.

3. Derivation proof validation (optional) — Verify HMAC derivation proof if binding to master identity is required.

Use Cases

Five verticals where unlinkable identity transforms regulatory compliance from a liability into a competitive advantage.

Benchmarks

The ephemeral identity pipeline completes in approximately 50 microseconds. Every step is measured. No other production system achieves unlinkable presentations at this latency.

Pipeline Breakdown

Competitor Comparison

xID is 10,000x faster than Phoenix and 40–100x faster than BBS+ for unlinkable presentations. The performance advantage comes from not requiring pairing-based cryptography, lattice operations, or zero-knowledge proof generation. XorIDA reconstruction is a GF(2) XOR operation — the fastest possible mathematical operation on binary data.

Limitations

xID achieves unlinkability through ephemeral DIDs and information-theoretic seed protection. These guarantees come with honest constraints.

What xID Does NOT Provide

1. Unlinkable Credential Issuance

xID does not obscure the relationship between holder and issuer at credential issuance time. The issuer knows which holder received the credential. Blinded issuance protocols (e.g., Privacy Pass, RSA blind signatures) are orthogonal to xID and can be layered on top.

2. Attribute-Level Unlinkability Across Presentations

If two presentations to different verifiers disclose identical rare attributes (e.g., "born 1987-03-14, nationality: Liechtenstein"), those presentations may be correlatable even with different ephemeral DIDs. The holder must use selective disclosure strategically to avoid leaking unique identifying information.

3. Protection Against Verifier Collusion

If verifiers collude and share disclosed attribute sets, they can correlate presentations through attribute intersection even with ephemeral DIDs. xID prevents passive surveillance but does not prevent active conspiracy. Defense: minimize attribute disclosure, use derived credentials where possible.

4. Protection Against Biometric Replay

Cancelable biometric templates (ISO 24745) protect against cross-context correlation but do not prevent replay attacks where an attacker captures a biometric sample and replays it to the same verifier. Liveness detection and challenge-response protocols are required at the signal collection layer.

5. Protection Against Device Compromise During Presentation

If an attacker compromises the device (malware, physical access) during the ~50µs window when the master seed is in volatile memory, the seed can be exfiltrated. The ~50µs exposure window is 7 orders of magnitude smaller than static seed storage, but it is not zero.

Deployment Considerations

Epoch Rotation Trade-Off

Shorter epochs (e.g., 1 hour) increase temporal unlinkability but break session continuity for long-lived interactions. Longer epochs (e.g., 7 days) improve session continuity but reduce temporal unlinkability. Default 24 hours balances both. The optimal epoch length depends on the use case.

Signal Channel Reliability

Self-convergence requires K-of-N signal channels to respond within the convergence window (default 30 seconds). Unreliable signals (e.g., network-dependent location checks, slow biometric scanners) can cause convergence failures. The system degrades to lower assurance levels if fewer signals respond, but requires minimum K to succeed.

Revocation Unlinkability Is Probabilistic

xID uses blinded revocation status checks where the holder queries a revocation registry with a salted hash of their credential ID rather than the ID itself. This achieves unlinkability against honest-but-curious revocation servers. A malicious revocation server that logs all queries and brute-forces credential IDs can still correlate. Full unlinkability requires cryptographic accumulators or zero-knowledge set membership proofs (future work).

Regulatory Compliance

xID maps directly to three major regulatory frameworks: eIDAS 2.0 (EU digital identity), GDPR Article 9 (special category data), and NIST SP 800-63A (digital identity guidelines).

eIDAS 2.0 Architecture Reference Framework

The eIDAS 2.0 regulation (EU 2024/1183) requires Member States to offer digital identity wallets to all citizens by 2026. Article 5a explicitly mandates that wallets must enable "pseudonymous authentication where the user can be authenticated without the authentication necessarily entailing the identification of the user."

The Architecture Reference Framework (ARF) published by the European Commission provides technical guidance. However, a 2025 formal privacy evaluation by academic researchers found that "the ARF fails to achieve unlinkability due to linkable cryptographic metadata." The static vct claims in SD-JWT credentials, the persistent issuer signatures in BBS+ proofs, and the static credential indices in revocation registries all create correlation vectors.

xID fills the gap. Ephemeral DIDs provide the pseudonymous authentication that Article 5a requires. A citizen presenting their driver's license to a pharmacy, a bar, and a bank uses three cryptographically independent identities. Epoch rotation ensures temporal unlinkability. The derivation schedule (which verifiers the holder has interacted with) is XorIDA-split to prevent surveillance of the holder's relationship graph.

GDPR Article 9 — Special Category Data

GDPR Article 9 prohibits processing of biometric data unless explicit consent is given or a legal basis exists. Traditional identity systems store biometric templates as persistent identifiers — a single breach compromises the biometric for life.

xID's ISO 24745 cancelable biometric templates address this. The raw biometric is never stored. An HMAC-SHA256 non-invertible transform with a context-specific transform seed produces a 32-byte template. Same biometric, different context = different template. On compromise: generate a new transform seed, re-transform, increment version. The old template becomes cryptographically useless. This satisfies GDPR's requirement for data minimization and the right to erasure.

NIST SP 800-63A — Identity Assurance Levels

NIST Special Publication 800-63A defines three Identity Assurance Levels (IAL) based on the evidence collected and verified during identity proofing:

• IAL1 (Self-asserted) — No identity verification required.
• IAL2 (Remote or in-person) — Evidence supports real-world identity. Remote verification allowed.
• IAL3 (In-person or supervised remote) — Physical presence before trained operator. Biometric collection.

xID's self-convergence architecture maps IAL levels to signal diversity requirements. IAL1 = 2-of-3 (device + knowledge). IAL2 = 3-of-5 (device + credential + knowledge, 2 distinct types). IAL3 = 4-of-7 (biometric + device + credential + hardware token, 3 distinct types, biometric required). Higher assurance = more signals, greater diversity.

Cross-ACI Integration

xID is a platform building block. It composes with other ACIs to deliver complete solutions.

Xlink (Secure M2M)

xID provides unlinkable holder identity. Xlink (@private.me/xlink) provides cryptographic agent identity and encrypted message transport. Together: ephemeral identity agents that present credentials over XorIDA-split channels. Use case: IoT devices presenting device credentials to cloud services with per-service unlinkable DIDs.

Xprove (Verifiable Computation)

xID ensures unlinkable presentations. Xprove (@private.me/xprove) proves that a presentation was computed correctly without revealing the computation inputs. Together: unlinkable presentations with cryptographic proof of policy compliance. Use case: proving "age ≥ 21" without revealing exact birthdate, with zero-knowledge proof that the age calculation was performed correctly.

Xwallet (Verifiable Credentials)

Xwallet (@private.me/xwallet) provides schema registry, issuance workflows, and selective disclosure for verifiable credentials. xID adds ephemeral identity and self-convergence to Xwallet. Together: complete credential lifecycle with unlinkability by default. Use case: enterprise credential issuance where employees present credentials to external verifiers with ephemeral DIDs.

Xfuse (Threshold Identity Fusion)

Xfuse (@private.me/xfuse) orchestrates K-of-N threshold operations across multiple ACIs with atomic execution pipelines. xID's self-convergence is built on Xfuse's convergence primitives. Together: multi-ACI identity workflows with all-or-nothing execution guarantees. Use case: high-assurance authentication that requires 3-of-5 signals (Xid biometric + Xlock push auth + Xpass credential) to converge before granting access.

Error Hierarchy

All xID operations return Result<T, E>. Errors implement a standard ErrorDetail interface:

interface ErrorDetail {
  code: string;         // Machine-readable error code
  message: string;      // Human-readable description
  hint?: string;        // Actionable suggestion for resolution
  field?: string;       // Which field/parameter caused the error
  docs?: string;        // Documentation URL for this error
}

// Example error
{
  code: 'INSUFFICIENT_SIGNALS',
  message: 'Need at least 2 signals for convergence, received 1',
  hint: 'Add another signal channel (biometric, device, or credential)',
  field: 'signals',
  docs: 'https://private.me/docs/xid#errors'
}

Error Taxonomy

50+ error codes across 8 categories. Representative examples:

Wallet Errors

Ephemeral Identity Errors

Self-Convergence Errors

Presentation Errors

Backup/Restore Errors

Full ACI Surface

Complete function inventory. All return Result<T, E>.

Ephemeral Identity

Wallet Lifecycle

Enterprise CLI

@private.me/xid-cli — 26-endpoint management server for enterprise xID deployments. Docker-ready, air-gapped capable.

Capabilities

• Ephemeral DID derivation — Server-side HKDF pipeline with HSM integration
• Self-convergence orchestration — K-of-N signal collection across enterprise signal providers
• Wallet lifecycle management — Backup/restore with enterprise key escrow
• Compliance assessment — Automated eIDAS/NIST/GDPR compliance reporting
• Audit logging — Append-only audit trail for all identity operations
• 3-role RBAC — Admin, Operator, Auditor with least-privilege enforcement

Deployment

# Pull image
docker pull private.me/xid-cli:latest

# Run server (port 4700)
docker run -p 4700:4700 \
  -e XID_ADMIN_DID="did:key:z6Mk..." \
  -e XID_AUDIT_LOG_PATH="/var/log/xid" \
  -v /data/xid:/var/lib/xid \
  private.me/xid-cli:latest

Codebase Stats

xID implementation metrics.

Test Coverage by Category