background gif
eni6ma

Applied scenario

Zero-knowledge attribute verification at the request edge

Privacy-preserving authorization (Design)

Illustrative ScenarioReference organization:Illustrative regulated attribute exchange

These Applied Scenarios are illustrative architectures, not case studies of customer deployments. Named organizations are reference points for sector and scale (they have not engaged ENI6MA for the work described). Outcomes are stated conditionally: what would be expected if an estate of this profile implemented the referenced Gate form factor and circuit variant under the reference architecture.

The problem as published

Partners often need to authorize a request based on an attribute (clearance band, residency, license status) without learning or storing the underlying PII. Today that usually means shipping attributes into a shared IdP or stuffing claims into long-lived tokens.

How ENI6MA would apply

ENI6MA would, as a Design-stage capability, bind attribute proofs into the envelope policy path so Gate could accept a request when a zero-knowledge attribute check and the request binding both succeed, without putting raw PII in the authority object. SSO-PII remains Design; this scenario tracks that posture.

Expected outcomes if implemented

  • Would let verifiers accept attribute-gated requests without receiving the underlying PII.
  • Would keep request binding (method, endpoint, body hash, nonce) so an attribute proof alone would not become a reusable bearer.
  • Would surface honestly as Design until SSO-PII and attribute circuits ship beyond documentation.

Reference architecture

Gate: SDK middleware (Design integration) · Circuit / SSO-PII: Design · Control: registry policy_hash for attribute-gated endpoints

Absolute mechanism claims hold under the reference architecture.

HealthcareGovernmentEnterpriseFinanceIdentityZKPrivacy

← All applied scenarios