Skip to content
ECZ-IDDevelopers
Concepts: all pages

Concepts

Authority

Authority answers who authorised the work. In ECZ-ID it is recorded on an Intent by an accountable principal, and it is never inferred from a Passport, a payment or a binding.

Live · signed-in operation in TrustOps

Live in production and operated by the account holder, signed in, through the TrustOps Dashboard. There is no public, unauthenticated developer API for it.

Accountability Chain:Authority

Who authorised it

An ECZ-ID Intent is authorised by an accountable principal of the operating organisation. Core records the authorisation on the Intent itself: what kind of authorisation it was, which principal gave it, in what role, when, and a digest of the evidence.

ElementCore values
Authorisation kindPRINCIPAL_ASSERTION (a principal authorised it directly) or DELEGATION_CHAIN (it derives from a parent Intent)
Principal roleOWNER, ADMIN or OPERATOR_OF_RECORD
Who may authoriseAn owner or an admin. A member may submit an Intent, which then waits in APPROVAL_REQUIRED.
VersionsA new version of an Intent needs fresh authorisation.

What is never authority

  • A Passport. Identity says who acts. The Resolver lists agent_authority, api_authority and action_authority among the things a record must not be read as establishing.
  • A payment. Buying a plan gives an entitlement. Authority comes only from an authorised Intent in force.
  • A binding. Proving control of an origin or package says nothing about what may be done with it.
  • A credential in your stack. Your OAuth scopes and API keys are permissions. They stay in your identity and access systems; ECZ-ID does not issue, read or replace them.

Related

This page is explanation, not authority. Current state is only ever the live Resolver record. Live facts on this page were measured read-only on 2026-10-10.