Architecture

How LastID works. No marketing. Just structure.

Human
  │
  ▼
┌──────────────────┐
│ 01 Root Identity │ ← mnemonic
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ 02 Pairwise DIDs │ ← per verifier
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ 03 Credentials   │ ← SD-JWT
└────────┬─────────┘
         │
    ┌────┴────┐
    ▼         ▼
┌────────┐ ┌────────┐
│04 OIDC │ │ 05 SDK │
└────────┘ └────────┘

Five layers

Each section below explains one layer of the system.

Bottom-up security

Identity starts with the human. Hardware-backed keys. Cryptographic chain of trust.

Standards-based

BIP39. X.509. SD-JWT. OAuth 2.0. OpenID Connect. No proprietary protocols.

Human Root Identity

┌─────────────────────────────────┐
│      24-Word Mnemonic           │
│      (BIP39, 256-bit entropy)   │
└───────────────┬─────────────────┘
                │
                ▼ PBKDF2 + HKDF
┌─────────────────────────────────┐
│       Master Identity           │
│  ┌───────────────────────────┐  │
│  │ P-256 Key Pair            │  │
│  │ X.509 Root Certificate    │  │
│  │ SHA-256 Fingerprint (DID) │  │
│  └───────────────────────────┘  │
│                                 │
│  Never stored on device.        │
│  Recoverable from mnemonic.     │
└───────────────┬─────────────────┘
                │
                ▼ Signs
┌─────────────────────────────────┐
│       Device Identity           │
│  ┌───────────────────────────┐  │
│  │ Hardware-backed key       │  │
│  │ (Secure Enclave/StrongBox)│  │
│  │ X.509 Device Certificate  │  │
│  └───────────────────────────┘  │
│                                 │
│  Private key never leaves HW.   │
│  Handles daily operations.      │
└─────────────────────────────────┘

Offline-recoverable root key

Master identity derived from 24-word mnemonic. Same words, same identity, any device.

Devices are delegated

Master key signs device certificates. Device keys live in hardware, never extracted.

Identity survives compromise

Device stolen? Revoke its certificate, recover identity to new device. Master key untouched.

Pairwise Identifiers

        ┌─────────────────┐
        │  Master DID     │
        │  (internal only)│
        └────────┬────────┘
                 │
    ┌────────────┼────────────┐
    │            │            │
    ▼            ▼            ▼
┌────────┐  ┌────────┐  ┌────────┐
│Pairwise│  │Pairwise│  │Pairwise│
│DID: aaa│  │DID: bbb│  │DID: ccc│
└────┬───┘  └────┬───┘  └────┬───┘
     │           │           │
     ▼           ▼           ▼
┌────────┐  ┌────────┐  ┌────────┐
│ Bank A │  │Telecom │  │ Gov B  │
└────────┘  └────────┘  └────────┘

Bank A sees: did:lastid:aaa...
Telecom sees: did:lastid:bbb...
Gov B sees: did:lastid:ccc...

None can correlate to each other.
Only registry knows the mapping.

No global identifier

Each verifier receives a unique DID. Master identity never exposed externally.

Relationship-scoped identity

Same user + same verifier = same pairwise DID. Deterministic for continuity.

Correlation resistant by default

Verifiers cannot collaborate to track users. Privacy boundary enforced by architecture.

Verifiable Credentials

┌─────────────────────────────────┐
│         LastID.Base             │
│  (device-bound root credential) │
└───────────────┬─────────────────┘
                │
    ┌───────────┼───────────┐
    ▼           ▼           ▼
┌────────┐ ┌────────┐ ┌────────┐
│Persona │ │Persona │ │Persona │
│  Work  │ │Personal│ │  Anon  │
└───┬────┘ └───┬────┘ └───┬────┘
    │          │          │
    ▼          ▼          ▼
┌────────┐ ┌────────┐ ┌────────┐
│Employ- │ │Verified│ │  Age   │
│  ment  │ │ Email  │ │ Proof  │
└────────┘ └────────┘ └────────┘

