114 lines
4.3 KiB
Markdown
114 lines
4.3 KiB
Markdown
# 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?
|