Access & Policy

Identity, attributes, policy and execution as separate control boundaries

Identity evidence does not automatically grant an application action. MEMM separates identity, attributes, policy evaluation and execution so each decision can have its own input, version and owner. The current development model includes a versioned identity-evidence boundary for EUDI Wallet, Health ID and eID-LE contexts.

Topics:IdentityAttributesPolicyAuthorizationZero Trust

Four questions instead of one “authenticated” flag

  • Identity: what evidence identifies the subject?
  • Attributes: which claims are available and in which versioned context?
  • Policy: which rule set evaluates the requested action?
  • Execution: which component owns the final action and its effects?

Why the separation matters

Keeping these controls distinct avoids treating a valid credential as universal authorization and keeps external evidence separate from application-specific policy.

What this page explicitly does not claim: The architecture does not establish general OIDC or federation support, ZETA conformance, identity-provider status or authorization correctness for every deployment.