# User Spec

## Topic

Dynamic Trust and Reputation for Multi-Agent Systems

## Goal

Produce a credible IETF-style Internet-Draft for an interoperable way to represent and exchange runtime trust signals about agents, so systems can adapt authorization, routing, or collaboration decisions as agent behavior changes over time.

## Intended status

Experimental.

Rationale: the need is clear, but trust scoring models are easy to overclaim and likely need deployment experience before standards-track treatment.

## Problem to solve

The analyzer identifies Dynamic Trust and Reputation as a high-severity gap. Current work is dominated by static identity and certificate-style authentication, but long-running agent ecosystems need a way to incorporate runtime behavior, observed failures, successful execution history, and policy violations into ongoing trust decisions.

The draft should address:

- how trust-relevant events are represented
- how trust assertions or trust updates are shared
- how recipients understand freshness, confidence, and scope
- how dynamic trust interacts with but does not replace identity and authorization

## What must be true in the final draft

- The draft distinguishes identity, attestation, authorization, and trust; it must not collapse them into one concept.
- Dynamic trust is presented as supplemental runtime evidence, not magic security.
- The mechanism is narrow enough to be interoperable and testable.
- Security and privacy analysis address manipulation, collusion, replay, reputational poisoning, and unwanted disclosure.
- The document remains grounded in observable events and explicit confidence, not vague AI safety rhetoric.

## Constraints

- scope constraints
  Do not try to standardize a universal reputation economy or global scoring service. Focus on exchangeable trust signals and their interpretation boundaries.
- compatibility constraints
  Reuse adjacent identity, attestation, and execution-evidence work when possible. Do not redefine base authentication or token exchange.
- terminology constraints
  Separate trust event, trust assertion, confidence, freshness, subject, issuer, and scope. Avoid anthropomorphic language.

## Source materials to prioritize

- `/home/c/projects/ietf-draft-analyzer/data/reports/gaps.md`
- `/home/c/projects/ietf-draft-analyzer/data/reports/holistic-agent-ecosystem-draft-outlines.md`
- `/home/c/projects/ietf-draft-analyzer/data/reports/ideas.md`
- `/home/c/projects/ietf-draft-analyzer/data/reports/overview.md`
- `draft-cosmos-protocol-specification`
- `draft-jiang-seat-dynamic-attestation`
- `draft-aylward-daap-v2`
- `draft-birkholz-verifiable-agent-conversations`
- relevant WIMSE, RATS, or attestation-adjacent drafts when they help prevent reinvention

## Success criteria

- A reader can tell what trust-relevant event data must be present and how it is scoped.
- A reader can tell how trust assertions expire, how confidence is expressed, and how misuse is limited.
- Reviewers can challenge the design on substance rather than on fuzzy terminology or missing threat analysis.
- The draft makes clear what decisions dynamic trust can inform and what it must not be trusted to do alone.

## Questions for the team

- What is the minimum interoperable trust event model?
- Should trust updates be absolute assertions, delta adjustments, or both?
- How should confidence, issuer scope, and freshness be represented?
- What privacy risks arise when sharing negative trust events across domains?