SPECIFICATION · AXIA.IDENTITY.V0 · DRAFT

Identity Governance

Signer types, delegation, signing policies and the distinction between governed and ungoverned provenance. Defines what cryptographic signatures actually attribute.

Cryptographic signatures attribute actions, not human intent.

A valid signature proves possession of a signing key. It does not prove that a human authored the content, that the content is true, or that the signer acted in good faith. Trust derives from the governance around the key, not from the cryptography alone.

1. Scope

This specification defines how signing identities are typed, delegated and governed within Axia. It complements axia.trust.v1 by clarifying who (or what) is cryptographically attributable to a given signature.

The protocol does not adjudicate whether a signer is "trustworthy" in a moral or factual sense. It records signer type, governance status and policy context so that verifiers and auditors can reason about provenance.

2. Identity types

Every identity MUST declare an identity_type from the set below.

An individual signer acting on their own behalf. Identity is bound to a person.

A legal entity (publisher, newsroom, enterprise). Default identity type for verified domains.

A non-AI deterministic system (CMS, build pipeline, camera firmware) signing on behalf of an organization.

An autonomous or semi-autonomous AI system signing content. Requires explicit operator and policy.

A scoped key derived from a parent identity, with delegation expiry and limited scopes.

3. Governed vs ungoverned provenance

The conceptual axis is not "human vs AI". It is governed vs ungoverned provenance.

• governed: signer operates under declared policies, scoped delegation, monitoring and revocation paths.
• ungoverned: signer holds direct authority without declared policies, scopes or operator attestation.
• revoked: signing authority has been withdrawn. Past entries are preserved; trust continuity is downgraded.

Verifiers SHOULD surface governance status alongside identity, and MUST NOT render an ai_agent signature as equivalent to a human signature without that context.

4. Delegated signing model

Organizations SHOULD NOT grant root signing authority to automated systems or AI agents. Instead, delegation SHOULD follow a scoped derivation:

Delegated identities MUST declare parent_identity_id, delegation_scope, delegation_expires_at and agent_operator when applicable.

5. Signing policies

Each identity MAY attach a signing_policy object expressing operational governance. Verifiers and auditors use this for downstream reasoning.

5a. Policy enforcement and violations

Declared signing policies MUST have enforcement semantics. When observed signing activity exceeds declared bounds, the protocol records a signing_policy_violation referencing the specific rule, the declared bound, and the observed value.

• rate_limit_exceeded — signing volume exceeds max_signatures_per_hour.
• dual_approval_missing — policy requires dual approval; only one approval observed.
• unauthorized_content_type — content type outside declared allowed_content_types.
• human_review_bypassed — requires_human_review set true; no review attestation present.
• unauthorized_model — AI agent signed using a model outside allowed_models.
• delegation_expired — signature occurred after delegation_expires_at.
• scope_violation — action outside the delegated scope.
• anomalous_activity — anomaly detector triggered policy review.

Operators SHOULD set auto_revoke_on_anomaly for autonomous signers. Violations are append-only and visible to org members; aggregate violation rates feed into the identity risk tier.

5b. Automation level and risk tier

Every identity carries an internal automation_level and risk_tier. These are used for governance, monitoring and enterprise reporting, and MUST NOT be rendered as a public trust score.

AUTOMATION_LEVEL

• human_supervised — Every signing action passes through human review or explicit human approval.
• low_automation — Automated systems sign with humans in the loop on policy or batch level.
• high_automation — Automated signing is the norm; humans intervene only on alerts or thresholds.
• fully_autonomous — Agents or systems sign without per-action human review under declared policy.

RISK_TIER

• standard — Default tier. Routine publisher activity within declared scopes.
• elevated — Higher-volume or broader-scope signing; requires monitoring.
• high — Sensitive content, regulated domain, or recently revoked-and-restored identity.
• critical — Restricted to operators with witness attestations and policy enforcement.

6. Governance events

The trust ledger accepts the following identity-governance event types:

• delegated_key_created — a parent identity issued a scoped delegation.
• agent_signing_detected — automated/agent activity observed against a key.
• policy_violation — signing activity exceeded declared policy bounds.
• auto_revocation — system or operator revoked an identity in response to anomalous activity.
• identity_revoked — formal withdrawal of signing authority.

7. Rendering rules

UI tier 1 — public

Surfaces MUST present friendly, accurate labels: Verified publisher, Signed origin, Human-reviewed, Publisher-attested disclosure. Surfaces MUST NOT render the phrase "Verified human content" or any equivalent claim that the protocol cannot prove.

UI tier 2 — expanded

Surfaces SHOULD reveal signer type, governance status and (where applicable) operator and delegation context.

UI tier 3 — proof

Surfaces MUST expose the underlying cryptographic and policy semantics for auditors and machine consumers.

8. Boundaries

Axia MUST NOT assert that a signature implies trusted human intent.

Axia MUST NOT prevent AI agents or automated systems from signing. The protocol records signer type and governance, and exposes that context to verifiers.

9. Witness attestations

To mitigate operator compromise, the transparency log MAY be co-signed by independent witnesses. A witness_attestation binds an external signer to a specific root_hash and tree_size.

• third_party — independent operator co-signing roots.
• notary — qualified trust service (eIDAS-style) attesting timestamps.
• regulator — supervisory authority attesting log inclusion.
• federation_node — peer node in a future provenance federation.
• internal_checkpoint — internal redundancy node, lowest assurance.

Witness attestations are public by default. A verifier SHOULD treat a root with multiple independent witness attestations as having stronger continuity assurance than an unwitnessed root.