Architecture Brief

Scope

Define an experimental, interoperable representation for dynamic trust information exchanged between agents or agent-adjacent services. The draft should standardize:

trust event vocabulary
trust assertion envelope
issuer, subject, scope, freshness, and confidence semantics
expiry or revocation behavior
minimal rules for how receivers interpret portable trust information

The document should remain supplemental to identity, attestation, and authorization systems.

Non-goals

creating a global reputation network or universal score
replacing authentication, attestation, or authorization
standardizing all behavior-verification evidence formats
requiring a single scoring algorithm
defining economic incentives, penalties, or marketplace reputation

Terminology and actors

trust event: an observed runtime occurrence relevant to trust assessment
trust assertion: a structured statement by an issuer about a subject's trust-relevant state
issuer: the party making the assertion
subject: the agent or service described by the assertion
confidence: how strongly the issuer stands behind the assertion
freshness: how current the assertion is and how long it remains usable
scope: the context in which the assertion is intended to apply
evidence reference: pointer to supporting execution, attestation, or compliance evidence
revocation: withdrawal or supersession of a prior trust assertion

Actors:

observing agent or service
trust assertion issuer
relying party that consumes trust information
optional policy authority governing how trust affects decisions

Protocol or data model shape

Use two related objects:

a trust event record
a trust assertion

Trust event record minimum fields:

event identifier
subject identifier
issuer or observer identifier
event type
timestamp
scope

Trust assertion minimum fields:

assertion identifier
subject identifier
issuer identifier
trust statement value
confidence value
freshness or expiry information
scope

Optional fields:

evidence reference
delta-from-prior assertion
revokes or supersedes assertion identifier
explanation code

Design choice: do not require one numeric scoring model. Allow bounded levels, numeric values, or deltas as long as the representation states which model is being used and how confidence and expiry apply.

Normative requirements candidates

A trust assertion MUST identify both issuer and subject.
A trust assertion MUST indicate scope and freshness.
A trust assertion MUST NOT be treated as a substitute for authentication or authorization.
If a trust assertion supersedes or revokes a prior assertion, it MUST identify the prior assertion.
Receivers MUST be able to distinguish portable trust assertions from local-only trust state.
Trust assertions SHOULD include evidence references when the underlying evidence is available and shareable.
Implementations SHOULD define local policy for how negative assertions are consumed; this document should not hardcode one response.
Issuers MUST NOT present stale assertions as current.

Security, privacy, and abuse considerations

false negative or false positive trust assertions can manipulate routing or authorization decisions
colluding issuers could amplify reputational poisoning
replayed stale assertions can preserve obsolete trust
over-shared negative trust information can leak sensitive incident details
portable trust data may be misread as global truth rather than scoped issuer opinion

The draft should strongly emphasize that trust assertions are context-bound statements requiring authenticated origin, explicit freshness, and local policy interpretation.

IANA impact

Potentially small registries only if needed by implementation experience:

trust event types
trust assertion statement models
explanation codes

Avoid large registries or score semantics that imply false precision.

Open design questions

Should the primary trust statement model be level-based, numeric, delta-based, or model-agnostic?
How much explanation should be mandatory when sharing negative trust?
How should a receiver compare assertions from different issuers with different confidence models?
Should revocation be a first-class assertion type or simply a superseding assertion?

4.3 KiB Raw Blame History