ARR Protocol v0.1

1. Abstract

The All Rights Respected (ARR) protocol defines a standard format for attesting creative intent and attribution for works created with AI tools. Unlike traditional copyright or DRM systems, ARR is designed for social recognition rather than legal enforcement.

ARR attestations are:

• Embeddable — stored within the file itself, traveling with the work
• Verifiable — cryptographically signed, checkable without external services
• Expirable — time-limited by default, renewable by intent
• Revocable — creators can withdraw attestations at any time
• Privacy-preserving — identity is optional; pseudonymous claims are valid

Non-normative interaction guidance is captured in docs/arr-interaction-layer.md. This document does not add protocol requirements.

2. Attestation Format

An ARR attestation is a structured document in JSON or YAML format. All implementations MUST support JSON; YAML support is RECOMMENDED.

2.1 Schema

{
  "attestation": {
    "version": "arr/0.1",
    "id": "uuid-v4",
    "created": "ISO-8601 timestamp",
    "creator": "creator identifier",
    "intent": "description of creative intent",
    "tool": "tool/version",
    "upstream": [/* array of upstream attestation IDs */],
    "content_hash": "sha256:...",
    "expires": "ISO-8601 date",
    "revocable": true,
    "license": "optional license identifier",
    "renews": "optional attestation id",
    "extensions": {/* optional custom fields */}
  },
  "signature": "algorithm:base64-encoded-signature"
}

2.2 Required Fields

2.3 Optional Fields

2.4 Example

{
  "attestation": {
    "version": "arr/0.1",
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "created": "2026-01-29T10:30:00Z",
    "creator": "hash:sha256:7f3a9b2c4d5e6f...",
    "intent": "Poster design for climate awareness campaign",
    "tool": "midjourney/6.1",
    "upstream": [],
    "expires": "2031-01-29",
    "revocable": true,
    "license": "CC-BY-4.0"
  },
  "signature": "ed25519:kF2h9Jx3mN7pQr..."
}

3. Signature Requirements

All attestations MUST be cryptographically signed. The signature ensures the attestation has not been tampered with and was created by someone with access to the private key.

3.1 Supported Algorithms

3.2 Signature Format

Signatures are encoded as: algorithm:base64-encoded-signature

"ed25519:kF2h9Jx3mN7pQrSt8vWxYz..."

3.3 Signing Process

1. Serialize the attestation object to canonical JSON (keys sorted alphabetically, no whitespace)
2. Compute the signature over the serialized bytes
3. Encode the signature as base64
4. Prefix with the algorithm identifier

3.4 Key Distribution

ARR does not mandate a specific key distribution mechanism. Implementers MAY use:

• Public key embedded in creator profile
• Web-based key discovery (e.g., /.well-known/arr-keys)
• Decentralized identity systems (DID)
• Social proof (linking to verified accounts)

4. Embedding Methods

ARR attestations travel with the work. Multiple embedding methods are supported.

4.1 File Metadata

4.1.1 Images (JPEG, PNG, WebP)

Store attestation in XMP metadata under the namespace http://arr.protocol/1.0/:

<x:xmpmeta xmlns:x="adobe:ns:meta/">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
        xmlns:arr="http://arr.protocol/1.0/">
      <arr:attestation>{JSON attestation}</arr:attestation>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

4.1.2 Audio (MP3, FLAC, WAV)

Store in ID3v2 tag TXXX:ARR (MP3) or Vorbis comment ARR (FLAC/OGG).

4.1.3 Video (MP4, WebM)

Store in XMP metadata or as a custom atom/box.

4.1.4 Documents (PDF)

Store in XMP metadata stream.

4.2 Sidecar Files

For formats that don't support metadata, store attestation in a sidecar file:

artwork.png
artwork.png.arr    # contains JSON attestation

4.3 Steganographic Embedding

For robustness against metadata stripping, implementers MAY additionally embed a hash of the attestation using steganographic methods. This is OPTIONAL and implementation-specific.

4.4 Content Addressing

Attestations SHOULD include a content hash to bind the attestation to a specific version of the work:

"content_hash": "sha256:abc123..."

This hash should be computed over the work's content BEFORE the attestation is embedded.

5. Expiration & Revocation

5.1 Expiration