Format: SD-JWT (selective disclosure)
Signing: ES256 (P-256 ECDSA)
Revocation: W3C Bitstring Status List

Multiple personas, one identity

Work persona for employers. Personal persona for services. Anonymous persona for age-gated content. All rooted to same human.

Context-appropriate disclosure

Present work credentials to employers. Present age proof to venues. Never mix contexts. User controls what goes where.

Cryptographically verifiable

SD-JWT format. Issuer signature. Holder binding. Revocation via status list.

OAuth / OIDC Surface

┌────────────────┐  ┌────────────────┐
│    Browser     │  │   Mobile App   │
│     (RP)       │  │    (Wallet)    │
└───────┬────────┘  └───────┬────────┘
        │                   │
        │ /authorize        │ Scan QR
        ▼                   │
┌───────────────────────────┴────────┐
│           LastID IDP               │
│  ┌──────────────────────────────┐  │
│  │ • OAuth 2.0 + PKCE           │  │
│  │ • OpenID Connect             │  │
│  │ • DPoP token binding         │  │
│  │ • RFC 8485 VoT claims        │  │
│  └──────────────────────────────┘  │
└────────────────────────────────────┘
        │
        │ VP presentation
        ▼
┌────────────────────────────────────┐
│  Token Response                    │
│  • access_token (DPoP-bound)       │
│  • id_token (pairwise sub)         │
│  • vot: "P3.Cf.Mb.Ac"              │
└────────────────────────────────────┘

Standard enterprise integration

OAuth 2.0 authorization code flow. PKCE. Standard token endpoint. Discovery metadata.

Identity verification layered into auth flows

User presents credentials via QR. LastID validates. Returns standard tokens with VoT claims.

Does not replace existing IdP

Adds verification layer. Existing authentication unchanged. Human identity proven on top.

SDK Verification

// TypeScript SDK
import { HumanIDPClient, PersonaPolicy }
  from '@lastid/human-idp-client';

const client = new HumanIDPClient({
  endpoint: 'https://human.lastid.co',
  clientId: 'your_client_id',
});

await client.initialize();

// Request work persona with employment
const policy = new PersonaPolicy()
  .requireDisplayName()
  .requireEmployment()
  .fromIssuer('did:lastid:...');

const { requestUrl } = await
  client.requestCredential(policy);

// Display QR, poll for completion
const status = await
  client.pollForCompletion(requestId);

// Verify the presentation
const result = await
  client.verifyPresentation(
    status.presentation
  );

if (result.valid) {
  // result.claims has verified data
}

Policy builders for each credential type

Fluent API for requesting specific claims. Age proofs, employment, verified email, personas. Type-safe, schema-validated.

DPoP authentication

RFC 9449 proof-of-possession tokens. No client secrets. Ephemeral key pairs. Replay-resistant.

TypeScript now. Rust and Go coming.

Full SDK for Node.js, Edge, and browser. Native SDKs for mobile and backend in development.

Standards

Identity
├─ BIP39 (mnemonic generation)
├─ PBKDF2 + HKDF (key derivation)
├─ P-256 / secp256r1 (ECDSA)
└─ X.509 (certificate chain)

Credentials
├─ SD-JWT (selective disclosure)
├─ ES256 (JWT signing)
├─ W3C Bitstring Status List
└─ OpenID4VCI (issuance)

Verification
├─ OpenID4VP (presentation)
├─ DPoP RFC 9449 (token binding)
└─ RFC 7800 cnf (holder binding)

Integration
├─ OAuth 2.0 + PKCE
├─ OpenID Connect
└─ RFC 8485 VoT (assurance)

No proprietary protocols

Every component uses published standards. RFCs, W3C specs, IETF drafts. Auditable. Interoperable.

Hardware security where available

Secure Enclave on iOS. StrongBox on Android. TPM on Windows. Keys never extracted from hardware.

Cryptographic agility

P-256 today. Architecture supports algorithm migration. No vendor lock-in on primitives.