13 KiB
Draft
Abstract
This document defines experimental semantics for exchanging portable dynamic trust assertions and associated trust-relevant runtime events in multi-agent systems. The mechanism allows one party to communicate a scoped, time-bounded opinion about another party's observed trust-relevant behavior, together with model identification, confidence, freshness, and optional evidence or explanation data. The mechanism supplements identity, attestation, and authorization systems; it does not replace them. Its purpose 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 assertions and supporting trust events. It standardizes how portable trust information is represented and how relying parties distinguish issuer opinion, freshness, scope, confidence, and model type. It does not define a global scoring algorithm, a reputation marketplace, or a replacement for authorization policy.
The intended status of this document is Experimental.
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.
Portable Trust Assertion: a trust assertion intended for use outside the issuer's local trust store.
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 degree of confidence in a trust assertion.
Freshness: the temporal validity information for a trust assertion, including creation time and expiry or equivalent validity bound.
Model Identifier: an identifier indicating how the trust statement value is to be interpreted, such as level-based, numeric, or delta-based.
Evidence Reference: a pointer to supporting execution, attestation, compliance, or observational evidence.
Explanation Code: a compact issuer-supplied explanation label associated with a trust assertion.
Revocation: invalidation of a previously issued trust assertion.
Supersession: replacement of a prior trust assertion by a newer assertion from the same issuer.
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 portable trust assertion envelope,
- to require issuer, subject, scope, freshness, confidence, and model identification,
- 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 standardizes portable trust assertions as the primary interoperable object. Trust events are supporting input objects that MAY be exchanged or MAY remain local, depending on deployment needs.
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 minimal representation of such events, but portable trust assertions are the main interoperability target.
A portable trust assertion is a scoped issuer opinion derived from local observation, policy processing, or supporting evidence. A portable 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 portable 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 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. If a portable trust assertion references a trust event, the implementation SHOULD preserve enough linkage that a relying party can understand the event context.
This document does not standardize a mandatory global event vocabulary in v2. Event-type names MAY be profile-specific unless later implementation experience shows the need for shared registries.
6. Trust Assertions
A portable trust assertion MUST include:
- assertion identifier,
- issuer identifier,
- subject identifier,
- trust statement value,
- model identifier,
- confidence value,
- freshness information,
- scope.
A portable trust assertion MAY include:
- evidence reference,
- explanation code,
- delta-from-prior value,
- revokes assertion identifier,
- supersedes assertion identifier.
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.
If a portable trust assertion carries a negative or cautionary trust statement, it MUST include either an evidence reference or an explanation code. It MAY include both.
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 bound 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.
Revocation and supersession are distinct. Revocation invalidates a prior assertion without necessarily replacing it with a new positive or negative assertion. Supersession replaces a prior assertion with a newer one from the same issuer. If an issuer revokes or supersedes a prior assertion, the new assertion MUST identify the prior assertion.
Issuers MUST NOT present stale assertions as current. A relying party MUST reject a clearly expired portable trust assertion as conformant input, though it MAY retain it locally for audit or diagnostic purposes.
8. Receiver Processing and Policy Boundaries
Portable trust assertions are 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 MUST NOT treat an unauthenticated portable trust assertion as conformant input under this specification. Likewise, a relying party MUST NOT treat a portable trust assertion alone as granting access absent normal authorization checks.
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. Implementations SHOULD take care not to treat closely related issuers as independent corroboration sources.
8.1 Non-Normative Assertion Example
An issuer may send a portable trust assertion with:
- assertion-id
ta-44 - subject
agent:example:planner7 - issuer
agent:example:gateway2 - model
level - trust-value
caution - confidence
0.8 - created-at
2026-03-02T17:00:00Z - expires-at
2026-03-02T18:00:00Z - scope
cross-domain-task-routing - explanation-code
policy-violation-recent
8.2 Non-Normative Multi-Issuer Conflict Example
Issuer A sends a fresh level=trusted assertion with confidence 0.6 for a subject in scope document-translation. Issuer B sends a newer level=caution assertion with confidence 0.9 in the same scope, referencing a recent attestation downgrade. This document does not require one aggregation outcome. It does require that the relying party preserve issuer identity, freshness, scope, and confidence rather than collapsing the two assertions into an unexplained average.
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 clearly expired portable trust assertions MUST be rejected as valid current input.
Colluding issuers can amplify false claims. This document does not solve collusion, but it reduces ambiguity by requiring issuer identification, scope, confidence, and model identification. 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 portable 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 model identifiers, trust-event categories, 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.