Identity
Who is the durable principal?
The corporation and its Corporate Digital Name outlive every provider, credential, agent and device below them.
Open specification · v1.5
A small vocabulary for corporate digital authority.
CorpID defines the relationships an enterprise needs to prove. It deliberately does not define a new login system, CA, directory, wallet, cloud or blockchain.
Design law
Every authority claim is an edge with evidence.
The specification does not contain a global “trusted” boolean. Each relationship states who asserted it, what evidence exists, when it was observed, and how strong that evidence is.
Authority
Why may this actor bind the company?
A published governance policy defines who may bind infrastructure, delegate actors and require escalation.
Message
What exact act was authorized?
Signed messages carry action, target, payload, issuer, expiry and nonce so authority travels with the bytes.
Core objects
Seven objects are enough.
Provider-specific features should map into these objects rather than expand the primitive set.
| Object | Purpose | Must survive provider replacement? |
|---|---|---|
| Corporation | Legal person and registry references. | Yes |
| Corporate Digital Name | Durable corporate identifier with stated legal / governance basis. | Yes |
| Authority Policy | Rules for binding, delegation, escalation, rotation and revocation. | Yes |
| Provider Binding | Connects a Microsoft/Google/AWS/Okta/etc. artifact to the Corporate Digital Name. | No — replaceable edge |
| Delegation | Bounds authority for a person, workload, machine, service or AI agent. | No — historical object remains |
| Authority Message | Exact signed corporate intent for a consequential action. | Yes — evidence record |
| Evidence | What supports each relationship and at what depth. | Yes |
Evidence depth
Never confuse origin with truth.
The same lesson applies to corporate authority as to AI data supply chains: a signature can perfectly preserve the origin of a bad claim. CorpID therefore reports what the evidence establishes, not what the interface hopes is true.
Gap
Not measured / not present
The system has no evidence for the edge. Absence is reported explicitly rather than inferred as safe.
Asserted / referenced / observed
Increasingly stronger observations
Self-assertion, externally checkable reference, and an actual retained observation remain distinct.
Signed / provider-issued / contract-verified
Cryptographic evidence
Strong evidence about who produced or authorized bytes. It still does not prove every semantic claim inside those bytes.
Authority message
The unit that travels.
The canonical message is intentionally independent of browser sessions or application accounts.
{
"version": "corpid-authority/1",
"message_id": "msg:…",
"corporation": {
"corp_id": "corp:rootz:0xD36A…1664",
"digital_name": "0xD36A…1664",
"legal_name": "Rootz Corp."
},
"action": "run-regression-suite",
"target": {
"type": "ai-agent",
"id": "gpt-eval-prod"
},
"payload": {
"scope": ["origin", "politics"],
"policy_hash": "…"
},
"issued_at": "…",
"expires_at": "…",
"nonce": "…"
}
Canonicalization
Sorted-key compact JSON
The prototype hashes a deterministic sorted-key JSON representation. Production profiles may later adopt a standards canonicalization method without changing the authority semantics.
Signature
Message signature, not account login
The current prototype supports EIP-191 device signatures and ERC-1271 contract verification. Other signature families can be added as evidence adapters.
Time
Scope and expiry are signed
A verifier forty days later can determine what the actor was permitted to do at the time, even if current policy and credentials have changed.
Provider binding
Microsoft and Google remain infrastructure.
CorpID does not ask an identity provider to become the legal corporate authority. The enterprise causes the Corporate Digital Name — or an unambiguous digest/reference — to appear in the provider-issued claim set. CorpID records the legal/governance side of the same identifier.
Provider artifact
Microsoft / Google / AWS credentialissuer infrastructure and credential proof
Provider side
Shared claim
corporateDigitalName = corp:…same durable identifier carried in the artifact
Join
CorpID record
Corporation + governance + evidencelegal and authority side independently discoverable
Corporate side
Epistery profile
Native bidirectional binding.
The current Epistery IdentityContract already has a world-readable public profile and ERC-1271. CorpID uses those existing primitives rather than creating a parallel authorization system.
IdentityContract.setPublic(
"_profile",
"corporate_authority",
"{\"v\":\"corpid1\",\"corp_id\":\"corp:…\",\"digital_name\":\"0x…\",\"policy_hash\":\"…\",\"authority_uri\":\"https://corpid.rootz.global/api/v1/verify?identifier=…\"}"
)
Security property
CorpID prepares; the contract steward decides.
An existing Epistery rivet signs and submits the profile write. The contract's own authorization gate decides whether the caller may change the profile. CorpID never receives a privileged key and never becomes a steward.
Bidirectional proof: CorpID lists the contract; the contract profile lists the CorpID.
Implementation
Build adapters, not new primitives.
Microsoft Entra, Google, AWS, FIDO, TPM/TEE, Epistery and future systems plug into the same relationship model. The spec should stay boring while the evidence gets stronger.