Internal Technical Specification · Premium Product Architecture · Tangem Ring · Multi-Partition Identity
A premium, four-partition identity vault that isolates government & healthcare credentials, financial identity, developer secrets, and recovery keys in cryptographically separate compartments — all unlocked by a single Tangem Ring NFC tap. CVS Health and all healthcare partners see only Partition 0 via scoped zero-knowledge proofs. Partitions 1–3 are cryptographically invisible to any external party. Now with Unstoppable Domains anchoring each partition's user-facing identity: P0 uses saludcap.x as the healthcare identity string at MinuteClinic, P1 uses saludcap.bitcoin for financial addressing, P2 anchors “Login with Unstoppable” OAuth, and P3 stores guardian UD domains for recovery coordination.
01 Core Concept
Standard SaludID stores a single healthcare credential set, partially visible to CVS Health via scoped access. SaludID Plus is an entirely different product: a sovereign identity vault with four cryptographically isolated partitions, each encrypted with a different child key derived from the Tangem ring's EAL6+ master hardware key via BIP-32 hardened derivation. No partition can reveal any information about any other partition. CVS Health and all healthcare partners see only Partition 0 — and cannot even detect the existence of Partitions 1, 2, or 3.
Each partition derives its signing and encryption keys from the ring’s EAL6+ secure element using BIP-32 hardened derivation: m/44'/7231'/partition'. Hardened derivation means a compromise of any child key — even when paired with the parent’s extended public key — cannot reveal the parent key or any sibling partition key. This is the same mathematical property that lets HD wallets share public keys without exposing private keys. Each partition is a cryptographic island. CVS gets a scoped zero-knowledge presentation from Partition 0 only. They receive no signal that other partitions exist.
02 Four-Partition Architecture
The single most painful gap in digital credential management for seniors is the "death problem" — when a spouse dies, digital assets, credentials, and healthcare proxies are inaccessible. Partition 3 solves this with a time-locked guardian protocol: three trusted family members each hold a Shamir Secret Sharing shard. After a configurable absence period (e.g., 90 days of inactivity), the guardians collectively unlock Partition 3 to access estate documents, the healthcare proxy, and legacy credentials. The ring cannot die — the EAL6+ chip has a 25-year rated lifespan. The Chainlink Automation trigger fires only after guardian quorum + absence threshold are both met.
03 BIP-32 Hierarchical Key Derivation
UD domains are user-facing identity labels mapped to addresses. They sit entirely above the BIP-32 hardware layer. A UD domain does not derive from any partition key and cannot reveal any key material. Leaking saludcap.bitcoin (P1 label) reveals only a BTC address — it reveals zero information about P0, P2, or P3 keys. The BIP-32 hardened isolation guarantee is fully preserved.
BIP-32 hierarchical deterministic key derivation allows one master key (generated inside the Tangem ring’s EAL6+ secure element at first setup and never exported) to deterministically produce child keys for each partition. The critical property for SaludID Plus is hardened child key derivation — indicated by the apostrophe in the derivation path. A hardened child key cannot have its parent reconstructed even if both the child private key AND the parent’s extended public key are known. This mathematical guarantee means leaking a credential from Partition 2 (developer credentials) reveals nothing about Partition 0 (healthcare) or any other partition.
// Master key generated at ring setup using hardware entropy — NEVER leaves chip MasterKey = HMAC-SHA512("SaludIDPlus", ring_hardware_entropy) // Hardened child keys (apostrophe = hardened = BIP-32 index + 2^31) // A leaked child key + parent xPub CANNOT reconstruct any sibling or parent key P0_key = CKDpriv(MasterKey, 44'/7231'/0') // Healthcare P1_key = CKDpriv(MasterKey, 44'/7231'/1') // Financial P2_key = CKDpriv(MasterKey, 44'/7231'/2') // Credentials P3_key = CKDpriv(MasterKey, 44'/7231'/3') // Recovery // Per-partition purpose sub-keys (also hardened) P0_sign_key = CKDpriv(P0_key, 0') // Signs W3C Verifiable Presentations for CVS/CMS P0_enc_key = HKDF(P0_key, "P0_ENC_v1") // AES-256-GCM encrypts P0 data on chip + IPFS P2_fido2_key = CKDpriv(P2_key, 0') // FIDO2/WebAuthn CTAP2 authenticator key P2_ssh_key = CKDpriv(P2_key, 1') // Ed25519 SSH signing key (deterministic) P2_gpg_key = CKDpriv(P2_key, 2') // GPG / code-signing certificate key P2_api_key = HKDF(P2_key, "P2_API_v1") // AES-256 encrypts stored API keys in IPFS vault // ISOLATION GUARANTEE (mathematical, not policy): // Know P1_key + MasterKey extended public key? Cannot derive P0, P2, P3, or MasterKey. // CVS/Aetna receive: ZK proof signed by P0_sign_key only. Zero key material shared. // Partitions 1/2/3 existence: cryptographically undetectable from P0 ZK proof.
| Partition | Derivation Path | Visible to Partners? | Key Usage | Data Location |
|---|---|---|---|---|
| P0 Healthcare | m/44'/7231'/0' | ZK scoped only | Sign W3C VP for CVS / CMS / ID.me | Ring chip + IPFS (encrypted) |
| P1 Financial | m/44'/7231'/1' | Never | Decrypt bank/brokerage tokens; crypto xPubs | Ring chip ONLY (no IPFS) |
| P2 Credentials | m/44'/7231'/2' | Never | FIDO2 authenticator; SSH; GPG; API key decrypt | Ring chip + IPFS (double-encrypted) |
| P3 Recovery | m/44'/7231'/3' | Guardian quorum only | Shamir anchor; estate unlock; healthcare proxy | Ring chip + 3-of-5 guardian shards |
| All key derivation occurs inside the EAL6+ chip. No key material transits to phone, app, or network. Chip is the trust root. | ||||
04 ERC-7231 On-Chain Token
The on-chain ERC-7231 token stores zero personal data. For each active partition, it records a commitment hash — proof that the partition data exists and is authentic (signed by the ring) without revealing any data. Healthcare partners can verify a valid P0 credential exists by checking the commitment against a ZK proof. They cannot determine whether P1, P2, or P3 partitions exist.
struct PartitionCommitment { bytes32 commitmentHash; // keccak256(partition || ring_addr || data_hash || nonce) uint64 lastUpdated; // Unix timestamp of last partition data update uint8 schemaVersion; // Credential schema version (forward compatibility) bool active; // Is this partition provisioned? } struct IdentityRecord { PartitionCommitment p0_healthcare; // P0: only partition with authorized access // P1/P2/P3: existence not publicly confirmable — double-blinded bytes32 p1_blinded; // keccak256(P1_commitment || ring_salt) — unlinkable to content bytes32 p2_blinded; // keccak256(P2_commitment || ring_salt) bytes32 p3_blinded; // keccak256(P3_commitment || ring_salt) address ringAddress; // Tangem ring's ERC-4337 smart account address bytes32 ringFingerprint; // keccak256(ring_public_key) — verifies hardware binding bool premiumTier; // True = all 4 partitions active } // P0 healthcare ZK verification — the ONLY function external partners can call function verifyHealthcareCredential( uint256 tokenId, bytes calldata zkProof, // ZK: "ring holds valid P0 credential matching commitment" bytes32 requestedClaim // Which claim (e.g. "medicare_part_b_enrolled") ) external view returns (bool valid, uint64 proofExpiry) { PartitionCommitment storage p0 = identities[tokenId].p0_healthcare; require(p0.active, "P0 not provisioned"); valid = IZKVerifier(zkVerifier).verifyPartitionClaim( p0.commitmentHash, requestedClaim, zkProof ); proofExpiry = uint64(block.timestamp) + 900; // 15-minute proof window } // P1/P2/P3: NO public function exists to confirm their state or content // Private partition access: ring holder only, via NFC signing session // ERC-5192 lock — SaludID Plus is NEVER transferable function locked(uint256) external pure returns (bool) { return true; } // Guardian recovery — P3 unlock after absence period + 3-of-5 shard quorum function initiateGuardianRecovery(uint256 tokenId, bytes32[3] calldata shards) external { require(block.timestamp > identities[tokenId].lastActivity + ABSENCE_THRESHOLD); // Validate Shamir reconstruction, emit RecoveryInitiated, off-chain P3 decrypt begins }
05 FIDO2 / WebAuthn Bridge — The Ring as Universal Security Key
The Tangem ring’s EAL6+ chip speaks CTAP2 (Client to Authenticator Protocol v2) over NFC — the same protocol that YubiKey and other FIDO2 security keys use. This means the ring can natively register as a FIDO2 roaming authenticator at any WebAuthn-enabled service. The P2 partition key signs authentication challenges. Users simply tap their ring near an NFC reader or their phone.
When the user taps their SaludID Plus ring near an iPhone or desktop NFC reader, the ring responds to CTAP2 challenges over NFC. Every service that supports WebAuthn (Google, Apple, Microsoft, GitHub, AWS console, Cloudflare, and 800+ others) sees a FIDO2 security key. The ring’s P2 signing key signs the authentication challenge inside the EAL6+ chip. The user just taps. No password, no 2FA app, no authenticator code — one ring tap.
| Platform / Service | P0 Healthcare | P1 Financial | P2 Credentials | Integration Method |
|---|---|---|---|---|
| Google Password Manager | Invisible | Invisible | Yes — passkey anchor | WebAuthn API: ring registered as Google account FIDO2 security key / passkey backup |
| Apple Keychain / iCloud | Invisible | Invisible | Yes — passkey anchor | iOS WebAuthn API: ring tap authenticates to iCloud Keychain. Same NFC position as Apple Pay. |
| 1Password | Invisible | Invisible | Yes — FIDO2 MFA | 1Password FIDO2 key registration: ring tap = vault unlock. Removes master password dependency. |
| Bitwarden | Invisible | Invisible | Yes — WebAuthn 2FA | Bitwarden Premium WebAuthn: ring registered as security key. NFC tap = Bitwarden auth. |
| Microsoft Entra ID | Invisible | Invisible | Yes — AAL3 | NIST AAL3 phishing-resistant auth. Ring registered in Entra FIDO2 policy. Enterprise SSO via ring tap. |
| GitHub / GitLab | Invisible | Invisible | Yes — passkey + SSH | FIDO2 passkey for web login. SSH key: Ed25519 derived from m/44'/7231'/2'/1' — deterministic, registerable at GitHub. |
| AWS / GCP / Azure CLI | Invisible | Invisible | Yes — agent bridge | Desktop credential agent: ring tap → decrypt session credentials from P2 vault → inject to CLI for 15 min → auto-expire. |
| CVS Health / Aetna | ZK scoped only | Invisible | Invisible | CVS sees only ZK proof from P0. P1 and P2 are cryptographically undetectable from P0 access. |
| Medicare.gov (ID.me) | P0 ZK + OAuth | Invisible | Invisible | P0 stores ID.me OIDC token + CMS-verified MBI hash. Ring tap authenticates to Medicare.gov. |
| Bank / Brokerage (Plaid) | Invisible | P1 OAuth token | Invisible | P1 stores Plaid OAuth refresh tokens encrypted with P1 key. Ring tap decrypts for account access. |
For developers, the most transformative Partition 2 feature is the desktop credential agent: a lightweight daemon (macOS, Windows, Linux) that intercepts credential access patterns and injects API keys from the ring’s encrypted vault on demand. AWS access keys never sit in ~/.aws/credentials. GitHub tokens never live in .env files. Nothing persists on disk after the session ends.
def credential_request_flow(service_name, cred_type): # 1. Agent intercepts service request (git push, aws s3 ls, docker push) challenge = generate_challenge(service_name, cred_type) # 2. Send NFC challenge to ring via phone BLE bridge # User sees notification: "Tap ring to approve AWS credentials" ring_sig = tangem_sdk.sign_nfc(challenge, partition=2, path="m/44'/7231'/2'/0'") # 3. Derive AES-256-GCM decryption key from ring signature + service context dk = HKDF(ring_sig.signature, label="P2_API_" + service_name) # 4. Fetch + decrypt credential from IPFS encrypted vault enc_cred = ipfs.get(P2_vault_manifest[service_name]) credential = AES256GCM.decrypt(enc_cred, dk) # 5. Inject into OS session for exactly 15 minutes, then wipe inject_to_os_keychain(credential, ttl_seconds=900) # Credential NEVER saved to disk. NEVER in shell history. NEVER in clipboard. # If ring is removed from proximity, session immediately revoked.
The average developer maintains AWS access keys in 3+ places: terminal history, .env files, CI/CD secrets, clipboard. The average executive’s financial credentials live in a password manager behind a master password that can be phished. SaludID Plus replaces the entire credential surface with a ring tap. One touch. 15-minute session. Nothing persists on disk. This is YubiKey + 1Password + AWS Secrets Manager + SSH agent — in a ring — at $15/month above the Salud Vault base plan.
06 Scoped Access Architecture — CVS Cannot See Partitions 1, 2, or 3
Every external access request produces a scoped W3C Verifiable Presentation (VP) revealing only the fields necessary for the specific request, signed by only the relevant partition key — inside the ring’s EAL6+ chip. The signing key never leaves hardware. CVS Health can verify Medicare enrollment without ever receiving a signal that the user holds financial credentials, developer credentials, or a recovery vault.
CVS receives zero information about: MBI value, Medicaid status, financial accounts, developer credentials, or recovery configuration. They cannot determine whether P1/P2/P3 exist.
The on-chain contract exposes only verifyHealthcareCredential() to external callers. All P1/P2/P3 functions are access-controlled to the ring address exclusively.
Challenge: CVS MinuteClinic tablet sends: {service_type, timestamp, clinic_id}. Ring signing (inside EAL6+ chip): Generates Groth16 ZK proof using P0 signing key that proves "this ring holds a valid Medicare enrollment credential matching the on-chain P0 commitment hash." Inputs (private): P0 raw credential data, P0 signing key, nonce. Inputs (public): P0 commitment hash (from chain), requested claim ID, proof expiry timestamp. Output: valid bool + copay amount for service type. CVS verifies proof on-chain against SaludIDPlus.sol. Total flow: ~2–3 seconds from tap to confirmed. MBI, full credentials, and all other partitions: never transmitted, never visible.
07 Build Plan — Claude Chat vs Claude Code Desktop
| Task | Tool | Priority | Deliverable | Effort |
|---|---|---|---|---|
| Phase 1 — Smart Contract + Key Architecture (Weeks 1–10) | ||||
SaludIDPlus.sol — ERC-7231 4-partition token PartitionCommitment struct, P0 ZK verify, P1/P2/P3 blinded hashes, guardian recovery, ERC-5192 lock |
Claude Code | Critical | Hardhat, ERC-7231 base, full contract, 95%+ test coverage, Polygon Amoy deploy — completely separate from SaludID.sol | 8–12 hrs |
BIP-32 hardened partition derivation in Tangem SDK Custom path m/44'/7231'/n' inside TangemSdk.startSession() — keys never leave chip |
Claude Code | Critical | Swift + Kotlin: SaludIDDerivationPath protocol, partition-scoped signing sessions, chip storage layout for 4-partition data, AES-256-GCM encryption per partition using HKDF-derived keys | 10–16 hrs |
ZK proof circuit spec — Groth16 P0 healthcare verifier Circom circuit design: prove P0 claim without revealing credential data or partition key |
Claude Chat | Critical | Circom spec: private inputs (P0 credential data, P0 key, nonce), public inputs (commitment hash, claim ID, expiry), output (valid + selective disclosure). ZK specialist required to implement + audit Groth16 circuit. | 4–6 hrs + specialist |
Partition data encryption + IPFS layer AES-256-GCM, HKDF key derivation, IPFS for P0/P2 only (P1/P3 chip-only) |
Claude Code | Critical | Python/TS: HKDF(partition_key, context) → AES-256-GCM, IPFS CID generation, schema versioning. P1 and P3 chip-only (no IPFS) — GDPR right-to-erasure compliance by design. | 6–10 hrs |
| Phase 2 — FIDO2 WebAuthn Bridge (Weeks 6–14) | ||||
FIDO2 CTAP2 NFC ring authenticator (P2) iOS NFC-native + Android BLE bridge for CTAP2 PIN-protected credentials |
Claude Code | Critical | Swift: ASAuthorizationController + CTAP2 NFC session, P2 signing key for WebAuthn assertion. Kotlin: FIDO2 BLE bridge (CTAP2-over-BLE to NFC-to-Tangem). Test against WebAuthn.io + real services. | 12–18 hrs |
SSH key derivation + agent integration Ed25519 from m/44'/7231'/2'/1' — ring-signed SSH challenges |
Claude Code | High | Python ssh-agent plugin: ring-signed SSH challenge via Tangem SDK, deterministic pubkey display for GitHub/GitLab registration, key rotation via path index increment | 4–8 hrs |
| Phase 3 — Desktop Credential Agent (Weeks 10–18) | ||||
Desktop credential agent daemon macOS + Windows + Linux: API key injection, 15-min TTL, auto-wipe on session end |
Claude Code | High | Python: system tray daemon, pyscard PCSC integration (Token2 NFC reader), P2 HKDF key derivation, AES-256-GCM decrypt from IPFS, OS keychain injection (Keychain / DPAPI / libsecret), 15-min TTL wipe | 16–24 hrs |
AWS / GCP / Azure / GitHub credential profiles Cloud CLI hooks: ring tap → inject session credentials → auto-expire |
Claude Code | High | aws credential_process hook, gcloud auth helper, az CLI credential provider, gh CLI token injection. Each: ring tap → P2 decrypt → 15-min session credential → auto-expire and wipe. | 6–10 hrs |
| Phase 4 — Recovery Protocol + Guardian System (Weeks 14–20) | ||||
Shamir Secret Sharing — P3 guardian setup 3-of-5 shard distribution, time-lock, Chainlink automation trigger |
Claude Code | High | Python secretsharing: shard generation, guardian wallet binding, ABSENCE_THRESHOLD config. Chainlink Automation: inactivity monitor + guardian quorum check. Guardian companion app: shard storage + recovery initiation. | 8–14 hrs |
Digital estate + PoA legal spec What goes in P3, how death trigger works, estate attorney review |
Claude Chat | Medium | Spec doc: which legal documents constitute P3 estate data, how Chainlink automation triggers P3 unlock (absence + guardian quorum), how digital assets transfer via P3 xPub reveal. Draft for estate attorney review before implementation. | 3–5 hrs + counsel |
| Continuous — Separation & Legal (Throughout All Phases) | ||||
Contract separation — SaludIDPlus stays hidden from CVS Separate contract address, separate admin keys, no cross-reference to SaludID.sol |
Claude Chat | Critical | Architecture review: confirm zero linkage between SaludID.sol (CVS-visible) and SaludIDPlus.sol (internal). Separate Polygon deployment, separate Polygonscan verification, separate Safe multisig admin wallets. | 2–3 hrs |
P1 Financial — GDPR / CCPA erasure compliance Chip-only design avoids right-to-erasure IPFS problem — legal confirmation |
Claude Chat | Critical | Legal memo: P1 chip-only (no IPFS) means right-to-erasure is satisfied by destroying or factory-resetting the ring. P0/P2 IPFS data requires user consent flows. Draft for GDPR/CCPA counsel review. | 2–4 hrs + counsel |
08 Risk Register — Risks Unique to SaludID Plus
09 The Three Starting Prompts
"In a new /contracts/premium/ folder in the Salud Vault Hardhat monorepo, create SaludIDPlus.sol extending ERC-7231 with: (1) PartitionCommitment struct (commitmentHash bytes32, lastUpdated uint64, schemaVersion uint8, active bool). (2) IdentityRecord mapping token IDs to: p0_healthcare as PartitionCommitment, p1_blinded/p2_blinded/p3_blinded as bytes32 (double-blinded salted hashes), ringAddress, ringFingerprint bytes32, premiumTier bool. (3) verifyHealthcareCredential(tokenId, zkProof bytes, requestedClaim bytes32) external view returns (bool valid, uint64 proofExpiry) calling an IZKVerifier interface. (4) ERC-5192 locked() always returns true, transferFrom always reverts. (5) initiateGuardianRecovery(tokenId, bytes32[3] shards) checking block.timestamp against ABSENCE_THRESHOLD constant. (6) All P1/P2/P3 partition functions access-controlled to ringAddress only — no public function can confirm P1/P2/P3 existence. Also create SaludIDPlusDerivation.swift implementing BIP-32 hardened path m/44'/7231'/n' in Tangem SDK sessions, with per-partition signing isolation and HKDF sub-key derivation for AES-256-GCM encryption. Deploy to Polygon Amoy completely separately from SaludID.sol with a different Safe multisig admin."
"Build P2 FIDO2 integration for the SaludVault iOS app (Swift). The Tangem ring must act as a FIDO2 roaming authenticator using CTAP2 over NFC via the Tangem SDK. Required: (1) Registration flow: WebAuthn navigator.credentials.create() challenge → Tangem NFC session with derivation path m/44'/7231'/2'/0' → CTAP2 authenticatorMakeCredential response → return attestation object to WebAuthn RP. (2) Authentication flow: navigator.credentials.get() → Tangem NFC → CTAP2 authenticatorGetAssertion → return assertion. (3) SSH key display: derive Ed25519 pubkey from m/44'/7231'/2'/1' and display as openssh-format for GitHub/GitLab registration. (4) Android BLE bridge: CTAP2-over-BLE service that proxies Chrome’s CTAP2 NFC requests to the Tangem SDK, working around Android’s NFC PIN limitation. Test all flows against WebAuthn.io and a local FIDO2 test server."
"Design the Circom/Groth16 circuit specification for SaludID Plus Partition 0 healthcare ZK verification. Private inputs: P0 raw credential JSON (Medicare/Medicaid/Aetna fields), P0 partition signing key (derived m/44'/7231'/0'/0'), a random nonce. Public inputs: P0 commitmentHash (from SaludIDPlus.sol on Polygon), requested claim ID string hash (e.g. keccak256('medicare_part_b_enrolled')), claim value (true/false), proof expiry timestamp, issuer public key hash (ID.me / CMS). Output: valid bool + single selective disclosure of the requested claim value. Constraint: circuit proves the credential contains the claim without revealing the MBI, any other credential fields, the partition key, or any P1/P2/P3 partition data. Also: design the GDPR/CCPA data architecture justifying P1 Financial as chip-only (no IPFS) — explain why this satisfies right-to-erasure, how P0/P2 IPFS data uses delete-key approach, and what user consent flows are needed for P0 IPFS storage. Draft legal memo for external counsel."