AXIS Protocol Specification

1. Introduction

AXIS (Agent Cross-system Identity Standard) is an open protocol for autonomous AI agent identity, delegation, and authorization. It defines how AI agents prove who they are, who authorized them to act, and what they are allowed to do, in a way that any third party can verify without relying on a shared registry or prior relationship.

The protocol addresses a specific gap in the current agent ecosystem: every existing agent identity solution operates within a single organization's boundaries. No production solution exists for cross-operator agent trust, the scenario where an agent from one system needs to be verified by a platform operated by a completely separate organization.

AXIS solves this with a three-layer architecture:

This specification includes a W3C-conformant DID method (did:axis) per W3C Decentralized Identifiers (DIDs) v1.0 and uses cryptographic primitives recommended by NIST SP 800-186.

1.1 Design Goals

• Cross-operator verification: Any system can verify any agent without prior knowledge of the operator's systems, shared infrastructure, or pre-existing relationships.
• Portability: An agent's identity is not bound to any single operator, platform, or infrastructure.
• Verifiability: Any system can verify an agent's identity, delegation chain, and authorization scope without contacting the registering operator.
• Accountability: Delegation chains create an auditable record of who authorized an agent to act and under what conditions.
• Openness: The protocol is Apache 2.0 licensed. Anyone can implement a registry, registrar, or resolver.
• Backend agnosticism: A compliant registry can be backed by Cloudflare Workers, a standard web server, a blockchain ledger, or any infrastructure that exposes the required endpoints.
• Registry/registrar distinction: A registry (e.g. AXIS Prime) is backend infrastructure that stores identity records and credential chains. A registrar is a consumer-facing service that handles agent registration, operator verification, pricing, and support on behalf of end users. Registrars write to the registry. Multiple registrars can write to the same registry. Agents registered through any accredited registrar are interoperable across the entire network.

1.2 Conformance

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Agent Identity Format

2.1 Dual Identifier System

AXIS supports two identifier formats that map to each other deterministically:

AXIS ID (human-readable):

axis:{operator}:{agent-name}

DID (W3C-compatible):

did:axis:{registry}:{agent-id}

Both formats are valid in all AXIS protocol messages. Implementations MUST support both and MUST be able to resolve either format to the same Agent Identity Record.

2.2 AXIS ID Format

The AXIS ID is the human-readable format used in day-to-day operations:

axis:offworld:mira-voss
axis:offworld:researcher-agent
axis:acme:legal

Where:

• axis is the protocol prefix (fixed)
• {operator} is the operator's namespace (derived from verified domain or account)
• {agent-name} is a human-readable agent name chosen by the operator

Agent names MUST be lowercase alphanumeric with hyphens. Maximum 64 characters.

2.3 DID Method Name

The W3C DID method name is axis.

2.4 DID Method-Specific Identifier

The AXIS DID format follows the W3C DID syntax:

did:axis:<registry>:<agent-id>

Where:

• did:axis is the method prefix (fixed)
• <registry> identifies the registry that issued the identity. For AXIS Prime, this is prime. Third-party registries use their registered registry identifier.
• <agent-id> is a unique identifier for the agent within that registry. This may be the human-readable name or a key-derived hash, depending on the registration tier.

2.5 Agent ID Generation

For auto-generated IDs (free/basic tiers), the <agent-id> MUST be derived from the agent's public key:

1. Generate an Ed25519 keypair per NIST SP 800-186.
2. Compute the SHA-256 hash of the raw 32-byte public key.
3. Encode the first 16 bytes of the hash using Base58btc (no prefix).
4. The result is the <agent-id>.

This produces identifiers like: did:axis:prime:7Kf9x2mPqRsT4vWn

For human-readable IDs (chosen by operator), the <agent-id> is the same as the agent name in the AXIS ID format.

2.6 Mapping Between Formats

The registry maintains the canonical mapping. Both formats resolve to the same Agent Identity Record and DID Document.

2.7 Examples

# AXIS ID format (human-readable)
axis:offworld:mira-voss                   # Named agent
axis:offworld:agent-7f3a2b9c              # Auto-generated ID
axis:acme:legal                           # Short/premium ID

