Vendor Licensing and Payment Lifecycle | Cyber Immunity Whitepaper

Overview

This document specifies the operational lifecycle governing Vendor Licensing and Payment within the Tide Cybersecurity Fabric. Before the network can issue any Anonymous Voucher (Protocol: Anonymous Voucher), the Vendor must be onboarded, funded, and linked to a credit facility. Six phases: initial Stripe checkout, webhook processing, VVK generation with credit facility linkage, admin quorum establishment, automated VRK rotation, and monthly credit refresh.

Loading diagram...

Preconditions

Artifact	Held By	Description
System Home ORK	TideCloak	Network address of the Tide bootstrap ORK for initial routing.
`gPORK`	TideCloak	Public key of the Payer ORK cluster.
Stripe API Credentials	Payer ORK	API keys enabling checkout creation and webhook validation.

Phase 1: Initial License Request and Stripe Checkout

Loading diagram...

TideCloak generates a temporary payment identity (obfGVVK = H2P(G), venID = DH(obfGVVK, vrk)) because VVK does not yet exist. Both are replaced after VVK generation in Phase 3.

The activationPackage contains: subscriptionId, customerId, licenseId, gVRK, payerPublic, maxUserAcc, maxConcAcc. After checkout, TideCloak polls the Payer ORK for activation. The Payer returns false until the Stripe webhook confirms payment (Phase 2). Upon activation, confirmInitialVRK() promotes the pending VRK, initializes the realm, and schedules the first rotation task.

Phase 2: Webhook Processing

The Payer ORK relies strictly on verified Stripe webhooks to alter license states.

checkout.session.completed - On initial checkout:

Fetch Session and Subscription from Stripe API.
Pause subscription (reason: waiting_for_new_key). This prevents Stripe from billing before VRK rotation completes.
Fetch Invoice and Customer.
Issue license with expiry = CurrentPeriodEnd + 7 days. The license record contains:

Field	Description
`LicenseId`	Vendor identity (`obfGVVK`)
`GVRK`	Active Vendor Rotating Key (public)
`Expiry`	Unix timestamp: `CurrentPeriodEnd` + 7 days
`MaxAccounts`	Total user account ceiling for this license
`MaxConcurrentAccountsPerMonth`	Rolling 30-day active user limit
`AllowVendorCreation`	Boolean gate: whether this license permits VVK generation
`VendorCreated`	Counter: VVK generation events consumed (maximum one)
`DebitCounter`	Cumulative usage counter incremented per metered action
`PayerSignature`	Payer's cryptographic signature over the license data

The Payer ORK stores the license indexed by the obfuscated vendor identity. The gVZK (Vendor Zero Key, initially equal to gVRK) is stored on the Vendor record and authenticates all subsequent management requests: subscription updates, cancellations, and portal sessions are verified by checking a timestamp signature against the gVZK.

Per-Action Metering

Every licensed operation increments the license's debit counter by an action-specific cost. The Payer enforces this metering during voucher validation, before issuing a RedemptProof.

Action	Debit Cost	Limit Enforced
`signup`	30	`MaxAccounts` (total user ceiling)
`signin`	10	`MaxConcurrentAccountsPerMonth` (rolling 30-day window)
`updateaccount`	40	`MaxConcurrentAccountsPerMonth` (rolling 30-day window)
`vendorsign`	10	None (fast path, no user tracking)
`vendordecrypt`	5	None (fast path, no user tracking)
`vendorcreation`	30	`AllowVendorCreation` (boolean, once per license)
`reserve`	10	`MaxAccounts` (total user ceiling)

Two distinct capacity limits operate independently:

Total accounts. The MaxAccounts ceiling limits the total number of user identities ever created under this license. Enforced on signup and reserve actions. Once the ceiling is reached, new account creation is rejected regardless of how many accounts are currently active.
Concurrent active accounts. The MaxConcurrentAccountsPerMonth limit counts distinct users whose last activity falls within a rolling 30-day window. Enforced on signin and updateaccount actions. A user whose last activity was more than 30 days ago does not count against this limit, even if their account still exists.