All attestations have an expiration date. This is a core design principle: nothing is permanent without renewal.

• Default expiration: 5 years from creation
• Maximum expiration: 25 years from creation
• Expired attestations are still valid historical records but SHOULD be displayed differently

5.2 Renewal

Creators can renew attestations by issuing a new attestation that references the original:

{
  "attestation": {
    "version": "arr/0.1",
    "id": "new-uuid",
    "created": "2031-01-29T00:00:00Z",
    "creator": "same-creator",
    "renews": "original-attestation-id",
    "expires": "2036-01-29"
  }
}

5.3 Revocation

If revocable: true (the default), creators can revoke attestations.

5.3.1 Revocation Record

{
  "revocation": {
    "attestation_id": "uuid-to-revoke",
    "revoked_at": "2027-06-15T12:00:00Z",
    "reason": "optional explanation"
  },
  "signature": "ed25519:..."
}

5.3.2 Revocation Distribution

Revocations can be distributed via:

• Well-known endpoint: /.well-known/arr-revocations
• Creator's published revocation list
• Platform-specific mechanisms

6. Verification Algorithm

Verifiers SHOULD implement the following algorithm:

6.1 Basic Verification

function verify(attestation, signature, publicKey):
    // 1. Check version compatibility
    if !supported(attestation.version):
        return { valid: false, reason: "unsupported_version" }

    // 2. Check expiration
    if attestation.expires < now():
        return { valid: true, expired: true }

    // 3. Serialize attestation canonically
    canonical = canonicalize(attestation)

    // 4. Verify signature
    if !verifySignature(canonical, signature, publicKey):
        return { valid: false, reason: "invalid_signature" }

    // 5. Success
    return { valid: true, expired: false }

6.2 Extended Verification (Optional)

Implementers MAY additionally:

• Check content hash against the work
• Query revocation lists
• Verify upstream attestations
• Validate creator identity through external systems

6.3 Verification Results

7. Privacy Considerations

7.1 Creator Identifiers

The creator field supports multiple identifier formats:

7.2 Unlinkability

Creators who want attestations to be unlinkable SHOULD:

• Use a unique keypair per attestation
• Use hash-based identifiers derived from random data
• Avoid including identifying information in intent or extensions

7.3 Right to Be Forgotten

Revocation supports the right to be forgotten. However:

• Attestations embedded in files may persist in copies
• Caches and archives may retain attestation data
• The protocol does not guarantee deletion

8. Versioning Strategy

8.1 Version Format

Versions follow arr/MAJOR.MINOR format:

• MAJOR: Breaking changes to required fields or signature format
• MINOR: New optional fields, clarifications, non-breaking additions

8.2 Compatibility

• Verifiers MUST reject attestations with unknown MAJOR versions
• Verifiers SHOULD accept attestations with higher MINOR versions
• Unknown fields in extensions MUST be ignored, not rejected

8.3 Version History

9. Conformance Levels

9.1 Level 1: Basic

Minimum viable implementation:

• Parse and display attestation data
• Verify ed25519 signatures
• Check expiration dates

9.2 Level 2: Standard

Recommended implementation:

• All Level 1 requirements
• Support multiple signature algorithms
• Embed attestations in file metadata
• Query revocation lists

9.3 Level 3: Full

Complete implementation:

• All Level 2 requirements
• Verify upstream attestations
• Support content addressing
• Implement renewal workflows
• Provide creator identity verification

10. Interaction Events (Optional)

ARR tools MAY emit interaction events to support live, in-context workflows. This section defines a minimal event envelope for interoperability. Emitting events is OPTIONAL and does not affect core attestation validity.

10.1 Event Envelope

If emitted, events MUST follow this shape:

{
  "event": {
    "version": "arr/event/0.1",
    "id": "uuid-v4",
    "type": "arr.attestation.draft.created",
    "created": "ISO-8601 timestamp",
    "session": "optional session identifier",
    "payload": {}
  }
}

Required fields: version, id, type, created. Optional fields: session, payload.

10.2 Event Types (Recommended)

10.3 Event Payload (Recommended)

If provided, payload SHOULD include:

• attestation — unsigned attestation object
• signed_attestation — full signed attestation object
• revocation — revocation record (Section 5.3.1)
• context — interaction context captured at creation time

Recommended context fields: