Developer manual · identity

Identity API

ENTITY identity is a persistent sovereign root, not a login account. The v3.4.2 reference implementation uses signed manifests, Ed25519 operational keys, dedicated recovery keys, explicit key rotation and optional hardware key protection.

Identifier forms

The canonical runtime accepts ent1- and ent2- Entity IDs with a fixed base32 form. New identities are created as ent2- identifiers. Supported public entity types include person, family, business, product, application, system, community, service, organization and project.

Create an Entity

EntityIdentityVault.create(display_name, entity_type, aliases, metadata) creates a new identity manifest plus two Ed25519 key roles: an operational signing key for assertion/authentication/contract use and a separate recovery key. The signed manifest records aliases, metadata, verification methods, the active signing key, recovery policy, crypto-agility metadata, creation time and manifest revision.

Storage boundary: the reference vault stores private key material under the local identity state directory. Operators must protect that directory. Hardware-backed wrapping can be supplied through the key-protector interface; hardware custody is still a post-release qualification gate, not a completed v3.4.2 claim.

Manifest verification

verify_manifest() validates schema, Entity ID syntax, active verification method, signature suite, signature, and—where present—rotation or recovery continuity proofs. Invalid or conflicting public manifests fail closed.

Signing records

sign(entity_id, payload) produces an entity-signature-record-v2 containing the Entity ID, active key ID, suite, signing time and payload SHA-256. A bounded bulk signing session can cache a validated operational key while preserving the same record schema.

Rotation

rotate_signing_key() retires the previous operational key, creates a replacement, increments the manifest revision, binds the new manifest to the previous manifest hash, signs a rotation proof with the old key and signs the new manifest with the new key. The previous private operational key is then removed from local key material.

Recovery

Recovery uses a verification method explicitly designated for the recovery purpose. A recovered operational key is not accepted merely because a new key exists; the manifest carries a signed recovery continuity proof tied to the Entity ID, new key and manifest revision.

Application rule

Do not treat a database user ID, OAuth account, hostname, wallet address, application installation or device as the sovereign Entity unless an explicit ENTITY relationship establishes the required authority. Applications should request scoped authorization from an Entity rather than impersonating the Entity root.

Canonical protocol identity is separate

The canonical ENTITY protocol identity and the Shawn Blackmore → Blackmore Technology Group → ENTITY release lineage identify the protocol origin. They do not make BTG the owner or controller of downstream user identities or assets.

Inspect implementation Operator key procedures