VVK generation is gated separately. The AllowVendorCreation flag permits exactly one vendorcreation action per license. Once the VendorCreated counter reaches the maximum, subsequent VVK generation requests are rejected. This ensures each license produces at most one organizational master key.

The debit counter provides aggregate usage visibility but does not itself gate operations. Capacity enforcement is performed by the specific limit checks above. The counter serves as an audit and billing reconciliation mechanism during monthly settlement.

invoice.payment_succeeded - On subsequent monthly renewals:

If billing_reason == "subscription_create": no action (handled above).
Otherwise: validate Subscription, pause (reason: waiting_for_new_license), issue renewed license with CurrentPeriodEnd + 7 days expiry.

Phase 3: Credit Facility Creation and VVK Linkage

With the license active, the Vendor generates its master identity (VVK) and cryptographically links it to the credit facility.

Loading diagram...

VVK generation is a metered operation, so TideCloak generates the first Anonymous Voucher using the funded VRK: vrk.genVoucher(obfGVVK, gPORK). TideCloak prepares a VRK-signed authorization (auth) with a 30-second expiry and random VVKiD, defines permittedORKs (100 ORKs for CVK/VVK) and TcloakSettings (return URL, gVRK, crypto model, flags).

The VVK ORKs verify gVRK with the Payer, execute Nested Shamir DKG, and register the key record on the TWLEVE-MAP directory with authority: gVRK - allowing setup to proceed before governance is established. Authority transfers to gVVK in Phase 4.

The VVK ORKs execute four signatures: permittedORKs, SignedSettings, gVRK attestation, and a semi-blind signature over gVRK with VVK (Algorithm 1). TideCloak derives the credit facility's permanent identity index and the Payer replaces the temporary venID with Y'' = gVVK · H(vrk).

Phase 4: Admin Quorum Establishment

TideCloak signs the admin creation request with VRK and routes createAdmin(gVVK) to the CMK ORKs. The CMK ORKs verify gVRK with the Payer, execute the signUp/signIn PRISM flow, and return a blindSig for the new administrator.

TideCloak compiles the governance structure:

text

signedAdmins = {
    member[1].publicKey = gCMKAuth,
    member[1].keyType = BEd255475,
    threshold = 0.7
}

The threshold value specifies the required quorum fraction: for i total admins, n = max(1, int(threshold × i)) must approve any governance change.

TideCloak signs this configuration with VRK and submits it to the VVK ORK swarm. The swarm verifies the VRK signature and gVRK funding status with the Payer, then threshold-signs the signedAdmins object with VVK.

The VVK ORKs issue the authority transfer:

text

updateKeyMAP(VVKID, gVVK, authority: gVVK)

This replaces authority: gVRK with authority: gVVK. Future modifications to the VVK swarm, admin roster, or authorization policies require a VVK-authorized threshold signature governed by the established quorum (Article 5: Governance Without God Mode). The VRK becomes a payment and communication delegate only.

TideCloak initializes the VRK rotation task scheduler and signs the finalized SignedSettings.

Phase 5: VRK Rotation Lifecycle

The VRK rotates monthly to limit compromise exposure, ensure per-period accounting, and prevent cross-period linkability. Three scheduled tasks govern this lifecycle.

Loading diagram...

Task 1: VRKGenerationTask - Executes at CurrentPeriodEnd - 1 day.

TideCloak retrieves SubscriptionInfo, generates a new VRK, and checks IsPendingLicenseActive(). If a pending license exists, the task exits. Otherwise, TideCloak generates the new VendorId, sends UpdateSubscription to the Payer, and marks the new VRK as pending. Schedules RotateVrkTask at CurrentPeriodEnd + 1 hour.

The Payer's UpdateSubscription handler validates against Stripe, lists draft invoices, and evaluates debt: if >12 consecutive unpaid months, rejects and initiates recovery. Otherwise, sets AutoAdvance = true on drafts, resumes the subscription (preserving billing anchor), and returns success.

