61 lines
5.1 KiB
Markdown
61 lines
5.1 KiB
Markdown
# 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.
|