11 KiB
Draft
Abstract
This document defines experimental semantics for exchanging dynamic trust assertions and trust-relevant runtime events in multi-agent systems. The mechanism allows one party to communicate scoped, time-bounded statements about another party's observed trust-relevant behavior, together with confidence and optional evidence references. The mechanism supplements identity, attestation, and authorization systems; it does not replace them. The goal is to improve interoperability where long-running agent interactions require trust decisions that evolve over time rather than remaining fixed at initial authentication.
1. Introduction
Many agent systems authenticate peers once and then rely on static identity or long-lived authorization artifacts for the remainder of an interaction. That approach is often insufficient for long-running or cross-domain systems in which runtime behavior, policy violations, attestation changes, or observed failures should affect how much confidence one participant places in another.
Several existing drafts address accountability, attestation, authorization, or cross-domain information sharing. However, the current landscape still lacks a compact, reusable way to represent and exchange dynamic trust information as an interoperable runtime signal. As a result, systems that do attempt dynamic trust tend to use proprietary or locally scoped semantics that are hard to compare or consume across implementations.
This document defines a narrow mechanism for trust events and trust assertions. It standardizes how such information is represented and how relying parties distinguish issuer opinion, freshness, scope, and confidence. It does not define a single global scoring algorithm, a reputation marketplace, or a replacement for authorization policy.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.
Trust Event: an observed runtime occurrence relevant to trust assessment.
Trust Assertion: a structured statement by an issuer regarding the trust-relevant state of a subject.
Issuer: the party that originates a trust assertion.
Subject: the agent or service that a trust assertion describes.
Relying Party: a party that consumes a trust assertion for local decision-making.
Scope: the context in which a trust assertion is intended to apply.
Confidence: the issuer's stated level of confidence in a trust assertion.
Freshness: the temporal validity information for a trust assertion, including creation time, expiry, or other recency limits.
Evidence Reference: a pointer to supporting execution, attestation, compliance, or observational evidence.
Revocation: withdrawal or supersession of a previously issued trust assertion.
Portable Trust Assertion: a trust assertion intended for use outside the issuer's local trust store.
Local Trust State: trust information maintained only within one implementation and not intended for exchange under this document.
3. Problem Statement and Design Goals
Static identity answers who a peer claims to be. Dynamic trust concerns whether recent behavior, evidence, and context justify continuing to rely on that peer in the same way. In current practice, systems often blur these concepts, leading to three recurring problems:
- trust information is shared without clear scope or expiry,
- negative trust signals are propagated without confidence or evidence context, and
- receivers treat portable trust statements as universal authorization decisions.
The design goals for this document are therefore:
- to define a compact representation for trust events and trust assertions,
- to require issuer, subject, scope, freshness, and confidence information,
- to support revocation or supersession of stale assertions,
- to preserve local policy discretion, and
- to avoid false precision by not mandating one global trust algorithm.
4. Trust Model Overview
This document defines two related objects:
- a
trust-event, and - a
trust-assertion.
A trust event is an observed occurrence that may justify a trust update. Examples include successful execution, attestation degradation, repeated policy violation, or verified protocol misbehavior. This document standardizes the representation of such events but does not require that every event be exchanged externally.
A trust assertion is a portable statement derived from local observation, policy processing, or supporting evidence. A trust assertion can be exchanged between participants when the issuer intends another relying party to consider that information.
This document is layered above identity, attestation, and authorization systems. A trust assertion MUST NOT be treated as proof of identity and MUST NOT be used as a substitute for authentication. Likewise, it MUST NOT by itself grant authorization. Instead, it provides a supplemental input to local policy.
5. Trust Events
A trust event record MUST include:
- event identifier,
- subject identifier,
- issuer or observer identifier,
- event type,
- timestamp,
- scope.
A trust event SHOULD include an evidence reference when supporting evidence exists and can be shared. A trust event MAY include an explanation code or local severity value.
This document does not require that all trust events be externally exchanged. An implementation MAY use local-only trust events to derive portable trust assertions. However, if a portable trust assertion references a trust event, the implementation SHOULD preserve enough linkage that a relying party can understand the event context.
Example trust-event categories include:
- successful verified execution,
- attestation downgrade,
- policy violation,
- repeated protocol error,
- trust recovery after remediation.
This list is illustrative only.
6. Trust Assertions
A trust assertion MUST include:
- assertion identifier,
- issuer identifier,
- subject identifier,
- trust statement value,
- confidence value,
- freshness information,
- scope.
A trust assertion MAY include:
- evidence reference,
- explanation code,
- delta-from-prior value,
- revokes or supersedes assertion identifier.
This document permits multiple trust statement models, including bounded levels, numeric values, or delta updates. If an issuer uses a given model, the assertion MUST identify that model clearly enough for the relying party to interpret the statement.
An issuer MUST distinguish portable trust assertions from local trust state. A relying party MUST be able to determine whether the received assertion is intended to travel across administrative boundaries or is only meaningful within the issuer's local environment.
7. Freshness, Confidence, and Revocation
Freshness is mandatory. An issuer MUST include enough temporal information for a relying party to detect stale assertions. At minimum, that means creation time and either expiry time or a validity policy that can be interpreted consistently.
Confidence is distinct from trust value. The trust statement says what the issuer believes about the subject; the confidence value says how strongly the issuer stands behind that statement. A relying party MUST NOT assume that a high trust value implies high confidence, or vice versa.
If an issuer revokes or supersedes a prior assertion, the new assertion MUST identify the prior assertion. A relying party receiving both old and new assertions SHOULD prefer the newer assertion when freshness and issuer identity indicate that supersession is valid.
Issuers MUST NOT present stale assertions as current. Relying parties SHOULD reject or downgrade stale assertions according to local policy.
8. Receiver Processing and Policy Boundaries
Relying parties consume trust assertions as local policy input. This document does not require one decision algorithm. However, receivers MUST preserve the following distinctions:
- issuer opinion versus objective fact,
- trust value versus confidence,
- portable assertion versus local trust state,
- trust input versus authorization decision.
A relying party MAY combine assertions from multiple issuers, but comparison across issuers is inherently local-policy dependent. This document therefore does not define issuer ranking, quorum rules, or mandatory aggregation algorithms.
When a negative assertion lacks sufficient freshness, scope, or issuer clarity, a relying party SHOULD treat it cautiously or ignore it. When a positive assertion lacks evidence reference where such evidence is normally expected, the relying party MAY reduce its weight.
9. Security Considerations
Dynamic trust information is vulnerable to spoofing, replay, collusion, and reputational poisoning. Implementations therefore need authenticated origin and integrity protection for portable trust assertions, even though this document does not define the underlying cryptographic transport or token format.
Replay of stale trust assertions can preserve outdated trust long after behavior has changed. For this reason, freshness is mandatory and receivers SHOULD apply explicit stale-data handling.
Colluding issuers can amplify false claims. This document does not solve collusion, but it reduces ambiguity by requiring issuer identification, scope, and confidence. Deployments SHOULD avoid treating multiple assertions as independent when they originate from closely related sources.
Trust assertions can also be misused as unauthorized access-control surrogates. Implementers MUST NOT treat a trust assertion alone as granting access absent normal authorization checks.
10. Privacy Considerations
Trust events and trust assertions may reveal sensitive operational information, including policy violations, remediation history, attestation degradation, or other indicators of weakness. Negative assertions may also expose behavior that a subject does not expect to be shared across domains.
Implementations SHOULD minimize disclosure to what is necessary for the intended scope. Evidence references SHOULD avoid exposing raw sensitive details when a narrower reference suffices. Cross-domain sharing of negative assertions deserves particular caution because it can create lasting reputational effects outside the original operational context.
11. IANA Considerations
This document currently requests no IANA action.
If implementation experience later shows clear need for shared registries, suitable candidates include trust-event categories, trust statement model identifiers, and explanation codes. Such registries should remain compact and avoid implying false precision.
12. References
- [RFC2119] Key words for use in RFCs to Indicate Requirement Levels.
- [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.
- Placeholder reference for
draft-cosmos-protocol-specification. - Placeholder reference for
draft-jiang-seat-dynamic-attestation. - Placeholder reference for
draft-aylward-daap-v2. - Placeholder reference for
draft-birkholz-verifiable-agent-conversations.