Skip to content

feat(spec): Trust Anchor Model (§3.4) + Revocation Propagation (§8.7) - closes #1#13

Merged
chrishooooo-netizen merged 1 commit intomainfrom
feature/trust-anchor-federation
Apr 21, 2026
Merged

feat(spec): Trust Anchor Model (§3.4) + Revocation Propagation (§8.7) - closes #1#13
chrishooooo-netizen merged 1 commit intomainfrom
feature/trust-anchor-federation

Conversation

@chrishooooo-netizen
Copy link
Copy Markdown
Contributor

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:

  • Tier-1 Root Registries — TSAI + curated operators, mutual recognition via §3.3 federation. Initial Tier-1 set to be finalized in the Genesis Issuer Set (v1.2.0-rc1). No single root is privileged.
  • Tier-2 Sub-Registries — Delegate from one or more Tier-1 roots. CA-like structure without a single trust anchor. Cross-signing supported.
  • Tier-3 Endpoint Endorsements — Web-of-trust overlay. Endorsements count in §7.3 D5 but are discounted via a Risk Penalty to prevent cluster attacks. Tier-3 entities cannot publish authoritative Status Lists.
  • Verifier Trust List — Verifiers select their active anchor set locally. No hard-coded single anchor. Closes the "MAY operate as a standalone registry" loophole previously in §3.3.

§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)

  • Authoritative Registry uniqueness — Exactly one per DID via the TrailRegistryService endpoint declared in the DID Document (§3.3.1 item 1). Conflicting claims = spec violation.
  • Status List 2021 (mandatory) — Every registry MUST publish a signed W3C Status List 2021 credential, served at a stable endpoint advertised in .well-known/trail-registry.json.
  • Verifier polling model — ≤1h cache consistent with §8.6. HTTP conditional requests (ETag/Last-Modified). Fail-closed on fetch failure for high-stakes contexts.
  • Cross-registry score verification — When Registry B presents a trust score for a DID authoritative to Registry A, the score is NOT canonical. Verifiers MUST fetch raw inputs from Registry A's §7.3.4 endpoint and recompute locally. This eliminates the score-laundering vector where a federated peer could fabricate scores.
  • Revocation latency budget — T+0 bit flip → T+≤60s served → T+≤1h all verifiers refreshed.

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)

"§3.3 lässt Federation-Modell offen ('MAY operate as standalone'). Amey: 'CA, federated, oder web-of-trust?' Diese Frage determiniert die TSAI-Root-CA-These und die Bootstrap-Strategie. Sie kann NICHT offen bleiben."

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)

"§3.3.2 nur HTTP 301. Keine Antwort: Wie wird Score aus Registry A in B verifiziert? Wie propagiert Revocation?"

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

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>
@chrishooooo-netizen
Copy link
Copy Markdown
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>
@chrishooooo-netizen chrishooooo-netizen merged commit 68f19f1 into main Apr 21, 2026
3 checks passed
@chrishooooo-netizen chrishooooo-netizen deleted the feature/trust-anchor-federation branch April 21, 2026 20:03
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'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RFC: Federation Model Architecture Review

1 participant