The company creates a durable digital name and keeps a public record, under its own control, of who may act for it. Enterprise PKI, cloud identity, certificates, people, machines and AI agents attach underneath that root. Whoever receives the work — or their AI — checks it and decides.
Shareholders govern through the board. The board governs corporate digital authority. Microsoft, Google, enterprise PKI, external CAs, domains, hardware systems and Rootz itself remain infrastructure or evidence beneath the corporation.
The chain is a place the company controls and anyone can read, independent of the providers, credentials and directories it may later replace or revoke. Don't take our word for it: the Rootz specimen's root is a 2-of-3 Safe on Ethereum, and its acts are shown live at /verify/rootz.
The identity remains under corporate governance rather than becoming subordinate to Rootz, Microsoft, Google or a certificate authority. The board can rotate control, infrastructure and delegated actors without replacing the corporation's digital name.
Authorization and revocation stay visible over time. Whoever receives an old act can check whether the actor was authorized when it happened, even after today's credentials have changed.
It does not make the company legally valid, make a claim true, or replace board/shareholder governance. It provides a durable, independently inspectable place for the corporation to exercise digital authority. We publish the limits as plainly as the claims.
That is the gap CorpID closes. Rootz's reference specimen uses a Delaware DBA that references its cryptographic address. The legal naming evidence gives outsiders an independently discoverable join to the Corporate Digital Name.
CorpID records public evidence of how the root is controlled. It never receives or holds keys.
The Safe is the corporate smart account. Multiple owners retain separate hardware-protected signer keys and approve according to a threshold such as 2-of-3.
One public signing address is controlled by a hardware device, with governance and recovery documented separately.
A mature enterprise may keep its established HSM or signing process and expose only public authority references and evidence.
A Safe is a smart account controlled by its owners. Those owner keys can themselves be hardware-protected. CorpID records the Safe address, threshold, signer protection and recovery policy—not private keys or seed phrases.
An enterprise may create and operate its own self-signed PKI root under its own internal policy. Microsoft may supply infrastructure for that process; Microsoft is not automatically the authority that certifies the corporation.
Record the enterprise PKI root as an authorized infrastructure binding under CorpID. CorpID explains why the corporation recognizes that root and preserves the authorization/revocation history.
A DigiCert or other externally issued certificate is third-party evidence. It may strengthen claims that issuer actually validated, but it never sits above the corporation or becomes the source of CorpID authority.
Provider-specific adapters map back to these acts; none creates a new root of authority.
This corporation recognizes this durable cryptographic identifier, supported by stated legal/governance evidence.
Recognize an enterprise PKI root, provider, key, person, machine, workload or AI agent for a defined scope and time.
Terminate recognition without depending on the provider or credential being revoked. Preserve the historical record.
Every object exists to answer an authority or evidence question.
| Object | Purpose |
|---|---|
| Corporation | Legal person and registry references. |
| Corporate Digital Name | Durable cryptographic identifier and stated legal/governance basis. |
| Root Control | Public description/evidence of how corporate authority is controlled and protected. |
| Authority Policy | Rules for authorization, delegation, escalation, rotation and revocation. |
| Infrastructure / Provider Binding | Connects PKI, cloud identity, HSM, CA or contract evidence beneath the Corporate Digital Name. |
| Delegation | Bounds authority for a person, workload, machine, service or AI agent. |
| Authority Message | Exact signed corporate intent for a consequential action. |
| Evidence | What supports each link, and how deep that evidence goes. |
Every item says what its evidence proves — and what it does not. The recipient decides what is enough.
No evidence exists for this item. The gap stays visible.
Self-assertion, externally checkable reference and retained observation remain distinct.
Strong evidence of who signed or authorized the bytes — not proof that what they say is true.
The employee creates their own address; the corporation authorizes it. The authorization expires; the key does not. A delegation therefore carries two fields beyond its scope: a title, and a grade.
A scope is not a title. The title is what a counterparty actually asks for, and it is already a mandatory field in federal rule — box 3a of the FinCEN beneficial-ownership certification — collected on the honour system and verified nowhere.
The same vocabulary grades a corporate document, an email and an identity credential. acquisition (ordinal) is how we came to hold it, on the unchanged ladder above. strength (ordinal) asks one question — can a third party re-verify it? — across self-asserted, examined, issuer-attested, issuer-signed. factors is a set, not a rung: document, biometric, device-bound, activation-factor. method records the mechanism and is deliberately not ordinal.
A biometric describes what happened at issuance, not whether the result is independently verifiable. A photocopied passport is biometric-backed and proves nothing to a stranger; a DKIM-signed email carries no biometric and can be re-checked by anyone, forever. Making biometric a rung would rank the photocopy above the signature.
Keeping factors as a set also makes multifactor derived — two or more — rather than something a form can assert. And it lands on the federal definition exactly: a credential meeting the 8 September 2026 US verifiable-digital-credential definition is issuer-signed with factors device-bound and activation-factor.
The corporation asserts its own grade. The relying party measures the evidence beneath it and may disagree. Rootz is never the grader of record. The grade measures the verification event the corporation performed — it is not a rating of the person, and it never records which identity document was examined or its contents.
REVOKE ends authority from that point forward. It does not rewrite the past: a message signed before the revocation still verifies as of its own date. Always evaluate authority as of the signing instant, never as of today.
For a person, subject_id is their Rootz V6 Identity contract — an EIP-1271 smart account holding multiple authorized device rivets (Secure Enclave on macOS, TPM on Windows) — never a raw device key. One durable address across machines, and losing a device does not lose the identity or the record built against it.
Key recovery is a second rivet. No seed phrase, no escrow, nothing the employer holds. A corporation may pay the gas to deploy an employee's identity; paying is not control, and a corporation is never a rivet on an employee's identity.
The corporation authorizes by transacting against its own root. The chain holds the authorization. Neither CorpID nor any other Rootz software is the authority, and neither is required in order to validate — the evidence is public on chain to the root, so any RPC client, any block explorer or a third party's own verifier can check it. Each authorization is a transaction that extends the quality of the root and what it can claim.
Did this identity sign these exact bytes? The Identity contract answers, via ERC-1271. What was it authorized to do, by whom, at that moment? The corporation's authority state answers. Neither implies the other: a valid signature from an unauthorized identity is a signature by a stranger, and a valid authorization with no signature is a personnel record.
Authorizations are not yet published on chain. They are held in this service's database, so today validation still depends on this service. That is the design's largest open item, not a claim we are making.
The rule that closes it: contract-verified-message may be claimed for a delegation only when the authorizing transaction can be read back from chain. An unanchored record is asserted and says so.
A consequential action carries its authority with it: exact corporation, action, target, payload, time, expiry and nonce, under signature — checked by the receiving system before it acts.
People and their AI get the same model at two depths. Start machine discovery at /.well-known/corpid.json.
Part of the Rootz family: CorpID answers who authorized it; Rootz Receipts attaches the answer to an agent's result; Rootz Data Centers carries it in every exchange.