Protocol v0.1

AuthorshipRepresentation

The third pillar of identity for the agentic era.

AuthN proves who you are. AuthZ decides what you can do. AuthR proves whose judgment drove the decision — and carries that proof, cryptographically, across every hop of an agentic execution graph.

✓ solved
AuthN
Authentication
Who are you?
✓ solved
AuthZ
Authorization
What can you do?
◎ AuthR
AuthR
Authorship Representation
Whose judgment drove this?

Identity infrastructure was built for humans at terminals.
That world is ending.

Autonomous agents, AI workers, 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 — OAuth's On-Behalf-Of can tell you which token was used. It cannot tell you whose judgment was behind it.

Intent drift is invisible

An OBO token propagates access. If the orchestrator re-plans and issues a wire with different rationale — same API call, different judgment — the token still passes. The CFO's original intent disappears with no structural trace.

Accountability chains don't exist

Multi-agent executions span hours, services, and model versions. Current standards answer which token was used and what scope it carried. They cannot answer whose judgment was executed across an async, multi-hop agent graph.

Scope enforcement is application-layer

A compromised sub-agent can attempt to widen its permissions. With OBO there is no structural enforcement — only application-layer policy that assumes agents are well-behaved. Rejection happens too late, if at all.

AuthR doesn't replace OAuth, OIDC, or SAML.
It adds authorship above them.

Where OAuth's On-Behalf-Of delegates access, AuthR delegates authorship: it carries grounded responsibility, intent, and lineage across the entire execution graph. AuthR sits above existing identity infrastructure without displacing it.

AuthRAuthorship · Intent · Provenance · Drift
↑ sits above, does not replace
OAuth 2.0 / OIDC
SPIFFE / SPIRE
W3C DIDs / VCs

Every AuthR record carries six first-class fields.

These are not metadata. They are structural primitives — cryptographically bound, inherited across hops, and enforced at the verification boundary. Together they make authorship provable, not just claimed.

Author
The grounded human, twin, or committee whose judgment is executed
Separates authorship from execution — the structural move that makes responsibility provable across every hop.
Actor
The agent, AI worker, or tool that actually runs the code
Bound to a measured model manifest and runtime attestation — not just an opaque token.
Intent
The why — canonical purpose, natural-language statement, risk tier, HITL flag
Inherited across hops, never reinvented. Makes intent drift legible and structurally detectable.
Scope
Explicit limits — permitted actions, resource constraints, monetary caps, max delegation depth
Attenuates monotonically. No child record can claim more than its parent — enforced at the verifier.
Provenance
Lineage — parent record IDs, correlation ID, data sources consulted at decision time
Without provenance, authorship is a claim with nothing behind it. Provenance makes it auditable.
Drift
Confidence at decision time, stale_after timestamp, observed deviation signals
A record that is not drift-aware is not really governed — it is hopeful. Drift is a first-class primitive.

Issue. Extend. Verify.

AuthR defines three core operations. Everything in the protocol flows through these three verbs — from the moment the CFO authorizes a wire to the moment the resource service decides whether to proceed.

01
Issue Root§5.3.1

The Issuing Authority mints a signed root AuthR record. Author, actor, intent, scope, and provenance are cryptographically bound at authorship time — not at execution time.

The root record anchors the entire chain. Everything downstream inherits from and traces back to this record.

02
Extend Chain§5.3.2

Each delegation hop creates a child record linked to its parent. Scope attenuates monotonically — the child can only narrow, never widen. The original author is preserved across every hop.

The orchestrator knows exactly what the CFO authorized. The sub-agent knows what the orchestrator delegated. No hop can invent new permissions.

03
Verify Chain§5.3.3

The enforcement point — an API gateway, MCP server, or resource service — verifies all six invariants structurally before any action reaches the resource.

A compromised sub-agent that claims wire.cancel when the root only authorized wire.submit is rejected before the request lands. Structural, not aspirational.

Reference implementation — PythonView on GitHub ↗
from authr import IssuingAuthority, Verifier, Author, Actor, Intent, Scope

ia = IssuingAuthority(key_id="treasury-twin-key-1")

