Quorum-Enforced Governance: Authorization Proofing | Cyber Immunity Whitepaper

Overview

This protocol specifies how changes to authorization rules - roles, permissions, scopes, groups, attributes, and client configurations - are governed by multi-admin quorum approval and sealed by VVK threshold signatures. The protocol has three phases: Change Request Creation (admin proposes, TideCloak drafts instead of committing), Co-Signing (additional admins independently review and cryptographically approve), and Commit (VVK ORKs verify the entire governance lifecycle and threshold-sign the resulting authorization proofs).

The output of this protocol - VVK-signed authorization proofs - is the input to the sibling protocol Protocol: VVK JWT Signing. During real-time token issuance, VVK ORKs call

gVVK.\textsf{verifySig}(proof, bareJWT)

to verify JWT claims against the proofs produced here. This creates the cryptographic link between asynchronous governance (this protocol, operating on the timescale of administrative decisions) and synchronous authorization (JWT signing, operating on the timescale of user logins).

The core architectural property: no single administrator, no compromised TideCloak server, and no colluding minority of VVK ORKs (

\leq

13 of 20) can create, modify, or forge an authorization proof. Every proof requires multi-admin quorum approval verified independently by each VVK ORK. The governance configuration itself (the

signedAdmins

group defining who can approve changes) is VVK-certified - modifying the admin roster requires the same quorum process, creating a closed loop with no external entry point.

Loading diagram...

Preconditions

The primary prerequisite is the existence of the

signedAdmins

governance configuration, which must be established and VVK-certified before any authorization changes can proceed through this protocol. The threshold is typically set to approximately 70% of the admin group (e.g., 2-of-3, 3-of-5) to balance security against operational availability.

Category	Artifact	Description
Governance Config	$signedAdmins$	VVK-certified admin group: list of authorized admin public keys ( $gCMKAuth$ values) + quorum threshold + VVK signature. Modifying this group requires quorum approval - the closed governance loop.
	$signedAdmins.threshold$	Quorum threshold (e.g., 2-of-3, 3-of-5, ~70%)
	$signedAdmins.signature$	VVK signature over the admin group definition
TideCloak	$VVID$ , $gVVK$	VVK identifier and public key
	$VRK$ , $gVRK$	Vendor Random Key pair (delegated communication key)
	$gVRKSig$	VVK-signed proof of VRK delegation
Each Admin	$SessKey$ , $gSessKeyPub$	Ephemeral session key pair from BYOiD authentication (stored in Tide Cookie)
(after BYOiD)	$blindSig$	Blind signature from BYOiD (proves identity)
	$gCMKAuth$	Admin's permanent authentication verifier (derived from CMK)

Protocol Flow

Phases 1-2: Change Request Creation and Co-Signing

Loading diagram...

Phase 1 replaces Keycloak's immediate-commit model with an asynchronous drafting pipeline. When an admin modifies any authorization-relevant record (roles, compound roles, groups, attributes, scopes, or client configurations), TideCloak intercepts the change and creates a draft record instead of committing it directly. The draft includes a precise timestamp (

epochTimeUTC()

) used later for replay protection - VVK ORKs reject any change-set older than 30 days.

The affected-assignment tracing (

traceAffectedAssignments(changeReq)

) maps the full graph of identity relationships to identify every user-per-client pair whose JWT claims would change. A single role modification can cascade across hundreds of users and multiple clients. For each affected pair, TideCloak generates a draft authorization proof (

proofDetail[i].draft

) specifying the new entitlements. The cryptographic checksum

H(proofDetail[1..z], draftRecord)

binds the entire change-set - every affected proof plus the draft record with its timestamp - into a single immutable unit. Any modification to any proof, any addition or removal of affected pairs, or any alteration of the timestamp changes the checksum.

The admin reviews the formatted change-set in their Secure Web Enclave (SWE) and signs with their ephemeral session key, not their permanent CMK. This is a deliberate design choice documented in Algorithm 2 - session-key signing provides temporal scoping and prevents replay of permanent-key signatures against future change-sets. TideCloak verifies the signature chain (

blindSig.gSessKeyPub.\textsf{verifySign}(proof, changeChecksum)

) and stores the approval.

Phase 2 repeats the review-and-sign cycle for each additional co-signer. Each admin authenticates independently via BYOiD (obtaining their own Tide Cookie with their own session key), reviews the identical change-set in their own SWE, independently re-computes the checksum, and signs it with their own session key. TideCloak accumulates signatures until the quorum threshold is met. The identical checksum computation by each SWE provides independent integrity verification - if TideCloak tampered with the change-set between signers, the checksums would diverge and subsequent verification would fail.

Phase 3: Commit - VVK ORK Verification and Proof Signing

Loading diagram...

