feat(spec): §8.13 Agent Declaration in Content Signatures

[chrishooooo-netizen]

Summary

Adds a new normative section §8.13 Agent Declaration in Content Signatures to the TRAIL DID Method specification.

This section defines a cryptographic mechanism for binding AI-generated content artifacts to the agent DID that produced them and the organization accountable for that output. Verification requires no cooperation from the AI platform — the full chain is resolvable from the public did:trail registry.

What this adds

Subsection	Purpose
§8.13.1 Motivation	Problem statement: verifiers need to establish whether content is AI-produced, which agent produced it, and which organization is accountable
§8.13.2 Format	AgentDeclaration — Data Integrity proof over JCS-canonicalized content manifest
§8.13.3 Verification Algorithm	7 steps: parse → hash check → DID resolution → proof verification → accountability chain → revocation
§8.13.4 Accountability Model	Three patterns: self-hosted / managed platform (§7.5) / federated delegation (§3.4)
§8.13.5 EU AI Act Art. 12	Audit trail mapping: attribution, integrity, non-repudiation, revocation awareness, 6-month retention floor
§8.13.6 Security Considerations	Crypto agility, replay, key compromise, content mutability

Design choices

• Default cryptosuite: eddsa-jcs-2023 — consistent with §8.2
• No platform cooperation required: verifier resolves the issuer chain through DIDs and VCs, not through the AI platform API
• Data Integrity over JCS (RFC 8785): deterministic canonicalization; signatures survive copy/paste and re-publication
• Detached form only: embedding in specific content formats (C2PA, PDF metadata, HTML) is out of scope and can follow in separate specs
• Crypto agility gated by trail:supportedCryptosuites: downgrade attacks addressed explicitly in §8.13.6

Cross-references added

• §3.4 — federation trust anchor (delegated accountability)
• §4.3 — agent DID assertion capability
• §7.5 — PlatformIdentityBinding VC as accountability root for managed platform deployments
• §8.2 — supported cryptosuites
• §8.6 — revocation check
• §8.7 — federation revocation propagation
• §8.8 — key rotation (post-rotation signatures MUST fail)

Open questions for review

1. purpose enum: currently specified as "assertion" with free-form extensibility. Should we enumerate common values (assertion / generation / translation / summarization / moderation)? Left open intentionally — feedback welcome.
2. contentType at hash time: derivative/re-encoded content requires a new declaration. Stated explicitly in §8.13.6. A ContentDerivation relationship could follow in v1.3.
3. C2PA interop: §8.13 is independent of C2PA. An informative mapping annex (AgentDeclaration ↔ C2PA manifest assertions) could follow as a non-blocking companion document.

Not in scope for this PR

• Embedding in specific content formats
• JSON-LD context file (https://trailprotocol.org/ns/trail/v1) — will follow in a separate PR
• Test vectors / conformance suite — planned under @trailprotocol/core v0.2.0

Review checklist

• Motivation covers the actual problem (three accountability questions)?
• Format choice (DataIntegrityProof + JCS) — any preference for JWS instead?
• Verification algorithm complete (missing steps or edge cases)?
• §8.13.4 managed platform pattern consistent with §7.5 expectations?
• §8.13.5 EU AI Act framing — is 6 months the right retention floor?
• §8.13.6 threat model — missed attack classes?

cc @AmeyParle