# DID format (W3C-compatible)
did:axis:prime:7Kf9x2mPqRsT4vWn          # Agent on AXIS Prime
did:axis:prime:mira-voss                  # Named agent on AXIS Prime
did:axis:acme:9qRs2tUvW4xYz1aB          # Agent on a third-party registry
did:axis:internal:5cDe6fGh7iJk8lMn       # Agent on a private registry

# Operator DIDs
did:axis:prime:op:offworld.news           # Operator identity

3. DID Document

Every registered AXIS agent has an associated DID Document conforming to W3C DID Core.

3.1 Structure

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1",
    "https://axis-protocol.org/ns/v1"
  ],
  "id": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  "controller": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  "verificationMethod": [
    {
      "id": "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:axis:prime:7Kf9x2mPqRsT4vWn",
      "publicKeyMultibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
    }
  ],
  "authentication": [
    "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1"
  ],
  "assertionMethod": [
    "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1"
  ],
  "service": [
    {
      "id": "did:axis:prime:7Kf9x2mPqRsT4vWn#operator",
      "type": "AxisOperator",
      "serviceEndpoint": "https://offworld.news"
    }
  ],
  "axisMetadata": {
    "registered": "2026-01-15T00:00:00Z",
    "registry": "prime",
    "operator": {
      "domain": "offworld.news",
      "verified": true,
      "operatorId": "did:axis:prime:op:offworld.news"
    },
    "status": "active",
    "delegations": [
      {
        "id": "dlg:prime:a1b2c3d4",
        "from": "did:axis:prime:7Kf9x2mPqRsT4vWn",
        "to": "did:axis:prime:3bNc8dFgH1jKlM5p",
        "scope": "full_authority",
        "created": "2026-02-01T00:00:00Z",
        "expires": "2027-02-01T00:00:00Z",
        "signature": "z3hQ9f..."
      }
    ]
  }
}

3.2 Required Properties

3.3 AXIS Metadata

The axisMetadata object contains AXIS-specific information not covered by the base W3C DID specification:

4. CRUD Operations

4.1 Create (Registration)

An agent identity is created through the following process:

Prerequisites:

• Operator has verified domain ownership (DNS TXT record or HTTP file verification)
• Operator has an active account on a registry

Process:

1. Client generates an Ed25519 keypair locally.
2. Client sends a registration request to the registry:

POST /api/v1/register
Content-Type: application/json

{
  "publicKey": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
  "operator": {
    "domain": "offworld.news"
  },
  "metadata": {
    "name": "news-writer-01",
    "description": "Autonomous news article writer"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-01-15T00:00:00Z",
    "verificationMethod": "self",
    "proofPurpose": "authentication",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp..."
  }
}

3. The proof field demonstrates that the client controls the private key corresponding to publicKey. The client signs a canonical representation of the registration request body (excluding the proof field) with the private key.
4. The registry validates:
   • The operator's domain is verified and in good standing
   • The operator has available agent slots (3 free, or has paid for additional)
   • The public key is a valid Ed25519 key
   • The proof signature is valid
   • The derived agent ID does not collide with an existing registration
5. On success, the registry returns the complete DID Document:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "did": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  "document": { ... },
  "registrationReceipt": {
    "registry": "prime",
    "timestamp": "2026-01-15T00:00:00Z",
    "signature": "z4hR8g..."
  }
}

4.2 Read (Resolution)

Any system can resolve an AXIS DID to its DID Document. Resolution is free, unlimited, and requires no authentication.

GET /api/v1/resolve/did:axis:prime:7Kf9x2mPqRsT4vWn

Response:

HTTP/1.1 200 OK
Content-Type: application/did+ld+json

{
  "@context": [ ... ],
  "id": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  ...
}

Resolution Metadata:

The resolver also returns resolution metadata per W3C DID Resolution:

{
  "didResolutionMetadata": {
    "contentType": "application/did+ld+json",
    "duration": 12
  },
  "didDocument": { ... },
  "didDocumentMetadata": {
    "created": "2026-01-15T00:00:00Z",
    "updated": "2026-03-01T00:00:00Z",
    "versionId": "3",
    "nextUpdate": null,
    "deactivated": false
  }
}

4.3 Update

An agent's DID Document can be updated by the controller. Updates require a valid signature from the agent's current key.

Updatable fields:

• service endpoints
• metadata.name and metadata.description
• Adding or rotating verification methods (key rotation)

Immutable fields:

• id (the DID itself)
• registry
• operator.domain (requires re-registration)
• registered timestamp

PATCH /api/v1/agents/did:axis:prime:7Kf9x2mPqRsT4vWn
Content-Type: application/json

{
  "service": [
    {
      "id": "did:axis:prime:7Kf9x2mPqRsT4vWn#operator",
      "type": "AxisOperator",
      "serviceEndpoint": "https://new-domain.com"
    }
  ],
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-01T00:00:00Z",
    "verificationMethod": "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1",
    "proofPurpose": "authentication",
    "proofValue": "z7jK2l..."
  }
}

4.4 Deactivate

An agent identity can be deactivated by the controller or the operator. Deactivation is permanent. The DID Document is retained for audit purposes but marked as deactivated.

DELETE /api/v1/agents/did:axis:prime:7Kf9x2mPqRsT4vWn

{
  "reason": "agent_retired",
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-06-01T00:00:00Z",
    "verificationMethod": "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1",
    "proofPurpose": "authentication",
    "proofValue": "z9mN4p..."
  }
}

After deactivation:

• Resolution returns the document with "deactivated": true in metadata
• All active delegations from this agent are revoked
• The DID cannot be reused or re-registered
• Verification calls against this DID return "status": "deactivated"

5. Verification

Verification is the process of confirming an agent's identity, the validity of its cryptographic signatures, and the status of its delegations. Verification is free, unlimited, and requires no authentication.

5.1 Identity Verification

Confirms that an agent is registered and active.

GET /api/v1/verify/did:axis:prime:7Kf9x2mPqRsT4vWn

Response:

{
  "verified": true,
  "did": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  "status": "active",
  "operator": {
    "domain": "offworld.news",
    "verified": true
  },
  "registered": "2026-01-15T00:00:00Z",
  "verifiedAt": "2026-04-11T14:30:00Z"
}

5.2 Signature Verification

Verifies that a message was signed by the agent's private key.

POST /api/v1/verify/signature
Content-Type: application/json

{
  "did": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  "message": "base64url-encoded-message",
  "signature": "z3hQ9f...",
  "verificationMethod": "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1"
}

Response:

{
  "valid": true,
  "did": "did:axis:prime:7Kf9x2mPqRsT4vWn",
  "verificationMethod": "did:axis:prime:7Kf9x2mPqRsT4vWn#key-1",
  "algorithm": "Ed25519",
  "verifiedAt": "2026-04-11T14:30:00Z"
}

5.3 Delegation Verification

Verifies the full delegation chain for an agent. See Section 7.

6. AXIS Identity Token (AIT)

The AXIS Identity Token is the bearer credential an agent presents to prove its identity. It is a standard JWT signed with the agent's Ed25519 private key.

6.1 Purpose

When an agent makes a request to a verifier (any platform or service), it presents an AIT. The verifier:

1. Extracts the registry_url from the token payload
2. Resolves the URL to retrieve the agent's public key
3. Verifies the JWT signature

This enables cross-operator verification without shared infrastructure. The verifier does not need prior knowledge of the agent's registry. The token provides the URL.

6.2 Token Structure

Header:

{
  "alg": "EdDSA",
  "typ": "AIT",
  "kid": "axis:offworld:mira-voss"
}

Payload:

{
  "iss": "axis:offworld:mira-voss",
  "sub": "axis:offworld:mira-voss",
  "iat": 1743292800,
  "exp": 1743379200,
  "axis_version": "0.1",
  "operator_id": "axis:offworld:operator",
  "registry_url": "https://api.offworldnews.ai/agents/mira-voss"
}

The token is signed with the agent's Ed25519 private key. The signature uses the EdDSA algorithm per RFC 8037.

6.3 Required Claims

6.4 Verification Process

A verifier receiving a request with an AIT MUST:

1. Decode the JWT and extract the header and payload.
2. Resolve the registry_url to retrieve the Agent Identity Record and public key. This is a call to a public AXIS endpoint that any party can reach independently.
3. Verify the EdDSA signature using the agent's public key from the registry.
4. Check expiry: reject if exp < current time.
5. Check revocation: call the agent's revocation endpoint. If revoked: true, reject.
6. Check delegation (if delegation_id present): verify the delegation chain (see Section 7).
7. Check scope (if scope present): confirm the requested action falls within scope.
8. Accept or reject.

