xID: Unlinkable Digital Identity

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.

Three Correlation Vectors

Current identity frameworks leak correlation through three 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 by Default

xID derives per-verifier, per-epoch DIDs from a XorIDA-split master identity seed via HKDF-SHA256. Each verifier sees a cryptographically independent identity. Each epoch rotates all identities automatically. The derivation schedule itself is split-protected.

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 (XorIDA). The master identity seed is never stored whole. It exists only as k-of-n XorIDA shares distributed across independent storage locations. 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

Four pipelines define the xID architecture: Import (credential ingestion), Ephemeral Present (unlinkable disclosure), Backup/Restore (XorIDA-split recovery), and Derivation Schedule (split-protected verifier tracking).

Import Pipeline

Ephemeral Present Pipeline

Backup & Restore Pipeline

Split-Protected Derivation Schedule

The record of which verifiers a holder has interacted with is itself XorIDA-split. No single storage location reveals the user's relationship graph. The schedule tracks context hashes (SHA-256 of verifierId + scope), never raw verifier identifiers. On each presentation, the schedule is reconstructed, the context record is updated, and the schedule is re-split.

Self-Converging Identity

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. No seed at rest. Ever.

The Face ID Analogy

Apple's Face ID projects 30,000 infrared dots onto your face. Each dot alone is meaningless. Only when enough dots converge does identity emerge. xID works the same way: your master identity seed is split into N XorIDA shares, each bound to an independent verification channel — biometric, device, credential, knowledge, hardware token, push authentication, behavioral, or location. Only when K-of-N channels respond does the seed reconverge. K-1 shares reveal zero information (information-theoretic security, not computational).

8-Step Convergence Pipeline

Self-convergence is an atomic operation. Either all 8 steps succeed and produce a valid ephemeral identity, or the operation fails and the seed is purged with zero information leakage.

Signal Type Taxonomy

Eight independent signal types ensure that identity convergence draws from diverse verification channels. The more diverse the signals, the higher the assurance level.

Identity Assurance Levels

Self-convergence maps directly to NIST SP 800-63A Identity Assurance Levels based on how many diverse signals participate.

Cancelable Biometric Templates

When biometric signals are configured, xID uses ISO 24745 cancelable biometric templates. Raw biometric data is never stored. Instead, an HMAC-SHA256 non-invertible transform produces a 32-byte template. Same biometric, different transform seed = different template (cross-binding unlinkability). On compromise: generate a new transform seed, re-transform, increment version. The old template becomes cryptographically useless.

Continuous Refresh

Self-convergence supports periodic reconvergence via an opt-in refresh loop. At each configurable interval, xID collects fresh signal responses, performs atomic convergence, derives a new ephemeral DID, and purges the seed. Each refresh produces a fresh identifier uncorrelated with previous iterations. Session continuity is maintained through the same verifier-scope-epoch derivation parameters.

Static Seed vs Self-Converging

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.

Self-Convergence Overhead

The 8-step convergence pipeline adds pre-reconstruction validation (consent, count, window, diversity) and post-reconstruction verification (HMAC, unpad). The overhead is sub-millisecond — dominated by the XorIDA reconstruction itself. The full atomic self-convergence pipeline (converge → derive ephemeral DID → purge) completes in under 100µs including all validation steps.

ACI Surface

Ephemeral identity first, then wallet lifecycle. Every function returns a Result<T, E> — no thrown exceptions.

Ephemeral Identity

Wallet Lifecycle

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

// Derive an ephemeral DID for a specific verifier
const epoch = computeCurrentEpoch(86_400_000); // 24-hour rotation
const did = await deriveContextDid(masterSeed, {
  verifierId: 'did:key:z6MkVerifier...',
  scope: 'age-verification',
  epoch,
});
// did.value.did → unique DID for this verifier + epoch

// Full unlinkable presentation with consent
const result = await unlinkablePresent(
  masterSeed,
  credentialShares,
  ['dateOfBirth', 'nationality'],
  { verifierId: 'did:key:z6MkVerifier...', scope: 'age-check', epoch },
  async () => userApproved,
);
// result.value.ephemeralDid → cryptographically independent from all other DIDs

Use Cases

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

Regulatory Compliance

Ephemeral identity directly satisfies four regulatory frameworks. Each maps to a specific xID capability — not a configuration option, but a structural guarantee.

Cross-ACI Composition

xID composes with four ACIs to form a complete identity infrastructure stack. Each integration is additive — xID works standalone, and each composition unlocks new capabilities.

Security Properties

xID enforces ten security properties by construction — six from the base wallet and four from ephemeral identity. Every property is tested and verifiable.

Core Guarantees

Ephemeral Identity Properties

Traditional Wallet vs. xID

Verifiable Identity Operations

Every xID operation — import, present, backup, restore, ephemeral derivation — produces integrity artifacts that xProve can chain into a verifiable audit trail. Prove that credentials were handled correctly without revealing the credentials themselves.

Limitations

Honest engineering requires honest documentation. Five known limitations with their mitigations.

Enterprise CLI

@private.me/xid-cli is a self-hosted identity wallet management server — Docker-ready, air-gapped capable, with three-role RBAC, ephemeral identity management, self-convergence endpoints, and append-only audit logging.

Endpoints

RBAC Roles

Admin — full access: wallets, credentials, presentations, lifecycle, backups, eIDAS, ephemeral, API keys, audit.
Operator — wallets, credentials (import/list/get), presentations, lifecycle, backups, eIDAS, ephemeral.
Auditor — read-only: wallet list, credentials, lifecycle, backup list, eIDAS checks, audit logs.

docker build -t xid-cli -f packages/xid-cli/Dockerfile .
docker run -d --name xid -p 4700:4700 \
  -v xid-data:/data \
  -e XID_ADMIN_KEY=your-secret-key \
  xid-cli

Get Started

Install xID, derive your first ephemeral identity, and present credentials unlinkably — all in a few lines of code.

npm install @private.me/xid

import {
  createWallet,
  importCredential,
  deriveContextDid,
  unlinkablePresent,
  computeCurrentEpoch,
  backupWallet,
} from '@private.me/xid';

// 1. Create a wallet
const wallet = createWallet({ ownerDid: 'did:key:z6Mk...' });

// 2. Import a credential (auto-categorized)
const withCred = await importCredential(
  wallet.value,
  { credential: passportVC, shares },
  verifySignature
);

// 3. Derive an ephemeral DID for a specific verifier
const epoch = computeCurrentEpoch(86_400_000);
const ephemeral = await deriveContextDid(masterSeed, {
  verifierId: 'did:key:z6MkBank...',
  scope: 'kyc-check',
  epoch,
});

// 4. Present unlinkably (consent required)
const presentation = await unlinkablePresent(
  masterSeed, credentialShares,
  ['fullName', 'dateOfBirth'],
  { verifierId: 'did:key:z6MkBank...', scope: 'kyc-check', epoch },
  async () => promptUser(),
);

// 5. Backup wallet (2-of-3 XorIDA split)
const backupShares = await backupWallet(withCred.value);

Ready to deploy xID?

Talk to Sol, our AI platform engineer, or book a live demo with our team.