feat(spec): Trust Anchor Model (§3.4) + Revocation Propagation (§8.7) - closes #1#13
Merged
chrishooooo-netizen merged 1 commit intomainfrom Apr 21, 2026
Merged
Conversation
Closes #1 (Federation + Trust Anchor). Addresses Challenge Register einwaende E-013 and E-014. Builds on the technical memo from Amey Parle (2026-04-13). Co-architected with Amey. Changes: - New §3.4 Trust Anchor Model — federated hybrid: Tier-1 Root Registries (TSAI + curated operators, mutual recognition), Tier-2 Sub-Registries (delegation from Tier-1, CA-like without single anchor), Tier-3 endpoint endorsements (web-of-trust with Risk Penalty discount in §7.3 D5). Verifier Trust List, no hard-coded anchor. - §3.3.3 hardened: discovery/referrals are MUST-level; "MAY operate as standalone" removed; every conforming registry declares a §3.4 tier. - New §8.7 Revocation Propagation Protocol — exactly one authoritative registry per DID via TrailRegistryService endpoint; mandatory signed W3C Status List 2021 credential; verifier polling ≤1h consistent with §8.6; cross-registry score verification requires verifier-side recomputation from §7.3.4 raw inputs (closes score-laundering vector); end-to-end revocation latency budget. - Renumbered §8.7-§8.11 → §8.8-§8.12 to make room. All cross-references updated. ToC and historical changelog updated. - §8.11 Revocation Roadmap marked as partially superseded by §8.7. Co-Authored-By: Amey Parle <amey@parle.ai>
Contributor
Author
|
@AmeyParle - this PR-Bundle implements Issue #1 (Federation Trust Anchor Model + Revocation Propagation) following your 13.04.2026 technical memo. §3.4 codifies the Federated Hybrid (Tier-1 Roots / Tier-2 Sub / Tier-3 web-of-trust with D5 Risk Penalty), §8.7 makes Status List 2021 normative with cross-registry score recomputation per §7.3.4. You are credited as Co-Architect in the changelog and commit trailer. Review welcome whenever it suits you. |
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 14, 2026
…ages First production-style reference for did:trail v1: 1 org + 5 agent DID Documents for the Rocking.AI.Sales AI Sales Crew, signed with an ed25519 test key (clearly marked POC-KEY-NOT-FOR-PRODUCTION). - examples/ras-crew-registry.json: 6 DID Documents, each with required TrailRegistryService endpoint per spec section 3.3.1, trail-hash per section 4.5.2, Ed25519Signature2020 over canonical JSON. - examples/js/ras-crew-poc/build-registry.js: deterministic builder. - examples/js/ras-crew-poc/build-verify-pages.js: zero-dep generator for the static verify endpoint on trailprotocol.org/verify/ras-crew/. - examples/js/resolve-ras-crew.js: local resolver, verifies registry signature + trail-hash, --list and --test modes (positive + negative). Builds on PR #13 (Trust Anchor Model). Demonstrates the spec live in a real deployment and answers the W3C CCG thread (Apr 2026) on what an agent identity layer looks like in practice. Co-Architect: Amey Parle <amey@example.invalid>
5 tasks
6 tasks
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 21, 2026
First production-style reference for did:trail v1: 1 org + 5 agent DID Documents for the Rocking.AI.Sales AI Sales Crew, signed with an ed25519 test key (clearly marked POC-KEY-NOT-FOR-PRODUCTION). - examples/ras-crew-registry.json: 6 DID Documents, each with required TrailRegistryService endpoint per spec section 3.3.1, trail-hash per section 4.5.2, Ed25519Signature2020 over canonical JSON. - examples/js/ras-crew-poc/build-registry.js: deterministic builder. - examples/js/ras-crew-poc/build-verify-pages.js: zero-dep generator for the static verify endpoint on trailprotocol.org/verify/ras-crew/. - examples/js/resolve-ras-crew.js: local resolver, verifies registry signature + trail-hash, --list and --test modes (positive + negative). Builds on PR #13 (Trust Anchor Model). Demonstrates the spec live in a real deployment and answers the W3C CCG thread (Apr 2026) on what an agent identity layer looks like in practice. Co-Architect: Amey Parle <amey@example.invalid>
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 21, 2026
First production-style reference for did:trail v1: 1 org + 5 agent DID Documents for the Rocking.AI.Sales AI Sales Crew, signed with an ed25519 test key (clearly marked POC-KEY-NOT-FOR-PRODUCTION). - examples/ras-crew-registry.json: 6 DID Documents, each with required TrailRegistryService endpoint per spec section 3.3.1, trail-hash per section 4.5.2, Ed25519Signature2020 over canonical JSON. - examples/js/ras-crew-poc/build-registry.js: deterministic builder. - examples/js/ras-crew-poc/build-verify-pages.js: zero-dep generator for the static verify endpoint on trailprotocol.org/verify/ras-crew/. - examples/js/resolve-ras-crew.js: local resolver, verifies registry signature + trail-hash, --list and --test modes (positive + negative). Builds on PR #13 (Trust Anchor Model). Demonstrates the spec live in a real deployment and answers the W3C CCG thread (Apr 2026) on what an agent identity layer looks like in practice. Co-Architect: Amey Parle <amey@example.invalid>
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 21, 2026
§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.
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 21, 2026
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).
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 21, 2026
§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.
chrishooooo-netizen
added a commit
that referenced
this pull request
Apr 21, 2026
* feat(spec): §8.12 Agent Declaration in Content Signatures (draft) 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). * fix(spec): renumber Agent Declaration §8.12 → §8.13 §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. * fix(spec): tone §8.13 motivation to spec register 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'
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #1 (Federation + Trust Anchor). This PR turns the Federation discussion into an implementable, normative spec section and closes the cross-registry revocation gap that has blocked verifier conformance.
Built on the technical memo from Amey Parle (2026-04-13) — co-architected with Amey. Amey's positioning paper reframed Issue #1 from "discussion" to "PRD", and this PR is the direct materialization of his recommendations.
What changed
New §3.4 — Trust Anchor Model (normative)
Federated hybrid trust model with three explicit tiers:
§3.3.3 — Federation Requirements hardened
Registry discovery and cross-registry referrals are now MUST-level. Every conforming registry must declare which §3.4 tier it operates in.
New §8.7 — Revocation Propagation Protocol (normative)
TrailRegistryServiceendpoint declared in the DID Document (§3.3.1 item 1). Conflicting claims = spec violation..well-known/trail-registry.json.Section renumbering
Existing §8.7–§8.11 (Key Recovery, Key Rotation, Spec Versioning, Revocation Roadmap, Protocol Roadmap) shifted down to §8.8–§8.12 to make room for the new §8.7. All cross-references, ToC, and historical v1.1.0 changelog entries updated. §8.11 Revocation Roadmap now marked as partially superseded by §8.7.
Why
Closes Challenge Register E-013 — Federation Trust Anchor Model (KRITISCH)
Fix: Hybrid model now normative. Tier-1/2/3 defined. Verifier picks via Trust List. No single anchor.
Closes Challenge Register E-014 — Cross-Registry Verification + Revocation Propagation (HOCH)
Fix: Score-inputs from §7.3.4 are canonical, verifier recomputes. Status List 2021 is the normative revocation mechanism with authoritative-registry-per-DID uniqueness.
Out of scope (deliberate)
Spec version
v1.2.0-draft → becomes v1.2.0-rc1 once this PR + PR #12 (evidence-weighted Trust Score) are merged.
Co-architected with
Amey Parle — originator of the federation/trust-anchor analysis that drove this PR.
cc @AmeyParle