Task 2: RotateVrkTask - Executes at CurrentPeriodEnd + 1 hour.

TideCloak retrieves GetLicenseDetails from the Payer. If the license is not yet active or the invoice is unpaid, TideCloak reschedules for +1 day. If active, TideCloak executes RotateVrk(): TideCloak signs the new gVRK with the current VRK private key, producing the pendingGVRKCertificate (certificate chain - the retiring key attests its successor). TideCloak schedules SwitchVRKTask at license expiry and the next VRKGenerationTask at next billing - 1 day.

Task 3: SwitchVRKTask - Executes at CurrentPeriodEnd + 7 days (license expiry).

TideCloak checks IsPendingLicenseActive() via the Payer. If inactive, reschedules for +1 day. If active, executes SwitchVRK(): the pending VRK is promoted to active; the retiring VRK is destroyed.

VRK Rotation Timing

Day	Action
0	Billing period starts. `VRK_A` active.
~28	`VRKGenerationTask`: `VRK_B` generated, registered as pending.
~29	Billing period ends. Stripe processes invoice.
~29 + 1hr	`RotateVrkTask`: verify license, build certificate chain, schedule switch.
~29 + 7d	`SwitchVRKTask`: `VRK_B` promoted to active. `VRK_A` retired.

The 7-day grace period (license expiry = CurrentPeriodEnd + 7 days) ensures operations using the retiring VRK continue uninterrupted while payment clears and the new VRK propagates.

Phase 6: Monthly Pre-Payment and Credit Refresh

On each monthly rotation, TideCloak prepares a renewal package:

text

newVRK = genKey()
newGVRK = newVRK.getPublic
newObfGVVK = DH(H2PVVK, H(newVRK.getPrivate))

renewalReq = {
    "VRKRenewalRequest",
    newGVRK,
    newObfGVVK,
    capacity,
    fromDate,
    toDate
}
renewalSig = VRK.sign(renewalReq)

TideCloak transmits the signed renewal to the VVK ORKs (which return updated SignedSettings) and to the Payer ORK. The Payer validates and writes the facility record to mimDB:

text

mimDB Facility Record:
  Index: H(gVRK)
  facilityID: gVRK
  credit, from, to

The Payer updates its internal store: Index: newObfGVVK → newGVRK, Capacity. Vouchers generated with the new VRK validate against this refreshed credit facility.

Algorithms

Algorithm 1 context: The Payer must track the Vendor's credit facility across billing cycles without learning the Vendor's master identity (gVVK). The VVK ORKs produce a semi-blind signature that binds the ephemeral VRK to the organizational VVK.

Algorithm 1: Semi-Blind Facility Linkage

Inputs:

v

(VRK private scalar),

V = G \cdot v

(gVRK public),

Y = gVVK

(master public key),

y_i

(VVK shard per ORK

i

)
Output: Facility permanently indexed by

Y'' = gVVK \cdot \textsf{H}(vrk)

. The Payer cannot reverse

\textsf{H}(vrk)

to recover

gVVK

Provisional credit facility. TideCloak computes $Y^{tmp} = G \cdot \textsf{H}(v)$ and registers a provisional facility with the Payer: index $V$ , id $Y^{tmp}$ .
AnonSign. Each VVK ORK $i$ generates $r_i \overset{\$}{\gets}$ ℤ $_\ell$ , computes $R_i = Y^{tmp} \cdot r_i$ , and returns $R_i, Y_i = G \cdot y_i$ .
Aggregation. TideCloak computes:
- $R = \sum_{i=1}^{t} R_i$
- $Y = \sum_{i=1}^{t} Y_i \equiv G \cdot y = gVVK$
- $Y'' = Y \cdot \textsf{H}(v) = gVVK \cdot \textsf{H}(vrk)$
Partial signing. Each ORK $i$ computes $s_i = r_i + \textsf{H}(R, Y'', V) \times y_i \times l_i$ where $l_i$ is the Lagrange coefficient.
Finalization. TideCloak computes $s = \sum s_i$ and $yProof = [R,\ s \cdot \textsf{H}(v)]$ .
Facility update. TideCloak signs $vProof = \textsf{sign}_v(Y'')$ and sends $\textsf{UpdateLicense}(V, Y'', YProof, vProof)$ to the Payer.
Payer verification. Payer verifies $\textsf{verify}_V(vProof, Y'')$ and $\textsf{verify}_{Y''}(YProof, V)$ , then updates the facility: index $V$ , id $Y''$ .

