ENTITY Documentation
Architecture Comparison

ENTITY is not a replacement name for conventional IAM

Identity and access management systems are optimized for authenticating users, assigning roles and controlling access inside an administrative domain. ENTITY extends the problem into portable authority, provenance, rights, governed state transitions and recovery that can survive a particular provider or application.

Conventional IAM

IAM commonly answers questions such as: who is this account, can it authenticate, which groups or roles apply, and which resource may it access inside this environment? Those are essential functions and ENTITY can coexist with them.

ENTITY's additional questions

QuestionTypical IAMENTITY
Authenticate an accountCore capabilityCan integrate with authentication but treats identity/authority as broader protocol state.
Delegate authority across systemsOften provider/domain specificDelegation and revocation are explicit protocol relationships.
Carry provenance with assetsUsually outside IAMProvenance/evidence are first-class governed state.
Represent asset/data rightsOften ACL/role orientedRights and entitlements can be attached to governed objects and transitions.
Survive provider lossDepends on provider/export mechanismsSovereign export and recovery are explicit design boundaries.
Represent economic consequenceUsually externalValue/economic lineage can be represented without becoming automatic entitlement.

Provider custody is not authority

A provider can host keys, accounts, APIs or infrastructure without thereby becoming the sovereign authority represented by ENTITY. That distinction matters when systems migrate, recover, federate or cross organizational boundaries.

Where IAM still fits

Enterprise SSO, directory services, MFA, device posture and workforce lifecycle remain useful. An ENTITY deployment can use those systems as authentication, evidence or policy inputs while preserving a separate protocol-level authority and rights model.

What this comparison does not claim

ENTITY is not presented as a universal replacement for Active Directory, OIDC providers, SAML, PAM, workforce IAM or cloud authorization products. It addresses a broader portability/governance layer and may rely on conventional IAM components in a deployment.

Evaluate the distinction

Inspect the current release and test whether a provider, resolver or host can acquire ENTITY authority merely by operating infrastructure. If that boundary can be crossed without an authorized transition, publish the counterexample.

Review the verification and authority boundaries →