Solutions · By problem
Replace or augment PKI
Public key infrastructure (PKI) still leaves reusable request credentials in place even when certificates and mTLS are healthy. ENI6MA replaces the part of PKI that keeps breaching you (the credentials that authorize requests). Certificate hierarchies and mTLS can stay.
PKI coexistence
PKI remains for channel while ENI6MA owns request authorization
Migration in four steps
Inventory, shadow, proof-required, then retire migration steps
Fighting the entire certificate ecosystem is the wrong war. Channel identity (mTLS, device certs, document signatures) remains useful. The failure buyers have lived through is reusable request credentials: bearer tokens and service certificates used as capabilities that work from anywhere until rotation catches up.
ENI6MA layers request-level authorization on top. An envelope (a one-time cryptographic authorization for a single request) proves that this message may change the world once. Gate enforces that proof at the request boundary; Control holds the registry and durable nonce ledger; Foundry mints the per-identity circuits that produce the proofs. Coexistence is the default migration posture. See Security → Coexistence for the staged path that keeps your IdP and certificate estate intact while high-risk routes flip to proof-required.
What this solution claims
ENI6MA replaces the part of PKI that keeps breaching you (the credentials that authorize requests) while certificates and mTLS can stay.ValidatedTransport identity (mTLS/PKI) coexists with request-level envelope authorization.
An envelope minted for one endpoint_id cannot authorize a different route.ShippingThe gate recomputes digests against its own endpoint_id and policy constants, not the client’s self-description.Holds under the reference architecture
SSO, federation, and PII
Enterprises already federate identity with SSO while still authorizing mutations with reusable tokens. SSO-PII is a design for keeping single sign-on and PII with your IdP while request authority still expires per call through ENI6MA proofs. It is specified on paper only: no runtime code, and not for purchase.
Enterprises already run OIDC, SAML, SCIM, and LDAP for who a person is. ENI6MA does not replace that authentication plane. The open design question is how to keep PII and directory attributes out of the authorization artifact while still binding an envelope to the exact action a federated user is about to take.
SSO-PII is specified on paper; no runtime code exists yet.Design targetREADME states no runtime code created yet.
Design badge. There is no evaluation, purchase, or get-started path yet. When a runtime ships, the public badge will update. Until then, treat this as design-only. Deploy Gate with your existing IdP for authentication.