6.5 Registry Resolution Note

The verifier calls the registry URL declared in the agent's own token. This is a public AXIS endpoint, not a callback to a proprietary system. The design enables cross-operator verification without shared infrastructure, pre-existing relationships, or a single global registry.

6.6 Platform Retention Recommendation

Platforms SHOULD retain the full credential chain presented by agents at the time of action. The credential chain is the forensic artifact that answers "who authorized this?" after the fact. The platform that accepted the action is the party holding the evidence.

This is a recommendation, not a requirement. It is analogous to web server access logs: not mandated by the HTTP spec, but universally adopted because they are necessary when something goes wrong.

7. Delegation Credentials (Layer 2: Authorization)

Delegation is the mechanism by which an operator grants authority to an agent, or by which one agent grants scoped authority to another. Delegation Credentials are the core of AXIS Layer 2.

7.1 Delegation Credential

A Delegation Credential is a signed document specifying what actions a delegate is authorized to take, under what constraints, and for how long.

{
  "axis_version": "0.1",
  "type": "DelegationCredential",
  "id": "dc:offworld:operator-editor-2026-03",
  "issued_by": "axis:offworld:operator",
  "issued_to": "axis:offworld:mira-voss",
  "root_operator": "axis:offworld:operator",
  "parent_credential_id": null,
  "scope": ["article:draft", "article:submit", "article:publish"],
  "constraints": {
    "max_sub_delegation_depth": 2
  },
  "created": "2026-03-01T00:00:00Z",
  "expires": "2026-06-01T00:00:00Z",
  "revocable": true,
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-01T00:00:00Z",
    "verificationMethod": "did:axis:prime:op:offworld.news#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3hQ9f..."
  }
}

7.2 Required Fields

7.3 The Attenuation Rule (Monotonic Scope Narrowing)

The scope in a Delegation Credential MUST be equal to or narrower than the scope in the parent credential. A verifier MUST reject any credential where the delegate's scope is wider than the delegator's scope.

Operator grants: ["article:draft", "article:submit", "article:publish"]
  └─ Editor delegates: ["article:draft", "article:submit"]     ← valid (narrower)
       └─ Researcher delegates: ["article:draft"]               ← valid (narrower)
            └─ Sub-agent delegates: ["article:draft", "image:generate"]  ← REJECTED (wider)

Each level of delegation can only reduce the scope, never expand it. This is a hard invariant.

7.3.1 Scope Taxonomy

The scope field uses an open namespace. AXIS v0.1 does not define a closed taxonomy of scope values. Operators and platforms negotiate accepted scopes out of band (e.g. by reading platform documentation). AXIS v0.2 will introduce:

1. A recommended vocabulary of standard common scopes (no namespace prefix required), e.g. content:read, content:write, payment:authorize
2. A namespace convention for platform-specific scopes using a prefix, e.g. shopify:inventory:update
3. A discovery endpoint at /.well-known/axis-scopes where platforms publish the scopes they recognize

7.4 The Root Operator Rule

The root_operator field MUST be byte-for-byte identical across every credential in a delegation chain. No intermediate agent can re-root the chain under itself. This prevents re-rooting attacks where a malicious delegate claims authority from a different operator.

A verifier MUST reject any chain where root_operator values differ between links.

7.5 Sub-Delegation Depth

The max_sub_delegation_depth constraint controls whether and how far a delegate can re-delegate:

• 0 = the delegate cannot delegate further
• 1 = the delegate can create one level of sub-delegation
• Each sub-delegation MUST decrement this value by 1

A verifier MUST reject any credential where max_sub_delegation_depth is negative.

7.6 Delegation Chains

Delegations can be chained. The operator delegates to Agent A, who delegates to Agent B, who delegates to Agent C. The chain is verifiable end-to-end.

Operator: axis:offworld:operator
  └─ DC: operator → mira-voss (scope: [article:*], depth: 2)
       └─ DC: mira-voss → researcher (scope: [article:draft], depth: 1)
            └─ DC: researcher → fact-checker (scope: [article:draft], depth: 0)

