Introduction: The Governance Gap
Every conventional authorization architecture (and not just for Identity and Access Management) harbors a structural vulnerability so pervasive that the industry has simply accepted it as a necessary condition. It is the existence of "god mode" - a concentration of systemic authority that, if captured, grants an attacker unchecked power over the entire system.
This vulnerability manifests across three attack surfaces. The first is the credential store - the verification artifacts for every actor/user. Article 4: BYOiD detailed how Tide eliminates this surface by replacing stored credentials with live, distributed zero-knowledge verification. However, even with credentials secured, two god-mode surfaces remain: the king's seal (the signing key) and the administrative process.
In a Identity Management model, the private key that signs authorizations (e.g. JWTs) resides on the server. Whoever compromises the server acquires the key. Whoever holds the key can forge valid tokens for any user with any privilege. Downstream applications will execute the attacker's instructions because the token bears a legitimate signature. Moving the key into an HSM merely shifts the vulnerability: the HSM protects the key from extraction, but it signs whatever the authorized server requests. A compromised server commands the HSM.
The administrative process compounds the problem. An administrator can unilaterally alter roles, group memberships, and access policies - changes that take effect immediately on the next token issuance. Traditional defenses (MFA for admin logins, RBAC policies, audit logs) are software checks evaluated by the very server the attacker may control. An attacker with root access can disable the MFA requirement, rewrite the RBAC policy, and delete the audit logs. Traditional governance is advisory - policies that can be overridden by a sufficiently privileged actor.
Tide replaces advisory governance with cryptographic governance. Authority is removed from the IAM server and distributed, making it mathematically impossible for any single actor - rogue administrator, compromised server, or even the IAM developer - to forge a token or unilaterally alter permissions. This article introduces the two pillars that accomplish this: Tamper-Proof Authorization and Quorum-Enforced Governance.
Loading diagram...
FIGURE 9: Pillars of Quorum Governance
The VVK: An Ineffable King's Seal
To eliminate the signing key as a single point of failure, Tide fundamentally alters the Identity Provider's relationship to cryptographic authority. In standard architectures, the IAM server is the signing authority. In the Tide architecture, the IAM server (TideCloak) is a facilitator - it still manages all the relationships between users and their permissions, drafts tokens and requests signatures, but the decision to sign rests elsewhere.
The Vendor Verifiable Key (VVK) is the organization's signing key. It governs JWT issuance, permission authorization, and enterprise encryption policies. Following the same Nested Shamir DKG used for user identities (see Article 3: The Ineffable Key Lifecycle), the VVK is generated across an independent 20-node VVK ORK swarm with a 14-of-20 threshold. The complete private key never exists in memory, on disk, or in transit.
A total compromise of TideCloak yields no signing key material. The attacker finds an IAM system that is entirely reliant on an external, decentralized swarm to execute any authoritative operation. To forge a signature, an attacker would need to simultaneously compromise TideCloak and 14 independently operated ORK nodes - run by distinct organizations in distinct jurisdictions - within the execution window of a single transient ceremony. The key insight applies directly: TideCloak has no signing keys. The authority that normally lives inside an IAM has been dissolved entirely.
The VRK Delegation Pattern
If TideCloak does not hold the VVK, it needs a mechanism to communicate with the swarm that does. The Vendor Random Key (VRK) delegation pattern separates communication authority from signing authority.
During initialization, TideCloak generates an ephemeral key pair (VRK). The VVK ORK swarm cryptographically certifies the VRK's public key, producing a signed delegation proof (
gVRKSig). In operation, TideCloak uses the VRK to establish ECDH channels with VVK ORKs. Every ORK independently verifies the VRK delegation (gVVK.verifySig(gVRKSig)) before processing any request.If an attacker extracts the VRK, they can communicate with the VVK ORKs - but unlike a traditional HSM that signs whatever the server requests, the VVK ORKs independently verify every claim before signing. The VRK grants the right to speak to the swarm, not the right to command it. The VRK can also be rotated without changing the VVK, limiting the value of a compromised delegation key.
Pillar One: Tamper-Proof Authorization
The first pillar ensures that a compromised IAM server cannot forge an access token with elevated privileges. It couples decentralized authentication (CMK ORKs) with decentralized authorization (VVK ORKs).
Loading diagram...
FIGURE 10: BYOiD Authorization Flow
The process begins where BYOiD concludes. After the user authenticates via their CMK ORK swarm, the Secure Web Enclave (SWE) produces a blind signature and an authentication token - proofs of identity and session validity. TideCloak drafts a JWT based on the user's stored roles and permissions.
Independent Claim Verification
When VVK ORKs receive the signature request, they do not sign blindly. Each ORK independently audits the request.
Cross-key verification. The VVK ORKs verify the user's blind signature using their public authentication key (
gCMKAuth.verifySig(blindSign, AuthToken)). This is the critical cross-key-population linkage: the user proved their identity to the CMK ORK swarm during authentication, and now the VVK ORK swarm cryptographically verifies that proof before authorizing the token. Two distinct key populations - the user's CMK swarm and the organization's VVK swarm - are linked through this verification.A compromised TideCloak cannot request a token for a user who has not genuinely authenticated, because the CMK blind signature cannot be forged without compromising the user's separate CMK ORK swarm.
Authorization proof verification. TideCloak maintains pre-approved "authorization proofs" - VVK-signed attestations that a specific user-client pair is entitled to specific roles, scopes, and permissions. These proofs were created during the Quorum-Enforced Governance workflow (Pillar Two) and are stored in TideCloak's database. Critically, the proofs are not mere database records - they are cryptographic artifacts bearing the VVK's threshold signature. When a JWT signing request arrives, TideCloak must look up the relevant proof (
DBlookup(proofDetails, RealmID, userID, clientID)) and attach it. Each VVK ORK verifies the VVK signature on the proof, then compares the JWT draft's claims against the authorized claims.TideCloak cannot create, modify, or forge a proof without the VVK swarm's participation, and the VVK swarm will not sign a proof without quorum approval.
Session binding. The VVK ORKs verify that the JWT's session identifiers match the session established during authentication (
session_state == gVenSessKey), preventing token replay across sessions.JWT Claim Enforcement
If an attacker injects elevated privileges into the JWT draft (adding
"role": "superadmin" or unauthorized scopes), the VVK ORKs detect the discrepancy against the pre-approved user context. Each ORK independently validates that every claim in the JWT draft is a subset of the VVK-signed user context: realm_access and resource_access roles must match, and no client role can appear in the draft unless the context authorizes it. If any claim exceeds the authorized scope, the ORK rejects the signing request entirely and drops the connection.TideCloak is responsible for constructing compliant JWT drafts. When IGA is enabled, only roles with ACTIVE governance status are included in the draft, and the audience is restricted to authorized clients. The ORK verification is the enforcement backstop: even if TideCloak is fully compromised, the attacker's injected privileges never reach a signed token because each of 14 ORKs independently rejects the non-compliant draft.
By pushing verification into the threshold layer, Tamper-Proof Authorization guarantees that the output of the identity system is a provable reflection of the organization's approved governance state, regardless of the IAM server's integrity.
Pillar Two: Quorum-Enforced Governance
If the VVK ORKs only sign JWT claims matching a pre-approved proof, the security of the entire architecture depends on how those proofs are created. If a single administrator can generate a proof unilaterally, god mode has merely relocated from the server to the admin console.
The second pillar closes this gap. Any modification capable of affecting JWT claims requires the cryptographic consensus of an administrative quorum before the VVK will seal it. The quorum-enforced governance workflow applies uniformly to every modification capable of affecting authorization state. The system governs fourteen distinct change types:
| Category | Change Types |
|---|---|
| Role management | Roles, composite roles, default roles |
| User assignments | User creation, user-role mappings |
| Group management | Groups, group-role mappings, user-group membership, group hierarchy moves |
| Client configuration | Clients, client default user contexts, client full-scope settings |
| Policy and licensing | Forseti policy deployment, realm licensing |
| Lifecycle | Ragnarok (organizational off-boarding) |
Notably, Forseti policy deployment is itself a governed change type. Deploying or modifying a programmable policy contract requires the same quorum approval and VVK threshold signing as any role or permission change. This closes a potential governance gap: administrators cannot bypass quorum requirements by deploying permissive policies, because the deployment itself requires quorum consensus.
The Governance Workflow
In standard IAM, an admin changes a role and the database updates immediately - the new policy dictates the next token minted. In TideCloak, changes trigger the Quorum-Enforced Identity Governance and Administration (IGA) workflow. Instead of applying the change directly, TideCloak creates a draft record of the proposed modification. The system traces the entire graph of relationships to identify every user-per-client assignment affected by the draft, generates a draft authorization proof for each affected pair, and computes a SHA-256 checksum digest of the entire change-set. This digest becomes the immutable identifier for the pending governance action.
The Governance State Machine
A change request does not transition directly from draft to committed. The system tracks six distinct states reflecting the progression of administrative consensus:
| State | Condition |
|---|---|
| DRAFT | The change has been proposed. No administrator has yet approved or rejected it. |
| PENDING | At least one administrator has approved, but the approval count has not yet reached the quorum threshold. Sufficient administrators remain to reach it. |
| APPROVED | The number of approvals meets or exceeds the quorum threshold. The change may be committed. |
| DENIED | The number of rejections has made approval mathematically impossible: the remaining non-rejecting administrators are fewer than the threshold. |
| ACTIVE | The change has been committed: VVK-signed proofs have been generated, draft records archived, and the new authorization state is in effect. |
The denial condition is evaluated preemptively. If at any point
(activeAdministrators - rejections) < threshold, the system transitions to DENIED without waiting for remaining votes. This prevents governance deadlock and provides immediate feedback to administrators that a proposed change has been definitively blocked.Administrators may also explicitly cancel a pending change request, withdrawing it from the approval pipeline before a final determination is reached.
Admin Co-Signing
For the draft to become policy, a threshold of administrators must ratify it. The threshold is derived from the governing policy bound to the administrative role, approximately 70% of active administrators (e.g., 2-of-3, 3-of-5). This value is itself a parameter of a VVK-signed policy: changing the threshold is an authorization change subject to the same quorum process. The threshold is materialized on the role for efficient lookup during approval evaluation, and updated automatically whenever the governing policy is committed.
If the configured threshold exceeds the current number of active administrators, for example after an admin departs, the system caps the effective threshold at 70% of the remaining active count, preventing governance deadlock without relaxing the quorum model.
Each admin authenticates via their own BYOiD ceremony, reviews the formatted change-set in their SWE, and signs the checksum. An administrator who has already approved a change request cannot approve it a second time. The system enforces this constraint before presenting the approval interface. If the current administrator's identity appears in the existing approval set, the signing request is rejected. This prevents a single compromised administrator from inflating the approval count toward the quorum threshold.
Cryptographic Consent: The Three-Artifact Approval
When an administrator approves a change request, the system records three distinct cryptographic artifacts, not a single signature:
| Artifact | Purpose |
|---|---|
| Authentication message | Proves the administrator completed a live BYOiD authentication ceremony against their CMK |
| Admin signature | The administrator's CMK blind signature, independently verifiable by VVK ORKs against the administrator's public authentication key |
| Session approval signature | The administrator's ephemeral session key signs the specific change-set checksum, providing temporal scoping |
Together these create an unforgeable chain of custody: the admin's root identity authorized the session (
gCMKAuth verified against blindSig), and the session key signed the policy change (gSessKeyPub signs changeChecksum). A compromised TideCloak cannot forge this chain because it does not hold any admin's CMK, and those keys are protected by the same distributed architecture described inArticle 4.VVK Verification and the Closed Loop
Once the quorum threshold is met, TideCloak submits the complete package to the VVK ORK swarm. Before sealing the new proofs, each VVK ORK independently verifies all three artifacts per administrator and checks:
- Authentication chain: each admin's authentication message and blind signature confirm a live BYOiD ceremony against their CMK root identity
- Group membership: the signing admins belong to the authorized governance group, itself a VVK-signed artifact (
signedAdmins) - Quorum threshold: the number of valid admin signatures meets the configured minimum
- Replay protection: the draft timestamp is within the last month
- Double-approval exclusion: no administrator identity appears more than once in the approval set
Only when every check passes do the VVK ORKs apply their shards. The resulting VVK-signed proofs are stored and used during future JWT signing.
Authority Assignment: The Dual-Signing Flow
Standard governance changes (adding a user to a role, modifying a group membership) require a single approval cycle and produce a single set of VVK-signed authorization proofs. Authority assignments are different. When the proposed change grants a role that carries a Forseti policy, a role whose holder gains the ability to authorize cryptographic operations, the governance flow bifurcates.
The system returns two distinct approval requests to the administrator's Secure Web Enclave: one for the user context change (the role assignment itself) and one for the policy entity (the Forseti contract bound to that role). Each requires independent review and approval through the enclave. This separation ensures that administrators explicitly consent to both the access grant and the policy that governs how that access will be exercised.
During the
commit phase, the system signs user context models first and defers policy commitment until all user context signatures are complete. This ordering prevents the threshold from changing mid-batch. If the policy being committed modifies the quorum threshold, that new threshold takes effect only after all current signatures have been sealed under the prior threshold.Loading diagram...
FIGURE 11: BYOiD Authorization Governance Flow
This creates a closed cryptographic loop with a deliberate circular dependency. The VVK certifies who the admins are (
signedAdmins). Admins must collaborate to approve changes. The VVK verifies their collaboration before certifying proofs. The VVK uses those proofs to verify every JWT before signing it. No single actor can insert themselves into this loop - a rogue admin cannot forge the quorum because other admins' keys are Tide-protected. A compromised TideCloak cannot create proofs because it does not hold the VVK. And no one can modify the admin roster without quorum approval that the VVK itself enforces. The loop has no external entry point.Bootstrap: From First Administrator to Quorum Governance
The quorum model requires administrators to exist before it can govern their creation, a bootstrapping problem. Tide resolves this through a two-phase authorizer transition.
When an organization first onboards, the system operates in single-administrator mode. The initial administrator authenticates and signs authorization proofs directly via VRK delegation, without quorum requirements. This mode is deliberately constrained: it cannot initiate Ragnarök, and it serves a single purpose, establishing the first
tide-realm-admin role assignment.The moment the first administrative role assignment is committed, the system automatically and irreversibly transitions to multi-administrator mode. All subsequent governance operations, including the appointment of additional administrators, require quorum approval and VVK threshold signatures. The transition also triggers regeneration of all default user contexts across every client, ensuring the entire authorization surface is re-sealed under the quorum model.
This transition is one-directional. Once multi-administrator governance is active, there is no mechanism to revert to single-administrator mode. The bootstrapping exception exists only long enough to eliminate itself.
Break-Glass and Governance Recovery
A common question: what happens when a critical update is needed at 3:00 AM but the quorum is unreachable? What if an admin loses access to their identity?
In traditional IAM, organizations maintain a "break-glass" account with unilateral root privileges. In Tide, there is no singular break-glass bypass. This is deliberate - a bypass that circumvents the quorum recreates the god-mode vulnerability the system eliminates. If a technical mechanism exists to bypass the quorum, an attacker will eventually exploit it. The absence of break-glass is not a gap in the design; it is the design. The strength of cryptographic governance lies in the absence of exceptions.
Instead, Tide relies on recovery mechanisms within the quorum itself:
Admin recovery. If an admin loses access, they execute the standard recovery flow (Protocol: Decentralized Account Recovery). If an admin departs, the remaining quorum members propose a governance draft to revoke the departed admin and add a replacement - using the same quorum-enforced loop. The VVK certifies the admin roster, so modifying it requires quorum approval.
Ragnarök. The ultimate governance action is the decision to exit the decentralized framework entirely. Protocol: Ragnarök reconstructs and exports the organization's VVK to transition back to standard, centralized authentication. Even this requires quorum approval - the organization can leave, but only through verified consensus of its leadership.
Advisory vs. Cryptographic Governance
The distinction between traditional IAM and Tide's governance model is best understood as the difference between detective controls and preventive constraints.
| Dimension | Traditional IAM | TideCloak |
|---|---|---|
| Signing key | Stored on server or in HSM | DKG across 20-node VVK ORK swarm; never exists in one place |
| Admin changes | Applied immediately | Require multi-admin quorum + VVK cryptographic seal |
| RBAC policies | Overridable by privileged admin | Changes require quorum approval before VVK will sign |
| Token forgery | Requires stealing one key | Requires compromising 14+ independent ORKs simultaneously |
| Claim verification | Server asserts claims; HSM signs blindly | VVK ORKs independently verify every claim against quorum-approved proofs |
| Governance model | Advisory: software guards, detective audit logs | Cryptographic: mathematical constraints, preventive threshold enforcement |
Traditional governance relies on the assumption that the enforcer of rules cannot be subverted. Audit logs record what happened - they are detective, not preventive. An attacker who compromises the server can disable MFA, rewrite RBAC policies, forge tokens, and delete the logs that would have recorded the intrusion. The organization discovers the breach after the damage is done.
Cryptographic governance prevents the anomaly from occurring. The VVK will not sign a claim that was not quorum-approved, regardless of who requests it or what level of server access they possess. There is no policy file to rewrite, no admin override to invoke, no audit log to delete that would change the mathematical fact that 14 independent ORKs will reject an unsigned claim. The governance constraint is not enforced by software running on a server - it is enforced by the structure of the cryptography itself.
Further Reading
- Protocol: VVK JWT Signing - The VVK ORK verification and two-phase signing ceremony.
- Protocol: Authorization Proofing - The authorization draft/co-sign/commit workflow and VVK authorization loop.
- Article 7: Client Architecture - Client-side architecture (SWE, TideCloak, Asgard roles in the governance flow).
- Article 9: Threat Model - How these governance mechanisms resist admin compromise, TideCloak compromise, and ORK collusion.
- Article 10: TideCloak - Integration using TideCloak deployments.
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.
- Komlo, C. & Goldberg, I. (2020). FROST: Flexible Round-Optimized Schnorr Threshold Signatures. SAC 2020.
- Wagner, D. (2002). A Generalized Birthday Problem. CRYPTO 2002.
- Tide Developer Documentation: docs.tidecloak.com