From 25637314dad898751267d2c39b69afd999c75156 Mon Sep 17 00:00:00 2001 From: Christian Hommrich Date: Tue, 21 Apr 2026 21:35:59 +0200 Subject: [PATCH 1/3] =?UTF-8?q?feat(spec):=20=C2=A78.12=20Agent=20Declarat?= =?UTF-8?q?ion=20in=20Content=20Signatures=20(draft)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Normative section binding AI-generated content cryptographically to a responsible identity. Offline-verifiable without AI platform cooperation. Structure (mirrors §7.5 PlatformIdentityBinding pattern): - 8.12.1 Motivation (three accountability questions) - 8.12.2 AgentDeclaration format (Data Integrity proof over JCS-canonicalized manifest) - 8.12.3 Verification Algorithm (7 steps, DID + VC resolution, revocation check) - 8.12.4 Accountability Model (self-hosted / managed platform / federated) - 8.12.5 EU AI Act Art. 12 Audit Trail (attribution, non-repudiation, 6-month retention) - 8.12.6 Security Considerations (crypto agility, replay, key compromise, content mutability) Default cryptosuite: eddsa-jcs-2023 (consistent with §8.2). Cross-references: §4.3 agent DIDs, §7.5 PlatformIdentityBinding, §8.6 revocation, §8.7 federation revocation propagation, §8.8 key rotation. Numbering note: slot §8.12 reflects current main (§8.11 is latest). If PR #13 (§3.4 + §8.7) lands first, this may reconcile to §8.13 during integration — no content changes needed, title stays "Agent Declaration in Content Signatures". Closes part of v1.2.0 Superspreading critical path (TRAIL Challenge Report 2026-04-21, Blocker 1). --- spec/did-method-trail-v1.md | 120 ++++++++++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) diff --git a/spec/did-method-trail-v1.md b/spec/did-method-trail-v1.md index ed64ce7..f9e88cb 100644 --- a/spec/did-method-trail-v1.md +++ b/spec/did-method-trail-v1.md @@ -1609,6 +1609,126 @@ The following items are planned for future specification versions. They are docu --- +## 8.12 Agent Declaration in Content Signatures + +### 8.12.1 Motivation + +As AI-generated content proliferates across channels (email, code, social media, customer interactions), recipients and downstream systems need a cryptographic mechanism to determine: + +1. **Whether** a given artifact was produced by an AI agent (as opposed to a human or a different agent) +2. **Which** agent produced it +3. **Which organization is accountable** for the agent's output under applicable regulation (e.g., EU AI Act Art. 12) + +Existing approaches — platform-specific watermarks, text-based disclaimers, metadata headers — are either easily stripped, non-verifiable without vendor cooperation, or cannot survive format conversion. A DID-based signature mechanism solves this by binding the artifact to an agent DID that is itself bound to a human-accountable organization DID through the chain established in §7.5 (PlatformIdentityBinding). + +The `AgentDeclaration` pattern defined in this section extends the assertion capability of `did:trail` agent DIDs (§4.3) to arbitrary content artifacts, producing a portable, verifier-friendly proof that: + +- Works offline (no call to AI platform required) +- Survives copy/paste and re-publication (signature travels with the content) +- Composes with existing W3C Verifiable Credentials and Data Integrity specifications +- Declares the accountable issuer organization explicitly + +### 8.12.2 AgentDeclaration Content Signature Format + +An AgentDeclaration is a Data Integrity proof ([VC-DATA-INTEGRITY]) over a canonicalized content manifest. Implementations MUST use a cryptosuite declared in the signing DID Document's `trail:supportedCryptosuites` (§8.2). The default cryptosuite is `eddsa-jcs-2023`. + +The signed manifest is a JSON object with the following shape: + +```json +{ + "@context": [ + "https://w3id.org/security/data-integrity/v2", + "https://trailprotocol.org/ns/trail/v1" + ], + "type": "AgentDeclaration", + "agent": "did:trail:agent:acme-sales-agent-v2-de-3f8c", + "accountableOrg": "did:trail:org:acme-corp-eu-a7f3b2c1e9d04f5a", + "contentHash": { + "algorithm": "sha-256", + "value": "3a7bd3e2360a3d29eea436fcfb7e44c735d117c42d1c1835420b6b9942dd4f1b" + }, + "contentType": "text/plain", + "createdAt": "2026-04-21T10:30:00Z", + "purpose": "assertion", + "proof": { + "type": "DataIntegrityProof", + "cryptosuite": "eddsa-jcs-2023", + "created": "2026-04-21T10:30:00Z", + "verificationMethod": "did:trail:agent:acme-sales-agent-v2-de-3f8c#key-1", + "proofPurpose": "assertionMethod", + "proofValue": "z3FXQjecWufY...signature..." + } +} +``` + +| Field | Requirement | Description | +|-------|-------------|-------------| +| `@context` | MUST | Includes `https://trailprotocol.org/ns/trail/v1` for the `AgentDeclaration` type | +| `type` | MUST | Fixed literal `"AgentDeclaration"` | +| `agent` | MUST | DID of the producing agent (Tier 1 or Tier 2 did:trail agent DID) | +| `accountableOrg` | MUST | DID of the organization accountable for the agent's output; MUST match the `issuer` of a resolvable `PlatformIdentityBinding` VC (§7.5) or a direct `controller` relationship on the agent DID Document | +| `contentHash.algorithm` | MUST | A hash algorithm declared in `trail:supportedCryptosuites` of the agent DID Document; default `"sha-256"` | +| `contentHash.value` | MUST | Lowercase hex digest of the raw content bytes | +| `contentType` | SHOULD | IANA media type of the signed content | +| `createdAt` | MUST | ISO 8601 UTC timestamp | +| `purpose` | MUST | MUST be `"assertion"` for content-origin claims | +| `proof` | MUST | W3C Data Integrity proof ([VC-DATA-INTEGRITY]) | +| `proof.verificationMethod` | MUST | Full DID URL of a verification method in the agent DID Document with `assertionMethod` relationship | + +The manifest is canonicalized using the JCS algorithm (RFC 8785) before signing, consistent with `eddsa-jcs-2023` (§8.2). + +Content MAY be transported alongside its AgentDeclaration as a detached envelope, or the declaration MAY be embedded (e.g., in HTTP headers, email headers per [RFC 5322], or file metadata). Embedding mechanisms are OUT OF SCOPE for this specification but implementations SHOULD prefer detached transport for format portability. + +### 8.12.3 Verification Algorithm + +A verifier presented with content C and a candidate AgentDeclaration D MUST perform the following steps: + +1. Parse D and confirm `type == "AgentDeclaration"` and the required fields listed in §8.12.2 are present. +2. Compute `hash(C)` using `D.contentHash.algorithm` and compare lowercase hex against `D.contentHash.value`. If unequal, verification FAILS. +3. Resolve `D.agent` using the `did:trail` resolution algorithm (§5). If resolution fails or the DID Document is revoked (§8.6), verification FAILS. +4. Locate the verification method identified by `D.proof.verificationMethod` within the resolved DID Document. The method MUST appear in the `assertionMethod` set. If absent, verification FAILS. +5. Verify `D.proof` using the cryptosuite named in `D.proof.cryptosuite`. The cryptosuite MUST be listed in `trail:supportedCryptosuites` of the resolved DID Document (§8.2). If verification fails or the cryptosuite is not supported, verification FAILS. +6. Resolve `D.accountableOrg` and establish the accountability chain by one of: + a. A `PlatformIdentityBinding` VC (§7.5) issued by `D.accountableOrg` naming `D.agent` as `credentialSubject.id`, OR + b. A direct `controller` entry in the agent DID Document referencing `D.accountableOrg`. + If neither binding is found, verification FAILS. +7. Check revocation status for both the agent DID and — if a binding VC was used — the VC's `credentialStatus` (§8.6). If either is revoked, verification FAILS. + +A verifier MUST NOT require cooperation from the AI platform on which the agent was deployed to complete verification. All required inputs are obtainable from the content, the declaration, and the public `did:trail` registry. + +### 8.12.4 Accountability Model + +The `accountableOrg` field makes the issuer organization the bearer of accountability for content signed under an AgentDeclaration. This mirrors the Tier 1 accountability model established in §7.5.4: the platform (if any) operates as infrastructure and is not a legal bearer of content responsibility. + +Three accountability patterns are valid: + +1. **Self-hosted agent** — The org runs the agent under its own infrastructure. `accountableOrg` = `controller` of the agent DID Document. No PlatformIdentityBinding VC is required. +2. **Managed platform deployment** — The agent runs on a third-party AI platform (e.g., Anthropic Managed Agents). `accountableOrg` issues a PlatformIdentityBinding VC (§7.5) that authoritatively names the agent DID as its delegate. The VC is the accountability root; the platform is transparent to the verifier. +3. **Federated delegation** — The `accountableOrg` DID is itself part of a Federation Trust Anchor chain (§3.4). Revocation propagates per §8.7. + +Verifiers MAY reject AgentDeclarations whose accountable organization is outside the verifier's trust policy (e.g., not listed in the verifier's accepted anchor set). + +### 8.12.5 EU AI Act Art. 12 Audit Trail + +AgentDeclarations are a compliant record-keeping mechanism under EU AI Act Art. 12 (Record-Keeping) for high-risk AI systems producing content in the EU. A deployer retaining the signed declarations alongside the content artifacts provides: + +- **Attribution** — which agent produced the content (§8.12.2 `agent`) +- **Accountability** — which legal entity is responsible (§8.12.2 `accountableOrg`) +- **Integrity** — the content has not been modified since signing (§8.12.3 step 2) +- **Non-repudiation** — the signature is verifiable against a public registry (§8.12.3 step 5) +- **Revocation awareness** — the audit trail reflects the DID and VC revocation state at verification time (§8.12.3 step 7) + +Conforming deployers SHOULD retain AgentDeclarations for at least the minimum period required by applicable sectoral regulation (for EU AI Act high-risk systems, 6 months per Art. 12(1), longer where sectoral law applies). + +### 8.12.6 Security Considerations + +- **Hash-algorithm agility** — The `contentHash.algorithm` MUST be constrained to algorithms declared in the agent's `trail:supportedCryptosuites`. Verifiers MUST reject declarations using algorithms outside that declared set to prevent downgrade attacks. +- **Replay across contexts** — Verifiers SHOULD incorporate `createdAt` into context-specific policy (e.g., reject declarations older than a sector-defined freshness window). +- **Key compromise** — If the agent's signing key is compromised and rotated (§8.8), existing declarations signed by the revoked key MUST verify as FAILED from the revocation time onward, consistent with §8.6. +- **Content mutability** — Signed content is integrity-locked at sign time. Downstream transformations (translation, summarization, quotation) produce new artifacts that require new declarations; the original declaration does not transitively cover derivative content. + +--- + ## 9. Privacy Considerations ### 9.1 Minimal Disclosure From f331eb93b8614c6b482e470e65cb9f103df18286 Mon Sep 17 00:00:00 2001 From: Christian Hommrich Date: Tue, 21 Apr 2026 22:06:06 +0200 Subject: [PATCH 2/3] =?UTF-8?q?fix(spec):=20renumber=20Agent=20Declaration?= =?UTF-8?q?=20=C2=A78.12=20=E2=86=92=20=C2=A78.13?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §8.12 is now occupied by Protocol Roadmap (post PR #13 merge). Agent Declaration moves to §8.13. All subsection refs and cross-references updated. Changelog entry added. --- spec/did-method-trail-v1.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/spec/did-method-trail-v1.md b/spec/did-method-trail-v1.md index f9e88cb..c29224d 100644 --- a/spec/did-method-trail-v1.md +++ b/spec/did-method-trail-v1.md @@ -68,6 +68,7 @@ This document is a **Draft** specification submitted for registration in the [W3 - 8.10 [Specification Versioning](#810-specification-versioning) - 8.11 [Revocation Roadmap](#811-revocation-roadmap) - 8.12 [Protocol Roadmap](#812-protocol-roadmap) + - 8.13 [Agent Declaration in Content Signatures](#813-agent-declaration-in-content-signatures) 9. [Privacy Considerations](#9-privacy-considerations) 10. [Reference Implementation](#10-reference-implementation) 11. [Governance](#11-governance) @@ -1609,9 +1610,9 @@ The following items are planned for future specification versions. They are docu --- -## 8.12 Agent Declaration in Content Signatures +## 8.13 Agent Declaration in Content Signatures -### 8.12.1 Motivation +### 8.13.1 Motivation As AI-generated content proliferates across channels (email, code, social media, customer interactions), recipients and downstream systems need a cryptographic mechanism to determine: @@ -1628,7 +1629,7 @@ The `AgentDeclaration` pattern defined in this section extends the assertion cap - Composes with existing W3C Verifiable Credentials and Data Integrity specifications - Declares the accountable issuer organization explicitly -### 8.12.2 AgentDeclaration Content Signature Format +### 8.13.2 AgentDeclaration Content Signature Format An AgentDeclaration is a Data Integrity proof ([VC-DATA-INTEGRITY]) over a canonicalized content manifest. Implementations MUST use a cryptosuite declared in the signing DID Document's `trail:supportedCryptosuites` (§8.2). The default cryptosuite is `eddsa-jcs-2023`. @@ -1679,11 +1680,11 @@ The manifest is canonicalized using the JCS algorithm (RFC 8785) before signing, Content MAY be transported alongside its AgentDeclaration as a detached envelope, or the declaration MAY be embedded (e.g., in HTTP headers, email headers per [RFC 5322], or file metadata). Embedding mechanisms are OUT OF SCOPE for this specification but implementations SHOULD prefer detached transport for format portability. -### 8.12.3 Verification Algorithm +### 8.13.3 Verification Algorithm A verifier presented with content C and a candidate AgentDeclaration D MUST perform the following steps: -1. Parse D and confirm `type == "AgentDeclaration"` and the required fields listed in §8.12.2 are present. +1. Parse D and confirm `type == "AgentDeclaration"` and the required fields listed in §8.13.2 are present. 2. Compute `hash(C)` using `D.contentHash.algorithm` and compare lowercase hex against `D.contentHash.value`. If unequal, verification FAILS. 3. Resolve `D.agent` using the `did:trail` resolution algorithm (§5). If resolution fails or the DID Document is revoked (§8.6), verification FAILS. 4. Locate the verification method identified by `D.proof.verificationMethod` within the resolved DID Document. The method MUST appear in the `assertionMethod` set. If absent, verification FAILS. @@ -1696,7 +1697,7 @@ A verifier presented with content C and a candidate AgentDeclaration D MUST perf A verifier MUST NOT require cooperation from the AI platform on which the agent was deployed to complete verification. All required inputs are obtainable from the content, the declaration, and the public `did:trail` registry. -### 8.12.4 Accountability Model +### 8.13.4 Accountability Model The `accountableOrg` field makes the issuer organization the bearer of accountability for content signed under an AgentDeclaration. This mirrors the Tier 1 accountability model established in §7.5.4: the platform (if any) operates as infrastructure and is not a legal bearer of content responsibility. @@ -1708,19 +1709,19 @@ Three accountability patterns are valid: Verifiers MAY reject AgentDeclarations whose accountable organization is outside the verifier's trust policy (e.g., not listed in the verifier's accepted anchor set). -### 8.12.5 EU AI Act Art. 12 Audit Trail +### 8.13.5 EU AI Act Art. 12 Audit Trail AgentDeclarations are a compliant record-keeping mechanism under EU AI Act Art. 12 (Record-Keeping) for high-risk AI systems producing content in the EU. A deployer retaining the signed declarations alongside the content artifacts provides: -- **Attribution** — which agent produced the content (§8.12.2 `agent`) -- **Accountability** — which legal entity is responsible (§8.12.2 `accountableOrg`) -- **Integrity** — the content has not been modified since signing (§8.12.3 step 2) -- **Non-repudiation** — the signature is verifiable against a public registry (§8.12.3 step 5) -- **Revocation awareness** — the audit trail reflects the DID and VC revocation state at verification time (§8.12.3 step 7) +- **Attribution** — which agent produced the content (§8.13.2 `agent`) +- **Accountability** — which legal entity is responsible (§8.13.2 `accountableOrg`) +- **Integrity** — the content has not been modified since signing (§8.13.3 step 2) +- **Non-repudiation** — the signature is verifiable against a public registry (§8.13.3 step 5) +- **Revocation awareness** — the audit trail reflects the DID and VC revocation state at verification time (§8.13.3 step 7) Conforming deployers SHOULD retain AgentDeclarations for at least the minimum period required by applicable sectoral regulation (for EU AI Act high-risk systems, 6 months per Art. 12(1), longer where sectoral law applies). -### 8.12.6 Security Considerations +### 8.13.6 Security Considerations - **Hash-algorithm agility** — The `contentHash.algorithm` MUST be constrained to algorithms declared in the agent's `trail:supportedCryptosuites`. Verifiers MUST reject declarations using algorithms outside that declared set to prevent downgrade attacks. - **Replay across contexts** — Verifiers SHOULD incorporate `createdAt` into context-specific policy (e.g., reject declarations older than a sector-defined freshness window). @@ -2188,6 +2189,7 @@ Addresses Issue [#1](https://github.com/trailprotocol/trail-did-method/issues/1) | 6 | **Federation requirements hardened** — §3.3.3 updated: registry discovery and cross-registry referrals are now MUST-level. "MAY operate as a standalone registry without federation support" removed; every conforming registry must declare a §3.4 tier. | §3.3.3 | | 7 | **Added Revocation Propagation Protocol (normative)** — New §8.7 specifying: exactly one authoritative registry per DID via `TrailRegistryService` endpoint; mandatory signed W3C Status List 2021 credential per registry; verifier polling with ≤1h cache consistent with §8.6; cross-registry score verification requires verifier-side recomputation from §7.3.4 raw inputs (eliminates score-laundering); end-to-end revocation latency budget. Closes E-014. | §8.7 (new), §8.6, §7.3.4 | | 8 | **Renumbered §8.7–§8.11 → §8.8–§8.12** — Key Recovery, Key Rotation Protocol, Specification Versioning, Revocation Roadmap, and Protocol Roadmap shifted down by one to make room for the new §8.7 Revocation Propagation Protocol. All cross-references updated. | §8.8–§8.12 | +| 9 | **Added Agent Declaration in Content Signatures (normative)** — New §8.13 defining the `AgentDeclaration` signature pattern: cryptographically binds AI-generated content artifacts to an agent DID and an accountable organization DID. Provides attribution, integrity, non-repudiation, and revocation-awareness properties required under EU AI Act Art. 12. Includes signature format (§8.13.2), verification algorithm (§8.13.3), accountability model (§8.13.4), audit trail mapping (§8.13.5), and security considerations (§8.13.6). | §8.13 (new) | ### v1.1.0-draft (2026-03-04) From 44844d9856e7a5dda5983170325fde26e1363cce Mon Sep 17 00:00:00 2001 From: Christian Hommrich Date: Tue, 21 Apr 2026 22:21:39 +0200 Subject: [PATCH 3/3] =?UTF-8?q?fix(spec):=20tone=20=C2=A78.13=20motivation?= =?UTF-8?q?=20to=20spec=20register?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Remove pitch-style opener, marketing adjectives, and legal overclaim. - 'proliferates' → neutral problem statement - 'solves this' → 'addresses this requirement' - 'verifier-friendly' removed - 'are a compliant mechanism' → 'designed to support compliance with' --- spec/did-method-trail-v1.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/spec/did-method-trail-v1.md b/spec/did-method-trail-v1.md index c29224d..6c11787 100644 --- a/spec/did-method-trail-v1.md +++ b/spec/did-method-trail-v1.md @@ -1614,15 +1614,15 @@ The following items are planned for future specification versions. They are docu ### 8.13.1 Motivation -As AI-generated content proliferates across channels (email, code, social media, customer interactions), recipients and downstream systems need a cryptographic mechanism to determine: +Verifiers of AI-generated content artifacts require a mechanism to establish: 1. **Whether** a given artifact was produced by an AI agent (as opposed to a human or a different agent) 2. **Which** agent produced it 3. **Which organization is accountable** for the agent's output under applicable regulation (e.g., EU AI Act Art. 12) -Existing approaches — platform-specific watermarks, text-based disclaimers, metadata headers — are either easily stripped, non-verifiable without vendor cooperation, or cannot survive format conversion. A DID-based signature mechanism solves this by binding the artifact to an agent DID that is itself bound to a human-accountable organization DID through the chain established in §7.5 (PlatformIdentityBinding). +Existing approaches — platform-specific watermarks, text-based disclaimers, metadata headers — are either easily stripped, non-verifiable without vendor cooperation, or do not survive format conversion. This specification addresses this requirement by binding the artifact to an agent DID that is itself bound to a human-accountable organization DID through the chain established in §7.5 (PlatformIdentityBinding). -The `AgentDeclaration` pattern defined in this section extends the assertion capability of `did:trail` agent DIDs (§4.3) to arbitrary content artifacts, producing a portable, verifier-friendly proof that: +The `AgentDeclaration` pattern defined in this section extends the assertion capability of `did:trail` agent DIDs (§4.3) to arbitrary content artifacts, producing a proof that: - Works offline (no call to AI platform required) - Survives copy/paste and re-publication (signature travels with the content) @@ -1711,7 +1711,7 @@ Verifiers MAY reject AgentDeclarations whose accountable organization is outside ### 8.13.5 EU AI Act Art. 12 Audit Trail -AgentDeclarations are a compliant record-keeping mechanism under EU AI Act Art. 12 (Record-Keeping) for high-risk AI systems producing content in the EU. A deployer retaining the signed declarations alongside the content artifacts provides: +AgentDeclarations are designed to support compliance with EU AI Act Art. 12 (Record-Keeping) for high-risk AI systems producing content in the EU. A deployer retaining the signed declarations alongside the content artifacts provides: - **Attribution** — which agent produced the content (§8.13.2 `agent`) - **Accountability** — which legal entity is responsible (§8.13.2 `accountableOrg`)