When an agent presents credentials to a receiving platform, it presents the full delegation chain as a single self-contained bundle. The bundle contains every signed link from the root operator down to the acting agent. The receiving platform does not need to chase individual links up the chain or rely on any party retaining intermediate receipts. The chain is complete and self-verifying at presentation time. The only external call needed is to the registry to confirm keys are active and not revoked.

Chain verification walks the delegation records from the terminal agent back to the root, verifying at each link:

1. Signature is valid (Ed25519)
2. root_operator is identical to every other link
3. Scope is equal to or narrower than parent
4. max_sub_delegation_depth is non-negative
5. Credential has not expired
6. Credential has not been revoked

7.7 Cross-System Delegation

The issued_to field MAY reference a foreign DID, not only axis: identifiers. This enables an AXIS operator to issue a scoped delegation to an agent from a completely separate identity system:

{
  "issued_by": "axis:offworld:mira-voss",
  "issued_to": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "root_operator": "axis:offworld:operator",
  "scope": ["article:draft"]
}

Verifier behavior when resolving foreign DIDs is implementation-defined in v0.1. A standard resolution path for cross-system delegation is planned for v0.2.

7.8 Delegation Revocation

A delegator can revoke a delegation at any time (if revocable: true). Revocation cascades: revoking a delegation also invalidates all downstream delegations in the chain.

DELETE /api/v1/delegations/dc:offworld:operator-editor-2026-03

{
  "reason": "authority_expired",
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:axis:prime:op:offworld.news#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5jM7n..."
  }
}

8. Domain Verification

Operators verify domain ownership before registering agents. This is the sole barrier to entry for the free tier.

8.1 DNS TXT Verification

Add a TXT record to your domain's DNS:

_axis-verify.offworld.news  TXT  "axis-verify=abc123def456"

The registry checks for this record and marks the domain as verified.

8.2 HTTP File Verification

Place a file at a well-known URL:

https://offworld.news/.well-known/axis-verify.json

Contents:

{
  "axis-verify": "abc123def456"
}

8.3 Verification Lifecycle

• Domain verification is checked at registration time and periodically (every 30 days).
• If domain verification lapses, the operator's agents remain active but new registrations are blocked until re-verified.
• Domain verification is tied to the operator account, not individual agents.

9. Operator Identity

Operator Identity is an optional, paid attestation that links a verified organizational identity to all agents under that operator. Available as Verified Individual ($20 one-time) or Verified Organization ($50 one-time).

9.1 Operator DID

Operators who purchase Operator Identity receive their own DID:

did:axis:prime:op:offworld.news

9.2 Operator DID Document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://axis-protocol.org/ns/v1"
  ],
  "id": "did:axis:prime:op:offworld.news",
  "controller": "did:axis:prime:op:offworld.news",
  "verificationMethod": [
    {
      "id": "did:axis:prime:op:offworld.news#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:axis:prime:op:offworld.news",
      "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
    }
  ],
  "service": [
    {
      "id": "did:axis:prime:op:offworld.news#website",
      "type": "OperatorWebsite",
      "serviceEndpoint": "https://offworld.news"
    }
  ],
  "axisOperatorMetadata": {
    "domain": "offworld.news",
    "operatorVerificationTier": "kyb_business",
    "domainVerified": true,
    "verifiedAt": "2026-01-20T00:00:00Z",
    "agentCount": 5,
    "status": "active"
  }
}

9.3 Operator Identity Lifecycle

• Operator Identity is permanent as long as at least one agent is registered under the operator.
• If all agents are deactivated, Operator Identity enters a 90-day grace period before deactivation.
• Operator Identity covers unlimited agents under the same verified domain.

9.4 Operator Verification Tier

Verification tiers are a property of operators, not agents. The operator's verification tier (e.g. email-verified, domain-verified, KYB-individual, KYB-business) is stored in the Operator Identity Record in the registry. It is NOT a field in delegation credentials or agent identity records.

Receiving platforms see the operator's verification tier by querying the registry when resolving the operator's identity, not by reading a field in the credential chain. This separates the identity verification signal (how thoroughly the operator proved who they are) from the authorization signal (what the agent is allowed to do).

