70 lines
3.4 KiB
Markdown
70 lines
3.4 KiB
Markdown
# 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?
|