Notation Reference

Symbol	Description
$G$	Generator point on the selected elliptic curve.
$\textsf{H}(\cdot)$	Cryptographic SHA256 hash function.
$\textsf{H2P}(\cdot)$	Hash-to-point operation.
$\textsf{DH}(A , b) \equiv \textsf{H}(A \cdot b)$	Diffie-Hellman key exchange function.
$vrk$ , $gVRK$	Vendor Random Key (private / public). Ephemeral payment identity, rotated monthly.
$vzk$ , $gVZK$	Voucher Zone Key (initially $= vrk / gVRK$ ).
$VVK$ , $gVVK$	Vendor Verifiable Key (private aggregate / public). Master organizational identity.
$Y''$	Obfuscated VVK: $gVVK \cdot \textsf{H}(vrk)$ . Payer facility index.
$Y^{tmp}$	Provisional credit facility identity: $G \cdot \textsf{H}(v)$ . Used before VVK exists.
$venID$	Temporary vendor identity during onboarding: $\textsf{H2P}(G) \cdot vrk$ .
$gPORK$	Public key of the Payer ORK cluster.
$\textsf{VVKID}$	Random identifier for the Vendor Verifiable Key record on the TWELVE-MAP directory.
$permittedORKs$	100-ORK roster authorized for CVK/VVK operations.
$\textsf{SignedSettings}$	VVK-signed configuration: return URL, gVRK, crypto model, flags.
$\textsf{signedAdmins}$	VVK-signed admin quorum: member keys, key types, threshold fraction.
$\textsf{activationPackage}$	Payer ORK response: Stripe session IDs, gVRK, license limits.
$\textsf{RedemptProof}$	Payer-signed receipt confirming voucher validation (sibling protocol).

Actors

Actor	Description	Role in This Protocol
Admin	Human administrator.	Initiates license request, completes Stripe checkout, triggers manual renewals.
TideCloak	Vendor's IAM server.	Orchestrates lifecycle: checkout sessions, activation, VRK task scheduling, rotation state. Generates VRKs, communicates with ORK swarms, signs renewal requests, generates vouchers.
Payer ORKs	Scrutinized payment-handling nodes.	Creates Stripe sessions, receives webhooks, issues licenses, tracks credit facilities/balances, manages subscriptions.
VVK ORKs	20 nodes holding VVK shards.	Generate VVK during onboarding, semi-blind-sign gVRK, sign settings and admin quorums, register key mapping on TWELVE-MAP.
CMK ORKs	Nodes holding user identity shards.	Create admin accounts, validate gVRK with Payer during operations.
Stripe	External payment processor.	Checkout, subscription billing, invoicing, webhooks.
mimDB	"Mimir" Database - Append-only Fabric synced registry. Stores committed records, Accountable Group Signatures, TWELVE-MAP entries.	Stores facility records, key map records (VVK → ORK swarm mapping), license metadata.
TWELVE-MAP	Tide Wide Enumerated Ledger of Verifiable Entries - Mapping Authoritative Pointers is the self-verifying directory service on mimDB.	Mapping key identifiers to ORK swarms.

Layer Traversal