Agents do not have an independent verification tier. Agent trust history is captured through Trust Attestations (Layer 3), not through registry-level verification. If an agent changes operators, the new operator's verification tier applies. The agent's prior track record is preserved in whatever Trust Attestations it has accumulated, which are stored outside the registry by the issuer or the agent itself.

10. Trust Attestations (Layer 3: Reputation)

Trust Attestations are signed statements about an agent's trustworthiness. They are distinct from Delegation Credentials: attestations say "I trust this agent" not "I authorize this agent to act."

Attestations are advisory. A verifier MAY use them to make trust decisions but is not required to.

10.1 Trust Attestation Structure

{
  "axis_version": "0.1",
  "type": "TrustAttestation",
  "id": "ta:offworld:editor-researcher-2026-03",
  "issued_by": "axis:offworld:mira-voss",
  "subject": "axis:offworld:researcher-agent",
  "issued_at": "2026-03-29T00:00:00Z",
  "scope": "editorial:research",
  "level": 3,
  "statement": "Consistently produces well-cited research briefs on time.",
  "signature": "<Ed25519 signature, base64url>"
}

10.2 Fields

10.3 Cross-System Interoperability (Known Gap)

Trust Attestations from foreign AXIS registries or non-AXIS identity systems may use different scope values and schema conventions. No standard cross-system schema exists for agent trust attestations yet. Evaluating a foreign agent's reputation currently requires out-of-band knowledge of the issuing system's encoding.

This is a known gap. A standard schema for agent trust attestation fields compatible with W3C Verifiable Credentials credentialSubject is planned for v0.2.

10.4 Scope Note

Trust Attestations are signed records. Aggregation, scoring, and evaluation of attestations is out of scope for v0.1 and planned for v0.2.

10.5 Storage

Trust Attestations do NOT live in the registry. They are stored either by the issuer (the entity that wrote the attestation) or by the agent (who collects and presents their own attestations as a portfolio). AXIS Prime never stores attestations. This keeps the registry lightweight and prevents unbounded database growth.

11. Content Provenance Attestations (Layer 3)

Content Provenance Attestations (CPAs) are signed records proving that specific content was produced by a specific agent, under a specific delegation, reviewed by a specific party. They are distinct from Trust Attestations (which are about general trustworthiness) and from Delegation Credentials (which are about authorization).

11.1 CPA Structure

{
  "axis_version": "0.1",
  "type": "ContentProvenanceAttestation",
  "id": "cpa:offworld:article-2026-03-29",
  "content_id": "https://offworld.news/articles/ai-agent-identity",
  "content_hash": {
    "algorithm": "sha-256",
    "value": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  },
  "produced_by": "axis:offworld:researcher-agent",
  "produced_under_credential": "dc:offworld:editor-researcher-2026-03",
  "reviewed_by": "axis:offworld:mira-voss",
  "approved_at": "2026-03-29T12:00:00Z",
  "root_operator": "axis:offworld:operator",
  "signature": "<Ed25519 signature by mira-voss, base64url>"
}

11.2 Purpose

The CPA enables a third-party platform to verify not just that an agent is authorized, but that a specific piece of content was produced through a legitimate, governed pipeline, without any prior relationship with the operator or agents involved.

A verifier receiving a CPA can:

1. Verify the reviewer's signature
2. Resolve the delegation credential to confirm the producing agent was authorized
3. Walk the delegation chain back to the root operator
4. Optionally verify the content hash to confirm the content has not been modified

11.3 Fields

12. Registry Federation

12.1 Registry Identifiers

Each registry has a unique identifier registered with AXIS Prime:

12.2 Connected Registrar Protocol

Connected registrars sync agent identities with AXIS Prime:

1. Registrar creates agent identity locally
2. Registrar submits identity to AXIS Prime for root registration
3. AXIS Prime validates and records the identity
4. Agent is now verifiable across the entire network

Per-agent sync fees apply for connected registrars.

12.3 Private Registries

Private registries operate independently:

• No sync with AXIS Prime
• No fees
• Agents are only verifiable within the private registry's network
• Can optionally federate later via federation agreement

12.4 Cross-Registry Resolution

When resolving a DID from a different registry, the resolver:

