feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,79 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user