# The CFO authorizes a $180K wire via her verified digital twin
root = ia.issue_root(
    author=Author(
        id="did:web:acme.com:people:jane-doe",
        type="verified_digital_twin",
        role="CFO"
    ),
    actor=Actor(
        id="spiffe://acme.com/agents/treasury-orchestrator",
        type="agent"
    ),
    intent=Intent(
        purpose="approve_wire_transfer",
        risk_tier="high",
        human_in_the_loop=True
    ),
    scope=Scope(
        actions=["wire.prepare", "wire.validate",
                 "wire.approve", "wire.submit"]
    ),
)

# The orchestrator delegates a narrower scope to the validator
hop = ia.extend_chain(
    parent=root,
    actor=Actor(id="spiffe://acme.com/agents/wire-validator"),
    scope=Scope(actions=["wire.prepare", "wire.validate"])
    # wire.approve and wire.submit removed — monotonic attenuation
)

# Wire service verifies before any action reaches the resource
Verifier(
    trust_store={"treasury-twin-key-1": ia.public_key}
).verify_chain([root, hop])
# Returns True — all six invariants pass
# A hop claiming wire.cancel would raise AuthRError here

For a chain to verify, all six MUST hold.

Verification is structural, not operational. A sub-agent cannot widen its scope at the application layer — the verifier rejects it before the request reaches any resource. One failed invariant invalidates the entire chain.

01
Signature validity
Every record in the chain is signed by a key present in the trust store
§5.3.3 inv.1
02
Not expired
The record's expires_at field has not passed at the moment of verification
§5.3.3 inv.2
03
Stable author
author.id is identical for every record in the chain — authorship cannot be transferred between hops
§5.3.3 inv.3
04
Monotonic scope
Every child record's permitted_actions is a strict subset of its parent's — scope widening is structurally impossible
§5.3.3 inv.4
05
Chain continuity
provenance.chain links unbroken with a single correlation_id across all hops in the execution graph
§5.3.3 inv.5
06
Revocation supremacy
A revoked record invalidates the entire downstream chain regardless of individual record validity
§5.3.3 inv.6

Three planes. One trust model.

AuthR operates across a control plane, an execution plane, and an enforcement plane. Each has distinct responsibilities — and distinct failure modes the protocol explicitly accounts for.

Control Plane
Issuing Authority — signs records; holds the root key
Registry — resolves grounded authors and actor manifests
Revocation Service — propagates invalidations downstream
Execution Plane
Verified digital twins — anchor chains to real humans
Orchestrator agents — carry and extend root records
Sub-agents — receive attenuated hops; cannot exceed parent scope
Enforcement Plane
API gateways — verify the chain before passing requests
MCP servers — verify per tool invocation
Resource services — last-mile enforcement; reject on any invariant failure

AuthR works with the identity stack you already have.

AuthR is not a competitor to existing standards. It is an additional assertion layer that slots above them. OAuth handles access delegation. AuthR handles authorship delegation. Both are necessary; neither is sufficient alone.

Standard
Role
How AuthR relates
OAuth 2.0 / OIDC
Authentication and access token issuance
Used unchanged. AuthR rides alongside as an additional authorship assertion.
RFC 8693 Token Exchange
Cross-domain delegation of access
AuthR's extend_chain is the authorship analogue to token exchange. Both can be used together.
RFC 9396 Rich Authorization Requests
Fine-grained permissions in authorization
AuthR scope.constraints can reference or embed RAR authorization_details directly.
W3C Verifiable Credentials / DIDs
Portable, tamper-evident identity assertions
Natural fit for author.id and grounding.evidence_digest — AuthR is VC-compatible.
SPIFFE / SPIRE
Workload identity and runtime attestation
Natural fit for actor.id and actor.model_manifest attestation evidence.
CoSAI Agentic IAM
Agents as first-class identities in IAM
AuthR is the authorship layer above the agent identity layer CoSAI defines.

AuthR is being developed in public.
Feedback, criticism, and implementations are actively wanted.

v0.1 is deliberately narrow. The v0.2 backlog includes cross-domain federation, multi-author records, formal revocation propagation, and threshold signing. Veterans of IETF, W3C, OpenID Foundation, and security researchers are especially welcome.

Read the Spec
The normative v0.1 protocol document. Six primitives, three operations, six invariants, and the full threat model.
AUTHR-v0.1.md ↗
Python Reference
A working implementation covering all three operations, the full invariant suite, and the CFO wire scenario end-to-end.
reference/python ↗
Try the Playground
Interactive demo of the full CFO wire scenario — mint a root record, delegate, verify the chain, and watch a scope-widening attack get rejected.
Launch playground →