Re: LLMs and Agents usage in the CCG

Hi Siri and all,

The HDP approach resonates with me. Structuring delegation provenance
as a cryptographically signed chain — anchored to the authorizing
human, with each agent hop appending its own signed record — is an
elegant solution to a problem the community has been circling for a
while. The decision to make verification fully offline, requiring only
a public key and session ID, is architecturally sound and avoids the
availability coupling that plagues registry-polling designs.

That said, I think there is a layer that HDP currently leaves open:
the agent_id field in each delegation hop is a string — meaningful
within a session, but carrying no cryptographic binding to a
persistent, cross-session identity. If the same logical agent is
deployed in a new environment, re-instantiated after a restart, or
accessed by a verifier in a different organizational context, there is
currently no standard way to establish that it is the same agent — or
to answer how trustworthy that agent has been over time, independent
of any single authorization chain. HDP answers "was this action
authorized?". What is still missing is a durable answer to "is this
agent who it claims to be?"

This is the gap we are trying to close with the TRAIL DID method
(did:trail). A did:trail identifier provides a resolvable, persistent
anchor that an HDP agent_id field can reference — giving provenance
chains a stable root that survives session boundaries and deployment
changes. The TRAIL Trust Score (§7.3 of the spec — five independently
verifiable dimensions covering identity verification, track record,
information provenance, behavioral consistency, and third-party
attestations) adds a longitudinal trust signal that complements HDP's
per-session accountability. Cross-registry federation (§3.3) means
this works across organizational and jurisdictional boundaries without
requiring a single central authority.

On that federation point: we just opened PR #13 on trail-did-method
which codifies this normatively. §3.4 Trust Anchor Model defines a
Federated Hybrid — Tier-1 Root Registries, Tier-2 Sub-Registries that
delegate from Tier-1, and Tier-3 endpoint endorsements (web-of-trust,
weighted into the Trust Score with a Risk Penalty discount). Verifiers
maintain a local Trust List — no hard-coded single anchor. §8.7 makes
W3C Status List 2021 the normative revocation mechanism, with exactly
one authoritative registry per DID (declared via TrailRegistryService
in the DID Document). Cross-registry score verification is
deliberately non-trivial: verifiers fetch raw inputs from the origin
registry's §7.3.4 endpoint and recompute the score locally, which
eliminates score-laundering across federated registries. PR:
https://github.com/trailprotocol/trail-did-method/pull/13

Amey Parle, who has been contributing to the trust score architecture
and is co-architect on the federation model landing in PR #13, and I
would be glad to explore how a did:trail reference could slot cleanly
into HDP's agent_id field — or how TRAIL and HDP could publish a joint
integration note for the CCG.

Spec: https://github.com/trailprotocol/trail-did-method
W3C DID Registry PR: w3c/did-extensions#669

Christian Hommrich
TRAIL Protocol

Received on Tuesday, 14 April 2026 11:00:52 UTC