RE: LLMs and Agents usage in the CCG

Hi all,

Three quick threads, since the last 36 hours covered a lot of ground:

------------------------------------------------------------------------

@Moses -- on your "id/ids" identity-bound pronoun proposal:

That maps cleanly onto the persistent-identity-anchor problem TRAIL
was built around. A did:trail DID gives an agent exactly what "id/ids"
implies: a stable, verifiable identity that survives reputation-tier
changes, role reassignments, and registry migrations, with
cryptographic continuity. The pronoun and the DID become two views of
the same anchor.

------------------------------------------------------------------------

@Michael -- on draft-herman-did-pnl-00:

Read it carefully. Your §1.3 framing -- did:pnl identifies a role
profile, not an agent instance, with the agent claiming PNL membership
via a PnlRoleCredential -- makes the relationship to instance-level
DID methods straightforward. did:trail fits cleanly into that pattern
as the identity + trust anchor for the agent that holds your role
profile.

Two seams I'd like to highlight, both as constructive contributions
rather than critique:

(1) Dimension D `trustLevel` as fast-path filter, evidence as the
substrate. Your enum (SELF < ORG < 3PVER < GOVVER < VCL2 < VCL3) is
useful as a quick filter -- "accept at least 3PVER". But two agents
both labelled 3PVER can carry very different verification depth. A
Big4 full-population audit (8,000 transactions, 90 days old, 2
findings) and a boutique sampling audit (50 transactions, 380 days
old, 0 findings) collapse to the same token. EU AI Act Articles 13/14
push that decision to the relying party, not the credential issuer.
TRAIL PR #12 (evidence-weighted Trust Score) sketches an EvidenceClaim
VC-bundle pattern that sits next to your trustLevel token without
replacing it -- token for fast-path, evidence for risk-mapped
evaluation.

(2) Cascading revocation for high-authority profiles. §11.2 covers
Status List 2021 and DIDComm-push to holder inboxes. Both work
agent-by-agent. When an accreditation body revokes a compromised
issuer, each PnlRoleCredential under that issuer needs to be
invalidated individually -- thousands of pushes, or a status-list pull
window of hours during which compromised credentials remain accepted.
TRAIL PR #13 (Trust Anchor Model + Revocation Propagation) defines a
single anchor-level revocation event that invalidates all dependent
credentials at once. For PAYEXEC / EXEC / SYSADMIN profiles, that's
the difference between damage limitation and damage propagation.

Concrete proposal: I'd be glad to open a PR against mwherman2000/SVRN7
adding §13.5 "Binding to did:trail Identity & Trust Anchor". Mirrors
the shape of your existing §13.1 (did:drn) and §13.4 (OID4VC)
sections. About 1-2 pages, with JSON snippets for the trailAnchorDid
field on PnlRoleCredential, the additive verification step, and an
optional evidenceBundle reference for high-authority contexts. Tracks
the same interop pattern your §13 already establishes -- did:pnl
identifies the role, the bound DID method handles instance identity
and trust mechanics. Happy to sketch the PR for your review before
opening it formally if that's easier.

------------------------------------------------------------------------

For the broader thread: the layering question -- "instance DID vs role
profile DID" -- seems to be where this discussion converges across
several proposals (PNL, AIR, the Morrow signature pattern). It's a
pattern worth naming explicitly. Happy to co-author a short CCG note
on the layering pattern if there's appetite in this group -- across
PNL, AIR, Morrow-style signature binding, and did:trail.

Repos + notes for reference:
- TRAIL spec + PRs: https://github.com/trailprotocol/trail-did-method
- Layering analysis (did:pnl vs did:trail), with JSON schema sketches
for a §13.5 binding proposal:
  https://github.com/trailprotocol/trail-did-method/discussions/15

Best,
Christian Hommrich
TRAIL Protocol
https://trailprotocol.org

Received on Tuesday, 21 April 2026 09:13:07 UTC