# 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:

1. a trust event record
2. 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?