Introduction
Every major Identity Provider breach of the last five years follows the same structural pattern: a single signing key, session token, or credential store is compromised, and the attacker inherits the IdP's full authority to mint valid tokens for any user. Storm-0558 (Microsoft, 2023), LAPSUS$ (Okta, 2022), and the LastPass vault exfiltration all exploited this topology. The problem is not operational failure - it is the architecture itself. (Article 1: The Authority Problem examines this pattern in depth.)
Tide's Bring Your Own Identity (BYOiD) eliminates this topology. Users authenticate through a distributed cryptographic ceremony across independent nodes - no single node, operator, or infrastructure provider ever holds enough information to verify a user's identity, forge a token, or correlate a user's activity across services. The output is a standard OIDC-compatible token that any relying party can verify using normal token validation. The downstream application requires zero changes.
This article describes what BYOiD achieves and how it is structured at an architectural level. The detailed protocol specification is in Protocol: CMK Authentication.
What BYOiD Replaces
In a conventional OIDC or SAML flow, a user authenticates against an Identity Provider that verifies the credential (typically by comparing against a stored hash), then signs a token with the IdP's private signing key. The relying party trusts the token because it trusts the IdP's key. The entire security model depends on the integrity of that signing key and the credential store.
Loading diagram...
FIGURE 7: Centralized IdP Authority Compromise
BYOiD replaces both components. The credential store is eliminated: no server, database, or node holds a password hash or any artifact that can be exfiltrated and attacked offline. Credential verification is performed via PRISM, a Threshold Oblivious Pseudorandom Function (TOPRF) distributed across independent nodes - the verification function cannot exist outside the live network. The signing key is dissolved: tokens are produced via a threshold blind signature where nodes contribute partial signatures without seeing the message being signed or the public key it will be verified against. The complete signing key never exists in any location.
The Core Invariants
BYOiD is built on four invariants that hold throughout the entire authentication ceremony:
1. No credential artifact exists at rest. There is no password hash, no stored secret, no brute-force-feasible verification record that an attacker can exfiltrate. The closest analog - per-node PRISM verifiers - are individually useless: each is cryptographically bound to that specific node's private key and reveals nothing about the user's password without simultaneously possessing the distributed PRISM product (that is never revealed).
2. No key exists in complete form. The user's Consumer Master Key (CMK) is generated via Distributed Key Generation as shards across 20 independent ORK nodes. The full private key never materializes - not during generation, not during signing, not during any maintenance operation. The same is true for the vendor's signing key (VVK). (See Article 3: The Ineffable Key Lifecycle.)
3. No single node learns anything actionable. Each node processes a blinded, obfuscated input using only its own key shard. It does not learn the user's password, the user's identity, which vendor the user is authenticating to, the content of the token being signed, or even the public key used to verify that token. The protocol is double-blind: the signing nodes cannot see the message or the verification key, and the verifying party cannot learn the signing key.
4. The verification function requires the live network. Unlike hash-based authentication - where the verification function can be replicated offline once the hash and salt are known - BYOiD's verification function is an emergent property of a live, threshold interaction with the ORK network. The concept of an "offline brute force attack" does not apply.
The Actors
The BYOiD ceremony involves three categories of participants:
The Secure Web Enclave (SWE) - a verifiable JavaScript runtime that operates as the user's cryptographic agent in the browser. It generates session keys, blinds the user's input, communicates with the ORK swarm, keeps the ORKs honest, and assembles the final token. Its integrity is verifiable via Subresource Integrity (SRI) - the code is open and independently hashable, unlike hardware authenticators where the user cannot inspect the running code. The SWE can be served by any node on the network and rehomed at will. (See Article 7: Client Architecture.)
The CMK ORK Swarm - the set of 20 independently operated nodes that hold the user's CMK shards. Any 14 of the 20 can collaboratively perform the authentication ceremony (the 14-of-20 threshold). These nodes are selected from the entire network nodes (designed for unlimited growth). Each node is operated by a different organization, under independent infrastructure, bound by staking-enforced SLAs. CMK ORKs store only key shards - they hold no metadata about which vendors a user is associated with.
The Vendor's TideCloak IAM - the vendor's Keycloak-based identity and access management server, integrated with Tide Cybersecurity Fabric as its user's IdP and own key vault. It initiates the authentication redirect and processes the returned token. TideCloak holds the vendor's public key (VVK) but never possesses the corresponding private key - that key is threshold-distributed via Nested Shamir DKG across a separate VVK ORK swarm. (See Article 10: TideCloak.)
The Authentication Flow
The BYOiD ceremony completes in exactly two round-trips between the SWE and the ORK swarm, plus a final proof token delivery to the vendor IdP. Both round-trips carry data for two parallel sub-protocols - password verification (PRISM) and identity proof token signing (CMK blind signature) - in the same messages.
Loading diagram...
FIGURE 8: BYOiD Authentication Flow
In the first round-trip (Convert), the SWE sends a blinded password to all 20 ORKs and receives back PRISM-applied shards, encrypted authentication challenges, and blind-signing nonces. Client-side, the SWE reconstructs the password proof via threshold interpolation, decrypts the challenges (which proves password knowledge), recovers the user's vendor-specific identity, and prepares a blinded sign request.
In the second round-trip (Authenticate), the SWE returns the decrypted challenge proofs and the blind signature request. Each ORK verifies the challenge and computes a partial blind signature using its CMK shard - without being able to read the message being signed or know the verification key. The SWE aggregates the partial signatures, removes the blinding factor, verifies the assembled signature locally, then prepares the signed proof token under the CMK anonymised public key and delivers it to TideCloak. TideCloak verifies the threshold signature and issues a standard OIDC authorization code. From this point, the application uses a conventional JWT flow - the JWT itself is signed by the VVK ORKs via a separate distributed signing ceremony (Article 5, Article 6).
Within the session window (1-3 hours), the SWE can re-authenticate without password re-entry by replaying stored challengecapsules - each cryptographically bound to the originating browser's non-extractable session key.
The detailed step-by-step protocol, including per-message payloads and cryptographic operations, is specified in Protocol: CMK Authentication.
Layer Traversal
The BYOiD ceremony traverses all four layers of Tide's architecture (Article 2: Ineffable Cryptography and the Cybersecurity Fabric):
| Layer | Role in BYOiD |
|---|---|
| Legitimacy | The voucher validates each API request. ECDH between the SWE's session key and each ORK qualifies the communication channel. |
| Authority | Each ORK retrieves its Shamir shards (PRISM shard and CMK shard). |
| Agency | The PRISM evaluation and the partial blind signature computation are the purpose-specific MPC operations that give those shard meaning in the authentication context. |
| Settlement | The voucher system funds each node's participation, binds the operation to the paying vendor, and ensures cross-vendor isolation - a forged vendor key can only produce identities bound to itself. |
PRISM: Why Offline Attacks Do Not Apply
The most persistent threat to authentication systems is the offline attack: exfiltrate a credential database, then brute-force at the attacker's pace. Every major credential breach - from LinkedIn (2012) to LastPass (2022) - exploits the fact that the verification function (hash + salt) can be replicated offline once obtained.
BYOiD eliminates this attack class via PRISM, a Threshold Oblivious Pseudorandom Function (TOPRF) extending the OPRF primitive formalized in RFC 9497 into a threshold setting. The full construction and security proofis published in "Towards Zero Trust Authentication in Critical Industrial Infrastructures with PRISM" (Springer, CIMSS2023).
In a conventional system, the "salt" is a stored string. In PRISM, the equivalent is the output of a live computation distributed across an entire swarm of independent nodes. The verification function cannot be constructed without real-time interaction with a threshold of the network. Each guess requires a network round-trip - and the network enforces rate limiting at the protocol level.
The per-node artifacts (PRISM verifiers) are individually useless. Each is cryptographically bound to that specific node's private key. Compromising a single node yields one verifier that cannot test passwords without also possessing the distributed PRISM product - which itself requires 14 nodes.
Privacy: Unlinkable Derivative Identities
If a user presents the same public key to multiple services, those services can collude to track activity. BYOiD addresses this with the Double-Blind Threshold Signature Scheme - a novel two-sided blinding construction (paper pending with RMIT University) that decouples the user's Master Identity from the identifiers seen by individual applications.
During authentication, the SWE derives a Vendor User ID (VUID) and a corresponding authentication public key that are unique to the combination of this user and this vendor. Different vendors receive different, mathematically uncorrelatable identifiers for the same user. The derivation uses the user's CMK projected through the vendor's identity space via voucher-derived values - ensuring that even the ORKs performing the computation cannot determine which vendor the user is authenticating to.
The isolation is bidirectional: CMK ORKs (ORKs that are being used for user key shards) - no metadata about which vendors a user is associated with. Vendors and VVK ORKs have no knowledge of which CMK ORKs serve their users (even if it's on the same ORK), and no vendor knows which other vendors their users are associated with.
To guarantee domain separation between the blind-signature ceremony and standard Ed25519 operations, the Double-Blind TSS operates on a specialized twisted Edwards curve (BEd255475) rather than standard Edwards25519. Curve-level separation ensures a malicious SWE cannot craft blinded messages that yield valid standard Ed25519 signatures - preventing the ORK swarm from being weaponized as a general-purpose signing oracle.
Session Security: Integrated DPoP Binding
BYOiD integrates Demonstrating Proof-of-Possession (DPoP) (RFC 9449) directly into the authentication protocol rather than bolting it on as a separate layer.
At the start of the ceremony, the SWE generates two ephemeral key pairs as non-extractable keys via the WebCrypto API (
extractable: false). The private key material cannot be exported by any JavaScript context - it can only be used for cryptographic operations through the crypto.subtle interface. The resulting token is cryptographically bound to these session keys: a stolen token is useless without the non-extractable private key in the originating browser.This provides software-level non-extractability. Tide does not claim hardware-level guarantees equivalent to FIDO2/WebAuthn platform authenticators - but the SWE code is SRI-verifiable, meaning any party can independently inspect the authentication logic. FIDO2, contrarily, requires blind trust in the device manufacturer's attestation.
The Fork: VVK-Only vs. CVK
The output of BYOiD - a verified VUID and authenticated session - serves as the entry point into one of two operational models:
VVK-Only (Organization-Centric): The user receives role-based access to operations performed under the organization's Vendor Verifiable Key. All users share access to a single organizational authority key, differentiated by RBAC policy. This is the standard IAM model: authentication, JWT signing, authorization, and using TideCloak, also organization-managed E2EE are all governed by the VVK.
CVK (User-Sovereign): The user goes through a secondary iteration against a separate Consumer Vendor Key ORK swarm, gaining session control over their personal key in that vendor's context. The CVK acts as a personal wallet in a specific vendor's scope - identity, cryptocurrency, or any use case requiring individual authority. The CMK authentication is the identity gate; the CVK session is the persona's authority.
Some platforms may use both. The CVK session activation is a simpler protocol detailed in Protocol: CVK Session.
Comparison with Existing Approaches
vs. FIDO2 / WebAuthn / Passkeys
FIDO2 effectively eliminates server-side secrets and provides some phishing resistance (only to the authentication flow) via domain-origin binding. Three structural limitations remain: session hijack resistance, device binding, and fragile recovery (credentials bound to a specific device; recovery depends on vendor sync mechanisms or pre-registered backups), and no user-side verifiability (blind trust in the device's authenticator firmware required).
BYOiD is device-agnostic - recovery uses distributed shards across the user's ORK swarm, requiring no centralized recovery service. The SWE is SRI-verifiable and independently inspectable.
A guessed Tide password cannot be tested offline: every attempt requires a live, rate-limited interaction with the user's ORK swarm, and the resulting session is bound to non-extractable keys in the authenticating browser. However, FIDO2's domain-origin binding provides some phishing resistance that password-based flows - including Tide's - do not inherently match.
vs. Threshold MPC Alternatives
Existing threshold MPC solutions - e.g. Fireblocks, Lit Protocol, Web3Auth - share cryptographic primitives with Tide but were designed for key management rather than authority management: securing the ability to use a key is distinct from securing the ability to verify identity, authorize actions, and enforce governance without any single party holding actionable authority.
| Property | Fireblocks | Lit Protocol | Web3Auth | Tide |
|---|---|---|---|---|
| Primary purpose | Asset custody | Signing/compute infrastructure | Wallet-as-a-service | User authority |
| Trust model | Bilateral (vendor + customer) | Token-staked federation + TEEs | 3-party (network + device + backup) | 14-of-20 independently operated swarms |
| Key ever materializes? | No (MPC-CMP) | No (MPC-TSS) | Yes (SSS mode) / No (TSS mode) | Never (Ineffable Cryptography) |
| Credential hardening | No | No | No | Yes (PRISM) |
| Vendor unlinkability | N/A | No | No | Yes (derivative identities) |
| Verifiability model | Hardware attestation (opaque) | TEE attestation (opaque) | Trust vendor network | End-to-end (entirely open) |
| OAuth dependency | No | Optional | Yes (primary factor) | No |
| Key exportability | No | Planned | Yes (SSS mode) | Never (by design) |
| Offline attack resistance | No credential layer | No credential layer | No credential layer | Yes (TOPRF-enforced) |
BYOiD is only one pillar. TideCloak extends the same distributed, ineffable-authority model into JWT signing (Article 6: Authority in Action), governance enforcement (Article 5: Governance Without God Mode), and end-to-end encryption - a scope no existing MPC key management solution attempts.
Security Properties
The following properties hold under the threshold assumption (fewer than 14 of a user's 20 ORK nodes compromised) and the hardness of the discrete logarithm problem on the chosen curves:
| Property | Mechanism |
|---|---|
| No credential storage, anywhere | Verification is an emergent property of the live PRISM protocol - cannot be exfiltrated |
| No single point of signing authority | Forgery requires simultaneous compromise of 14 independently operated nodes within a single transaction window |
| Double-blind token issuance | ORKs cannot see the message, vendor identity or verification key; vendor cannot learn user's ORKs orthe signing key |
| Vendor-unlinkable identities | Each vendor receives a mathematically distinct, uncorrelatable identifier; two colluding vendors cannot link users |
| Transport-independent security | All properties independent of TLS; distributed ceremony provides equivalent guarantees |
| Non-extractable session binding | Tokens bound to WebCrypto non-extractable keys; stolen tokens unusable outside originating browser |
| Replay resistance | Per-node challenges include session-specific cache entries destroyed on use; triple-encrypted and bound to node + session + time window |
| User sovereignty | SWE is SRI-verifiable and rehomeable; no binding to any single operator |
Further Reading
- Protocol: PRISM - The companion sub-protocol providing distributed password verification.
- Protocol: Double-Blind TSS - The companion sub-protocol producing vendor-unlinkable identity tokens.
- Protocol: CMK Authentication - How PRISM and Double-Blind TSS are orchestrated into a 2-round-trip flow.
- Protocol: CVK Session - Secondary authentication from CMK to personal wallet session.
- Protocol: Authenticator App - The Authenticator App flow, eliminating password entry.
- Article 2: Ineffable Cryptography and the Cybersecurity Fabric - The four-layer architecture, ORK model, and primitive suite.
- Article 3: The Ineffable Key Lifecycle - How keys are generated, maintained, and destroyed without ever being assembled.
References
- Hall, J. L., Hertzog, Y., et al. (2023). Manifesting Unobtainable Secrets: Threshold Elliptic Curve Key Generation using Nested Shamir Secret Sharing. arXiv:2309.00915. Presented at AustMS 2021.
- Wang, F., Hertzog, Y., et al. (2023). Towards Zero Trust Authentication in Critical Industrial Infrastructures with PRISM. ACNS 2023 Workshops, LNCS 13907. Springer, Cham.
- RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession (DPoP). IETF, 2023.
- RFC 9497 - Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups. IETF, 2023.
- Tide Developer Documentation: docs.tidecloak.com