AuthR — Authorship Representation

Overview

Identity and Access Management has historically answered two questions. AuthN asks who you are. AuthZ asks what you may do. Both were designed for a world where a human sits in front of a terminal, signs in, and directly invokes a system. That world is ending.

Autonomous agents, AI workers, synthetic personas, and verified digital twins now act across time, systems, and teams on behalf of people and organizations. They compose. They re-plan. They chain tools. They run overnight. When something goes wrong — or right — the question that matters is not who signed in, nor what scope did the token carry. The question is: who is ultimately responsible for this action?

This paper proposes AuthR — Authorship Representation — as the third pillar of identity, complementing AuthN and AuthZ. Where OAuth's On-Behalf-Of pattern delegates access, AuthR delegates authorship: it carries grounded responsibility, intent, and lineage across the entire execution graph.

Why AuthR

Naming matters. A new primitive that does not feel native to engineers who already live in AuthN and AuthZ will not be adopted. AuthR was chosen because the ambiguity of R is a feature: authorship, responsibility, and representation are the same idea viewed from three angles. The protocol exists to make all three verifiable.

The six primitives

AuthR defines six primitives. The first four derive directly from the Verified Intelligence pillars (Grounding, Scope, Provenance, Drift) and extend them for identity contexts.

The three operations

# Python reference
from authr import IssuingAuthority, Author, Actor, Intent, Scope

ia = IssuingAuthority(kid="treasury-twin-key-2026-05")

root = ia.issue_root(
    author=Author(id="did:web:acme.com:people:jane-doe", role="CFO"),
    actor=Actor(id="spiffe://acme.com/agents/treasury-orchestrator"),
    intent=Intent(
        purpose="approve_wire_transfer",
        statement="Release Q2 supplier payment. Halt if variance >5%.",
        risk_tier="high",
        human_in_the_loop=True,
    ),
    scope=Scope(
        permitted_actions=["wire.prepare","wire.validate","wire.approve","wire.submit"],
        constraints={"max_amount": 250000, "currency": "USD"},
    ),
)

# Python reference
hop = ia.extend(
    parent=root,
    actor=Actor(id="spiffe://acme.com/agents/wire-validator"),
    attenuated_scope=Scope(
        permitted_actions=["wire.prepare","wire.validate"],  # narrowed
        constraints={"max_amount": 250000, "currency": "USD"},
    ),
)
# Attempting to add wire.cancel here raises:
# ScopeExpansionError: actions {'wire.cancel'} not in parent scope

# Python reference
verifier = Verifier(trust_store=trust_store)
result = verifier.verify_chain([root, hop])

# result.passed  → True
# result.invariants[3].passed  → True (scope monotonically narrows)

# Attempting with a widened scope:
bad_hop = ia.extend(parent=root, actor=validator,
    attenuated_scope=Scope(permitted_actions=["wire.cancel"]))
# Raises: ScopeExpansionError before record is even issued

Verification invariants

A relying party verifies a chain by checking all six invariants in order. Any failure blocks the request before it reaches the resource. Invariants are checked structurally — not by policy, not by the application.

Record structure — v0.1

An AuthR Record is a JSON object signed with EdDSA (Ed25519). The signature covers the canonicalized record minus the signature field itself.

{
  "authr_id": "urn:authr:01HZXQ6K8Y4F9D3W2P7N5V0A1B",
  "version": "0.1",
  "issued_at": "2026-04-20T14:02:11Z",
  "expires_at": "2026-04-20T14:32:11Z",
  "author": {
    "id": "did:web:acme.com:people:jane-doe",
    "type": "verified_digital_twin",
    "role": "CFO",
    "display_name": "Jane Doe (CFO)",
    "grounding": {
      "referent_type": "verified_human",
      "verified_at": "2026-04-20T14:02:10Z",
      "verifier": "acme-hrms",
      "evidence_digest": "sha256:a3f2..."
    }
  },
  "actor": {
    "id": "spiffe://acme.com/agents/treasury-orchestrator/instance-42",
    "type": "agent",
    "model_manifest": {
      "code_hash": "sha256:c81e...",
      "model_hash": "sha256:9f0a...",
      "model_version": "2026.04",
      "signer_id": "acme-ai-governance"
    },
    "attestation": {
      "type": "tee_tdx",
      "evidence_digest": "sha256:...",
      "verified_at": "2026-04-20T14:02:11Z"
    }
  },
  "intent": {
    "purpose": "approve_wire_transfer",
    "statement": "Release Q2 supplier payment per approved schedule.",
    "risk_tier": "high",
    "human_in_the_loop": true
  },
  "scope": {
    "permitted_actions": ["wire.prepare","wire.validate","wire.approve","wire.submit"],
    "resources": ["account:acme-opex-7788","counterparty:acme-supplies"],
    "constraints": {
      "max_amount": 250000.00,
      "currency": "USD",
      "max_delegation_depth": 2
    }
  },
  "provenance": {
    "chain": [],
    "correlation_id": "corr-7e21...",
    "data_sources": [
      { "source_id": "policy:treasury-payments-v7", "source_type": "policy" }
    ]
  },
  "drift": {
    "confidence": 0.97,
    "stale_after": "2026-04-20T14:32:11Z",
    "deviation_signals": []
  },
  "signature": {
    "alg": "EdDSA",
    "kid": "treasury-twin-key-1",
    "value": "..."
  }
}

Relationship to existing standards

AuthR does not replace OAuth, SAML, OIDC, or UMA. It sits above them.

Open questions — v0.2 scope