1. Extracts the registry identifier from the DID
2. Looks up the registry's resolution endpoint in the AXIS Prime registry directory
3. Forwards the resolution request to the appropriate registry
4. Returns the DID Document to the caller

13. The API Contract

Any AXIS-compliant registry MUST expose these endpoints:

All public endpoints are free, unlimited, and require no authentication. This is a design requirement, not a pricing decision. Verification infrastructure must be universally accessible for the trust model to work.

Full request/response schemas are in the schemas/ directory. An OpenAPI 3.1 specification is available in openapi.yaml.

13.1 Registry Data Visibility Model

Added April 13, 2026. This supersedes the previous assumption that all operator and agent records are fully public.

Registry data is organized into three visibility tiers:

Public Layer

Available to anyone, no authentication required. Contains only what is necessary for cryptographic verification:

• public_key and key_algorithm
• agent_id or operator_id
• status (active, suspended, revoked)
• revocation_url
• registry_url
• axis_version

Presentation Layer

Visible when an agent actively presents credentials to a receiving platform. The requesting platform includes the agent's AIT in its registry query; the registry verifies the AIT, confirms the agent belongs to the requested operator, and returns the presentation layer:

• display_name
• Operator verification_level (email, domain, KYB individual, KYB business)
• purpose (agent description)
• platform (agent runtime)
• capability_tier

Private Layer

Only visible through the registrar relationship or explicit operator consent. Never exposed through registry API:

• Operator contact information
• Business registration details
• KYB verification documents
• Billing information

Rationale: Public endpoints return only what's needed for cryptographic verification. Display names, verification levels, and purpose descriptions are only revealed when an agent actively presents credentials. This mirrors how identity works in physical interactions and gives operators meaningful control over their visibility.

13.2 Platform-side Access Control

Added April 13, 2026.

Platforms that accept AXIS-verified agents SHOULD publish their access requirements at a well-known endpoint:

/.well-known/axis-access

{
  "axis_version": "0.1",
  "platform_id": "ghost.example.com",
  "access_policy": {
    "minimum_verification_level": "domain",
    "required_scopes": ["content:comment"],
    "allow_unverified": false,
    "registration_url": "https://kipplelabs.com/register"
  },
  "updated_at": "2026-04-13T00:00:00Z"
}

v0.2 candidates: blocked_operators, approved_operators, rate_limits.

Design rationale: The protocol defines how platforms communicate their access policy. Enforcement is the platform's responsibility. AXIS provides identity data and trust signals; platforms make their own decisions.

14. Security Considerations

14.1 Cryptographic Algorithms

14.2 Key Management

• Private keys MUST be generated and stored by the agent operator. The registry never has access to private keys.
• Key rotation is supported via DID Document updates. Old keys are retained in the document history for signature verification of past assertions.
• Compromised keys SHOULD be rotated immediately. The operator can also deactivate the agent.

14.3 Replay Protection

• All proof objects include a created timestamp.
• Registries MUST reject proofs with timestamps more than 5 minutes in the past or future.
• Each proof is bound to the specific request body, preventing reuse.

14.4 Registry Trust Model

The AXIS trust model is hierarchical, inspired by DNSSEC:

• AXIS Prime is the root of trust (like the DNS root zone)
• Connected registrars derive trust from AXIS Prime
• Private registries are self-sovereign (trust is internal)
• Cross-registry trust is established through federation agreements

14.5 Threat Model

15. Privacy Considerations

• Agent DIDs are public. Anyone can resolve them.
• Operator domains are public (required for domain verification).
• Delegation records are public (required for chain verification).
• The registry does not store private keys, agent behavior data, or communication content.
• Operators may choose to use private registries to keep agent identities internal.

16. References

• W3C Decentralized Identifiers (DIDs) v1.0
• W3C DID Resolution
• W3C Verifiable Credentials Data Model
• Ed25519 Signature Suite 2020
• NIST SP 800-186: Recommendations for Discrete Logarithm-based Cryptography
• NIST FIPS 186-5: Digital Signature Standard
• RFC 2119: Key words for use in RFCs
• Multibase Data Format
• RFC 7519: JSON Web Token (JWT)
• RFC 8037: CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JOSE
• W3C Authorization Capabilities (zcap) Specification
• Model Context Protocol (MCP)