Layer	How This Protocol Engages It
Legitimacy	VRK registration with Payer establishes the Vendor's legitimacy. License validity dates enforce temporal legitimacy.
Authority	VVK signs admin quorum, permittedORKs, and settings. Authority transfers from gVRK to gVVK after admin establishment.
Agency	Every Agency Layer operation requires gVRK verification at the Payer. The voucher (sibling protocol) is the per-operation gate.
Settlement	Primary layer. This protocol defines the Settlement Layer's operational infrastructure: Credit Facility management, licensing, Stripe integration, VRK rotation.

Security Properties

Property	Mechanism	Assumption
Payment-before-service	Every ORK operation requires Payer validation of gVRK. No valid license = no service.	-
Exposure limitation	Monthly VRK rotation limits the window of a compromised payment key. Each period uses a fresh key.	Server integrity during key generation.
Facility unlinkability	Payer indexes facility by $Y'' = gVVK \cdot \textsf{H}(vrk)$ . Without $vrk$ , the Payer cannot recover $gVVK$ . Monthly rotation changes $Y''$ .	Collision resistance of hash function.
Certificate chain	Retiring VRK signs incoming gVRK. Verifiable succession without quorum-gated VVK signature per rotation.	Unforgeability of signature scheme.
Licensing enforcement	Payer tracks two independent limits per facility: total accounts (`MaxAccounts`) and rolling 30-day concurrent active users (`MaxConcurrentAccountsPerMonth`). Exceeded limits → voucher rejection for the gated action type.	Database integrity at Payer.
Grace period resilience	License expiry = `CurrentPeriodEnd + 7 days`. Covers Stripe webhook delays and VRK propagation.	-
Billing synchronization	Stripe subscription paused before VRK generation, resumed after rotation. Prevents billing/key desynchronization.	Stripe API reliability.
Debt protection	>12 unpaid months triggers recovery. Prevents unbounded debt from abandoned tenants.	-
Semi-blind Facility Linkage	VVK ORKs compute semi-blind signature over gVRK without observing $vrk$ . Unforgeable bond between master identity and credit facility.	Security of Nested Shamir DKG.
Authority transfer	TWELVE-MAP directory authority transitions gVRK → gVVK. Post-transfer, governance changes require VVK-authorized quorum.	TWELVE-MAP ZK-proven integrity.

Call Summary

Call	Direction	Phase	Purpose
`CreateCheckoutSession`	TideCloak → Payer ORK	1	Initiate Stripe session with billing anchor.
`CreateCustomer` / `CreateSession`	Payer ORK → Stripe	1	Create Stripe customer and checkout session.
`IsLicenseActive`	TideCloak → Payer ORK	1	Poll for license activation (1s intervals, 60s timeout).
`Webhook: session.completed`	Stripe → Payer ORK	2	Trigger license issuance on initial checkout.
`Webhook: invoice.payment_succeeded`	Stripe → Payer ORK	2	Trigger license renewal on monthly billing.
`GenVVK`	TideCloak → VVK ORKs	3	Generate master VVK via distributed key generation.
`addKeyMAP`	VVK ORKs → mimDB	3	Register Vendor key record (initially authority: gVRK).
`updateLicense`	TideCloak → Payer ORK	3	Replace temporary facility ID with permanent $Y''$ .
`createAdmin`	TideCloak → CMK ORKs	4	Create administrator accounts via PRISM.
`signVVK(signedAdmins)`	TideCloak → VVK ORKs	4	VVK-sign the admin quorum configuration.
`updateKeyMAP`	VVK ORKs → mimDB	4	Transfer key authority from gVRK to gVVK.
`GetSubscriptionInfo`	TideCloak → Payer ORK	5	Retrieve billing state for VRK generation.
`UpdateSubscription`	TideCloak → Payer ORK	5	Register new VRK, resume Stripe subscription.
`IsPendingLicenseActive`	TideCloak → Payer ORK	5	Check pending license before switch.
`VRK.sign(renewalReq)`	TideCloak → Payer ORK	6	Monthly pre-payment and credit refresh.

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.
Tide Developer Documentation: docs.tidecloak.com
Stripe API Reference: stripe.com/docs/api