Phase 3 is the core cryptographic ceremony. Any admin can trigger the commit once they observe sufficient approvals. TideCloak sends the complete package - draft record, proof details, and all admin signatures - to the VVK ORK swarm via preSignProofs.

Each VVK ORK independently executes Algorithm 1 (the Governance Gate). The ORK does not trust TideCloaks's assertion that the quorum was met - it mathematically re-verifies the entire governance lifecycle. First, VRK delegation and ECDH decryption (proving TideCloak is authorized). Then replay protection - the draft timestamp must fall within the last 30 days (

draftRecord.timestamp > now() - 2628000

), preventing resurrection of old, legitimately approved but subsequently reversed change-sets. Then, for each co-signing admin, the full 4-link signature chain (Algorithm 2): identity verification (

gCMKAuth

matches

blindSig

), group validation (

signedAdmins

is VVK-certified), membership check (admin is in the VVK-certified group), and co-signature verification (session key signed this specific checksum). Only verified admins increment the

approvers

count. Finally, the quorum threshold check:

approvers \geq signedAdmins.threshold

A critical detail in the preSignProofs payload: the ORK receives the

draftRecord

(which contains the

changeChecksum

), the admin signatures, and the

signedAdmins

group definition - but NOT the individual proof details. The proof content is only sent in the subsequent SignProofs call. This is the two-phase split: preSignProofs verifies governance legitimacy and commits nonces; SignProofs delivers the actual content to be signed.

During SignProofs, each ORK performs a critical integrity check: it re-computes

H(proofDetail[1..numOfProofs])

from the proof details received in this phase and verifies the result matches the

changeChecksum

from its preSignProofs cache. This ensures TideCloak did not swap or alter the proof details between the two phases. The ORK then iterates over each proof, computing a partialSign using its VVK shard, the committed nonce, the aggregate nonce, and the proof draft content. See Article 6: Authority in Action for the general threshold signing construction.

TideCloak aggregates the partial signatures per proof (

approved[j] = \sum approved_i[j][1..I]

), verifies each assembled signature against

gVVK

, and attaches the VVK signatures (

\{approved[i], gVVKR[i]\}

) to the proof details, commits them to the database, and archives the draft records and admin signatures for audit. The proofs are now available for retrieval during JWT signing:

DBlookup(proofDetails, RealmID, userID, clientID)

Batching: If the change affects more than 30 user-client pairs, TideCloak breaks the workload into sequential rounds of at most 30 proofs each. The 30-proof cap mitigates Wagner birthday attacks on the threshold signing scheme - with more concurrent nonces per round, an adversary gains computational advantage in finding forgeries. Each round follows the complete preSignProofs → SignProofs cycle independently, with fresh nonces committed and destroyed per round. For a role change affecting 500 users across 3 clients, this produces 1,500 proofs requiring 50 sequential rounds - every affected authorization relationship is individually sealed by the VVK.

Algorithms

Algorithm 1

VVK ORK Governance Gate (per ORK, preSignProofs)

Input:

encSignReq_i

gVRKSig

VVID

Output:

encR_i

(encrypted nonces for

numOfProofs

proofs) or ABORT

Retrieve VVK record: $gVVK \leftarrow \textsf{retrieveVVKRecord}(VVID)$
VRK delegation: $\textsf{ASSERT } gVVK.\textsf{verifySig}(gVRKSig.\text{sig},\ gVRKSig.\text{Message})$
ECDH decryption: $ECDH_i \leftarrow gVRK.\textsf{DH}(vSecORK_i)$ $\{draftRecord,\ numOfProofs,\ draftAdmin[1..s],\ signedAdmins[1..a]\} \leftarrow \textsf{AES\_DEC}_{ECDH_i}(encSignReq_i)$
Replay protection: $\textsf{ASSERT } draftRecord.\text{timestamp} > \textsf{now}() - 2628000$
Per-admin verification (for each $i = 1$ to $s$ ): Execute Algorithm 2 on $draftAdmin[i]$ with $signedAdmins$ , $gVVK$ If all 4 checks pass: $approvers \mathrel{+}= 1$
Quorum threshold: $\textsf{ASSERT } approvers \geq signedAdmins.\text{threshold}$
Nonce generation (only if all above pass): $numOfProofs \leftarrow \min(numOfProofs,\ 30)$ For $j = 1$ to $numOfProofs$ : $\quad VVKR_i[j] \overset{\$}{\gets}$ ℤ $_\ell,\quad gVVKR_i[j] \leftarrow G \cdot VVKR_i[j]$ $encR_i \leftarrow \textsf{AES\_ENC}_{ECDH_i}(gVVKR_i[1..numOfProofs])$ $\textsf{CreateLimited CacheEntry } changeChecksum\ (TTL\!:\!30s,\ max\!:\!30\ per\ VVID)$

Any single ASSERT failure → ABORT.

Algorithm 2

