Research Brief

Problem framing

Fact: the analyzer marks Dynamic Trust and Reputation as a high-severity gap in the agent identity and authorization space. Fact: the stated problem is that static authentication is not enough for long-running autonomous systems, because past behavior, policy violations, successful task history, and environmental changes can alter whether another agent should be trusted.

Inference: this topic is worth pursuing, but it is easy to overreach. The most defensible first draft is not a universal reputation system. It is a narrow mechanism for representing and exchanging trust-relevant runtime assertions with freshness, confidence, issuer scope, and revocation semantics.

Evidence from existing drafts

Fact: the gap report identifies only five partially related ideas across the full corpus. The clearest named mechanism is Trust Scoring from draft-cosmos-protocol-specification. Other partial signals include Trust Score-based Policy Enforcement, Cryptographic Proof-Based Autonomy, and dynamic attestation work.

Fact: the gap report points to several related drafts: draft-jiang-seat-dynamic-attestation, draft-cosmos-protocol-specification, draft-diaconu-agents-authz-info-sharing, draft-agent-gw, and draft-li-dmsc-inf-architecture. These appear to provide fragments such as attestation, trust-native semantics, or information sharing, but not a generally reusable dynamic trust exchange core.

Fact: the broader overview shows stronger maturity in adjacent accountability and attestation drafts such as draft-aylward-daap-v2, draft-guy-bary-stamp-protocol, and draft-birkholz-verifiable-agent-conversations. Those are important not because they solve dynamic trust directly, but because they provide candidate evidence sources from which trust events might be derived.

Fact: the holistic ecosystem outline places dynamic trust alongside assurance, cross-domain security, and provenance rather than as a standalone identity replacement. That is a strong scope signal.

Overlap and adjacent work

Inference: the main collision risks are:

collapsing trust into identity or attestation
drifting into full behavior verification and assurance profiles
defining global reputation semantics that are impossible to standardize early

Inference: the architect should treat dynamic trust as a supplemental decision input. A trust assertion should help receivers adjust risk posture, routing, delegation, or policy thresholds, but should not replace authentication, authorization, or local policy.

There is also a likely layering opportunity: trust events may be derived from signed execution evidence, attestation results, policy compliance checks, or observed protocol outcomes. That suggests the first draft should define a trust event model and trust assertion envelope rather than inventing a new base proof system.

Gaps and unresolved questions

Fact: the available analyzer artifacts do not yet show a shared vocabulary for freshness, confidence, negative trust evidence, or revocation of prior trust assertions. Fact: the ideas corpus surfaced less direct material than expected, which suggests the field is genuinely underdefined rather than merely fragmented.

Open questions:

What is the minimum trust event payload: subject, issuer, event type, score or delta, confidence, freshness, scope, and evidence reference are likely candidates, but this needs careful architectural pruning.
Should trust be represented as absolute score, bounded level, delta adjustment, or a combination?
How should a receiver distinguish local opinion from portable inter-domain assertion?
How should negative trust events be shared without creating privacy, defamation, or poisoning problems?
What revocation or expiry mechanism is needed so stale trust does not silently persist?

Additional data worth investigating

Inspect draft-cosmos-protocol-specification directly for the semantics of trust scoring and whether any parts are salvageable without importing the whole model.
Inspect draft-jiang-seat-dynamic-attestation for how runtime attestation changes over time and whether it offers reusable freshness or confidence patterns.
Compare draft-aylward-daap-v2 and draft-birkholz-verifiable-agent-conversations for event formats that could serve as evidence references.
Search more deeply for confidence, reputation, revocation, behavioral, policy violation, and provenance in raw draft text if the architect needs a stronger evidence base.

Recommendation to the architect

Design the first draft as an experimental representation for dynamic trust assertions and trust events, not as a global scoring system. Keep the document centered on:

trust event vocabulary
trust assertion envelope and required fields
issuer, subject, scope, freshness, and confidence semantics
revocation or expiry behavior
security and privacy limits on exchanging negative or cross-domain trust information

Avoid redefining identity, token exchange, attestation, or full behavior verification. If evidence references from adjacent drafts can be reused, bind to them rather than creating a new proof substrate.

5.1 KiB Raw Blame History