80 lines
3.0 KiB
Markdown
80 lines
3.0 KiB
Markdown
# Draft Outline
|
|
|
|
## Abstract
|
|
|
|
State that the document defines experimental semantics for exchanging dynamic trust assertions and trust-relevant runtime events in multi-agent systems. Make clear that the mechanism supplements, but does not replace, identity, attestation, and authorization.
|
|
|
|
## Section plan
|
|
|
|
1. Introduction
|
|
2. Terminology
|
|
3. Problem Statement and Design Goals
|
|
4. Trust Model Overview
|
|
5. Trust Events
|
|
6. Trust Assertions
|
|
7. Freshness, Confidence, and Revocation
|
|
8. Receiver Processing and Policy Boundaries
|
|
9. Security Considerations
|
|
10. Privacy Considerations
|
|
11. IANA Considerations
|
|
12. References
|
|
|
|
## Author guidance by section
|
|
|
|
### 1. Introduction
|
|
|
|
Anchor the problem in long-running agent interactions where static identity is insufficient. Avoid implying that trust scores solve security by themselves.
|
|
|
|
### 2. Terminology
|
|
|
|
Define trust event, trust assertion, issuer, subject, confidence, freshness, scope, evidence reference, and revocation. Be disciplined about these distinctions.
|
|
|
|
### 3. Problem Statement and Design Goals
|
|
|
|
Explain the gap between static authentication and runtime trust decisions. State that the document aims to standardize representation and exchange, not one universal scoring algorithm.
|
|
|
|
### 4. Trust Model Overview
|
|
|
|
Show the layering clearly: identity and attestation remain below; trust assertions sit above them as supplemental runtime signals interpreted by local policy.
|
|
|
|
### 5. Trust Events
|
|
|
|
Define the observable events that can feed trust changes. Avoid overloading this section with algorithmic scoring guidance.
|
|
|
|
### 6. Trust Assertions
|
|
|
|
Define the required fields of a portable trust assertion and how issuer, subject, scope, confidence, and statement value are represented.
|
|
|
|
### 7. Freshness, Confidence, and Revocation
|
|
|
|
This is the core interoperability section. Be precise about expiry, supersession, stale data, and the difference between confidence and trust value.
|
|
|
|
### 8. Receiver Processing and Policy Boundaries
|
|
|
|
Explain what a receiver may infer and what remains local policy. This section must prevent readers from treating portable trust as universal authorization.
|
|
|
|
### 9. Security Considerations
|
|
|
|
Address poisoning, collusion, replay, spoofing, and misuse of trust assertions in access-control flows.
|
|
|
|
### 10. Privacy Considerations
|
|
|
|
Address cross-domain disclosure of incidents, behavior, and negative assertions.
|
|
|
|
### 11. IANA Considerations
|
|
|
|
Either no action or minimal registries for event types and assertion models.
|
|
|
|
### 12. References
|
|
|
|
Keep placeholders if needed, but cite adjacent attestation, accountability, and evidence-bearing drafts that influenced the layering.
|
|
|
|
## Issues that must not be hand-waved
|
|
|
|
- whether trust assertions are scoped issuer opinions or universal facts
|
|
- how freshness and expiry are represented
|
|
- how revocation or supersession works
|
|
- how confidence differs from trust value
|
|
- what evidence reference means and when it is optional
|
|
- how receivers avoid using trust as a drop-in replacement for authorization
|