Per-Admin Signature Chain Verification (sub-routine of Algorithm 1)

Input:

draftAdmin[i]

signedAdmins

gVVK

changeChecksum

Output: PASS or FAIL

Identity verification: $isAuthVerifier \leftarrow draftAdmin[i].\text{publicKey}.\textsf{verifySign}(draftAdmin[i].\text{blindSig})$ Proves: this admin's $gCMKAuth$ matches their BYOiD blind signature.
Group validation: $isGroupValidated \leftarrow gVVK.\textsf{verifySig}(signedAdmins.\text{signature})$ Proves: the admin group definition is VVK-certified.
Membership: $isAdminGroupMember \leftarrow signedAdmins.\textsf{findMember}(draftAdmin[i].\text{publicKey})$ Proves: this admin is a member of the authorized governance group.
Co-signature: $isVerified \leftarrow draftAdmin[i].\text{blindSig}.\text{gSessKeyPub}.\textsf{verifySign}(draftAdmin[i].\text{proof},\ draftRecord,\ changeChecksum)$ Proves: this admin signed this specific change-set with their authenticated session key.

\textsf{PASS if } isAuthVerifier \land isGroupValidated \land isAdminGroupMember \land isVerified

The admin signature chain (Algorithm 2) deserves explanation. Each admin signs with their ephemeral session key (

SessKey

), not their permanent CMK directly. The chain links four artifacts:

gCMKAuth \rightarrow blindSig \rightarrow gSessKeyPub \rightarrow proof

The admin's permanent identity (

gCMKAuth

, derived from their CMK) is verified via the BYOiD blind signature (

blindSig

). The session key (

gSessKeyPub

) is embedded in that blind signature, binding it to a specific authenticated session. The

proof

is the session key's signature over the

changeChecksum

, binding this admin's approval to this specific change-set. The VVK ORKs verify each link independently - no link can be forged without the preceding link's private material.

This provides temporal scoping: the signature is valid only within the authenticated session. An attacker cannot harvest a permanent CMK signature and reuse it against future change-sets, because the admin never signs the changeset with their CMK - only with the ephemeral session key. The session key also provides separation of concerns: the admin's permanent identity root is never directly exposed to TideCloak during the signing operation.

The closed governance loop is enforced through

signedAdmins

. The VVK ORKs verify both that the admin group definition is VVK-certified (

gVVK.\textsf{verifySig}(signedAdmins.signature)

) and that each co-signer is a member. Because modifying the

signedAdmins

group is itself an authorization change requiring the same quorum process, there is no way to inject an unauthorized admin into the governance group without existing admin consensus. The VVK certifies the admins; the admins approve changes; the VVK signs the proofs; the proofs constrain authorization. Every link in this chain is cryptographically sealed.

Notation Reference

Symbol	Description
$changeReq$	Triggering change (role/group/scope/attribute/client modification)
$draftRecord$	Proposed change record: $\{ID, req, timestamp, checksum\}$
$Assignment[1..z]$	Affected user-client pairs: $\{kcUserID, kcClientID\}$
$proofDetail[i]$	Draft authorization proof for pair $i$ : $\{recordID, draft\}$
$proofDetail[i].sig$	VVK signature over proof: $\{approved, gVVKR\}$ (output of this protocol)
$changeChecksum$	$H(proofDetail[1..z], draftRecord)$
$draftAdmin[j]$	Co-signing admin $j$ : $\{recordID, adminID, publicKey, sig, proof\}$
$signedAdmins$	VVK-certified admin group (member keys + threshold + VVK signature)
$SessKey$ , $gSessKeyPub$	Admin's ephemeral session key pair (from BYOiD, in Tide Cookie)
$blindSig$	Admin's BYOiD blind signature
$gCMKAuth$	Admin's permanent authentication verifier (derived from CMK)
$VVK$ , $gVVK$ , $VVK_i$	Vendor Verifiable Key (aggregate / public / shard)
$VVID$	VVK identifier
$VRK$ , $gVRK$ , $gVRKSig$	Vendor Random Key (delegate, VVK-certified)
$VVKR_i[j]$ , $gVVKR_i[j]$	ORK $i$ 's nonce for proof $j$ (private / public)
$gVVKR[j]$	Aggregate nonce for proof $j$
$approved_i[j]$	ORK $i$ 's partial signature for proof $j$
$approved[j]$	Aggregate signature for proof $j$
$ECDH_i$	Pairwise ECDH secret: $vgORK_i.\textsf{DH}(VRK)$
$\textsf{AES\_ENC}_{a}(B)$	AES256 encryption of message $B$ with key $a$
$\textsf{AES\_DEC}_{a}(B)$	AES256 decryption of message $B$ with key $a$
$ORKsBitwise$	Bitwise array of participating ORKs
$numOfProofs$	Proofs in this batch (max 30)
$n$ , $t$ , $I$	Total ORKs (20) / threshold (14) / responding count

Actors and Trust Assumptions

Actor	Description	Trust Assumption
Admin (Proposer)	Initiates the change. Authenticates via BYOiD. Signs with session key.	Cannot unilaterally commit - requires quorum.
Admin (Co-signers)	Review and co-sign. Each authenticates independently via BYOiD.	Each admin's identity is Tide-protected. No impersonation possible.
Admin SWE	Browser agent. Formats change-set for review. Signs $changeChecksum$ with session key.	Cannot forge signatures without session key from authenticated BYOiD session.
TideCloak	Detects changes, creates drafts, manages approval queue, stores signatures, Holds VRK, Encrypts requests. Aggregates partial signatures.	Can be compromised - but cannot forge admin signatures or bypass VVK ORK verification. Holds VRK, not VVK. Cannot forge VVK signatures or bypass quorum.
VVK ORKs	20 nodes holding VVK shards. Final authority. Independently verify VRK delegation, replay, admin chain, group membership, quorum threshold.	Standard threshold trust ( $\leq$ 13 may collude).

Layer Traversal

Layer	How Authorization Proofing Engages It
Legitimacy	Admin authentication via BYOiD (Tide Cookie / session key). ECDH channels ( $VRK \leftrightarrow ORK$ ). Replay protection (30-day timestamp). VRK delegation verification.
Authority	VVK shard management. ORKs load $VVK_i$ for partial signing. The $signedAdmins$ group is VVK-certified - Authority Layer maintains governance configuration.
Agency	Primary layer. Two Agency operations: (1) admin co-signing via session-key signatures, (2) VVK threshold signing of authorization proofs ( $\textsf{partialSign}$ per proof).
Settlement	Voucher validation for signing operations. Archive of $draftRecord$ and $draftAdmin$ signatures provides audit trail.

Security Properties

Property	Mechanism	Assumption
Quorum enforcement	VVK ORKs independently count valid approvers against $signedAdmins.threshold$ . Below-threshold commits rejected.	DLP hardness
Admin identity verification	Each admin's $gCMKAuth$ verified against their $blindSig$ . Forged identities fail.	DLP hardness
Admin group membership	VVK ORKs verify $signedAdmins$ is VVK-signed and each admin is a member. Non-members rejected.	-
Session-bound signatures	Admin signs with ephemeral session key, not permanent CMK. Temporal scoping prevents replay.	Session key randomness
Closed governance loop	Admin group is VVK-certified. Adding/removing admins requires quorum → no external entry.	-
Replay protection	30-day timestamp window ( $draftRecord.timestamp > now() - 2628000$ ). Stale change-sets rejected.	ORK NTP accuracy
Checksum integrity	$changeChecksum$ computed independently by SWE, TideCloak, and VVK ORKs. During SignProofs, ORKs re-compute $H(proofDetail[1..numOfProofs])$ and verify against the cached checksum from preSignProofs - detecting any payload swaps between phases.	SHA-256 collision resistance
Wagner birthday mitigation	Two-phase signing (preSignProofs → SignProofs). 30-proof batch cap. Nonce commitment before signing.	DLP hardness
Per-proof signing	Each affected user-client pair gets an individual VVK-signed proof. No mass-assignment shortcuts.	-
No single-admin bypass	Rogue admin can draft and sign but cannot commit without quorum co-signatures.	Threshold assumption
No TideCloak bypass	Compromised TideCloak cannot forge admin session signatures or bypass VVK ORK verification.	-
VRK delegation ≠ authority	VRK enables communication. Compromised VRK cannot bypass quorum verification on VVK ORKs.	-
Audit trail	Draft records and admin signatures archived after commit. Full forensic traceability.	Database integrity

Call Summary

Call	Direction	Purpose
`traceAffectedAssignments`	TideCloak → Local DB	Identify all user-client pairs whose JWT claims are affected by the change.
`SessKey.sign`	SWE (client-side)	Admin signs $changeChecksum$ with ephemeral session key.
`SignChange`	TideCloak	Submit complete governance package for VVK signing.
`keyLookup`	TideCloak → Home ORK	Resolve VVK ORK swarm roster via the TWELVE-MAP directory (the self-verifying, Merkle-anchored mapping of key IDs to ORK sets).
`preSignProofs`	TideCloak → all $n$ VVK ORKs	Phase 1 commitment. Each ORK executes Algorithm 1 (Governance Gate) and commits nonces.
`SignProofs`	TideCloak → $I$ participating ORKs	Phase 2 execution. Each ORK re-verifies checksum and computes $\textsf{partialSign}$ per proof.
`commitChangeToDatabase`	TideCloak → Local DB	Persist VVK-signed proofs. Archive draft records and admin signatures.

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